]> rtime.felk.cvut.cz Git - l4.git/blob - l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/ext/lwg-defects.html
update
[l4.git] / l4 / pkg / libstdc++-v3 / contrib / libstdc++-v3-4.7 / doc / html / ext / lwg-defects.html
1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2 <!-- saved from url=(0060)http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html -->
3 <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
4 <title>C++ Standard Library Defect Report 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">D3182=10-0172</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 Defect Report 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-closed.html">Library Closed Issues List</a></li>
50     </ul>
51   <p>This document contains only library issues which have been closed
52   by the Library Working Group (LWG) after being found to be defects
53   in the standard.  That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>,
54   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
55   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
56   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
57   introductory material in that document also applies to this
58   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>Defect Reports</h2>
1103 <hr>
1104 <h3><a name="1"></a>1. C library linkage editing oversight</h3>
1105 <p><b>Section:</b> 17.6.2.3 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1106  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <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#TC1">TC1</a> status.</p>
1108 <p><b>Discussion:</b></p>
1109 <p>The change specified in the proposed resolution below did not make
1110 it into the Standard. This change was accepted in principle at the
1111 London meeting, and the exact wording below was accepted at the
1112 Morristown meeting.</p>
1113
1114
1115 <p><b>Proposed resolution:</b></p>
1116 <p>Change 17.6.2.3 [using.linkage] paragraph 2
1117 from:</p>
1118
1119 <blockquote>
1120   <p>It is unspecified whether a name from the Standard C library
1121   declared with external linkage has either extern "C" or
1122   extern "C++" linkage.</p>
1123 </blockquote>
1124
1125 <p>to:</p>
1126
1127 <blockquote>
1128   <p>Whether a name from the Standard C library declared with external
1129   linkage has extern "C" or extern "C++" linkage
1130   is implementation defined. It is recommended that an implementation
1131   use extern "C++" linkage for this purpose.</p>
1132 </blockquote>
1133
1134
1135
1136
1137
1138 <hr>
1139 <h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
1140 <p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1141  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1997-12-12 <b>Last modified:</b> 2010-10-29</p>
1142 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
1143 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1144 <p><b>Discussion:</b></p>
1145 <p>We appear not to have covered all the possibilities of
1146  exit processing with respect to
1147 atexit registration. <br>
1148 <br>
1149 Example 1: (C and C++)</p>
1150
1151 <pre>    #include &lt;stdlib.h&gt;
1152     void f1() { }
1153     void f2() { atexit(f1); }
1154     
1155     int main()
1156     {
1157         atexit(f2); // the only use of f2
1158         return 0; // for C compatibility
1159     }</pre>
1160
1161 <p>At program exit, f2 gets called due to its registration in
1162 main. Running f2 causes f1 to be newly registered during the exit
1163 processing. Is this a valid program? If so, what are its
1164 semantics?</p>
1165
1166 <p>
1167 Interestingly, neither the C standard, nor the C++ draft standard nor
1168 the forthcoming C9X Committee Draft says directly whether you can
1169 register a function with atexit during exit processing.</p>
1170
1171 <p>
1172 All 3 standards say that functions are run in reverse order of their
1173 registration. Since f1 is registered last, it ought to be run first,
1174 but by the time it is registered, it is too late to be first.</p>
1175
1176 <p>If the program is valid, the standards are self-contradictory about
1177 its semantics.</p>
1178
1179 <p>Example 2: (C++ only)</p>
1180
1181 <pre>    
1182     void F() { static T t; } // type T has a destructor
1183
1184     int main()
1185     {
1186         atexit(F); // the only use of F
1187     }
1188 </pre>
1189
1190 <p>Function F registered with atexit has a local static variable t,
1191 and F is called for the first time during exit processing. A local
1192 static object is initialized the first time control flow passes
1193 through its definition, and all static objects are destroyed during
1194 exit processing. Is the code valid? If so, what are its semantics?</p>
1195
1196 <p>
1197 Section 18.3 "Start and termination" says that if a function
1198 F is registered with atexit before a static object t is initialized, F
1199 will not be called until after t's destructor completes.</p>
1200
1201 <p>
1202 In example 2, function F is registered with atexit before its local
1203 static object O could possibly be initialized. On that basis, it must
1204 not be called by exit processing until after O's destructor
1205 completes. But the destructor cannot be run until after F is called,
1206 since otherwise the object could not be constructed in the first
1207 place.</p>
1208
1209 <p>If the program is valid, the standard is self-contradictory about
1210 its semantics.</p>
1211
1212 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
1213 a recommendation that the results be undefined. (Alternative: make it
1214 unspecified. I don't think it is worthwhile to specify the case where
1215 f1 itself registers additional functions, each of which registers
1216 still more functions.)</p>
1217
1218 <p>I think we should resolve the situation in the whatever way the C
1219 committee decides. </p>
1220
1221 <p>For Example 2, I recommend we declare the results undefined.</p>
1222
1223 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
1224
1225
1226
1227
1228 <p><b>Proposed resolution:</b></p>
1229 <p>Change section 18.3/8 from:</p>
1230 <blockquote><p>
1231   First, objects with static storage duration are destroyed and
1232   functions registered by calling atexit are called. Objects with
1233   static storage duration are destroyed in the reverse order of the
1234   completion of their constructor.  (Automatic objects are not
1235   destroyed as a result of calling exit().) Functions registered with
1236   atexit are called in the reverse order of their registration.  A
1237   function registered with atexit before an object obj1 of static
1238   storage duration is initialized will not be called until obj1's
1239   destruction has completed. A function registered with atexit after
1240   an object obj2 of static storage duration is initialized will be
1241   called before obj2's destruction starts.
1242 </p></blockquote>
1243 <p>to:</p>
1244 <blockquote><p>
1245   First, objects with static storage duration are destroyed and
1246   functions registered by calling atexit are called. Non-local objects
1247   with static storage duration are destroyed in the reverse order of
1248   the completion of their constructor. (Automatic objects are not
1249   destroyed as a result of calling exit().) Functions registered with
1250   atexit are called in the reverse order of their registration, except
1251   that a function is called after any previously registered functions
1252   that had already been called at the time it was registered. A
1253   function registered with atexit before a non-local object obj1 of
1254   static storage duration is initialized will not be called until
1255   obj1's destruction has completed. A function registered with atexit
1256   after a non-local object obj2 of static storage duration is
1257   initialized will be called before obj2's destruction starts. A local
1258   static object obj3 is destroyed at the same time it would be if a
1259   function calling the obj3 destructor were registered with atexit at
1260   the completion of the obj3 constructor.
1261 </p></blockquote>
1262
1263
1264 <p><b>Rationale:</b></p>
1265 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
1266 supporting to the proposed resolution.</p>
1267
1268
1269
1270
1271
1272 <hr>
1273 <h3><a name="5"></a>5. String::compare specification questionable</h3>
1274 <p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1275  <b>Submitter:</b> Jack Reeves <b>Opened:</b> 1997-12-11 <b>Last modified:</b> 2010-10-29</p>
1276 <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>
1277 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1278 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
1279 <p><b>Discussion:</b></p>
1280 <p>At the very end of the basic_string class definition is the signature: int
1281 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
1282 following text this is defined as: returns
1283 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
1284 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
1285
1286 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
1287 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
1288 throws length_error if n == npos, it appears the compare() signature above should always
1289 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
1290 null terminated character array. </p>
1291
1292 <p>This appears to be a typo since the obvious intent is to allow either the call above or
1293 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
1294
1295 <p>This would imply that what was really intended was two signatures int compare(size_type
1296 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
1297 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
1298
1299
1300 <p><b>Proposed resolution:</b></p>
1301 <p>Replace the compare signature in 21.4 [basic.string]
1302 (at the very end of the basic_string synopsis) which reads:</p>
1303
1304 <blockquote>
1305   <p><tt>int compare(size_type pos1, size_type n1,<br>
1306   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
1307   size_type n2 = npos) const;</tt></p>
1308 </blockquote>
1309
1310 <p>with:</p>
1311
1312 <blockquote>
1313   <p><tt>int compare(size_type pos1, size_type n1,<br>
1314   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
1315   int compare(size_type pos1, size_type n1,<br>
1316   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
1317   size_type n2) const;</tt></p>
1318 </blockquote>
1319
1320 <p>Replace the portion of 21.4.6.8 [string::swap]
1321 paragraphs 5 and 6 which read:</p>
1322
1323 <blockquote>
1324   <p><tt>int compare(size_type pos, size_type n1,<br>
1325   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
1326   = npos) const;<br>
1327   </tt>Returns:<tt><br>
1328   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1329   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1330   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
1331 </blockquote>
1332
1333 <p>with:</p>
1334
1335 <blockquote>
1336   <p><tt>int compare(size_type pos, size_type n1,<br>
1337   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
1338   </tt>Returns:<tt><br>
1339   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1340   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1341   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
1342   <br>
1343   int compare(size_type pos, size_type n1,<br>
1344   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
1345   size_type n2) const;<br>
1346   </tt>Returns:<tt><br>
1347   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1348   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1349   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
1350 </blockquote>
1351
1352 <p>Editors please note that in addition to splitting the signature, the third argument
1353 becomes const, matching the existing synopsis.</p>
1354
1355
1356 <p><b>Rationale:</b></p>
1357 <p>While the LWG dislikes adding signatures, this is a clear defect in
1358 the Standard which must be fixed.&nbsp; The same problem was also
1359 identified in issues 7 (item 5) and 87.</p>
1360
1361
1362
1363
1364
1365 <hr>
1366 <h3><a name="7"></a>7. String clause minor problems</h3>
1367 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1368  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2010-10-29</p>
1369 <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>
1370 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1371 <p><b>Discussion:</b></p>
1372 <p>(1) In 21.4.6.4 [string::insert], the description of template
1373 &lt;class InputIterator&gt; insert(iterator, InputIterator,
1374 InputIterator) makes no sense. It refers to a member function that
1375 doesn't exist. It also talks about the return value of a void
1376 function. </p>
1377
1378 <p>(2) Several versions of basic_string::replace don't appear in the
1379 class synopsis. </p>
1380
1381 <p>(3) basic_string::push_back appears in the synopsis, but is never
1382 described elsewhere.  In the synopsis its argument is const charT,
1383 which doesn't makes much sense; it should probably be charT, or
1384 possible const charT&amp;. </p>
1385
1386 <p>(4) basic_string::pop_back is missing. </p>
1387
1388 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
1389 = npos) make no sense. First, it's const charT* in the synopsis and
1390 charT* in the description. Second, given what it says in RETURNS,
1391 leaving out the final argument will always result in an exception
1392 getting thrown. This is paragraphs 5 and 6 of 
1393 21.4.6.8 [string::swap]</p>
1394
1395 <p>(6) In table 37, in section 21.2.1 [char.traits.require],
1396 there's a note for X::move(s, p, n). It says "Copies correctly
1397 even where p is in [s, s+n)". This is correct as far as it goes,
1398 but it doesn't go far enough; it should also guarantee that the copy
1399 is correct even where s in in [p, p+n). These are two orthogonal
1400 guarantees, and neither one follows from the other. Both guarantees
1401 are necessary if X::move is supposed to have the same sort of
1402 semantics as memmove (which was clearly the intent), and both
1403 guarantees are necessary if X::move is actually supposed to be
1404 useful. </p>
1405
1406
1407 <p><b>Proposed resolution:</b></p>
1408 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
1409 <br>
1410 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
1411 <br>
1412 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
1413 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
1414 <br>
1415 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
1416 [lib.basic.string]) from:</p>
1417
1418 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
1419 <br>
1420 to<br>
1421 <br>
1422 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
1423 <br>
1424 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
1425 <br>
1426 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
1427 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
1428 <br>
1429 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
1430 <br>
1431 ITEM 5: Duplicate; see issue 5 (and 87).<br>
1432 <br>
1433 ITEM 6: In table 37, Replace:<br>
1434 <br>
1435 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
1436 <br>
1437 with:<br>
1438 <br>
1439 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
1440 s+n) overlap."</p>
1441
1442
1443
1444
1445
1446 <hr>
1447 <h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
1448 <p><b>Section:</b> 22.3.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1449  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-24 <b>Last modified:</b> 2010-10-29</p>
1450 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1451 <p><b>Discussion:</b></p>
1452 <p>It appears there's an important guarantee missing from clause
1453 22. We're told that invoking locale::global(L) sets the C locale if L
1454 has a name. However, we're not told whether or not invoking
1455 setlocale(s) sets the global C++ locale. </p>
1456
1457 <p>The intent, I think, is that it should not, but I can't find any
1458 such words anywhere. </p>
1459
1460
1461 <p><b>Proposed resolution:</b></p>
1462 <p>Add a sentence at the end of 22.3.1.5 [locale.statics],
1463 paragraph 2:&nbsp; </p>
1464
1465 <blockquote>
1466   <p>No library function other than <tt>locale::global()</tt> shall affect 
1467   the value returned by <tt>locale()</tt>. </p>
1468
1469 </blockquote>
1470
1471
1472
1473
1474
1475 <hr>
1476 <h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
1477 <p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1478  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-01-04 <b>Last modified:</b> 2010-10-29</p>
1479 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
1480 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1481 <p><b>Discussion:</b></p>
1482 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
1483 section 3.7.3.1 of CD2 seems to allow for the possibility that all
1484 calls to operator new(0) yield the same pointer, an implementation
1485 technique specifically prohibited by ARM 5.3.3.Was this prohibition
1486 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
1487 list maintainer's note: the IS is the same.]</p>
1488
1489
1490 <p><b>Proposed resolution:</b></p>
1491 <p>Change the last paragraph of 3.7.3 from:</p>
1492 <blockquote>
1493   <p>Any allocation and/or deallocation functions defined in a C++ program shall
1494   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
1495 </blockquote>
1496 <p>to:</p>
1497 <blockquote>
1498   <p>Any allocation and/or deallocation functions defined in a C++ program,
1499   including the default versions in the library, shall conform to the semantics
1500   specified in 3.7.3.1 and 3.7.3.2.</p>
1501 </blockquote>
1502 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
1503 <blockquote>
1504   <p>If the size of the space requested is zero, the value returned shall not be
1505   a null pointer value (4.10).</p>
1506 </blockquote>
1507 <p>to:</p>
1508 <blockquote>
1509   <p>Even if the size of the space requested is zero, the request can fail. If
1510   the request succeeds, the value returned shall be a non-null pointer value
1511   (4.10) p0 different from any previously returned value p1, unless that value
1512   p1 was since passed to an operator delete.</p>
1513 </blockquote>
1514 <p>5.3.4/7 currently reads:</p>
1515 <blockquote>
1516   <p>When the value of the expression in a direct-new-declarator is zero, the
1517   allocation function is called to allocate an array with no elements. The
1518   pointer returned by the new-expression is non-null. [Note: If the library
1519   allocation function is called, the pointer returned is distinct from the
1520   pointer to any other object.]</p>
1521 </blockquote>
1522 <p>Retain the first sentence, and delete the remainder.</p>
1523 <p>18.5.1 currently has no text. Add the following:</p>
1524 <blockquote>
1525   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
1526   library versions of operator new and operator delete.</p>
1527 </blockquote>
1528 <p>To 18.5.1.3, add the following text:</p>
1529 <blockquote>
1530   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
1531   operator new and operator delete.</p>
1532 </blockquote>
1533
1534
1535 <p><b>Rationale:</b></p>
1536 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
1537 supporting to the proposed resolution.</p>
1538
1539
1540
1541
1542
1543 <hr>
1544 <h3><a name="11"></a>11. Bitset minor problems</h3>
1545 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1546  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2010-10-29</p>
1547 <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>
1548 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1549 <p><b>Discussion:</b></p>
1550 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
1551 not documented in 23.3.5.2. </p>
1552
1553 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
1554 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
1555 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
1556
1557 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
1558 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
1559 go in the Effects clause.</p>
1560
1561
1562 <p><b>Proposed resolution:</b></p>
1563 <p>ITEMS 1 AND 2:<br>
1564 <br>
1565 In the bitset synopsis (20.5 [template.bitset]), 
1566 replace the member function <br>
1567 <br>
1568 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
1569 </tt><br>
1570 with the two member functions<br>
1571 <br>
1572 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
1573 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
1574 </tt><br>
1575 Add the following text at the end of 20.5.2 [bitset.members], 
1576 immediately after paragraph 45:</p>
1577
1578 <blockquote>
1579   <p><tt>bool operator[](size_t pos) const;</tt><br>
1580   Requires: pos is valid<br>
1581   Throws: nothing<br>
1582   Returns: <tt>test(pos)</tt><br>
1583   <br>
1584   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
1585   Requires: pos is valid<br>
1586   Throws: nothing<br>
1587   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
1588   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
1589   val);</tt></p>
1590 </blockquote>
1591
1592
1593 <p><b>Rationale:</b></p>
1594 <p>The LWG believes Item 3 is not a defect. "Formatted
1595 input" implies the desired semantics. See 27.7.1.2 [istream.formatted].
1596 </p>
1597
1598
1599
1600
1601
1602 <hr>
1603 <h3><a name="13"></a>13. Eos refuses to die</h3>
1604 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1605  <b>Submitter:</b> William M. Miller <b>Opened:</b> 1998-03-03 <b>Last modified:</b> 2010-10-29</p>
1606 <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>
1607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1608 <p><b>Discussion:</b></p>
1609 <p>In 27.6.1.2.3, there is a reference to "eos", which is
1610 the only one in the whole draft (at least using Acrobat search), so
1611 it's undefined. </p>
1612
1613
1614 <p><b>Proposed resolution:</b></p>
1615 <p>In 27.7.1.2.3 [istream::extractors], replace "eos" with
1616 "charT()"</p>
1617
1618
1619
1620
1621
1622 <hr>
1623 <h3><a name="14"></a>14. Locale::combine should be const</h3>
1624 <p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1625  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1626 <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>
1627 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1628 <p><b>Discussion:</b></p>
1629 <p>locale::combine is the only member function of locale (other than constructors and
1630 destructor) that is not const. There is no reason for it not to be const, and good reasons
1631 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
1632 paragraph 6: "An instance of a locale is immutable." </p>
1633
1634 <p>History: this member function originally was a constructor. it happened that the
1635 interface it specified had no corresponding language syntax, so it was changed to a member
1636 function. As constructors are never const, there was no "const" in the interface
1637 which was transformed into member "combine". It should have been added at that
1638 time, but the omission was not noticed. </p>
1639
1640
1641 <p><b>Proposed resolution:</b></p>
1642 <p>In 22.3.1 [locale] and also in 22.3.1.3 [locale.members], add 
1643 "const" to the declaration of member combine: </p>
1644 <blockquote>
1645   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
1646 </blockquote>
1647
1648
1649
1650
1651
1652 <hr>
1653 <h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
1654 <p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1655  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1656 <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>
1657 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1658 <p><b>Discussion:</b></p>
1659 <p>locale::name() is described as returning a string that can be passed to a locale
1660 constructor, but there is no matching constructor. </p>
1661
1662
1663 <p><b>Proposed resolution:</b></p>
1664 <p>In 22.3.1.3 [locale.members], paragraph 5, replace
1665 "<tt>locale(name())</tt>" with
1666 "<tt>locale(name().c_str())</tt>".
1667 </p>
1668
1669
1670
1671
1672
1673 <hr>
1674 <h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
1675 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1676  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1677 <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>
1678 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1679 <p><b>Discussion:</b></p>
1680 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
1681 edited in properly. Instead, the member do_widen appears four times, with wrong argument
1682 lists. </p>
1683
1684
1685 <p><b>Proposed resolution:</b></p>
1686 <p>The correct declarations for the overloaded members
1687 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied 
1688 from 22.4.1.3 [facet.ctype.special].</p>
1689
1690
1691
1692
1693
1694 <hr>
1695 <h3><a name="17"></a>17. Bad bool parsing</h3>
1696 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1697  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1698 <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>
1699 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1700 <p><b>Discussion:</b></p>
1701 <p>This section describes the process of parsing a text boolean value from the input
1702 stream. It does not say it recognizes either of the sequences "true" or
1703 "false" and returns the corresponding bool value; instead, it says it recognizes
1704 only one of those sequences, and chooses which according to the received value of a
1705 reference argument intended for returning the result, and reports an error if the other
1706 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
1707 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
1708 flag wrongly; it doesn't define the value "loc"; and finally, it computes
1709 wrongly whether to use numeric or "alpha" parsing.<br>
1710 <br>
1711 I believe the correct algorithm is "as if": </p>
1712
1713 <pre>  // in, err, val, and str are arguments.
1714   err = 0;
1715   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
1716   const string_type t = np.truename(), f = np.falsename();
1717   bool tm = true, fm = true;
1718   size_t pos = 0;
1719   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
1720     if (in == end) { err = str.eofbit; }
1721     bool matched = false;
1722     if (tm &amp;&amp; pos &lt; t.size()) {
1723       if (!err &amp;&amp; t[pos] == *in) matched = true;
1724       else tm = false;
1725     }
1726     if (fm &amp;&amp; pos &lt; f.size()) {
1727       if (!err &amp;&amp; f[pos] == *in) matched = true;
1728       else fm = false;
1729     }
1730     if (matched) { ++in; ++pos; }
1731     if (pos &gt; t.size()) tm = false;
1732     if (pos &gt; f.size()) fm = false;
1733   }
1734   if (tm == fm || pos == 0) { err |= str.failbit; }
1735   else                      { val = tm; }
1736   return in;</pre>
1737
1738 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
1739 when one is a substring of the other. The proposed text below captures the logic of the
1740 code above.</p>
1741
1742
1743 <p><b>Proposed resolution:</b></p>
1744 <p>In 22.4.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
1745 change "&amp;&amp;" to "&amp;".</p>
1746
1747 <p>Then, replace paragraphs 15 and 16 as follows:</p>
1748
1749 <blockquote>
1750
1751   <p>Otherwise target sequences are determined "as if" by
1752   calling the members <tt>falsename()</tt> and
1753   <tt>truename()</tt> of the facet obtained by
1754   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.  
1755   Successive characters in the range <tt>[in,end)</tt> (see
1756   [lib.sequence.reqmts]) are obtained and matched against
1757   corresponding positions in the target sequences only as necessary to
1758   identify a unique match. The input iterator <tt>in</tt> is
1759   compared to <tt>end</tt> only when necessary to obtain a
1760   character. If and only if a target sequence is uniquely matched,
1761   <tt>val</tt> is set to the corresponding value.</p>
1762
1763 </blockquote>
1764
1765 <blockquote>
1766   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
1767   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
1768   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
1769   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
1770   <tt>(str.failbit|str.eofbit)</tt>if
1771   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
1772   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
1773   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
1774   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
1775   <tt>true</tt>:"1"
1776   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
1777   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
1778   <tt>err==str.failbit</tt>. --end example]</p>
1779 </blockquote>
1780
1781
1782
1783
1784
1785 <hr>
1786 <h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
1787 <p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1788  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1789 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
1790 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1791 <p><b>Discussion:</b></p>
1792 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
1793 that parses bool values was omitted from the list of definitions of non-virtual
1794 members, though it is listed in the class definition and the corresponding
1795 virtual is listed everywhere appropriate. </p>
1796
1797
1798 <p><b>Proposed resolution:</b></p>
1799 <p>Add at the beginning of 22.4.2.1.1 [facet.num.get.members]
1800 another get member for bool&amp;, copied from the entry in 
1801 22.4.2.1 [locale.num.get].</p>
1802
1803
1804
1805
1806
1807 <hr>
1808 <h3><a name="19"></a>19. "Noconv" definition too vague</h3>
1809 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1810  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1811 <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>
1812 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1813 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
1814 <p><b>Discussion:</b></p>
1815 <p>
1816 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
1817 specified to return noconv if "no conversion is
1818 needed". This definition is too vague, and does not say
1819 normatively what is done with the buffers.
1820 </p>
1821
1822
1823 <p><b>Proposed resolution:</b></p>
1824 <p>
1825 Change the entry for noconv in the table under paragraph 4 in section 
1826 22.4.1.4.2 [locale.codecvt.virtuals] to read:
1827 </p>
1828 <blockquote>
1829   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
1830   and input sequence is identical to converted sequence.</p>
1831 </blockquote>
1832 <p>Change the Note in paragraph 2 to normative text as follows:</p>
1833 <blockquote>
1834   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
1835   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
1836   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
1837   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
1838 </blockquote>
1839
1840
1841
1842
1843
1844 <hr>
1845 <h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
1846 <p><b>Section:</b> 22.4.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1847  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1849 <p><b>Discussion:</b></p>
1850 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
1851 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
1852 that it returns a value of type char_type. Here it is erroneously
1853 described as returning a "string_type". </p>
1854
1855
1856 <p><b>Proposed resolution:</b></p>
1857 <p>In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change 
1858 "string_type" to "char_type". </p>
1859
1860
1861
1862
1863
1864 <hr>
1865 <h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
1866 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1867  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1868 <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>
1869 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1870 <p><b>Discussion:</b></p>
1871 <p>In the second table in the section, captioned "Required
1872 instantiations", the instantiations for codecvt_byname&lt;&gt;
1873 have been omitted. These are necessary to allow users to construct a
1874 locale by name from facets. </p>
1875
1876
1877 <p><b>Proposed resolution:</b></p>
1878 <p>Add in 22.3.1.1.1 [locale.category] to the table captioned
1879 "Required instantiations", in the category "ctype"
1880 the lines </p>
1881
1882 <blockquote>
1883   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
1884 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
1885 </blockquote>
1886
1887
1888
1889
1890
1891 <hr>
1892 <h3><a name="22"></a>22. Member open vs. flags</h3>
1893 <p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1894  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1895 <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>
1896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
1897 <p><b>Discussion:</b></p>
1898 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
1899 responds to or changes flags in the error status for the stream. A strict reading
1900 indicates that it ignores the bits and does not change them, which confuses users who do
1901 not expect eofbit and failbit to remain set after a successful open. There are three
1902 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
1903 and eofbit on call to open(). </p>
1904
1905
1906 <p><b>Proposed resolution:</b></p>
1907 <p>In 27.9.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.9.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
1908 </p>
1909
1910 <blockquote>
1911   <p>A successful open does not change the error state.</p>
1912 </blockquote>
1913
1914
1915 <p><b>Rationale:</b></p>
1916 <p>This may seem surprising to some users, but it's just an instance
1917 of a general rule: error flags are never cleared by the
1918 implementation. The only way error flags are are ever cleared is if
1919 the user explicitly clears them by hand.</p>
1920
1921 <p>The LWG believed that preserving this general rule was
1922 important enough so that an exception shouldn't be made just for this
1923 one case.  The resolution of this issue clarifies what the LWG
1924 believes to have been the original intent.</p>
1925
1926
1927
1928
1929
1930
1931 <hr>
1932 <h3><a name="23"></a>23. Num_get overflow result</h3>
1933 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
1934  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
1935 <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>
1936 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
1937 <p><b>Discussion:</b></p>
1938 <p>The current description of numeric input does not account for the
1939 possibility of overflow. This is an implicit result of changing the
1940 description to rely on the definition of scanf() (which fails to
1941 report overflow), and conflicts with the documented behavior of
1942 traditional and current implementations. </p>
1943
1944 <p>Users expect, when reading a character sequence that results in a
1945 value unrepresentable in the specified type, to have an error
1946 reported. The standard as written does not permit this. </p>
1947
1948 <p><b>Further comments from Dietmar:</b></p>
1949
1950 <p>
1951 I don't feel comfortable with the proposed resolution to issue 23: It
1952 kind of simplifies the issue to much. Here is what is going on:
1953 </p>
1954
1955 <p>
1956 Currently, the behavior of numeric overflow is rather counter intuitive
1957 and hard to trace, so I will describe it briefly:
1958 </p>
1959
1960 <ul>
1961   <li>
1962     According to 22.4.2.1.2 [facet.num.get.virtuals]
1963     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
1964     return an input error; otherwise a value is converted to the rules
1965     of <tt>scanf</tt>.
1966   </li>
1967   <li> 
1968     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. 
1969   </li>
1970   <li>
1971     <tt>fscanf()</tt> returns an input failure if during conversion no
1972     character matching the conversion specification could be extracted
1973     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
1974     to fail due to an input error and clearly does not apply to the case
1975     of overflow.
1976   </li>
1977   <li>
1978     Thus, the conversion is performed according to the rules of
1979     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
1980     <tt>strtol()</tt>, etc. are to be used for the conversion.
1981   </li>
1982   <li>
1983     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
1984     many matching characters as there are and on overflow continue to
1985     consume matching characters but also return a value identical to
1986     the maximum (or minimum for signed types if there was a leading minus)
1987     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
1988   </li>
1989   <li>
1990     Thus, according to the current wording in the standard, overflows
1991     can be detected! All what is to be done is to check <tt>errno</tt>
1992     after reading an element and, of course, clearing <tt>errno</tt>
1993     before trying a conversion. With the current wording, it can be
1994     detected whether the overflow was due to a positive or negative
1995     number for signed types.
1996   </li>
1997 </ul>
1998
1999 <p><b>Further discussion from Redmond:</b></p>
2000
2001 <p>The basic problem is that we've defined our behavior,
2002 including our error-reporting behavior, in terms of C90.  However,
2003 C90's method of reporting overflow in scanf is not technically an
2004 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
2005
2006 <p>There was general consensus that <tt>failbit</tt> should be set
2007 upon overflow.  We considered three options based on this:</p>
2008 <ol>
2009 <li>Set failbit upon conversion error (including overflow), and 
2010     don't store any value.</li>
2011 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to 
2012     indicated the precise nature of the error.</li>
2013 <li>Set failbit upon conversion error.  If the error was due to
2014     overflow, store +-numeric_limits&lt;T&gt;::max() as an
2015     overflow indication.</li>
2016 </ol>
2017
2018 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
2019
2020
2021 <p>Discussed at Lillehammer.  General outline of what we want the
2022   solution to look like: we want to say that overflow is an error, and
2023   provide a way to distinguish overflow from other kinds of errors.
2024   Choose candidate field the same way scanf does, but don't describe
2025   the rest of the process in terms of format.  If a finite input field
2026   is too large (positive or negative) to be represented as a finite
2027   value, then set failbit and assign the nearest representable value.
2028   Bill will provide wording.</p>
2029
2030 <p>
2031 Discussed at Toronto:
2032 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
2033 is in alignment with the direction we wanted to go with in Lillehammer.  Bill
2034 to work on.
2035 </p>
2036
2037
2038
2039 <p><b>Proposed resolution:</b></p>
2040
2041 <p>
2042 Change 22.4.2.1.2 [facet.num.get.virtuals], end of p3:
2043 </p>
2044
2045 <blockquote>
2046 <p>
2047 <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
2048 <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
2049 converted to a numeric value by the rules of one of the functions declared
2050 in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
2051 </p>
2052 <ul>
2053 <li>
2054 <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
2055 converted (according to the rules of <tt>scanf</tt>) to a value of the
2056 type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
2057 stored in <i>err</i>.</del>
2058 <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
2059 </li>
2060 <li>
2061 <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
2062 <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
2063 assigned to <i>err</i>.</del>
2064 <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
2065 </li>
2066 <li>
2067 <ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
2068 </li>
2069 </ul>
2070 <p>
2071 <ins>The numeric value to be stored can be one of:</ins>
2072 </p>
2073 <ul>
2074 <li><ins>zero, if the conversion function fails to convert the entire field.
2075 <tt>ios_base::failbit</tt> is assigned to err.</ins></li>
2076 <li><ins>the most positive representable value, if the field represents a value
2077 too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
2078 to <i>err</i>.</ins></li>
2079 <li><ins>the most negative representable value (zero for unsigned integer), if
2080 the field represents a value too large negative to be represented in <i>val</i>.
2081 <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
2082 <li><ins>the converted value, otherwise.</ins></li>
2083 </ul>
2084
2085 <p><ins>
2086 The resultant numeric value is stored in <i>val</i>.
2087 </ins></p>
2088 </blockquote>
2089
2090 <p>
2091 Change 22.4.2.1.2 [facet.num.get.virtuals], p6-p7:
2092 </p>
2093
2094 <blockquote>
2095 <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>, 
2096                  ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
2097 </pre>
2098 <blockquote>
2099 <p>
2100 -6- <i>Effects:</i> If
2101 <tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
2102 proceeds as it would for a <tt>long</tt> except that if a value is being
2103 stored into <i>val</i>, the value is determined according to the
2104 following: If the value to be stored is 0 then <tt>false</tt> is stored.
2105 If the value is 1 then <tt>true</tt> is stored. Otherwise
2106 <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
2107 stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
2108 </p>
2109 <p>
2110 -7- Otherwise target sequences are determined "as if" by calling the
2111 members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
2112 obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
2113 &gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
2114 <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
2115 against corresponding positions in the target sequences only as
2116 necessary to identify a unique match. The input iterator <i>in</i> is
2117 compared to <i>end</i> only when necessary to obtain a character. If <del>and
2118 only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
2119 corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
2120 is assigned to <i>err</i>.</ins>
2121 </p>
2122 </blockquote>
2123 </blockquote>
2124
2125
2126
2127
2128
2129 <hr>
2130 <h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
2131 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2132  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2133 <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>
2134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2135 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
2136 <p><b>Discussion:</b></p>
2137 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
2138 symbol "do_convert" which is not defined in the
2139 standard. This is a leftover from an edit, and should be "do_in
2140 and do_out". </p>
2141
2142
2143 <p><b>Proposed resolution:</b></p>
2144 <p>In 22.4.1.4 [locale.codecvt], paragraph 3, change
2145 "do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
2146 or do_out". </p>
2147
2148
2149
2150
2151
2152 <hr>
2153 <h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
2154 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2155  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2156 <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>
2157 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2158 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
2159 <p><b>Discussion:</b></p>
2160 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
2161 the smaller of os.width() and str.size(), to pad "as described in stage 3"
2162 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
2163
2164
2165 <p><b>Proposed resolution:</b></p>
2166 <p>Change 21.4.8.9 [string.io]  paragraph 4 from:<br>
2167 <br>
2168 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
2169 ..."<br>
2170 <br>
2171 to: <br>
2172 <br>
2173 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
2174 ..."</p>
2175
2176
2177
2178
2179
2180 <hr>
2181 <h3><a name="26"></a>26. Bad sentry example</h3>
2182 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2183  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2184 <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>
2185 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2186 <p><b>Discussion:</b></p>
2187 <p>In paragraph 6, the code in the example: </p>
2188
2189 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
2190   basic_istream&lt;charT,traits&gt;::sentry(
2191            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
2192       ...
2193       int_type c;
2194       typedef ctype&lt;charT&gt; ctype_type;
2195       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
2196       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2197         if (ctype.is(ctype.space,c)==0) {
2198           is.rdbuf()-&gt;sputbackc (c);
2199           break;
2200         }
2201       }
2202       ...
2203    }</pre>
2204
2205 <p>fails to demonstrate correct use of the facilities described. In
2206 particular, it fails to use traits operators, and specifies incorrect
2207 semantics. (E.g. it specifies skipping over the first character in the
2208 sequence without examining it.) </p>
2209
2210
2211 <p><b>Proposed resolution:</b></p>
2212 <p>Remove the example above from 27.7.1.1.3 [istream::sentry]
2213 paragraph 6.</p>
2214
2215
2216 <p><b>Rationale:</b></p>
2217 <p>The originally proposed replacement code for the example was not
2218 correct. The LWG tried in Kona and again in Tokyo to correct it
2219 without success. In Tokyo, an implementor reported that actual working
2220 code ran over one page in length and was quite complicated. The LWG
2221 decided that it would be counter-productive to include such a lengthy
2222 example, which might well still contain errors.</p>
2223
2224
2225
2226
2227
2228 <hr>
2229 <h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
2230 <p><b>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2231  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2232 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
2233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2234 <p><b>Discussion:</b></p>
2235 <p>The string::erase(iterator first, iterator last) is specified to return an element one
2236 place beyond the next element after the last one erased. E.g. for the string
2237 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
2238 while 'd' has not been erased. </p>
2239
2240
2241 <p><b>Proposed resolution:</b></p>
2242 <p>In 21.4.6.5 [string::erase], paragraph 10, change: </p>
2243
2244 <blockquote>
2245   <p>Returns: an iterator which points to the element immediately following _last_ prior to
2246   the element being erased. </p>
2247 </blockquote>
2248
2249 <p>to read </p>
2250
2251 <blockquote>
2252   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
2253   other elements being erased. </p>
2254 </blockquote>
2255
2256
2257
2258
2259
2260 <hr>
2261 <h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
2262 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2263  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2264 <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>
2265 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2266 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
2267 <p><b>Discussion:</b></p>
2268 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
2269 something very different from what was intended. Paragraph 4 says </p>
2270
2271 <blockquote>
2272   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
2273   table()[(unsigned char)*p]. </p>
2274 </blockquote>
2275
2276 <p>This is intended to copy the value indexed from table()[] into the place identified in
2277 vec[]. </p>
2278
2279
2280 <p><b>Proposed resolution:</b></p>
2281 <p>Change 22.4.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
2282
2283 <blockquote>
2284   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
2285   the value table()[(unsigned char)*p]. </p>
2286 </blockquote>
2287
2288
2289
2290
2291
2292 <hr>
2293 <h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
2294 <p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2295  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2296 <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>
2297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2298 <p><b>Discussion:</b></p>
2299 <p>Sections 27.4.1 [narrow.stream.objects] and 27.4.2 [wide.stream.objects] mention
2300 a function ios_base::init, which is not defined. Probably they mean
2301 basic_ios&lt;&gt;::init, defined in 27.5.4.1 [basic.ios.cons],
2302 paragraph 3. </p>
2303
2304
2305 <p><b>Proposed resolution:</b></p>
2306 <p>[R12: modified to include paragraph 5.]</p>
2307
2308 <p>In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
2309
2310 <blockquote>
2311   <p>ios_base::init </p>
2312 </blockquote>
2313
2314 <p>to </p>
2315
2316 <blockquote>
2317   <p>basic_ios&lt;char&gt;::init </p>
2318 </blockquote>
2319
2320 <p>Also, make a similar change in 27.4.2 [wide.stream.objects] except it
2321 should read </p>
2322
2323 <blockquote>
2324   <p>basic_ios&lt;wchar_t&gt;::init </p>
2325 </blockquote>
2326
2327
2328
2329
2330
2331 <hr>
2332 <h3><a name="30"></a>30. Wrong header for LC_*</h3>
2333 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2334  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2335 <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>
2336 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2337 <p><b>Discussion:</b></p>
2338 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
2339 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
2340
2341
2342 <p><b>Proposed resolution:</b></p>
2343 <p>In 22.3.1.1.1 [locale.category], paragraph 2, change
2344 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
2345
2346
2347
2348
2349
2350 <hr>
2351 <h3><a name="31"></a>31. Immutable locale values</h3>
2352 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2353  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2354 <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>
2355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2356 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
2357 <p><b>Discussion:</b></p>
2358 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
2359 <i>immutable</i>; once a facet reference is obtained from it,
2360 ...". This has caused some confusion, because locale variables
2361 are manifestly assignable. </p>
2362
2363
2364 <p><b>Proposed resolution:</b></p>
2365 <p>In 22.3.1 [locale] replace paragraph 6</p>
2366
2367 <blockquote>
2368   <p>An instance of <tt>locale</tt> is immutable; once a facet
2369   reference is obtained from it, that reference remains usable as long
2370   as the locale value itself exists.</p>
2371 </blockquote>
2372
2373 <p>with</p>
2374
2375 <blockquote>
2376   <p>Once a facet reference is obtained from a locale object by
2377   calling use_facet&lt;&gt;, that reference remains usable, and the
2378   results from member functions of it may be cached and re-used, as
2379   long as some locale object refers to that facet.</p>
2380 </blockquote>
2381
2382
2383
2384
2385
2386 <hr>
2387 <h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
2388 <p><b>Section:</b> 27.6.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2389  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2391 <p><b>Discussion:</b></p>
2392 <p>The description of the required state before calling virtual member
2393 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
2394 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
2395 Specifically, the latter says it calls pbackfail if: </p>
2396
2397 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
2398
2399 <p>where pbackfail claims to require: </p>
2400
2401 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
2402
2403 <p>It appears that the pbackfail description is wrong. </p>
2404
2405
2406 <p><b>Proposed resolution:</b></p>
2407 <p>In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
2408
2409 <blockquote>
2410   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
2411 </blockquote>
2412
2413 <p>to </p>
2414
2415 <blockquote>
2416   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
2417   </p>
2418 </blockquote>
2419
2420
2421 <p><b>Rationale:</b></p>
2422 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
2423 the argument value.</p>
2424
2425
2426
2427
2428
2429 <hr>
2430 <h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
2431 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2432  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2433 <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>
2434 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2435 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
2436 <p><b>Discussion:</b></p>
2437 <p>In the table defining the results from do_out and do_in, the specification for the
2438 result <i>error</i> says </p>
2439
2440 <blockquote>
2441   <p>encountered a from_type character it could not convert </p>
2442 </blockquote>
2443
2444 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
2445 an internT for do_out. </p>
2446
2447
2448 <p><b>Proposed resolution:</b></p>
2449 <p>In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
2450 in the table for the case of _error_ with </p>
2451
2452 <blockquote>
2453   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
2454 </blockquote>
2455
2456
2457
2458
2459
2460 <hr>
2461 <h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
2462 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2463  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2464 <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>
2465 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2466 <p><b>Discussion:</b></p>
2467 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
2468 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
2469 22.2.2.1.2, addressed in (4). </p>
2470
2471
2472 <p><b>Proposed resolution:</b></p>
2473 <p>In 22.4.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
2474 clause for member put(...., bool), replace the initialization of the
2475 string_type value s as follows: </p>
2476
2477 <blockquote>
2478   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
2479 string_type s = val ? np.truename() : np.falsename(); </pre>
2480 </blockquote>
2481
2482
2483
2484
2485
2486 <hr>
2487 <h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
2488 <p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2489  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2490 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
2491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2492 <p><b>Discussion:</b></p>
2493 <p>In 27.5.5.1 [fmtflags.manip], we have a definition for a manipulator
2494 named "unitbuf". Unlike other manipulators, it's not listed
2495 in synopsis. Similarly for "nounitbuf". </p>
2496
2497
2498 <p><b>Proposed resolution:</b></p>
2499 <p>Add to the synopsis for &lt;ios&gt; in 27.5 [iostreams.base], after
2500 the entry for "nouppercase", the prototypes: </p>
2501
2502 <blockquote>
2503   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
2504 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
2505 </blockquote>
2506
2507
2508
2509
2510
2511 <hr>
2512 <h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
2513 <p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2514  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2515 <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>
2516 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2517 <p><b>Discussion:</b></p>
2518 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
2519 specified badly, so that an implementation which only keeps the last value stored appears
2520 to conform. In particular, it says: </p>
2521
2522 <p>The reference returned may become invalid after another call to the object's iword
2523 member with a different index ... </p>
2524
2525 <p>This is not idle speculation; at least one implementation was done this way. </p>
2526
2527
2528 <p><b>Proposed resolution:</b></p>
2529 <p>Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in
2530 paragraph 4, replace the sentence: </p>
2531
2532 <blockquote>
2533   <p>The reference returned may become invalid after another call to the object's iword
2534   [pword] member with a different index, after a call to its copyfmt member, or when the
2535   object is destroyed. </p>
2536 </blockquote>
2537
2538 <p>with: </p>
2539
2540 <blockquote>
2541   <p>The reference returned is invalid after any other operations on the object. However,
2542   the value of the storage referred to is retained, so that until the next call to copyfmt,
2543   calling iword [pword] with the same index yields another reference to the same value. </p>
2544 </blockquote>
2545
2546 <p>substituting "iword" or "pword" as appropriate. </p>
2547
2548
2549
2550
2551
2552 <hr>
2553 <h3><a name="37"></a>37. Leftover "global" reference</h3>
2554 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2555  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2556 <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>
2557 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2558 <p><b>Discussion:</b></p>
2559 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
2560
2561 <blockquote>
2562   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
2563   the standard exception bad_cast. </p>
2564 </blockquote>
2565
2566 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
2567 from an old draft. </p>
2568
2569
2570 <p><b>Proposed resolution:</b></p>
2571 <p>In 22.3.1 [locale], paragraph 4, delete the parenthesized
2572 expression </p>
2573
2574 <blockquote>
2575   <p>(or, failing that, in the global locale) </p>
2576 </blockquote>
2577
2578
2579
2580
2581
2582 <hr>
2583 <h3><a name="38"></a>38. Facet definition incomplete</h3>
2584 <p><b>Section:</b> 22.3.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2585  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2586 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2587 <p><b>Discussion:</b></p>
2588 <p>It has been noticed by Esa Pulkkinen that the definition of
2589 "facet" is incomplete. In particular, a class derived from
2590 another facet, but which does not define a member <i>id</i>, cannot
2591 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
2592 because there is no guarantee that a reference to the facet instance
2593 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
2594
2595
2596 <p><b>Proposed resolution:</b></p>
2597 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
2598 reads: </p>
2599
2600 <blockquote>
2601   <p>Get a reference to a facet of a locale. </p>
2602 </blockquote>
2603
2604 <p>with: </p>
2605
2606 <blockquote>
2607   <p>Requires: <tt>Facet</tt> is a facet class whose definition
2608   contains the public static member <tt>id</tt> as defined in 22.3.1.1.2 [locale.facet]. </p>
2609 </blockquote>
2610
2611 <p><i>[
2612 Kona: strike as overspecification the text "(not inherits)"
2613 from the original resolution, which read "... whose definition
2614 contains (not inherits) the public static member
2615 <tt>id</tt>..."
2616 ]</i></p>
2617
2618
2619
2620
2621
2622
2623
2624 <hr>
2625 <h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
2626 <p><b>Section:</b> 24.6.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2627  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2628 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2629 <p><b>Discussion:</b></p>
2630 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
2631 3, the standard contains three lines of garbage text left over from a previous edit. </p>
2632
2633 <blockquote>
2634   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
2635 sbuf_-&gt;sbumpc();
2636 return(tmp); </pre>
2637 </blockquote>
2638
2639
2640 <p><b>Proposed resolution:</b></p>
2641 <p>In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
2642 end of paragraph 3. </p>
2643
2644
2645
2646
2647
2648 <hr>
2649 <h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
2650 <p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2651  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2652 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
2653 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2654 <p><b>Discussion:</b></p>
2655 <p>Paragraph 3 of the locale examples is a description of part of an
2656 implementation technique that has lost its referent, and doesn't mean
2657 anything. </p>
2658
2659
2660 <p><b>Proposed resolution:</b></p>
2661 <p>Delete 22.4.8 [facets.examples] paragraph 3 which begins "This
2662 initialization/identification system depends...", or (at the
2663 editor's option) replace it with a place-holder to keep the paragraph
2664 numbering the same. </p>
2665
2666
2667
2668
2669
2670 <hr>
2671 <h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
2672 <p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2673  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2674 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
2675 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2676 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
2677 <p><b>Discussion:</b></p>
2678 <p>The description of ios_base::iword() and pword() in 27.5.2.4 [ios.members.static], say that if they fail, they "set badbit,
2679 which may throw an exception". However, ios_base offers no
2680 interface to set or to test badbit; those interfaces are defined in
2681 basic_ios&lt;&gt;. </p>
2682
2683
2684 <p><b>Proposed resolution:</b></p>
2685 <p>Change the description in 27.5.2.5 [ios.base.storage] in
2686 paragraph 2, and also in paragraph 4, as follows. Replace</p>
2687
2688 <blockquote>
2689   <p>If the function fails it sets badbit, which may throw an exception.</p>
2690 </blockquote>
2691
2692 <p>with</p>
2693
2694 <blockquote>
2695   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
2696   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
2697   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
2698   on the derived object (which may throw <tt>failure</tt>).</p>
2699 </blockquote>
2700
2701 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
2702 setstate(badbit).]</i></p>
2703
2704
2705
2706
2707
2708
2709
2710 <hr>
2711 <h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
2712 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2713  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2714 <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>
2715 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
2716 <p><b>Discussion:</b></p>
2717 <p>The basic_string&lt;&gt; copy constructor: </p>
2718
2719 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2720              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
2721
2722 <p>specifies an Allocator argument default value that is
2723 counter-intuitive. The natural choice for a the allocator to copy from
2724 is str.get_allocator(). Though this cannot be expressed in
2725 default-argument notation, overloading suffices. </p>
2726
2727 <p>Alternatively, the other containers in Clause 23 (deque, list,
2728 vector) do not have this form of constructor, so it is inconsistent,
2729 and an evident source of confusion, for basic_string&lt;&gt; to have
2730 it, so it might better be removed. </p>
2731
2732
2733 <p><b>Proposed resolution:</b></p>
2734 <p> In 21.4 [basic.string], replace the declaration of the copy
2735 constructor as follows: </p>
2736
2737 <blockquote>
2738   <pre>basic_string(const basic_string&amp; str);
2739 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
2740              const Allocator&amp; a = Allocator());</pre>
2741 </blockquote>
2742
2743 <p>In 21.4.1 [string.require], replace the copy constructor declaration
2744 as above. Add to paragraph 5, Effects:</p>
2745
2746 <blockquote>
2747   <p>In the first form, the Allocator value used is copied from
2748   <tt>str.get_allocator()</tt>.</p>
2749 </blockquote>
2750
2751
2752 <p><b>Rationale:</b></p>
2753 <p>The LWG believes the constructor is actually broken, rather than
2754 just an unfortunate design choice.</p>
2755
2756 <p>The LWG considered two other possible resolutions:</p>
2757
2758 <p>A. In 21.4 [basic.string], replace the declaration of the copy
2759 constructor as follows:</p>
2760
2761 <blockquote>
2762   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2763              size_type n = npos);
2764 basic_string(const basic_string&amp; str, size_type pos,
2765              size_type n, const Allocator&amp; a); </pre>
2766 </blockquote>
2767
2768 <p>In 21.4.1 [string.require], replace the copy constructor declaration
2769 as above. Add to paragraph 5, Effects: </p>
2770
2771 <blockquote>
2772   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
2773   value <tt>str.get_allocator()</tt>. </p>
2774 </blockquote>
2775
2776 <p>B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace
2777 the declaration of the copy constructor as follows: </p>
2778
2779 <blockquote>
2780   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2781              size_type n = npos); </pre>
2782 </blockquote>
2783
2784 <p>The proposed resolution reflects the original intent of the LWG. It
2785 was also noted by Pete Becker that this fix "will cause
2786 a small amount of existing code to now work correctly."</p>
2787
2788 <p><i>[
2789 Kona: issue editing snafu fixed - the proposed resolution now correctly
2790 reflects the LWG consensus.
2791 ]</i></p>
2792
2793
2794
2795
2796
2797
2798 <hr>
2799 <h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
2800 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
2801  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
2802 <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>
2803 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
2804 <p><b>Discussion:</b></p>
2805 <p>Many of the specifications for iostreams specify that character
2806 values or their int_type equivalents are compared using operators ==
2807 or !=, though in other places traits::eq() or traits::eq_int_type is
2808 specified to be used throughout. This is an inconsistency; we should
2809 change uses of == and != to use the traits members instead. </p>
2810
2811
2812 <p><b>Proposed resolution:</b></p>
2813
2814 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
2815
2816
2817 <p>List of changes to clause 27:</p>
2818 <ol>
2819 <li>
2820    In lib.basic.ios.members paragraph 13 (postcondition clause for
2821    'fill(cT)') change
2822
2823 <blockquote><pre>     fillch == fill()
2824 </pre></blockquote>
2825
2826    to
2827
2828 <blockquote><pre>     traits::eq(fillch, fill())
2829 </pre></blockquote>
2830
2831
2832 </li>
2833 <li>
2834    In lib.istream.unformatted paragraph 7 (effects clause for
2835    'get(cT,streamsize,cT)'), third bullet, change
2836
2837 <blockquote><pre>     c == delim for the next available input character c
2838 </pre></blockquote>
2839
2840    to
2841
2842 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2843 </pre></blockquote>
2844
2845 </li>
2846 <li>
2847    In lib.istream.unformatted paragraph 12 (effects clause for
2848    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
2849
2850 <blockquote><pre>     c == delim for the next available input character c
2851 </pre></blockquote>
2852
2853    to
2854
2855 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2856 </pre></blockquote>
2857
2858 </li>
2859 <li>
2860    In lib.istream.unformatted paragraph 17 (effects clause for
2861    'getline(cT,streamsize,cT)'), second bullet, change
2862
2863 <blockquote><pre>     c == delim for the next available input character c
2864 </pre></blockquote>
2865
2866    to
2867
2868 <blockquote><pre>     traits::eq(c, delim) for the next available input character c
2869   </pre></blockquote>
2870
2871 </li>
2872 <li>
2873    In lib.istream.unformatted paragraph 24 (effects clause for
2874    'ignore(int,int_type)'), second bullet, change
2875
2876 <blockquote><pre>     c == delim for the next available input character c
2877 </pre></blockquote>
2878
2879    to
2880
2881 <blockquote><pre>     traits::eq_int_type(c, delim) for the next available input
2882      character c
2883 </pre></blockquote>
2884   
2885 </li>
2886 <li>
2887    In lib.istream.unformatted paragraph 25 (notes clause for
2888    'ignore(int,int_type)'), second bullet, change
2889
2890 <blockquote><pre>     The last condition will never occur if delim == traits::eof()
2891 </pre></blockquote>
2892
2893    to
2894
2895 <blockquote><pre>     The last condition will never occur if
2896      traits::eq_int_type(delim, traits::eof()).
2897 </pre></blockquote>
2898
2899 </li>
2900 <li>
2901    In lib.istream.sentry paragraph 6 (example implementation for the
2902    sentry constructor) change
2903
2904 <blockquote><pre>     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2905 </pre></blockquote>
2906
2907    to
2908
2909 <blockquote><pre>     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
2910 </pre></blockquote>
2911
2912 </li>
2913 </ol>
2914
2915 <p>List of changes to Chapter 21:</p>
2916
2917 <ol>
2918 <li>
2919    In lib.string::find paragraph 1 (effects clause for find()),
2920    second bullet, change
2921
2922 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2923 </pre></blockquote>
2924
2925    to
2926
2927 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2928 </pre></blockquote>
2929
2930 </li>
2931 <li>
2932    In lib.string::rfind paragraph 1 (effects clause for rfind()),
2933    second bullet, change
2934
2935 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2936 </pre></blockquote>
2937
2938    to
2939
2940 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2941 </pre></blockquote>
2942
2943 </li>
2944 <li>
2945    In lib.string::find.first.of paragraph 1 (effects clause for
2946    find_first_of()), second bullet, change
2947
2948 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2949 </pre></blockquote>
2950
2951    to
2952
2953 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2954 </pre></blockquote>
2955
2956 </li>
2957 <li>
2958    In lib.string::find.last.of paragraph 1 (effects clause for
2959    find_last_of()), second bullet, change
2960
2961 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2962 </pre></blockquote>
2963
2964    to
2965
2966 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2967 </pre></blockquote>
2968
2969 </li>
2970 <li>
2971    In lib.string::find.first.not.of paragraph 1 (effects clause for
2972    find_first_not_of()), second bullet, change
2973
2974 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2975 </pre></blockquote>
2976
2977    to
2978
2979 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2980 </pre></blockquote>
2981 </li>
2982
2983 <li>
2984    In lib.string::find.last.not.of paragraph 1 (effects clause for
2985    find_last_not_of()), second bullet, change
2986
2987 <blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2988 </pre></blockquote>
2989
2990    to
2991
2992 <blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2993 </pre></blockquote>
2994 </li>
2995
2996 <li>
2997    In lib.string.ios paragraph 5 (effects clause for getline()),
2998    second bullet, change
2999
3000 <blockquote><pre>     c == delim for the next available input character c 
3001 </pre></blockquote>
3002
3003    to
3004
3005 <blockquote><pre>     traits::eq(c, delim) for the next available input character c 
3006 </pre></blockquote>
3007 </li>
3008
3009 </ol>
3010
3011 <p>Notes:</p>
3012 <ul>
3013 <li>
3014   Fixing this issue highlights another sloppyness in
3015   lib.istream.unformatted paragraph 24: this clause mentions a "character"
3016   which is then compared to an 'int_type' (see item 5. in the list
3017   below). It is not clear whether this requires explicit words and
3018   if so what these words are supposed to be. A similar issue exists,
3019   BTW, for operator*() of istreambuf_iterator which returns the result
3020   of sgetc() as a character type (see lib.istreambuf.iterator::op*
3021   paragraph 1), and for operator++() of istreambuf_iterator which
3022   passes the result of sbumpc() to a constructor taking a char_type
3023   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
3024   assignment operator ostreambuf_iterator passes a char_type to a function
3025   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
3026 </li>
3027 <li>
3028   It is inconsistent to use comparisons using the traits functions in
3029   Chapter 27 while not using them in Chapter 21, especially as some
3030   of the inconsistent uses actually involve streams (eg. getline() on
3031   streams). To avoid leaving this issue open still longer due to this
3032   inconsistency (it is open since 1998), a list of changes to Chapter
3033   21 is below.
3034 </li>
3035 <li>
3036   In Chapter 24 there are several places with statements like "the end
3037   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
3038   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
3039   paragraph 5). It is unclear whether these should be clarified to use
3040   traits::eq_int_type() for detecting traits::eof().
3041 </li>
3042 </ul>
3043
3044
3045
3046
3047
3048
3049 <hr>
3050 <h3><a name="46"></a>46. Minor Annex D errors</h3>
3051 <p><b>Section:</b> D.9 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3052  <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2010-10-29</p>
3053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3054 <p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
3055
3056 <p><b>Proposed resolution:</b></p>
3057 <p>Change D.9.1 [depr.strstreambuf] (since streambuf is a typedef of
3058 basic_streambuf&lt;char&gt;) from:</p>
3059
3060 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
3061
3062 <p>to:</p>
3063
3064 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
3065
3066 <p>In D.9.4 [depr.strstream] insert the semicolon now missing after
3067 int_type:</p>
3068
3069 <pre>     namespace std {
3070        class strstream
3071          : public basic_iostream&lt;char&gt; {
3072        public:
3073          // Types
3074          typedef char                                char_type;
3075          typedef typename char_traits&lt;char&gt;::int_type int_type
3076          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
3077
3078
3079
3080
3081
3082 <hr>
3083 <h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
3084 <p><b>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3085  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
3086 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
3087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3088 <p><b>Discussion:</b></p>
3089 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
3090 section has two RETURNS clauses, and they make no sense as
3091 stated. They make perfect sense, though, if you swap them. Am I
3092 correct in thinking that paragraphs 2 and 4 just got mixed up by
3093 accident?</p>
3094
3095
3096 <p><b>Proposed resolution:</b></p>
3097 <p>In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
3098
3099
3100
3101
3102
3103 <hr>
3104 <h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
3105 <p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3106  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
3107 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
3108 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3109 <p><b>Discussion:</b></p>
3110 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
3111 base class, exception, with exception(msg). Class exception (see
3112 18.6.1) has no such constructor.</p>
3113
3114
3115 <p><b>Proposed resolution:</b></p>
3116 <p>Replace 27.5.2.1.1 [ios::failure], paragraph 2, with</p>
3117
3118 <blockquote>
3119   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
3120 </blockquote>
3121
3122
3123
3124
3125
3126 <hr>
3127 <h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
3128 <p><b>Section:</b> 27.5.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
3129  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
3130 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
3131 <p><b>Discussion:</b></p>
3132 <p>Two problems</p>
3133
3134 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
3135 returns. Does it return f, or does it return the previous
3136 synchronization state? My guess is the latter, but the standard
3137 doesn't say so.</p>
3138
3139 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
3140 synchronized with stdio.  Again, of course, I can make some
3141 guesses. (And I'm unhappy about the performance implications of those
3142 guesses, but that's another matter.)</p>
3143
3144
3145 <p><b>Proposed resolution:</b></p>
3146 <p>Change the following sentence in 27.5.2.4 [ios.members.static]
3147 returns clause from:</p>
3148
3149 <blockquote>
3150   <p><tt>true</tt> if the standard iostream objects (27.3) are
3151   synchronized and otherwise returns <tt>false</tt>.</p>
3152 </blockquote>
3153
3154 <p>to:</p>
3155
3156 <blockquote>
3157   <p><tt>true</tt> if the previous state of the standard iostream
3158   objects (27.3) was synchronized and otherwise returns
3159   <tt>false</tt>.</p>
3160 </blockquote>
3161
3162 <p>Add the following immediately after 27.5.2.4 [ios.members.static],
3163 paragraph 2:</p>
3164
3165 <blockquote>
3166 <p>When a standard iostream object str is <i>synchronized</i> with a
3167 standard stdio stream f, the effect of inserting a character c by</p>
3168 <pre>  fputc(f, c);
3169 </pre>
3170
3171 <p>is the same as the effect of</p>
3172 <pre>  str.rdbuf()-&gt;sputc(c);
3173 </pre>
3174
3175 <p>for any sequence of characters; the effect of extracting a
3176 character c by</p>
3177 <pre>  c = fgetc(f);
3178 </pre>
3179
3180 <p>is the same as the effect of:</p>
3181 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
3182 </pre>
3183
3184 <p>for any sequences of characters; and the effect of pushing
3185 back a character c by</p>
3186 <pre>  ungetc(c, f);
3187 </pre>
3188
3189 <p>is the same as the effect of</p>
3190 <pre>  str.rdbuf()-&gt;sputbackc(c);
3191 </pre>
3192
3193 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
3194 that operations on a standard iostream object can be mixed arbitrarily
3195 with operations on the corresponding stdio stream.  In practical
3196 terms, synchronization usually means that a standard iostream object
3197 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
3198 </blockquote>
3199
3200 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
3201 of "synchronization"]</i></p>
3202
3203
3204 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
3205 text was added in the non-normative footnote to say that operations
3206 on the two streams can be mixed arbitrarily.]</i></p>
3207
3208
3209
3210
3211
3212
3213 <hr>
3214 <h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
3215 <p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3216  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
3217 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
3218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3219 <p><b>Discussion:</b></p>
3220 <p>As written, ios_base has a copy constructor and an assignment
3221 operator. (Nothing in the standard says it doesn't have one, and all
3222 classes have copy constructors and assignment operators unless you
3223 take specific steps to avoid them.) However, nothing in 27.4.2 says
3224 what the copy constructor and assignment operator do. </p>
3225
3226 <p>My guess is that this was an oversight, that ios_base is, like
3227 basic_ios, not supposed to have a copy constructor or an assignment
3228 operator.</p>
3229
3230 <p>
3231 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
3232 sense to what you're suggesting. At one point there was a definite
3233 intention that you could copy ios_base. It's an easy way to save the
3234 entire state of a stream for future use. As you note, to carry out
3235 that intention would have required a explicit description of the
3236 semantics (e.g. what happens to the iarray and parray stuff).
3237 </p>
3238
3239
3240 <p><b>Proposed resolution:</b></p>
3241 <p>In 27.5.2 [ios.base], class ios_base, specify the copy
3242 constructor and operator= members as being private.</p>
3243
3244
3245 <p><b>Rationale:</b></p>
3246 <p>The LWG believes the difficulty of specifying correct semantics
3247 outweighs any benefit of allowing ios_base objects to be copyable.</p>
3248
3249
3250
3251
3252
3253 <hr>
3254 <h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
3255 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3256  <b>Submitter:</b> David Vandevoorde <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
3257 <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>
3258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3259 <p><b>Discussion:</b></p>
3260 <p>The std::sort algorithm can in general only sort a given sequence
3261 by moving around values. The list&lt;&gt;::sort() member on the other
3262 hand could move around values or just update internal pointers. Either
3263 method can leave iterators into the list&lt;&gt; dereferencable, but
3264 they would point to different things. </p>
3265
3266 <p>Does the FDIS mandate anywhere which method should be used for
3267 list&lt;&gt;::sort()?</p>
3268
3269 <p>Matt Austern comments:</p>
3270
3271 <p>I think you've found an omission in the standard. </p>
3272
3273 <p>The library working group discussed this point, and there was
3274 supposed to be a general requirement saying that list, set, map,
3275 multiset, and multimap may not invalidate iterators, or change the
3276 values that iterators point to, except when an operation does it
3277 explicitly. So, for example, insert() doesn't invalidate any iterators
3278 and erase() and remove() only invalidate iterators pointing to the
3279 elements that are being erased. </p>
3280
3281 <p>I looked for that general requirement in the FDIS, and, while I
3282 found a limited form of it for the sorted associative containers, I
3283 didn't find it for list. It looks like it just got omitted. </p>
3284
3285 <p>The intention, though, is that list&lt;&gt;::sort does not
3286 invalidate any iterators and does not change the values that any
3287 iterator points to. There would be no reason to have the member
3288 function otherwise.</p>
3289
3290
3291 <p><b>Proposed resolution:</b></p>
3292 <p>Add a new paragraph at the end of 23.1:</p>
3293
3294 <blockquote>
3295   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
3296   other functions), invoking a container member function or passing a container as an
3297   argument to a library function shall not invalidate iterators to, or change the values of,
3298   objects within that container. </p>
3299 </blockquote>
3300
3301
3302 <p><b>Rationale:</b></p>
3303 <p>This was US issue CD2-23-011; it was accepted in London but the
3304 change was not made due to an editing oversight. The wording in the
3305 proposed resolution below is somewhat updated from CD2-23-011,
3306 particularly the addition of the phrase "or change the values
3307 of"</p>
3308
3309
3310
3311
3312
3313 <hr>
3314 <h3><a name="52"></a>52. Small I/O problems</h3>
3315 <p><b>Section:</b> 27.5.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3316  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
3317 <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>
3318 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3319 <p><b>Discussion:</b></p>
3320 <p>First, 27.5.4.1 [basic.ios.cons], table 89. This is pretty obvious:
3321 it should be titled "basic_ios&lt;&gt;() effects", not
3322 "ios_base() effects". </p>
3323
3324 <p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
3325 resolution.]</p>
3326
3327 <p>Second, 27.5.3.2 [fpos.operations] table 88 . There are a couple
3328 different things wrong with it, some of which I've already discussed
3329 with Jerry, but the most obvious mechanical sort of error is that it
3330 uses expressions like P(i) and p(i), without ever defining what sort
3331 of thing "i" is.
3332 </p>
3333
3334 <p>(The other problem is that it requires support for streampos
3335 arithmetic. This is impossible on some systems, i.e. ones where file
3336 position is a complicated structure rather than just a number. Jerry
3337 tells me that the intention was to require syntactic support for
3338 streampos arithmetic, but that it wasn't actually supposed to do
3339 anything meaningful except on platforms, like Unix, where genuine
3340 arithmetic is possible.) </p>
3341
3342
3343 <p><b>Proposed resolution:</b></p>
3344 <p>Change 27.5.4.1 [basic.ios.cons] table 89 title from
3345 "ios_base() effects" to "basic_ios&lt;&gt;()
3346 effects". </p>
3347
3348
3349
3350
3351
3352 <hr>
3353 <h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
3354 <p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3355  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
3356 <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>
3357 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3358 <p><b>Discussion:</b></p>
3359 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
3360 The important question is whether basic_ios::~basic_ios() destroys
3361 rdbuf().</p>
3362
3363
3364 <p><b>Proposed resolution:</b></p>
3365 <p>Add after 27.5.4.1 [basic.ios.cons] paragraph 2:</p>
3366
3367 <blockquote>
3368   <p><tt>virtual ~basic_ios();</tt></p>
3369   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
3370 </blockquote>
3371
3372
3373 <p><b>Rationale:</b></p> 
3374 <p>The LWG reviewed the additional question of whether or not
3375 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
3376 clearly yes; it may be set via <tt>clear()</tt>.  See 27.5.4.2 [basic.ios.members], paragraph 6.  This issue was reviewed at length
3377 by the LWG, which removed from the original proposed resolution a
3378 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
3379 <tt>badbit</tt>".</p>
3380
3381
3382
3383
3384
3385 <hr>
3386 <h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
3387 <p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3388  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-25 <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#streambuf.cons">issues</a> in [streambuf.cons].</p>
3390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3391 <p><b>Discussion:</b></p>
3392 <p>The class synopsis for basic_streambuf shows a (virtual)
3393 destructor, but the standard doesn't say what that destructor does. My
3394 assumption is that it does nothing, but the standard should say so
3395 explicitly. </p>
3396
3397
3398 <p><b>Proposed resolution:</b></p>
3399 <p>Add after 27.6.2.1 [streambuf.cons] paragraph 2:</p>
3400
3401 <blockquote>
3402   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
3403   <p><b>Effects</b>: None.</p>
3404 </blockquote>
3405
3406
3407
3408
3409
3410 <hr>
3411 <h3><a name="55"></a>55. Invalid stream position is undefined</h3>
3412 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3413  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-26 <b>Last modified:</b> 2010-10-29</p>
3414 <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>
3415 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3416 <p><b>Discussion:</b></p>
3417 <p>Several member functions in clause 27 are defined in certain
3418 circumstances to return an "invalid stream position", a term
3419 that is defined nowhere in the standard. Two places (27.5.2.4.2,
3420 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
3421 a definition in _lib.iostreams.definitions_, a nonexistent
3422 section. </p>
3423
3424 <p>I suspect that the invalid stream position is just supposed to be
3425 pos_type(-1).  Probably best to say explicitly in (for example)
3426 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
3427 the term "invalid stream position", define that term
3428 somewhere, and then put in a cross-reference. </p>
3429
3430 <p>The phrase "invalid stream position" appears ten times in
3431 the C++ Standard.  In seven places it refers to a return value, and it
3432 should be changed. In three places it refers to an argument, and it
3433 should not be changed. Here are the three places where "invalid
3434 stream position" should not be changed:</p>
3435
3436 <blockquote>
3437   <p>27.8.1.4 [stringbuf.virtuals], paragraph 14<br>
3438   27.9.1.5 [filebuf.virtuals], paragraph 14<br>
3439   D.9.1.3 [depr.strstreambuf.virtuals], paragraph 17
3440   </p>
3441 </blockquote>
3442
3443
3444 <p><b>Proposed resolution:</b></p>
3445 <p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
3446 object of class pos_type that stores an invalid stream position
3447 (_lib.iostreams.definitions_)" to "Returns
3448 <tt>pos_type(off_type(-1))</tt>".
3449 </p>
3450
3451 <p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
3452 an object of class pos_type that stores an invalid stream
3453 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
3454
3455 <p>In 27.8.1.4 [stringbuf.virtuals], paragraph 13, change "the object
3456 stores an invalid stream position" to "the return value is
3457 <tt>pos_type(off_type(-1))</tt>". </p>
3458
3459 <p>In 27.9.1.5 [filebuf.virtuals], paragraph 13, change "returns an
3460 invalid stream position (27.4.3)" to "returns
3461 <tt>pos_type(off_type(-1))</tt>" </p>
3462
3463 <p>In 27.9.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
3464 returns an invalid stream position (_lib.iostreams.definitions_)"
3465 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
3466 </p>
3467
3468 <p>In D.9.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
3469 stores an invalid stream position" to "the return value is
3470 <tt>pos_type(off_type(-1))</tt>" </p>
3471
3472 <p>In D.9.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
3473 stores an invalid stream position" to "the return value is
3474 <tt>pos_type(off_type(-1))</tt>"</p>
3475
3476
3477
3478
3479
3480 <hr>
3481 <h3><a name="56"></a>56. Showmanyc's return type</h3>
3482 <p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3483  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-29 <b>Last modified:</b> 2010-10-29</p>
3484 <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>
3485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3486 <p><b>Discussion:</b></p>
3487 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
3488 showmanyc has return type int. However, 27.5.2.4.3 says that its
3489 return type is streamsize. </p>
3490
3491
3492 <p><b>Proposed resolution:</b></p>
3493 <p>Change <tt>showmanyc</tt>'s return type in the
3494 27.6.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
3495
3496
3497
3498
3499
3500 <hr>
3501 <h3><a name="57"></a>57. Mistake in char_traits</h3>
3502 <p><b>Section:</b> 21.2.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3503  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2010-10-29</p>
3504 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3505 <p><b>Discussion:</b></p>
3506 <p>21.1.3.2, paragraph 3, says "The types streampos and
3507 wstreampos may be different if the implementation supports no shift
3508 encoding in narrow-oriented iostreams but supports one or more shift
3509 encodings in wide-oriented streams". </p>
3510
3511 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
3512 in 27.2 says that streampos and wstreampos are, respectively, synonyms
3513 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
3514 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
3515 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
3516 char_traits&lt;char&gt;::state_type and
3517 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
3518
3519
3520 <p><b>Proposed resolution:</b></p>
3521 <p>Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
3522 begins "The types streampos and wstreampos may be
3523 different..." . </p>
3524
3525
3526
3527
3528
3529 <hr>
3530 <h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
3531 <p><b>Section:</b> 27.6.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3532  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-28 <b>Last modified:</b> 2010-10-29</p>
3533 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3534 <p><b>Discussion:</b></p>
3535 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
3536 next pointer for the input sequence by n." </p>
3537
3538 <p>The straightforward interpretation is that it is just gptr() +=
3539 n. An alternative interpretation, though, is that it behaves as if it
3540 calls sbumpc n times. (The issue, of course, is whether it might ever
3541 call underflow.) There is a similar ambiguity in the case of
3542 pbump. </p>
3543
3544 <p>(The "classic" AT&amp;T implementation used the
3545 former interpretation.)</p>
3546
3547
3548 <p><b>Proposed resolution:</b></p>
3549 <p>Change 27.6.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
3550
3551 <blockquote>
3552   <p>Effects: Advances the next pointer for the input sequence by n.</p>
3553 </blockquote>
3554
3555 <p>to:</p>
3556
3557 <blockquote>
3558   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
3559 </blockquote>
3560
3561 <p>Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump
3562 effects.</p>
3563
3564
3565
3566
3567
3568 <hr>
3569 <h3><a name="60"></a>60. What is a formatted input function?</h3>
3570 <p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3571  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2010-10-29</p>
3572 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
3573 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3574 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p>
3575 <p><b>Discussion:</b></p>
3576 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
3577 formatted input functions. Some of the functions defined in section
3578 27.6.1.2 explicitly say that those requirements apply ("Behaves
3579 like a formatted input member (as described in 27.6.1.2.1)"), but
3580 others don't. The question: is 27.6.1.2.1 supposed to apply to
3581 everything in 27.6.1.2, or only to those member functions that
3582 explicitly say "behaves like a formatted input member"? Or
3583 to put it differently: are we to assume that everything that appears
3584 in a section called "Formatted input functions" really is a
3585 formatted input function? I assume that 27.6.1.2.1 is intended to
3586 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
3587 is not intended to apply to extractors like </p>
3588
3589 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
3590
3591 <p>and </p>
3592
3593 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
3594
3595 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
3596 output. </p>
3597
3598 <p>Comments from Judy Ward: It seems like the problem is that the
3599 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
3600 for the manipulators and streambuf* are in the wrong section and
3601 should have their own separate section or be modified to make it clear
3602 that the "Common requirements" listed in section 27.6.1.2.1
3603 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
3604 apply to them. </p>
3605
3606 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
3607 nonsensical to consider the functions defined in 27.7.1.2.3 [istream::extractors] paragraphs 1 to 5 to be "Formatted input
3608 function" but since these functions are defined in a section
3609 labeled "Formatted input functions" it is unclear to me
3610 whether these operators are considered formatted input functions which
3611 have to conform to the "common requirements" from 27.7.1.2.1 [istream.formatted.reqmts]: If this is the case, all manipulators, not
3612 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
3613 set (... but setting <tt>noskipws</tt> using the manipulator syntax
3614 would also skip whitespace :-)</p> <p>It is not clear which functions
3615 are to be considered unformatted input functions. As written, it seems
3616 that all functions in 27.7.1.3 [istream.unformatted] are unformatted input
3617 functions. However, it does not really make much sense to construct a
3618 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
3619 unclear what happens to the <tt>gcount()</tt> if
3620 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
3621 <tt>sync()</tt> is called: These functions don't extract characters,
3622 some of them even "unextract" a character. Should this still
3623 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
3624 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
3625 (the last unformatted input function, <tt>gcount()</tt>, didn't
3626 extract any character) and after a call to <tt>putback()</tt>
3627 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
3628 function <tt>putback()</tt> did "extract" back into the
3629 stream). Correspondingly for <tt>unget()</tt>. Is this what is
3630 intended?  If so, this should be clarified. Otherwise, a corresponding
3631 clarification should be used.</p>
3632
3633
3634 <p><b>Proposed resolution:</b></p>
3635 <p>
3636 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
3637 Change the beginning of the second sentence from "The conversion
3638 occurs" to "These extractors behave as formatted input functions (as
3639 described in 27.6.1.2.1).  After a sentry object is constructed,
3640 the conversion occurs"
3641 </p>
3642
3643 <p>
3644 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
3645 Add an effects clause.  "Effects: None.  This extractor does
3646 not behave as a formatted input function (as described in
3647 27.6.1.2.1).
3648 </p>
3649
3650 <p>
3651 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
3652 effects clause to "Effects: Calls pf(*this).  This extractor does not
3653 behave as a formatted input function (as described in 27.6.1.2.1).
3654 </p>
3655
3656 <p>
3657 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
3658 effects clause to "Effects: Calls pf(*this).  This extractor does not
3659 behave as a formatted input function (as described in 27.6.1.2.1).
3660 </p>
3661
3662 <p>
3663 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
3664 first two sentences from "If sb is null, calls setstate(failbit),
3665 which may throw ios_base::failure (27.4.4.3).  Extracts characters
3666 from *this..." to "Behaves as a formatted input function (as described
3667 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
3668 throw ios_base::failure (27.4.4.3).  After a sentry object is
3669 constructed, extracts characters from *this...".
3670 </p>
3671
3672 <p>
3673 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
3674 effects clause.  "Effects: none. This member function does not behave
3675 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
3676 </p>
3677
3678 <p>
3679 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
3680 beginning of the first sentence of the effects clause from "Extracts a
3681 character" to "Behaves as an unformatted input function (as described
3682 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
3683 character"
3684 </p>
3685
3686 <p>
3687 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
3688 beginning of the first sentence of the effects clause from "Extracts a
3689 character" to "Behaves as an unformatted input function (as described
3690 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
3691 character"
3692 </p>
3693
3694 <p>
3695 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
3696 beginning of the first sentence of the effects clause from "Extracts
3697 characters" to "Behaves as an unformatted input function (as described
3698 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3699 characters"
3700 </p>
3701
3702 <p>
3703 [No change needed in paragraph 10, because it refers to paragraph 7.]
3704 </p>
3705
3706 <p>
3707 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
3708 beginning of the first sentence of the effects clause from "Extracts
3709 characters" to "Behaves as an unformatted input function (as described
3710 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3711 characters"
3712 </p>
3713
3714 <p>
3715 [No change needed in paragraph 15.]
3716 </p>
3717
3718 <p>
3719 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
3720 beginning of the first sentence of the effects clause from "Extracts
3721 characters" to "Behaves as an unformatted input function (as described
3722 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3723 characters"
3724 </p>
3725
3726 <p>
3727 [No change needed in paragraph 23.]
3728 </p>
3729
3730 <p>
3731 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
3732 beginning of the first sentence of the effects clause from "Extracts
3733 characters" to "Behaves as an unformatted input function (as described
3734 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3735 characters"
3736 </p>
3737
3738 <p>
3739 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
3740 Effects clause: "Effects: Behaves as an unformatted input function (as
3741 described in 27.6.1.3, paragraph 1).  After constructing a sentry
3742 object, reads but does not extract the current input character."
3743 </p>
3744
3745 <p>
3746 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
3747 first sentence of the Effects clause from "If !good() calls" to
3748 Behaves as an unformatted input function (as described in 27.6.1.3,
3749 paragraph 1).  After constructing a sentry object, if !good() calls"
3750 </p>
3751
3752 <p>
3753 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
3754 first sentence of the Effects clause from "If !good() calls" to
3755 "Behaves as an unformatted input function (as described in 27.6.1.3,
3756 paragraph 1).  After constructing a sentry object, if !good() calls"
3757 </p>
3758
3759 <p>
3760 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
3761 first sentence of the Effects clause from "If !good() calls..." to
3762 "Behaves as an unformatted input function (as described in 27.6.1.3,
3763 paragraph 1).  After constructing a sentry object, if !good()
3764 calls..."  Add a new sentence to the end of the Effects clause:
3765 "[Note: this function extracts no characters, so the value returned
3766 by the next call to gcount() is 0.]"
3767 </p>
3768
3769 <p>
3770 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
3771 first sentence of the Effects clause from "If !good() calls" to
3772 "Behaves as an unformatted input function (as described in 27.6.1.3,
3773 paragraph 1).  After constructing a sentry object, if !good() calls".
3774 Add a new sentence to the end of the Effects clause: "[Note: this
3775 function extracts no characters, so the value returned by the next
3776 call to gcount() is 0.]"
3777 </p>
3778
3779 <p>
3780 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
3781 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
3782 as an unformatted input function (as described in 27.6.1.3, paragraph
3783 1), except that it does not count the number of characters extracted
3784 and does not affect the value returned by subsequent calls to
3785 gcount().  After constructing a sentry object, if rdbuf() is"
3786 </p>
3787
3788 <p>
3789 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
3790 Effects clause: "Effects: Behaves as an unformatted input function (as
3791 described in 27.6.1.3, paragraph 1), except that it does not count the
3792 number of characters extracted and does not affect the value returned
3793 by subsequent calls to gcount()."  Change the first sentence of
3794 paragraph 37 from "if fail()" to "after constructing a sentry object,
3795 if fail()".
3796 </p>
3797
3798 <p>
3799 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
3800 first sentence of the Effects clause from "If fail()" to "Behaves
3801 as an unformatted input function (as described in 27.6.1.3, paragraph
3802 1), except that it does not count the number of characters extracted
3803 and does not affect the value returned by subsequent calls to
3804 gcount().  After constructing a sentry object, if fail()
3805 </p>
3806
3807 <p>
3808 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
3809 first sentence of the Effects clause from "If fail()" to "Behaves
3810 as an unformatted input function (as described in 27.6.1.3, paragraph
3811 1), except that it does not count the number of characters extracted
3812 and does not affect the value returned by subsequent calls to
3813 gcount().  After constructing a sentry object, if fail()
3814 </p>
3815
3816 <p>
3817 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
3818 the beginning of the third sentence from "The formatting conversion"
3819 to "These extractors behave as formatted output functions (as
3820 described in 27.6.2.5.1).  After the sentry object is constructed, the
3821 conversion occurs".
3822 </p>
3823
3824 <p>
3825 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
3826 effects clause: "Effects: None. Does not behave as a formatted output
3827 function (as described in 27.6.2.5.1).".
3828 </p>
3829
3830 <p>
3831 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
3832 effects clause to "Effects: calls pf(*this).  This extractor does not
3833 behave as a formatted output function (as described in 27.6.2.5.1).".
3834 </p>
3835
3836 <p>
3837 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
3838 effects clause to "Effects: calls pf(*this).  This extractor does not
3839 behave as a formatted output function (as described in 27.6.2.5.1).".
3840 </p>
3841
3842 <p>
3843 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
3844 sentence from "If sb" to "Behaves as a formatted output function (as
3845 described in 27.6.2.5.1).  After the sentry object is constructed, if
3846 sb".
3847 </p>
3848
3849 <p>
3850 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
3851 sentence from "Inserts the character" to "Behaves as an unformatted
3852 output function (as described in 27.6.2.6, paragraph 1).  After
3853 constructing a sentry object, inserts the character".
3854 </p>
3855
3856 <p>
3857 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
3858 sentence from "Obtains characters" to "Behaves as an unformatted
3859 output function (as described in 27.6.2.6, paragraph 1).  After
3860 constructing a sentry object, obtains characters".
3861 </p>
3862
3863 <p>
3864 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
3865 sentence at the end of the paragraph: "Does not behave as an
3866 unformatted output function (as described in 27.6.2.6, paragraph 1)."
3867 </p>
3868
3869
3870 <p><b>Rationale:</b></p>
3871 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
3872 by Judy Ward and Matt Austern.  This proposed resolution is section
3873 VI of that paper.</p>
3874
3875
3876
3877
3878
3879 <hr>
3880 <h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
3881 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3882  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
3883 <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>
3884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3885 <p><b>Discussion:</b></p>
3886 <p>The introduction to the section on unformatted input (27.6.1.3)
3887 says that every unformatted input function catches all exceptions that
3888 were thrown during input, sets badbit, and then conditionally rethrows
3889 the exception. That seems clear enough. Several of the specific
3890 functions, however, such as get() and read(), are documented in some
3891 circumstances as setting eofbit and/or failbit. (The standard notes,
3892 correctly, that setting eofbit or failbit can sometimes result in an
3893 exception being thrown.) The question: if one of these functions
3894 throws an exception triggered by setting failbit, is this an exception
3895 "thrown during input" and hence covered by 27.6.1.3, or does
3896 27.6.1.3 only refer to a limited class of exceptions? Just to make
3897 this concrete, suppose you have the following snippet. </p>
3898
3899 <pre>  
3900   char buffer[N];
3901   istream is;
3902   ...
3903   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
3904   is.read(buffer, N);</pre>
3905
3906 <p>Now suppose we reach EOF before we've read N characters. What
3907 iostate bits can we expect to be set, and what exception (if any) will
3908 be thrown? </p>
3909
3910
3911 <p><b>Proposed resolution:</b></p>
3912 <p>
3913 In 27.6.1.3, paragraph 1, after the sentence that begins
3914 "If an exception is thrown...", add the following
3915 parenthetical comment: "(Exceptions thrown from 
3916 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
3917 </p>
3918
3919
3920 <p><b>Rationale:</b></p>
3921 <p>The LWG looked to two alternative wordings, and choose the proposed
3922 resolution as better standardese.</p>
3923
3924
3925
3926
3927
3928 <hr>
3929 <h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
3930 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3931  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
3932 <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>
3933 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3934 <p><b>Discussion:</b></p>
3935 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
3936 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
3937 ... returns traits::eof()." </p>
3938
3939 <p>That looks suspicious, because traits::eof() is of type
3940 traits::int_type while the return type of sync() is int. </p>
3941
3942
3943 <p><b>Proposed resolution:</b></p>
3944 <p>In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns
3945 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
3946 </p>
3947
3948
3949
3950
3951
3952 <hr>
3953 <h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
3954 <p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3955  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2010-10-29</p>
3956 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
3957 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
3958 <p><b>Discussion:</b></p>
3959 <p>Clause 27 details an exception-handling policy for formatted input,
3960 unformatted input, and formatted output. It says nothing for
3961 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
3962 kind of exception-handling policy as in the other three places, or
3963 else it should have a footnote saying that the omission is
3964 deliberate. </p>
3965
3966
3967 <p><b>Proposed resolution:</b></p>
3968 <p>
3969 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
3970 case, the unformatted output function ends by destroying the sentry
3971 object, then returning the value specified for the formatted output
3972 function.") with the following text:
3973 </p>
3974 <blockquote><p>
3975 If an exception is thrown during output, then <tt>ios::badbit</tt> is
3976 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
3977 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
3978 badbit) != 0</tt> then the exception is rethrown.  In any case, the
3979 unformatted output function ends by destroying the sentry object,
3980 then, if no exception was thrown, returning the value specified for
3981 the formatted output function.
3982 </p></blockquote>
3983
3984
3985 <p><b>Rationale:</b></p>
3986 <p>
3987 This exception-handling policy is consistent with that of formatted
3988 input, unformatted input, and formatted output.
3989 </p>
3990
3991
3992
3993
3994
3995 <hr>
3996 <h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
3997 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
3998  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2010-10-29</p>
3999 <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>
4000 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4001 <p><b>Discussion:</b></p>
4002 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
4003 different ways, depending on whether the second sentence is read as an
4004 elaboration of the first. </p>
4005
4006
4007 <p><b>Proposed resolution:</b></p>
4008 <p>Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins
4009 "If the function inserts no characters ..." with:</p>
4010
4011 <blockquote>
4012   <p>If the function inserts no characters, it calls
4013   <tt>setstate(failbit)</tt>, which may throw
4014   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
4015   because it caught an exception thrown while extracting characters
4016   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
4017   (27.4.4.3), then the caught exception is rethrown. </p>
4018 </blockquote>
4019
4020
4021
4022
4023
4024 <hr>
4025 <h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
4026 <p><b>Section:</b> D.9.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4027  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2010-10-29</p>
4028 <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>
4029 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4030 <p><b>Discussion:</b></p>
4031 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
4032 "Performs an operation that is defined separately for each class
4033 derived from strstreambuf". This is obviously an incorrect
4034 cut-and-paste from basic_streambuf. There are no classes derived from
4035 strstreambuf. </p>
4036
4037
4038 <p><b>Proposed resolution:</b></p>
4039 <p>D.9.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
4040 clause which currently says "Performs an operation that is
4041 defined separately for each class derived from strstreambuf"
4042 with:</p>
4043
4044 <blockquote>
4045   <p><b>Effects</b>: implementation defined, except that
4046   <tt>setbuf(0,0)</tt> has no effect.</p>
4047 </blockquote>
4048
4049
4050
4051
4052
4053 <hr>
4054 <h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
4055 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4056  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-07-14 <b>Last modified:</b> 2010-10-29</p>
4057 <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>
4058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4059 <p><b>Discussion:</b></p>
4060 <p>Extractors for char* (27.6.1.2.3) do not store a null character
4061 after the extracted character sequence whereas the unformatted
4062 functions like get() do. Why is this?</p>
4063
4064 <p>Comment from Jerry Schwarz: There is apparently an editing
4065 glitch. You'll notice that the last item of the list of what stops
4066 extraction doesn't make any sense. It was supposed to be the line that
4067 said a null is stored.</p>
4068
4069
4070 <p><b>Proposed resolution:</b></p>
4071 <p>27.7.1.2.3 [istream::extractors], paragraph 7, change the last list
4072 item from:</p>
4073
4074 <blockquote><p>
4075   A null byte (<tt>charT()</tt>) in the next position, which may be
4076   the first position if no characters were extracted.
4077 </p></blockquote>
4078
4079 <p>to become a new paragraph which reads:</p>
4080
4081 <blockquote><p>
4082   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
4083   next position, which may be the first position if no characters were
4084   extracted.
4085 </p></blockquote>
4086
4087
4088
4089
4090
4091 <hr>
4092 <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
4093 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4094  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1998-07-29 <b>Last modified:</b> 2010-10-29</p>
4095 <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>
4096 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4097 <p><b>Discussion:</b></p>
4098 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
4099
4100 <p>(Please note that this is entirely separate from the question of
4101 whether a vector iterator is required to be a pointer; the answer to
4102 that question is clearly "no," as it would rule out
4103 debugging implementations)</p>
4104
4105
4106 <p><b>Proposed resolution:</b></p>
4107 <p>Add the following text to the end of 23.4.1 [vector],
4108 paragraph 1. </p>
4109
4110 <blockquote>
4111   <p>The elements of a vector are stored contiguously, meaning that if
4112   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
4113   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
4114   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
4115 </blockquote>
4116
4117
4118 <p><b>Rationale:</b></p>
4119 <p>The LWG feels that as a practical matter the answer is clearly
4120 "yes".  There was considerable discussion as to the best way
4121 to express the concept of "contiguous", which is not
4122 directly defined in the standard.  Discussion included:</p>
4123
4124 <ul>
4125   <li>An operational definition similar to the above proposed resolution is 
4126     already used for valarray (26.6.2.3 [valarray.access]).</li>
4127   <li>There is no need to explicitly consider a user-defined operator&amp; 
4128     because elements must be copyconstructible (23.2 [container.requirements] para 3) 
4129     and copyconstructible (20.2.1 [utility.arg.requirements]) specifies
4130     requirements for operator&amp;.</li>
4131   <li>There is no issue of one-past-the-end because of language rules.</li>
4132 </ul>
4133
4134
4135
4136
4137
4138 <hr>
4139 <h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
4140 <p><b>Section:</b> 18.8 [support.exception], 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4141  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2010-10-29</p>
4142 <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>
4143 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4144 <p><b>Discussion:</b></p>
4145 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
4146
4147 <p>uncaught_exception() doesn't have a throw specification.</p>
4148
4149 <p>It is intentional ? Does it means that one should be prepared to
4150 handle exceptions thrown from uncaught_exception() ?</p>
4151
4152 <p>uncaught_exception() is called in exception handling contexts where
4153 exception safety is very important.</p>
4154
4155
4156 <p><b>Proposed resolution:</b></p>
4157 <p>In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception], and 18.8.4 [uncaught], add "throw()" to uncaught_exception().</p>
4158
4159
4160
4161
4162 <hr>
4163 <h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
4164 <p><b>Section:</b> 22.4.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4165  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-13 <b>Last modified:</b> 2010-10-29</p>
4166 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4167 <p><b>Discussion:</b></p>
4168 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
4169 is described in 22.4.5.1.2 [locale.time.get.virtuals] with five arguments,
4170 consistent with do_get_weekday and with its specified use by member
4171 get_monthname. However, in the synopsis, it is specified instead with
4172 four arguments. The missing argument is the "end" iterator
4173 value.</p>
4174
4175
4176 <p><b>Proposed resolution:</b></p>
4177 <p>In 22.4.5.1 [locale.time.get], add an "end" argument to
4178 the declaration of member do_monthname as follows:</p>
4179
4180 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
4181                                      ios_base::iostate&amp; err, tm* t) const;</pre>
4182
4183
4184
4185
4186 <hr>
4187 <h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
4188 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4189  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-08 <b>Last modified:</b> 2010-10-29</p>
4190 <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>
4191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4192 <p><b>Discussion:</b></p>
4193 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
4194 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
4195 parentheses and a spurious <b>n</b>.</p>
4196
4197
4198 <p><b>Proposed resolution:</b></p>
4199 <p>Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
4200 following:</p>
4201
4202 <blockquote><p>
4203   <b>Returns</b>: The maximum value that
4204   <tt>do_length(state, from, from_end, 1)</tt> can return for any
4205   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
4206   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
4207   mbstate_t&gt;::do_max_length()</tt> returns 1.
4208 </p></blockquote>
4209
4210
4211
4212
4213 <hr>
4214 <h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
4215 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4216  <b>Submitter:</b>  Matt
4217 Austern <b>Opened:</b> 1998-09-18 <b>Last modified:</b> 2010-10-29</p>
4218 <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>
4219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4220 <p><b>Discussion:</b></p>
4221 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
4222 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
4223 parameter of the member functions <tt>length</tt> and
4224 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
4225 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
4226 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
4227 synopsis or the summary must be changed. </p>
4228
4229 <p>If (as I believe) the member function descriptions are correct,
4230 then we must also add text saying how <tt>do_length</tt> changes its
4231 <tt>stateT</tt> argument. </p>
4232
4233
4234 <p><b>Proposed resolution:</b></p>
4235 <p>In 22.4.1.4 [locale.codecvt], and also in 22.4.1.5 [locale.codecvt.byname],
4236 change the <tt>stateT</tt> argument type on both member
4237 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
4238
4239 <blockquote>
4240   <p><tt>const stateT&amp;</tt></p>
4241 </blockquote>
4242
4243 <p>to</p>
4244
4245 <blockquote>
4246   <p><tt>stateT&amp;</tt></p>
4247 </blockquote>
4248
4249 <p>In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member
4250 <tt>do_length</tt> a paragraph:</p>
4251
4252 <blockquote>
4253   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
4254   it called <tt>do_in(state, from, from_end, from, to, to+max,
4255   to)</tt> for <tt>to</tt> pointing to a buffer of at least
4256   <tt>max</tt> elements.</p>
4257 </blockquote>
4258
4259
4260
4261
4262 <hr>
4263 <h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
4264 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4265  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-25 <b>Last modified:</b> 2010-10-29</p>
4266 <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>
4267 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4268 <p><b>Discussion:</b></p>
4269 <p>This issue concerns the requirements on classes derived from
4270 <tt>codecvt</tt>, including user-defined classes. What are the
4271 restrictions on the conversion from external characters
4272 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
4273 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
4274 the I/O library make? </p>
4275
4276 <p>The question is whether it's possible to convert from internal
4277 characters to external characters one internal character at a time,
4278 and whether, given a valid sequence of external characters, it's
4279 possible to pick off internal characters one at a time. Or, to put it
4280 differently: given a sequence of external characters and the
4281 corresponding sequence of internal characters, does a position in the
4282 internal sequence correspond to some position in the external
4283 sequence? </p>
4284
4285 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
4286 sequence of <i>M</i> external characters and that <tt>[ifirst,
4287 ilast)</tt> is the corresponding sequence of <i>N</i> internal
4288 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
4289 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
4290 ilast)</tt>. Now the question: does there necessarily exist a
4291 subsequence of external characters, <tt>[first, last_1)</tt>, such
4292 that the corresponding sequence of internal characters is the single
4293 character <tt>*ifirst</tt>?
4294 </p>
4295
4296 <p>(What a "no" answer would mean is that
4297 <tt>my_encoding</tt> translates sequences only as blocks. There's a
4298 sequence of <i>M</i> external characters that maps to a sequence of
4299 <i>N</i> internal characters, but that external sequence has no
4300 subsequence that maps to <i>N-1</i> internal characters.) </p>
4301
4302 <p>Some of the wording in the standard, such as the description of
4303 <tt>codecvt::do_max_length</tt> (22.4.1.4.2 [locale.codecvt.virtuals],
4304 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.9.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
4305 possible to pick off internal characters one at a time from a sequence
4306 of external characters. However, this is never explicitly stated one
4307 way or the other. </p>
4308
4309 <p>This issue seems (and is) quite technical, but it is important if
4310 we expect users to provide their own encoding facets. This is an area
4311 where the standard library calls user-supplied code, so a well-defined
4312 set of requirements for the user-supplied code is crucial. Users must
4313 be aware of the assumptions that the library makes. This issue affects
4314 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
4315 and several of <tt>codecvt</tt>'s member functions. </p>
4316
4317
4318 <p><b>Proposed resolution:</b></p>
4319 <p>Add the following text as a new paragraph, following 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
4320
4321 <blockquote>
4322 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
4323 (27.9 [file.streams]) must have the property that if</p>
4324 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
4325 </pre>
4326 <p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
4327 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
4328 </pre>
4329 <p>must also return <tt>ok</tt>, and that if</p>
4330 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
4331 </pre>
4332 <p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
4333 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
4334 </pre>
4335 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
4336 means that <tt>basic_filebuf</tt> assumes that the mapping from
4337 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
4338 used by <tt>basic_filebuf</tt> must be able to translate characters
4339 one internal character at a time.  <i>--End Footnote</i>]</p>
4340 </blockquote>
4341
4342 <p><i>[Redmond: Minor change in proposed resolution.  Original
4343 proposed resolution talked about "success", with a parenthetical
4344 comment that success meant returning <tt>ok</tt>.  New wording
4345 removes all talk about "success", and just talks about the
4346 return value.]</i></p>
4347
4348
4349
4350
4351 <p><b>Rationale:</b></p>
4352
4353   <p>The proposed resoluion says that conversions can be performed one
4354   internal character at a time.  This rules out some encodings that
4355   would otherwise be legal.  The alternative answer would mean there
4356   would be some internal positions that do not correspond to any
4357   external file position.</p>
4358   <p>
4359   An example of an encoding that this rules out is one where the
4360   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
4361   where the internal sequence <tt>c1 c2</tt> corresponds to the
4362   external sequence <tt>c2 c1</tt>.
4363   </p>
4364   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
4365   on this property: it was designed under the assumption that
4366   the external-to-internal mapping is N-to-1, and it is not clear
4367   that <tt>basic_filebuf</tt> is implementable without that 
4368   restriction.
4369   </p>
4370   <p>
4371   The proposed resolution is expressed as a restriction on
4372   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
4373   than a blanket restriction on all <tt>codecvt</tt> facets,
4374   because <tt>basic_filebuf</tt> is the only other part of the 
4375   library that uses <tt>codecvt</tt>.  If a user wants to define
4376   a <tt>codecvt</tt> facet that implements a more general N-to-M
4377   mapping, there is no reason to prohibit it, so long as the user
4378   does not expect <tt>basic_filebuf</tt> to be able to use it.
4379   </p>
4380
4381
4382
4383
4384
4385 <hr>
4386 <h3><a name="78"></a>78. Typo: event_call_back</h3>
4387 <p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4388  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4389 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
4390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4391 <p><b>Discussion:</b></p>
4392 <p>typo: event_call_back should be event_callback &nbsp; </p>
4393
4394
4395 <p><b>Proposed resolution:</b></p>
4396 <p>In the 27.5.2 [ios.base] synopsis change
4397 "event_call_back" to "event_callback". </p>
4398
4399
4400
4401
4402 <hr>
4403 <h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
4404 <p><b>Section:</b> 26.4.1 [complex.syn], 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4405  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4406 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
4407 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4408 <p><b>Discussion:</b></p>
4409 <p>In 26.4.1 [complex.syn] polar is declared as follows:</p>
4410 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
4411
4412 <p>In 26.4.7 [complex.value.ops] it is declared as follows:</p>
4413 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
4414
4415 <p>Thus whether the second parameter is optional is not clear. </p>
4416
4417
4418 <p><b>Proposed resolution:</b></p>
4419 <p>In 26.4.1 [complex.syn] change:</p>
4420 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
4421
4422 <p>to:</p>
4423 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
4424
4425
4426
4427
4428
4429 <hr>
4430 <h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
4431 <p><b>Section:</b> 26.4.1 [complex.syn], 26.4.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4432  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4433 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
4434 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4435 <p><b>Discussion:</b></p>
4436 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
4437 class complex. This redundancy should be removed.</p>
4438
4439
4440 <p><b>Proposed resolution:</b></p>
4441 <p>Reduce redundancy according to the general style of the standard. </p>
4442
4443
4444
4445
4446 <hr>
4447 <h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
4448 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4449  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4450 <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>
4451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4452 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
4453 <p><b>Discussion:</b></p>
4454 <p>Many string member functions throw if size is getting or exceeding
4455 npos. However, I wonder why they don't throw if size is getting or
4456 exceeding max_size() instead of npos.  May be npos is known at compile
4457 time, while max_size() is known at runtime. However, what happens if
4458 size exceeds max_size() but not npos, then? It seems the standard
4459 lacks some clarifications here.</p>
4460
4461
4462 <p><b>Proposed resolution:</b></p>
4463 <p>After 21.4 [basic.string] paragraph 4 ("The functions
4464 described in this clause...") add a new paragraph:</p>
4465
4466 <blockquote>
4467   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
4468   <tt> max_size()</tt> then
4469   the operation throws <tt>length_error</tt>.</p>
4470 </blockquote>
4471
4472
4473 <p><b>Rationale:</b></p>
4474 <p>The LWG believes length_error is the correct exception to throw.</p>
4475
4476
4477
4478
4479 <hr>
4480 <h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
4481 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4482  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4483 <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>
4484 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4485 <p><b>Discussion:</b></p>
4486 <p>The constructor from a range:</p>
4487
4488 <pre>template&lt;class InputIterator&gt; 
4489          basic_string(InputIterator begin, InputIterator end, 
4490                       const Allocator&amp; a = Allocator());</pre>
4491
4492 <p>lacks a throws clause. However, I would expect that it throws
4493 according to the other constructors if the numbers of characters in
4494 the range equals npos (or exceeds max_size(), see above). </p>
4495
4496
4497 <p><b>Proposed resolution:</b></p>
4498 <p>In 21.4.1 [string.require], Strike throws paragraphs for
4499 constructors which say "Throws: length_error if n ==
4500 npos."</p>
4501
4502
4503 <p><b>Rationale:</b></p>
4504 <p>Throws clauses for length_error if n == npos are no longer needed
4505 because they are subsumed by the general wording added by the
4506 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
4507
4508
4509
4510
4511 <hr>
4512 <h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
4513 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4514  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4515 <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>
4516 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4517 <p><b>Discussion:</b></p>
4518 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
4519
4520 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
4521 character c.</p>
4522
4523 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
4524
4525
4526 <p><b>Proposed resolution:</b></p>
4527 <p>In 21.4.8.9 [string.io] paragraph 1 Effects clause replace:</p>
4528
4529 <blockquote>
4530   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
4531 </blockquote>
4532
4533 <p>with:</p>
4534
4535 <blockquote>
4536   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
4537 </blockquote>
4538
4539
4540
4541
4542
4543 <hr>
4544 <h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
4545 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4546  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4547 <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>
4548 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4549 <p><b>Discussion:</b></p>
4550 <p>Operator &gt;&gt; and getline() for strings read until eof()
4551 in the input stream is true. However, this might never happen, if the
4552 stream can't read anymore without reaching EOF. So shouldn't it be
4553 changed into that it reads until !good() ? </p>
4554
4555
4556 <p><b>Proposed resolution:</b></p>
4557 <p>In 21.4.8.9 [string.io], paragraph 1, replace:</p>
4558 <blockquote><p>
4559 Effects: Begins by constructing a sentry object k as if k were
4560 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
4561 bool( k) is true, it calls str.erase() and then extracts characters
4562 from is and appends them to str as if by calling str.append(1, c). If
4563 is.width() is greater than zero, the maximum number n of characters
4564 appended is is.width(); otherwise n is str.max_size(). Characters are
4565 extracted and appended until any of the following occurs:
4566 </p></blockquote>
4567 <p>with:</p>
4568 <blockquote><p>
4569 Effects: Behaves as a formatted input function (27.7.1.2.1 [istream.formatted.reqmts]).  After constructing a sentry object, if the
4570 sentry converts to true, calls str.erase() and then extracts
4571 characters from is and appends them to str as if by calling
4572 str.append(1,c). If is.width() is greater than zero, the maximum
4573 number n of characters appended is is.width(); otherwise n is
4574 str.max_size(). Characters are extracted and appended until any of the
4575 following occurs:
4576 </p></blockquote>
4577
4578 <p>In 21.4.8.9 [string.io], paragraph 6, replace</p>
4579 <blockquote><p>
4580 Effects: Begins by constructing a sentry object k as if by typename
4581 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
4582 it calls str.erase() and then extracts characters from is and appends
4583 them to str as if by calling str.append(1, c) until any of the
4584 following occurs:
4585 </p></blockquote>
4586 <p>with:</p>
4587 <blockquote><p>
4588 Effects: Behaves as an unformatted input function (27.7.1.3 [istream.unformatted]), except that it does not affect the value returned
4589 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
4590 constructing a sentry object, if the sentry converts to true, calls
4591 str.erase() and then extracts characters from is and appends them to
4592 str as if by calling str.append(1,c) until any of the following
4593 occurs:
4594 </p></blockquote>
4595
4596 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
4597 should be a formatted input function, not an unformatted input function.
4598 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
4599 there is no mechanism for <tt>gcount</tt> to be set except by one of
4600 <tt>basic_istream</tt>'s member functions.]</i></p>
4601
4602
4603 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
4604
4605
4606
4607
4608 <p><b>Rationale:</b></p>
4609 <p>The real issue here is whether or not these string input functions
4610 get their characters from a streambuf, rather than by calling an
4611 istream's member functions, a streambuf signals failure either by
4612 returning eof or by throwing an exception; there are no other
4613 possibilities.  The proposed resolution makes it clear that these two
4614 functions do get characters from a streambuf.</p>
4615
4616
4617
4618
4619
4620 <hr>
4621 <h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
4622 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4623  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
4624 <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>
4625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4626 <p><b>Discussion:</b></p>
4627 <p>The standard does not state, how often a function object is copied,
4628 called, or the order of calls inside an algorithm. This may lead to
4629 surprising/buggy behavior. Consider the following example: </p>
4630
4631 <pre>class Nth {    // function object that returns true for the nth element 
4632   private: 
4633     int nth;     // element to return true for 
4634     int count;   // element counter 
4635   public: 
4636     Nth (int n) : nth(n), count(0) { 
4637     } 
4638     bool operator() (int) { 
4639         return ++count == nth; 
4640     } 
4641 }; 
4642 .... 
4643 // remove third element 
4644     list&lt;int&gt;::iterator pos; 
4645     pos = remove_if(coll.begin(),coll.end(),  // range 
4646                     Nth(3)),                  // remove criterion 
4647     coll.erase(pos,coll.end()); </pre>
4648
4649 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
4650 happens because the usual implementation of the algorithm copies the
4651 function object internally: </p>
4652
4653 <pre>template &lt;class ForwIter, class Predicate&gt; 
4654 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
4655
4656     beg = find_if(beg, end, op); 
4657     if (beg == end) { 
4658         return beg; 
4659     } 
4660     else { 
4661         ForwIter next = beg; 
4662         return remove_copy_if(++next, end, beg, op); 
4663     } 
4664 } </pre>
4665
4666 <p>The algorithm uses find_if() to find the first element that should
4667 be removed. However, it then uses a copy of the passed function object
4668 to process the resulting elements (if any). Here, Nth is used again
4669 and removes also the sixth element. This behavior compromises the
4670 advantage of function objects being able to have a state. Without any
4671 cost it could be avoided (just implement it directly instead of
4672 calling find_if()). </p>
4673
4674
4675 <p><b>Proposed resolution:</b></p>
4676
4677 <p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
4678 <blockquote><p>
4679 [Note: Unless otherwise specified, algorithms that take function
4680 objects as arguments are permitted to copy those function objects
4681 freely.  Programmers for whom object identity is important should
4682 consider using a wrapper class that points to a noncopied
4683 implementation object, or some equivalent solution.]
4684 </p></blockquote>
4685
4686 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
4687 but rather something that programmers need to be educated about.
4688 There was discussion of adding wording to the effect that the number
4689 and order of calls to function objects, including predicates, not
4690 affect the behavior of the function object.]</i></p>
4691
4692
4693 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
4694 have a clear statement of "predicate" in the
4695 standard. People including me seemed to think "a function
4696 returning a Boolean value and being able to be called by an STL
4697 algorithm or be used as sorting criterion or ... is a
4698 predicate". But a predicate has more requirements: It should
4699 never change its behavior due to a call or being copied. IMHO we have
4700 to state this in the standard. If you like, see section 8.1.4 of my
4701 library book for a detailed discussion.]</i></p>
4702
4703
4704 <p><i>[Kona: Nico will provide wording to the effect that "unless
4705 otherwise specified, the number of copies of and calls to function
4706 objects by algorithms is unspecified".&nbsp; Consider placing in
4707 25 [algorithms] after paragraph 9.]</i></p>
4708
4709
4710 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
4711   functions object won't be copied, and what isn't forbidden is
4712   allowed.  It is believed (especially since implementations that were
4713   written in concert with the standard do make copies of function
4714   objects) that this was intentional.  Thus, no normative change is
4715   needed.  What we should put in is a non-normative note suggesting to
4716   programmers that if they want to guarantee the lack of copying they
4717   should use something like the <tt>ref</tt> wrapper.]</i></p>
4718
4719
4720 <p><i>[Oxford: Matt provided wording.]</i></p>
4721
4722
4723
4724
4725
4726
4727
4728
4729 <hr>
4730 <h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
4731 <p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4732  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
4733 <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>
4734 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4735 <p><b>Discussion:</b></p>
4736 <p>Table 72 in 24.2.3 [input.iterators] specifies semantics for
4737 <tt>*r++</tt> of:</p>
4738
4739 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
4740
4741 <p>There are two problems with this.  First, the return type is
4742 specified to be "T", as opposed to something like "convertible to T".
4743 This is too specific: we want to allow *r++ to return an lvalue.</p>
4744
4745 <p>Second, writing the semantics in terms of code misleadingly
4746 suggests that the effects *r++ should precisely replicate the behavior
4747 of this code, including side effects.  (Does this mean that *r++
4748 should invoke the copy constructor exactly as many times as the sample
4749 code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
4750 problem.</p>
4751
4752
4753
4754 <p><b>Proposed resolution:</b></p>
4755 <p>In Table 72 in 24.2.3 [input.iterators], change the return type
4756 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
4757
4758
4759 <p><b>Rationale:</b></p>
4760 <p>This issue has two parts: the return type, and the number of times
4761   the copy constructor is invoked.</p>
4762
4763 <p>The LWG believes the the first part is a real issue.  It's
4764   inappropriate for the return type to be specified so much more
4765   precisely for *r++ than it is for *r.  In particular, if r is of
4766   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
4767   but <tt>int&amp;</tt>.</p>
4768
4769 <p>The LWG does not believe that the number of times the copy
4770   constructor is invoked is a real issue.  This can vary in any case,
4771   because of language rules on copy constructor elision.  That's too
4772   much to read into these semantics clauses.</p>
4773
4774 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since 
4775    we're told (24.1/3) that forward iterators satisfy all the requirements
4776    of input iterators, we can't impose any requirements in the Input
4777    Iterator requirements table that forward iterators don't satisfy.</p>
4778
4779
4780
4781
4782
4783 <hr>
4784 <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
4785 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4786  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
4787 <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>
4788 <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>
4789 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4790 <p><b>Discussion:</b></p>
4791 <p>Set::iterator is described as implementation-defined with a
4792 reference to the container requirement; the container requirement says
4793 that const_iterator is an iterator pointing to const T and iterator an
4794 iterator pointing to T.</p>
4795
4796 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
4797 break the ordering of elements. But that is not clearly
4798 specified. Especially considering that the current standard requires
4799 that iterator for associative containers be different from
4800 const_iterator. Set, for example, has the following: </p>
4801
4802 <p><tt>typedef implementation defined iterator;<br>
4803 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
4804
4805 <p>23.2 [container.requirements] actually requires that iterator type pointing
4806 to T (table 65). Disallowing user modification of keys by changing the
4807 standard to require an iterator for associative container to be the
4808 same as const_iterator would be overkill since that will unnecessarily
4809 significantly restrict the usage of associative container. A class to
4810 be used as elements of set, for example, can no longer be modified
4811 easily without either redesigning the class (using mutable on fields
4812 that have nothing to do with ordering), or using const_cast, which
4813 defeats requiring iterator to be const_iterator. The proposed solution
4814 goes in line with trusting user knows what he is doing. </p>
4815
4816 <p><b>Other Options Evaluated:</b> </p>
4817
4818 <p>Option A.&nbsp;&nbsp; In 23.2.4 [associative.reqmts], paragraph 2, after
4819 first sentence, and before "In addition,...", add one line:
4820 </p>
4821
4822 <blockquote>
4823   <p>Modification of keys shall not change their strict weak ordering. </p>
4824 </blockquote>
4825
4826 <p>Option B.&nbsp;Add three new sentences to 23.2.4 [associative.reqmts]:</p>
4827
4828 <blockquote>
4829   <p>At the end of paragraph 5: "Keys in an associative container
4830   are immutable." At the end of paragraph 6: "For
4831   associative containers where the value type is the same as the key
4832   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
4833   constant iterators. It is unspecified whether or not
4834   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
4835   type."</p>
4836 </blockquote>
4837
4838 <p>Option C.&nbsp;To 23.2.4 [associative.reqmts], paragraph 3, which
4839 currently reads:</p>
4840
4841 <blockquote>
4842   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
4843   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
4844   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
4845   == false &amp;&amp; comp(k2, k1) == false.</p>
4846 </blockquote>
4847
4848 <p>&nbsp; add the following:</p>
4849
4850 <blockquote>
4851   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
4852   value whenever it is evaluated. [Note: If k2 is removed from the container and later
4853   reinserted, comp(k1, k2) must still return a consistent value but this value may be
4854   different than it was the first time k1 and k2 were in the same container. This is
4855   intended to allow usage like a string key that contains a filename, where comp compares
4856   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
4857   reinserted, comp(k1, k2) must again return a consistent value but this value may be
4858   different than it was the previous time k2 was in the container.]</p>
4859 </blockquote>
4860
4861
4862
4863 <p><b>Proposed resolution:</b></p>
4864 <p>Add the following to 23.2.4 [associative.reqmts] at
4865 the indicated location:</p>
4866
4867 <blockquote>
4868   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
4869   calling comp(k1, k2) shall always return the same
4870   value."</p>
4871   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
4872   <p>At the end of paragraph 6: "For associative containers where the value type is the
4873   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
4874   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
4875   are the same type."</p>
4876 </blockquote>
4877
4878
4879 <p><b>Rationale:</b></p>
4880 <p>Several arguments were advanced for and against allowing set elements to be
4881 mutable as long as the ordering was not effected. The argument which swayed the
4882 LWG was one of safety; if elements were mutable, there would be no compile-time
4883 way to detect of a simple user oversight which caused ordering to be
4884 modified.  There was a report that this had actually happened in practice,
4885 and had been painful to diagnose.  If users need to modify elements,
4886 it is possible to use mutable members or const_cast.</p>
4887
4888 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
4889 object may indirectly (via pointers) operate on values outside of the keys.</p>
4890
4891 <p>
4892 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
4893 to be different types to allow for potential future work in which some
4894 member functions might be overloaded between the two types.  No such
4895 member functions exist now, and the LWG believes that user functionality
4896 will not be impaired by permitting the two types to be the same.  A
4897 function that operates on both iterator types can be defined for 
4898 <tt>const_iterator</tt> alone, and can rely on the automatic
4899 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
4900 </p>
4901
4902 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
4903
4904
4905
4906
4907
4908
4909 <hr>
4910 <h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
4911 <p><b>Section:</b> 26.6.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4912  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
4913 <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>
4914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4915 <p><b>Discussion:</b></p>
4916 <p>This is the only place in the whole standard where the implementation has to document
4917 something private.</p>
4918
4919
4920 <p><b>Proposed resolution:</b></p>
4921 <p>
4922 Remove the comment which says "// remainder implementation defined" from:
4923 </p>
4924
4925 <ul>
4926   <li>26.6.5 [template.slice.array]</li>
4927   <li>26.6.7 [template.gslice.array]</li>
4928   <li>26.6.8 [template.mask.array]</li>
4929   <li>26.6.9 [template.indirect.array]</li>
4930 </ul>
4931
4932
4933
4934
4935
4936 <hr>
4937 <h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
4938 <p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
4939  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
4940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
4941 <p><b>Discussion:</b></p>
4942 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
4943 exception::what() is left unspecified. This issue has implications
4944 with exception safety of exception handling: some exceptions should
4945 not throw bad_alloc.</p>
4946
4947
4948 <p><b>Proposed resolution:</b></p>
4949 <p>Add to 18.7.1 [type.info] paragraph 9 (exception::what notes
4950 clause) the sentence:</p>
4951
4952 <blockquote>
4953   <p>The return value remains valid until the exception object from which it is obtained is
4954   destroyed or a non-const member function of the exception object is called.</p>
4955 </blockquote>
4956
4957
4958 <p><b>Rationale:</b></p>
4959 <p>If an exception object has non-const members, they may be used
4960 to set internal state that should affect the contents of the string
4961 returned by <tt>what()</tt>.
4962 </p>
4963
4964
4965
4966
4967
4968 <hr>
4969 <h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
4970 <p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4971  <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
4972 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
4973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4974 <p><b>Discussion:</b></p>
4975
4976 <p>There are no versions of binders that apply to non-const elements
4977 of a sequence. This makes examples like for_each() using bind2nd() on
4978 page 521 of "The C++ Programming Language (3rd)"
4979 non-conforming. Suitable versions of the binders need to be added.</p>
4980
4981 <p>Further discussion from Nico:</p>
4982
4983 <p>What is probably meant here is shown in the following example:</p>
4984
4985 <pre>class Elem { 
4986   public: 
4987     void print (int i) const { } 
4988     void modify (int i) { } 
4989 }; </pre>
4990 <pre>int main() 
4991
4992     vector&lt;Elem&gt; coll(2); 
4993     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK 
4994     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR 
4995 }</pre>
4996
4997 <p>The error results from the fact that bind2nd() passes its first
4998 argument (the argument of the sequence) as constant reference. See the
4999 following typical implementation:</p>
5000
5001 <blockquote>
5002   <pre>template &lt;class Operation&gt; 
5003 class binder2nd 
5004   : public unary_function&lt;typename Operation::first_argument_type, 
5005                           typename Operation::result_type&gt; { 
5006 protected: 
5007   Operation op; 
5008   typename Operation::second_argument_type value; 
5009 public: 
5010   binder2nd(const Operation&amp; o, 
5011             const typename Operation::second_argument_type&amp; v) 
5012       : op(o), value(v) {} </pre>
5013   <pre> typename Operation::result_type 
5014   operator()(const typename Operation::first_argument_type&amp; x) const { 
5015     return op(x, value); 
5016   } 
5017 };</pre>
5018 </blockquote>
5019
5020 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
5021
5022 <blockquote>
5023   <pre>template &lt;class Operation&gt; 
5024 class binder2nd 
5025   : public unary_function&lt;typename Operation::first_argument_type, 
5026                           typename Operation::result_type&gt; { 
5027 protected: 
5028   Operation op; 
5029   typename Operation::second_argument_type value; 
5030 public: 
5031   binder2nd(const Operation&amp; o, 
5032             const typename Operation::second_argument_type&amp; v) 
5033       : op(o), value(v) {} </pre>
5034   <pre> typename Operation::result_type 
5035   operator()(const typename Operation::first_argument_type&amp; x) const { 
5036     return op(x, value); 
5037   } 
5038   typename Operation::result_type 
5039   operator()(typename Operation::first_argument_type&amp; x) const { 
5040     return op(x, value); 
5041   } 
5042 };</pre>
5043 </blockquote>
5044
5045
5046 <p><b>Proposed resolution:</b></p>
5047
5048 <p><b>Howard believes there is a flaw</b> in this resolution.
5049 See c++std-lib-9127.  We may need to reopen this issue.</p>
5050
5051 <p>In D.11 [depr.lib.binders] in the declaration of binder1st after:</p>
5052 <blockquote>
5053   <p><tt>typename Operation::result_type<br>
5054   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
5055 </blockquote>
5056 <p>insert:</p>
5057 <blockquote>
5058   <p><tt>typename Operation::result_type<br>
5059   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
5060 </blockquote>
5061 <p>In D.11 [depr.lib.binders] in the declaration of binder2nd after:</p>
5062 <blockquote>
5063   <p><tt>typename Operation::result_type<br>
5064   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
5065 </blockquote>
5066 <p>insert:</p>
5067 <blockquote>
5068   <p><tt>typename Operation::result_type<br>
5069   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
5070 </blockquote>
5071
5072 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
5073 this is a mistake in the design, but there was no consensus on whether
5074 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
5075 proposed resolution - 3.  Leave open - 6.]</i></p>
5076
5077
5078 <p><i>[Copenhagen: It was generally agreed that this was a defect.
5079 Strap poll: NAD - 0.  Accept proposed resolution - 10. 
5080 Leave open - 1.]</i></p>
5081
5082
5083
5084
5085
5086
5087
5088 <hr>
5089 <h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
5090 <p><b>Section:</b> 24.6.3 [istreambuf.iterator], 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5091  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2010-10-29</p>
5092 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
5093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5094 <p><b>Discussion:</b></p>
5095 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
5096 "const", yet 24.6.3.6 [istreambuf.iterator::op==] says that operator==,
5097 which is const, calls it. This is contradictory. </p>
5098
5099
5100 <p><b>Proposed resolution:</b></p>
5101 <p>In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal],
5102 replace:</p>
5103
5104 <blockquote>
5105   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
5106 </blockquote>
5107
5108 <p>with:</p>
5109
5110 <blockquote>
5111   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
5112 </blockquote>
5113
5114
5115
5116
5117
5118 <hr>
5119 <h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
5120 <p><b>Section:</b> 24.6.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5121  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-10-20 <b>Last modified:</b> 2010-10-29</p>
5122 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5123 <p><b>Discussion:</b></p>
5124 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
5125 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
5126 reads "<i>s</i> is not null". However, <i>s</i> is a
5127 reference, and references can't be null. </p>
5128
5129
5130 <p><b>Proposed resolution:</b></p>
5131 <p>In 24.6.4.1 [ostreambuf.iter.cons]:</p>
5132
5133 <p>Move the current paragraph 1, which reads "Requires: s is not
5134 null.", from the first constructor to the second constructor.</p>
5135
5136 <p>Insert a new paragraph 1 Requires clause for the first constructor
5137 reading:</p>
5138
5139 <blockquote>
5140   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
5141 </blockquote>
5142
5143
5144
5145
5146
5147 <hr>
5148 <h3><a name="114"></a>114. Placement forms example in error twice</h3>
5149 <p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5150  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-28 <b>Last modified:</b> 2010-10-29</p>
5151 <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>
5152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5153 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
5154 <p><b>Discussion:</b></p>
5155 <p>Section 18.5.1.3 contains the following example: </p>
5156
5157 <pre>[Example: This can be useful for constructing an object at a known address:
5158         char place[sizeof(Something)];
5159         Something* p = new (place) Something();
5160  -end example]</pre>
5161
5162 <p>First code line: "place" need not have any special alignment, and the
5163 following constructor could fail due to misaligned data.</p>
5164
5165 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
5166 believes the () are correct.]</p>
5167
5168 <p>Examples are not normative, but nevertheless should not show code that is invalid or
5169 likely to fail.</p>
5170
5171
5172 <p><b>Proposed resolution:</b></p>
5173 <p>Replace the first line of code in the example in 
5174 18.6.1.3 [new.delete.placement] with:
5175 </p>
5176
5177 <blockquote>
5178   <pre>void* place = operator new(sizeof(Something));</pre>
5179 </blockquote>
5180
5181
5182
5183
5184
5185 <hr>
5186 <h3><a name="115"></a>115. Typo in strstream constructors</h3>
5187 <p><b>Section:</b> D.9.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5188  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-11-02 <b>Last modified:</b> 2010-10-29</p>
5189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5190 <p><b>Discussion:</b></p>
5191 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
5192
5193 <blockquote>
5194   <p>Effects: Constructs an object of class strstream, initializing the base class with
5195   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
5196   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
5197   elements. The constructor is strstreambuf(s, n, s). </p>
5198   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
5199   elements that contains an NTBS whose first element is designated by s. The constructor is
5200   strstreambuf(s, n, s+std::strlen(s)).</p>
5201 </blockquote>
5202
5203 <p>Notice the second condition is the same as the first. I think the second condition
5204 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
5205 the append bit is set.</p>
5206
5207
5208 <p><b>Proposed resolution:</b></p>
5209 <p>In D.9.3.1 [depr.ostrstream.cons] paragraph 2 and D.9.4.1 [depr.strstream.cons]
5210 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
5211 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
5212
5213
5214
5215
5216
5217 <hr>
5218 <h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
5219 <p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
5220  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2010-10-29</p>
5221 <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>
5222 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5223 <p><b>Discussion:</b></p>
5224 <p>The <b>effects</b> clause for numeric inserters says that
5225 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
5226 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
5227 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
5228 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
5229 delegated to <tt>num_put</tt>, and that insertion is performed as if
5230 through the following code fragment: </p>
5231
5232 <pre>bool failed = use_facet&lt;
5233    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt; 
5234    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
5235
5236 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
5237 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
5238 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
5239 void*</tt>. That is, the code fragment in the standard is incorrect
5240 (it is diagnosed as ambiguous at compile time) for the types
5241 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
5242 int</tt>, and <tt>float</tt>. </p>
5243
5244 <p>We must either add new member functions to <tt>num_put</tt>, or
5245 else change the description in <tt>ostream</tt> so that it only calls
5246 functions that are actually there. I prefer the latter. </p>
5247
5248
5249 <p><b>Proposed resolution:</b></p>
5250 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
5251
5252 <blockquote>
5253 <p>
5254 The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
5255 formatting and parsing.  These inserter functions use the imbued
5256 locale value to perform numeric formatting.  When val is of type bool,
5257 long, unsigned long, double, long double, or const void*, the
5258 formatting conversion occurs as if it performed the following code
5259 fragment:
5260 </p>
5261
5262 <pre>bool failed = use_facet&lt;
5263    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5264    &gt;(getloc()).put(*this, *this, fill(), val). failed();
5265 </pre>
5266
5267 <p>
5268 When val is of type short the formatting conversion occurs as if it
5269 performed the following code fragment:
5270 </p>
5271
5272 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
5273 bool failed = use_facet&lt;
5274    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5275    &gt;(getloc()).put(*this, *this, fill(),
5276       baseflags == ios_base::oct || baseflags == ios_base::hex
5277          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
5278          : static_cast&lt;long&gt;(val)). failed();
5279 </pre>
5280
5281 <p>
5282 When val is of type int the formatting conversion occurs as if it performed
5283 the following code fragment:
5284 </p>
5285
5286 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
5287 bool failed = use_facet&lt;
5288    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5289    &gt;(getloc()).put(*this, *this, fill(),
5290       baseflags == ios_base::oct || baseflags == ios_base::hex
5291          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
5292          : static_cast&lt;long&gt;(val)). failed();
5293 </pre>
5294
5295 <p>
5296 When val is of type unsigned short or unsigned int the formatting conversion
5297 occurs as if it performed the following code fragment:
5298 </p>
5299
5300 <pre>bool failed = use_facet&lt;
5301    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5302    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
5303 failed();
5304 </pre>
5305
5306 <p>
5307 When val is of type float the formatting conversion occurs as if it
5308 performed the following code fragment:
5309 </p>
5310
5311 <pre>bool failed = use_facet&lt;
5312    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5313    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
5314 failed();
5315 </pre>
5316
5317 </blockquote>
5318
5319 <p><i>[post-Toronto: This differs from the previous proposed
5320 resolution; PJP provided the new wording.  The differences are in
5321 signed short and int output.]</i></p>
5322
5323
5324
5325 <p><b>Rationale:</b></p>
5326 <p>The original proposed resolution was to cast int and short to long,
5327 unsigned int and unsigned short to unsigned long, and float to double,
5328 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
5329 member functions.  The current proposed resolution is more
5330 complicated, but gives more expected results for hex and octal output
5331 of signed short and signed int.  (On a system with 16-bit short, for
5332 example, printing short(-1) in hex format should yield 0xffff.)</p>
5333
5334
5335
5336
5337
5338 <hr>
5339 <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
5340 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
5341  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2010-10-29</p>
5342 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
5343 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5344 <p><b>Discussion:</b></p>
5345 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
5346 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
5347 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
5348 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
5349
5350 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget; 
5351 iostate err = 0; 
5352 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val); 
5353 setstate(err);</pre>
5354
5355 <p>According to section 22.4.2.1.1 [facet.num.get.members], however,
5356 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
5357 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
5358 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
5359 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
5360 <tt>void*</tt>. Comparing the lists from the two sections, we find
5361 that 27.6.1.2.2 is using a nonexistent function for types
5362 <tt>short</tt> and <tt>int</tt>. </p>
5363
5364
5365 <p><b>Proposed resolution:</b></p>
5366 <p>In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
5367 two lines (1st and 3rd) which read:</p>
5368 <blockquote>
5369   <pre>operator&gt;&gt;(short&amp; val);
5370 ...
5371 operator&gt;&gt;(int&amp; val);</pre>
5372 </blockquote>
5373
5374 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
5375
5376 <blockquote>
5377   <pre>operator&gt;&gt;(short&amp; val);</pre>
5378   <p>The conversion occurs as if performed by the following code fragment (using
5379   the same notation as for the preceding code fragment):</p>
5380   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
5381   iostate err = 0;
5382   long lval;
5383   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
5384         if (err == 0
5385                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
5386                 err = ios_base::failbit;
5387   setstate(err);</pre>
5388   <pre>operator&gt;&gt;(int&amp; val);</pre>
5389   <p>The conversion occurs as if performed by the following code fragment (using
5390   the same notation as for the preceding code fragment):</p>
5391   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
5392   iostate err = 0;
5393   long lval;
5394   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
5395         if (err == 0
5396                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
5397                 err = ios_base::failbit;
5398   setstate(err);</pre>
5399 </blockquote>
5400
5401 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
5402
5403
5404
5405
5406
5407
5408 <hr>
5409 <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
5410 <p><b>Section:</b> 17.6.4.12 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5411  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5412 <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>
5413 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5414 <p><b>Discussion:</b></p>
5415 <p>Section 17.6.4.12 [res.on.exception.handling] states: </p>
5416
5417 <p>"An implementation may strengthen the exception-specification
5418 for a function by removing listed exceptions." </p>
5419
5420 <p>The problem is that if an implementation is allowed to do this for
5421 virtual functions, then a library user cannot write a class that
5422 portably derives from that class. </p>
5423
5424 <p>For example, this would not compile if ios_base::failure::~failure
5425 had an empty exception specification: </p>
5426
5427 <pre>#include &lt;ios&gt;
5428 #include &lt;string&gt;
5429
5430 class D : public std::ios_base::failure {
5431 public:
5432         D(const std::string&amp;);
5433         ~D(); // error - exception specification must be compatible with 
5434               // overridden virtual function ios_base::failure::~failure()
5435 };</pre>
5436
5437
5438 <p><b>Proposed resolution:</b></p>
5439 <p>Change Section 17.6.4.12 [res.on.exception.handling] from:</p>
5440
5441 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
5442 exception-specification for a function"</p>
5443
5444 <p>to:</p>
5445
5446 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
5447 exception-specification for a non-virtual function". </p>
5448
5449
5450
5451
5452
5453 <hr>
5454 <h3><a name="120"></a>120. Can an implementor add specializations?</h3>
5455 <p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
5456  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5457 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
5458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5459 <p><b>Discussion:</b></p>
5460
5461 <p>The original issue asked whether a library implementor could
5462 specialize standard library templates for built-in types.  (This was
5463 an issue because users are permitted to explicitly instantiate
5464 standard library templates.)</p>
5465
5466 <p>Specializations are no longer a problem, because of the resolution
5467 to core issue 259.  Under the proposed resolution, it will be legal
5468 for a translation unit to contain both a specialization and an
5469 explicit instantiation of the same template, provided that the
5470 specialization comes first.  In such a case, the explicit
5471 instantiation will be ignored.  Further discussion of library issue
5472 120 assumes that the core 259 resolution will be adopted.</p>
5473
5474 <p>However, as noted in lib-7047, one piece of this issue still
5475 remains: what happens if a standard library implementor explicitly
5476 instantiates a standard library templates?  It's illegal for a program
5477 to contain two different explicit instantiations of the same template
5478 for the same type in two different translation units (ODR violation),
5479 and the core working group doesn't believe it is practical to relax
5480 that restriction.</p>
5481
5482 <p>The issue, then, is: are users allowed to explicitly instantiate
5483 standard library templates for non-user defined types?  The status quo
5484 answer is 'yes'.  Changing it to 'no' would give library implementors
5485 more freedom.</p>
5486
5487 <p>This is an issue because, for performance reasons, library
5488 implementors often need to explicitly instantiate standard library
5489 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
5490 users freedom to explicitly instantiate standard library templates for
5491 non-user defined types make it impossible or painfully difficult for
5492 library implementors to do this?</p>
5493
5494 <p>John Spicer suggests, in lib-8957, that library implementors have a
5495 mechanism they can use for explicit instantiations that doesn't
5496 prevent users from performing their own explicit instantiations: put
5497 each explicit instantiation in its own object file.  (Different
5498 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
5499 some platforms, library implementors might not need to do anything
5500 special: the "undefined behavior" that results from having two
5501 different explicit instantiations might be harmless.</p>
5502
5503
5504
5505 <p><b>Proposed resolution:</b></p>
5506   <p>Append to 17.6.3.3 [reserved.names] paragraph 1: </p>
5507   <blockquote><p>
5508     A program may explicitly instantiate any templates in the standard
5509     library only if the declaration depends on the name of a user-defined
5510     type of external linkage and the instantiation meets the standard library
5511     requirements for the original template.
5512   </p></blockquote>
5513
5514 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
5515   a user-defined type"]</i></p>
5516
5517
5518
5519
5520 <p><b>Rationale:</b></p>
5521 <p>The LWG considered another possible resolution:</p>
5522 <blockquote>
5523   <p>In light of the resolution to core issue 259, no normative changes
5524   in the library clauses are necessary.  Add the following non-normative
5525   note to the end of 17.6.3.3 [reserved.names] paragraph 1:</p>
5526   <blockquote><p>
5527     [<i>Note:</i> A program may explicitly instantiate standard library
5528     templates, even when an explicit instantiation does not depend on
5529     a user-defined name. <i>--end note</i>]
5530   </p></blockquote>
5531 </blockquote>
5532
5533 <p>The LWG rejected this because it was believed that it would make
5534   it unnecessarily difficult for library implementors to write
5535   high-quality implementations.  A program may not include an
5536   explicit instantiation of the same template, for the same template
5537   arguments, in two different translation units.  If users are
5538   allowed to provide explicit instantiations of Standard Library
5539   templates for built-in types, then library implementors aren't,
5540   at least not without nonportable tricks.</p>
5541
5542 <p>The most serious problem is a class template that has writeable
5543   static member variables.  Unfortunately, such class templates are
5544   important and, in existing Standard Library implementations, are
5545   often explicitly specialized by library implementors: locale facets,
5546   which have a writeable static member variable <tt>id</tt>.  If a
5547   user's explicit instantiation collided with the implementations
5548   explicit instantiation, iostream initialization could cause locales
5549   to be constructed in an inconsistent state.</p>
5550
5551 <p>One proposed implementation technique was for Standard Library
5552   implementors to provide explicit instantiations in separate object
5553   files, so that they would not be picked up by the linker when the
5554   user also provides an explicit instantiation.  However, this
5555   technique only applies for Standard Library implementations that
5556   are packaged as static archives.  Most Standard Library
5557   implementations nowadays are packaged as dynamic libraries, so this
5558   technique would not apply.</p>
5559
5560 <p>The Committee is now considering standardization of dynamic
5561   linking.  If there are such changes in the future, it may be
5562   appropriate to revisit this issue later.</p>
5563
5564
5565
5566
5567
5568 <hr>
5569 <h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
5570 <p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5571  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5572 <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>
5573 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5574 <p><b>Discussion:</b></p>
5575 <p>Section 27.5.2 describes the streambuf classes this way: </p>
5576
5577 <blockquote>
5578
5579 <p>The class streambuf is a specialization of the template class basic_streambuf
5580 specialized for the type char. </p>
5581
5582 <p>The class wstreambuf is a specialization of the template class basic_streambuf
5583 specialized for the type wchar_t. </p>
5584
5585 </blockquote>
5586
5587 <p>This implies that these classes must be template specializations, not typedefs. </p>
5588
5589 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
5590
5591
5592 <p><b>Proposed resolution:</b></p>
5593 <p>Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two
5594 sentences). </p>
5595
5596
5597 <p><b>Rationale:</b></p>
5598 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
5599 typedefs and that is sufficient. </p>
5600
5601
5602
5603
5604
5605 <hr>
5606 <h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
5607 <p><b>Section:</b> 26.6.5.3 [slice.arr.fill], 26.6.7.3 [gslice.array.fill], 26.6.8.3 [mask.array.fill], 26.6.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
5608  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5609 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5610 <p><b>Discussion:</b></p>
5611 <p>One of the operator= in the valarray helper arrays is const and one
5612 is not. For example, look at slice_array. This operator= in Section
5613 26.6.5.1 [slice.arr.assign] is const: </p>
5614
5615 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
5616
5617 <p>but this one in Section 26.6.5.3 [slice.arr.fill] is not: </p>
5618
5619 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
5620
5621 <p>The description of the semantics for these two functions is similar. </p>
5622
5623
5624 <p><b>Proposed resolution:</b></p>
5625
5626 <p>26.6.5 [template.slice.array] Template class slice_array</p>
5627 <blockquote>
5628
5629    <p>In the class template definition for slice_array, replace the member
5630    function declaration</p>
5631     <pre>      void operator=(const T&amp;);
5632     </pre>
5633    <p>with</p>
5634     <pre>      void operator=(const T&amp;) const;
5635     </pre>
5636 </blockquote>
5637
5638 <p>26.6.5.3 [slice.arr.fill] slice_array fill function</p>
5639 <blockquote>
5640
5641    <p>Change the function declaration</p>
5642     <pre>      void operator=(const T&amp;);
5643     </pre>
5644    <p>to</p>
5645     <pre>      void operator=(const T&amp;) const;
5646     </pre>
5647 </blockquote>
5648
5649 <p>26.6.7 [template.gslice.array] Template class gslice_array</p>
5650 <blockquote>
5651
5652    <p>In the class template definition for gslice_array, replace the member
5653    function declaration</p>
5654     <pre>      void operator=(const T&amp;);
5655     </pre>
5656    <p>with</p>
5657     <pre>      void operator=(const T&amp;) const;
5658     </pre>
5659 </blockquote>
5660
5661 <p>26.6.7.3 [gslice.array.fill] gslice_array fill function</p>
5662 <blockquote>
5663
5664    <p>Change the function declaration</p>
5665     <pre>      void operator=(const T&amp;);
5666     </pre>
5667    <p>to</p>
5668     <pre>      void operator=(const T&amp;) const;
5669     </pre>
5670 </blockquote>
5671
5672 <p>26.6.8 [template.mask.array] Template class mask_array</p>
5673 <blockquote>
5674
5675    <p>In the class template definition for mask_array, replace the member
5676    function declaration</p>
5677     <pre>      void operator=(const T&amp;);
5678     </pre>
5679    <p>with</p>
5680     <pre>      void operator=(const T&amp;) const;
5681     </pre>
5682 </blockquote>
5683
5684 <p>26.6.8.3 [mask.array.fill] mask_array fill function</p>
5685 <blockquote>
5686
5687    <p>Change the function declaration</p>
5688     <pre>      void operator=(const T&amp;);
5689     </pre>
5690    <p>to</p>
5691     <pre>      void operator=(const T&amp;) const;
5692     </pre>
5693 </blockquote>
5694
5695 <p>26.6.9 [template.indirect.array] Template class indirect_array</p>
5696 <blockquote>
5697
5698    <p>In the class template definition for indirect_array, replace the member
5699    function declaration</p>
5700     <pre>      void operator=(const T&amp;);
5701     </pre>
5702    <p>with</p>
5703     <pre>      void operator=(const T&amp;) const;
5704     </pre>
5705 </blockquote>
5706
5707 <p>26.6.9.3 [indirect.array.fill] indirect_array fill function</p>
5708 <blockquote>
5709
5710    <p>Change the function declaration</p>
5711     <pre>      void operator=(const T&amp;);
5712     </pre>
5713    <p>to</p>
5714     <pre>      void operator=(const T&amp;) const;
5715     </pre>
5716 </blockquote>
5717
5718
5719 <p><i>[Redmond: Robert provided wording.]</i></p>
5720
5721
5722
5723
5724 <p><b>Rationale:</b></p>
5725 <p>There's no good reason for one version of operator= being const and
5726 another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
5727 matters: these functions are now callable in more circumstances.  In
5728 many existing implementations, both versions are already const.</p>
5729
5730
5731
5732
5733
5734 <hr>
5735 <h3><a name="124"></a>124. ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3>
5736 <p><b>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5737  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5738 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
5739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5740 <p><b>Discussion:</b></p>
5741 <p>In Section 22.4.1.2 [locale.ctype.byname]
5742 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
5743 to return a const char* not a const charT*. </p>
5744
5745
5746 <p><b>Proposed resolution:</b></p>
5747 <p>Change Section 22.4.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
5748 <tt>do_scan_not()</tt> to return a <tt> const
5749 charT*</tt>. </p>
5750
5751
5752
5753
5754
5755 <hr>
5756 <h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
5757 <p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5758  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5759 <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>
5760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5761 <p><b>Discussion:</b></p>
5762 <p>In Section 26.6.2 [template.valarray] valarray&lt;T&gt;::operator!() is
5763 declared to return a valarray&lt;T&gt;, but in Section 26.6.2.5 [valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
5764 latter appears to be correct. </p>
5765
5766
5767 <p><b>Proposed resolution:</b></p>
5768 <p>Change in Section 26.6.2 [template.valarray] the declaration of
5769 <tt>operator!()</tt> so that the return type is
5770 <tt>valarray&lt;bool&gt;</tt>. </p>
5771
5772
5773
5774
5775 <hr>
5776 <h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
5777 <p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5778  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
5779 <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>
5780 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5781 <p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
5782
5783 <p><b>Proposed resolution:</b></p>
5784 <p>In Section 22.4.1.1.2 [locale.ctype.virtuals] change: </p>
5785
5786 <pre>   do_widen(do_narrow(c),0) == c</pre>
5787
5788 <p>to:</p>
5789
5790 <pre>   do_widen(do_narrow(c,0)) == c</pre>
5791
5792 <p>and change:</p>
5793
5794 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
5795
5796 <p>to:</p>
5797
5798 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
5799
5800
5801
5802
5803
5804 <hr>
5805 <h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
5806 <p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5807  <b>Submitter:</b> Greg Colvin <b>Opened:</b> 1999-02-17 <b>Last modified:</b> 2010-10-29</p>
5808 <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>
5809 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5810 <p><b>Discussion:</b></p>
5811 <p>There are two problems with the current <tt>auto_ptr</tt> wording
5812 in the standard: </p>
5813
5814 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
5815 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
5816 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
5817 Nathan Myers, with the same proposed resolution.</i></p>
5818
5819 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
5820 <tt>auto_ptr_ref</tt> argument. </p>
5821
5822 <p>I have discussed these problems with my proposal coauthor, Bill
5823 Gibbons, and with some compiler and library implementors, and we
5824 believe that these problems are not desired or desirable implications
5825 of the standard. </p>
5826
5827 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
5828 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
5829 "assignment operator" to "public assignment
5830 operator", 2) changed effects to specify use of release(), 3)
5831 made the conversion to auto_ptr_ref const. </p>
5832
5833 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
5834 states that the conversion from auto_ptr to auto_ptr_ref should
5835 be const.  This is not acceptable, because it would allow
5836 initialization and assignment from _any_ const auto_ptr!  It also
5837 introduces an implementation difficulty in writing this conversion
5838 function -- namely, somewhere along the line, a const_cast will be
5839 necessary to remove that const so that release() may be called.  This
5840 may result in undefined behavior [7.1.5.1/4]. The conversion
5841 operator does not have to be const, because a non-const implicit
5842 object parameter may be bound to an rvalue [13.3.3.1.4/3]
5843 [13.3.1/5]. </p>
5844
5845   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
5846
5847   <p>In 20.7.4 [meta.unary], paragraph 2, and 20.7.4.3 [meta.unary.prop], 
5848   paragraph 2, make the conversion to auto_ptr_ref const:</p>
5849   <blockquote>
5850     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
5851   </blockquote>
5852
5853
5854 <p><b>Proposed resolution:</b></p>
5855 <p>In 20.7.4 [meta.unary], paragraph 2, move
5856 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
5857
5858 <p>In 20.7.4 [meta.unary], paragraph 2, add
5859 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
5860
5861 <blockquote>
5862   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
5863 </blockquote>
5864
5865 <p>Also add the assignment operator to 20.7.4.3 [meta.unary.prop]: </p>
5866
5867 <blockquote>
5868   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
5869
5870   <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
5871   p</tt> that <tt>r</tt> holds a reference to.<br>
5872   <b>Returns: </b><tt>*this</tt>.</p>
5873
5874 </blockquote>
5875
5876
5877
5878
5879
5880 <hr>
5881 <h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
5882 <p><b>Section:</b> 27.7.1.3 [istream.unformatted], 27.7.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5883  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2010-10-29</p>
5884 <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>
5885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
5886 <p><b>Discussion:</b></p>
5887 <p>Currently, the standard does not specify how seekg() and seekp()
5888 indicate failure. They are not required to set failbit, and they can't
5889 return an error indication because they must return *this, i.e. the
5890 stream. Hence, it is undefined what happens if they fail. And they
5891 <i>can</i> fail, for instance, when a file stream is disconnected from the
5892 underlying file (is_open()==false) or when a wide character file
5893 stream must perform a state-dependent code conversion, etc. </p>
5894
5895 <p>The stream functions seekg() and seekp() should set failbit in the
5896 stream state in case of failure.</p>
5897
5898
5899 <p><b>Proposed resolution:</b></p>
5900 <p>Add to the Effects: clause of&nbsp; seekg() in 
5901 27.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
5902 27.7.2.5 [ostream.seeks]: </p>
5903
5904 <blockquote>
5905   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
5906   </p>
5907 </blockquote>
5908
5909
5910 <p><b>Rationale:</b></p>
5911 <p>Setting failbit is the usual error reporting mechanism for streams</p>
5912
5913
5914
5915
5916 <hr>
5917 <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
5918 <p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
5919  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-02 <b>Last modified:</b> 2010-10-29</p>
5920 <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>
5921 <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>
5922 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5923 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
5924 <p><b>Discussion:</b></p>
5925 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
5926 iterator. Table 69 (23.1.2) says that in addition to this requirement,
5927 associative containers also say that container::erase(iterator)
5928 returns void.  That's not an addition; it's a change to the
5929 requirements, which has the effect of making associative containers
5930 fail to meet the requirements for containers.</p>
5931
5932
5933 <p><b>Proposed resolution:</b></p>
5934
5935 <p>
5936 In 23.2.4 [associative.reqmts], in Table 69 Associative container
5937 requirements, change the return type of <tt>a.erase(q)</tt> from
5938 <tt>void</tt> to <tt>iterator</tt>.  Change the
5939 assertion/not/pre/post-condition from "erases the element pointed to
5940 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
5941 Returns an iterator pointing to the element immediately following q
5942 prior to the element being erased. If no such element exists, a.end()
5943 is returned."
5944 </p>
5945
5946 <p>
5947 In 23.2.4 [associative.reqmts], in Table 69 Associative container
5948 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
5949 from <tt>void</tt> to <tt>iterator</tt>.  Change the
5950 assertion/not/pre/post-condition from "erases the elements in the
5951 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
5952 q2)</tt>.  Returns q2."
5953 </p>
5954
5955 <p>
5956 In 23.6.1 [map], in the <tt>map</tt> class synopsis; and 
5957 in 23.6.2 [multimap], in the <tt>multimap</tt> class synopsis; and
5958 in 23.6.3 [set], in the <tt>set</tt> class synopsis; and
5959 in 23.6.4 [multiset], in the <tt>multiset</tt> class synopsis:
5960 change the signature of the first <tt>erase</tt> overload to
5961 </p>
5962 <pre>   iterator erase(iterator position);
5963 </pre>
5964 <p>and change the signature of the third <tt>erase</tt> overload to</p>
5965 <pre>  iterator erase(iterator first, iterator last); 
5966 </pre>
5967
5968
5969 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
5970
5971
5972 <p><i>[Post-Kona: the LWG agrees the return type should be
5973 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
5974 Matt provided wording.]</i></p>
5975
5976
5977 <p><i>[
5978  Sydney: the proposed wording went in the right direction, but it
5979  wasn't good enough. We want to return an iterator from the range form
5980  of erase as well as the single-iterator form. Also, the wording is
5981  slightly different from the wording we have for sequences; there's no
5982  good reason for having a difference.  Matt provided new wording,
5983 (reflected above) which we will review at the next meeting.
5984 ]</i></p>
5985
5986
5987 <p><i>[
5988 Redmond:  formally voted into WP.
5989 ]</i></p>
5990
5991
5992
5993
5994
5995
5996
5997 <hr>
5998 <h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
5999 <p><b>Section:</b> 23.3.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6000  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
6001 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.capacity">issues</a> in [list.capacity].</p>
6002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6003 <p><b>Discussion:</b></p>
6004 <p>The description reads:</p>
6005
6006 <p>-1- Effects:</p>
6007
6008 <pre>         if (sz &gt; size())
6009            insert(end(), sz-size(), c);
6010          else if (sz &lt; size())
6011            erase(begin()+sz, end());
6012          else
6013            ;                           //  do nothing</pre>
6014
6015 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
6016
6017
6018 <p><b>Proposed resolution:</b></p>
6019 <p>Change 23.3.4.2 [list.capacity] paragraph 1 to:</p>
6020
6021 <p>Effects:</p>
6022
6023 <pre>         if (sz &gt; size())
6024            insert(end(), sz-size(), c);
6025          else if (sz &lt; size())
6026          {
6027            iterator i = begin();
6028            advance(i, sz);
6029            erase(i, end());
6030          }</pre>
6031
6032 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
6033 with David Abrahams. They had a discussion and believe there is
6034 no issue of exception safety with the proposed resolution.]</i></p>
6035
6036
6037
6038
6039
6040
6041 <hr>
6042 <h3><a name="133"></a>133. map missing get_allocator()</h3>
6043 <p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6044  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
6045 <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>
6046 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6047 <p><b>Discussion:</b></p><p>The title says it all.</p>
6048
6049 <p><b>Proposed resolution:</b></p>
6050 <p>Insert in 23.6.1 [map], paragraph 2,
6051 after operator= in the map declaration:</p>
6052
6053 <pre>    allocator_type get_allocator() const;</pre>
6054
6055
6056
6057
6058 <hr>
6059 <h3><a name="134"></a>134. vector constructors over specified</h3>
6060 <p><b>Section:</b> 23.4.1.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6061  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
6062 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6063 <p><b>Discussion:</b></p>
6064 <p>The complexity description says: "It does at most 2N calls to the copy constructor
6065 of T and logN reallocations if they are just input iterators ...".</p>
6066
6067 <p>This appears to be overly restrictive, dictating the precise memory/performance
6068 tradeoff for the implementor.</p>
6069
6070
6071 <p><b>Proposed resolution:</b></p>
6072 <p>Change 23.4.1.1 [vector.cons], paragraph 1 to:</p>
6073
6074 <p>-1- Complexity: The constructor template &lt;class
6075 InputIterator&gt; vector(InputIterator first, InputIterator last)
6076 makes only N calls to the copy constructor of T (where N is the
6077 distance between first and last) and no reallocations if iterators
6078 first and last are of forward, bidirectional, or random access
6079 categories. It makes order N calls to the copy constructor of T and
6080 order logN reallocations if they are just input iterators.
6081 </p>
6082
6083
6084 <p><b>Rationale:</b></p>
6085 <p>"at most 2N calls" is correct only if the growth factor
6086 is greater than or equal to 2.
6087 </p>
6088
6089
6090
6091
6092 <hr>
6093 <h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
6094 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
6095  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
6096 <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>
6097 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
6098 <p><b>Discussion:</b></p>
6099 <p>I may be misunderstanding the intent, but should not seekg set only
6100 the input stream and seekp set only the output stream? The description
6101 seems to say that each should set both input and output streams. If
6102 that's really the intent, I withdraw this proposal.</p>
6103
6104
6105 <p><b>Proposed resolution:</b></p>
6106 <p>In section 27.6.1.3 change:</p>
6107
6108 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
6109 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
6110
6111 <p>To:</p>
6112
6113 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
6114 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
6115
6116 <p>In section 27.6.1.3 change:</p>
6117
6118 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
6119 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
6120
6121 <p>To:</p>
6122
6123 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
6124 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
6125
6126 <p>In section 27.6.2.4, paragraph 2 change:</p>
6127
6128 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
6129
6130 <p>To:</p>
6131
6132 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
6133
6134 <p>In section 27.6.2.4, paragraph 4 change:</p>
6135
6136 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
6137
6138 <p>To:</p>
6139
6140 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
6141
6142 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
6143 like the opinion of more iostream experts before taking action.]</i></p>
6144
6145
6146 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
6147 incorrect, his implementation already implements the Proposed
6148 Resolution.]</i></p>
6149
6150
6151 <p><i>[Post-Tokyo: Matt Austern comments:<br>
6152 Is it a problem with basic_istream and basic_ostream, or is it a problem
6153 with basic_stringbuf?
6154 We could resolve the issue either by changing basic_istream and
6155 basic_ostream, or by changing basic_stringbuf. I prefer the latter
6156 change (or maybe both changes): I don't see any reason for the standard to
6157 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
6158 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
6159 This requirement is a bit weird. There's no similar requirement
6160 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
6161 basic_filebuf&lt;&gt;::seekpos.]</i></p>
6162
6163
6164
6165
6166
6167
6168 <hr>
6169 <h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
6170 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6171  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-17 <b>Last modified:</b> 2010-10-29</p>
6172 <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>
6173 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6174 <p><b>Discussion:</b></p>
6175 <p>Section 22.3.1 [locale] says:</p>
6176
6177 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
6178 chooses a facet, making available all members of the named type. If
6179 Facet is not present in a locale (or, failing that, in the global
6180 locale), it throws the standard exception bad_cast. A C++ program can
6181 check if a locale implements a particular facet with the template
6182 function has_facet&lt;Facet&gt;(). </p>
6183
6184 <p>This contradicts the specification given in section 
6185 22.3.2 [locale.global.templates]:
6186 <br><br>
6187 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
6188 locale&amp;&nbsp; loc); <br>
6189 <br>
6190 -1- Get a reference to a facet of a locale. <br>
6191 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
6192 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
6193 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
6194 </p>
6195
6196
6197 <p><b>Proposed resolution:</b></p>
6198 <p>Remove the phrase "(or, failing that, in the global locale)"
6199 from section 22.1.1. </p>
6200
6201
6202 <p><b>Rationale:</b></p>
6203 <p>Needed for consistency with the way locales are handled elsewhere
6204 in the standard.</p>
6205
6206
6207
6208
6209 <hr>
6210 <h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
6211 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6212  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-30 <b>Last modified:</b> 2010-10-29</p>
6213 <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>
6214 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6215 <p><b>Discussion:</b></p>
6216 <p>The sentence introducing the Optional sequence operation table
6217 (23.1.1 paragraph 12) has two problems:</p>
6218
6219 <p>A. It says ``The operations in table 68 are provided only for the containers for which
6220 they take constant time.''<br>
6221 <br>
6222 That could be interpreted in two ways, one of them being ``Even though table 68 shows
6223 particular operations as being provided, implementations are free to omit them if they
6224 cannot implement them in constant time.''<br>
6225 <br>
6226 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
6227
6228
6229 <p><b>Proposed resolution:</b></p>
6230 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
6231 with:</p>
6232
6233 <blockquote>
6234   <p>Table 68 lists sequence operations that are provided for some types of sequential
6235   containers but not others. An implementation shall provide these operations for all
6236   container types shown in the ``container'' column, and shall implement them so as to take
6237   amortized constant time.</p>
6238 </blockquote>
6239
6240
6241
6242
6243 <hr>
6244 <h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
6245 <p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6246  <b>Submitter:</b> Arch Robison <b>Opened:</b> 1999-04-28 <b>Last modified:</b> 2010-10-29</p>
6247 <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>
6248 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6249 <p><b>Discussion:</b></p>
6250 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
6251 say:<br>
6252 <br>
6253 \97 <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
6254
6255 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
6256
6257 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
6258 proposed resolution.]</i></p>
6259
6260
6261
6262 <p><b>Proposed resolution:</b></p>
6263 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
6264 <br>
6265 \97 <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
6266 <br>
6267 </tt>to:<br>
6268 <tt><br>
6269 </tt>\97 <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
6270
6271
6272
6273
6274 <hr>
6275 <h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
6276 <p><b>Section:</b> 25.4.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6277  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-06-20 <b>Last modified:</b> 2010-10-29</p>
6278 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6279 <p><b>Discussion:</b></p>
6280 <p>The lexicographical_compare complexity is specified as:<br>
6281 <br>
6282 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
6283 applications of the corresponding comparison."<br>
6284 <br>
6285 The best I can do is twice that expensive.</p>
6286
6287 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
6288 equality you have to check both &lt; and &gt;? Yes, IMO you are
6289 right! (and Matt states this complexity in his book)</p>
6290
6291
6292
6293 <p><b>Proposed resolution:</b></p>
6294 <p>Change 25.4.8 [alg.lex.comparison] complexity to:</p>
6295     <blockquote><p>
6296     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
6297     applications of the corresponding comparison.
6298     </p></blockquote>
6299
6300 <p>Change the example at the end of paragraph 3 to read:</p>
6301     <blockquote><p>
6302     [Example:<br>
6303     <br>
6304     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
6305     ++first1, ++first2) {<br>
6306     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
6307     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
6308     &nbsp;&nbsp;&nbsp; }<br>
6309     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
6310     &nbsp;&nbsp;&nbsp;<br>
6311     --end example]
6312     </p></blockquote>
6313
6314
6315
6316
6317 <hr>
6318 <h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
6319 <p><b>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6320  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1999-05-09 <b>Last modified:</b> 2010-10-29</p>
6321 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
6322 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6323 <p><b>Discussion:</b></p>
6324 <p>In 23.3.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
6325 to have complexity requirements which are incorrect, and which contradict the
6326 complexity requirements for insert(). I suspect that the text in question,
6327 below, was taken from vector:</p>
6328 <blockquote>
6329   <p>Complexity: If the iterators first and last are forward iterators,
6330   bidirectional iterators, or random access iterators the constructor makes only
6331   N calls to the copy constructor, and performs no reallocations, where N is
6332   last - first.</p>
6333 </blockquote>
6334 <p>The word "reallocations" does not really apply to deque. Further,
6335 all of the following appears to be spurious:</p>
6336 <blockquote>
6337   <p>It makes at most 2N calls to the copy constructor of T and log N
6338   reallocations if they are input iterators.1)</p>
6339   <p>1) The complexity is greater in the case of input iterators because each
6340   element must be added individually: it is impossible to determine the distance
6341   between first abd last before doing the copying.</p>
6342 </blockquote>
6343 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
6344 an efficiency advantage from knowing in advance the number of elements to
6345 insert?</p>
6346
6347
6348 <p><b>Proposed resolution:</b></p>
6349 <p>In 23.3.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
6350 footnote, with the following text (which also corrects the "abd"
6351 typo):</p>
6352 <blockquote>
6353   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
6354 </blockquote>
6355
6356
6357
6358
6359 <hr>
6360 <h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
6361 <p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6362  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2010-10-29</p>
6363 <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>
6364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6365 <p><b>Discussion:</b></p>
6366 <p>The extractor for complex numbers is specified as:&nbsp;</p>
6367
6368 <blockquote>
6369
6370 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6371      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
6372      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
6373 &nbsp;<br>
6374 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
6375 where u is the real part and v is the imaginary part
6376 (lib.istream.formatted).&nbsp;<br>
6377 Requires: The input values be convertible to T. If bad input is
6378 encountered, calls is.setstate(ios::failbit) (which may throw
6379 ios::failure (lib.iostate.flags).&nbsp;<br>
6380 Returns: is .</p>
6381
6382 </blockquote>
6383 <p>Is it intended that the extractor for complex numbers does not skip
6384 whitespace, unlike all other extractors in the standard library do?
6385 Shouldn't a sentry be used?&nbsp;<br>
6386 <br>
6387 The inserter for complex numbers is specified as:</p>
6388
6389 <blockquote>
6390
6391 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6392      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
6393      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
6394 <br>
6395 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
6396 <br>
6397      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6398      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
6399      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
6400      {&nbsp;<br>
6401              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
6402              s.flags(o.flags());&nbsp;<br>
6403              s.imbue(o.getloc());&nbsp;<br>
6404              s.precision(o.precision());&nbsp;<br>
6405              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
6406              return o &lt;&lt; s.str();&nbsp;<br>
6407      }</p>
6408
6409 </blockquote>
6410
6411 <p>Is it intended that the inserter for complex numbers ignores the
6412 field width and does not do any padding? If, with the suggested
6413 implementation above, the field width were set in the stream then the
6414 opening parentheses would be adjusted, but the rest not, because the
6415 field width is reset to zero after each insertion.</p>
6416
6417 <p>I think that both operations should use sentries, for sake of
6418 consistency with the other inserters and extractors in the
6419 library. Regarding the issue of padding in the inserter, I don't know
6420 what the intent was.&nbsp;</p>
6421
6422
6423 <p><b>Proposed resolution:</b></p>
6424 <p>After 26.4.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
6425 Notes clause:</p>
6426
6427 <blockquote>
6428
6429 <p>Notes: This extraction is performed as a series of simpler
6430 extractions. Therefore, the skipping of whitespace is specified to be the
6431 same for each of the simpler extractions.</p>
6432
6433 </blockquote>
6434
6435
6436 <p><b>Rationale:</b></p>
6437 <p>For extractors, the note is added to make it clear that skipping whitespace
6438 follows an "all-or-none" rule.</p>
6439
6440 <p>For inserters, the LWG believes there is no defect; the standard is correct
6441 as written.</p>
6442
6443
6444
6445
6446 <hr>
6447 <h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
6448 <p><b>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6449  <b>Submitter:</b> Lois Goldthwaite <b>Opened:</b> 1999-06-04 <b>Last modified:</b> 2010-10-29</p>
6450 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
6451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6452 <p><b>Discussion:</b></p>
6453 <p>The library had many global functions until 17.4.1.1 [lib.contents]
6454 paragraph 2 was added: </p>
6455
6456 <blockquote>
6457
6458 <p>All library entities except macros, operator new and operator
6459 delete are defined within the namespace std or namespaces nested
6460 within namespace std. </p>
6461
6462 </blockquote>
6463
6464 <p>It appears "global function" was never updated in the following: </p>
6465
6466 <blockquote>
6467
6468 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
6469 <br>
6470 -1- It is unspecified whether any global functions in the C++ Standard
6471 Library are defined as inline (dcl.fct.spec).<br>
6472 <br>
6473 -2- A call to a global function signature described in Clauses
6474 lib.language.support through lib.input.output behaves the same as if
6475 the implementation declares no additional global function
6476 signatures.*<br>
6477 <br>
6478     [Footnote: A valid C++ program always calls the expected library
6479     global function. An implementation may also define additional
6480     global functions that would otherwise not be called by a valid C++
6481     program. --- end footnote]<br>
6482 <br>
6483 -3- A global function cannot be declared by the implementation as
6484 taking additional default arguments.&nbsp;<br>
6485 <br>
6486 17.4.4.4 - Member functions [lib.member.functions]<br>
6487 <br>
6488 -2- An implementation can declare additional non-virtual member
6489 function signatures within a class: </p>
6490
6491   <blockquote>
6492
6493 <p>-- by adding arguments with default values to a member function
6494 signature; The same latitude does not extend to the implementation of
6495 virtual or global functions, however. </p>
6496
6497   </blockquote>
6498 </blockquote>
6499
6500
6501 <p><b>Proposed resolution:</b></p>
6502 <p>     Change "global" to "global or non-member" in:</p>
6503 <blockquote>
6504   <p>17.4.4.3 [lib.global.functions] section title,<br>
6505   17.4.4.3 [lib.global.functions] para 1,<br>
6506   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 
6507            places in the footnote,<br>
6508   17.4.4.3 [lib.global.functions] para 3,<br>
6509   17.4.4.4 [lib.member.functions] para 2</p>
6510 </blockquote>
6511
6512
6513 <p><b>Rationale:</b></p>
6514 <p>
6515 Because operator new and delete are global, the proposed resolution
6516 was changed from "non-member" to "global or non-member.
6517 </p>
6518
6519
6520
6521
6522 <hr>
6523 <h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
6524 <p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6525  <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 1999-06-03 <b>Last modified:</b> 2010-10-29</p>
6526 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
6527 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6528 <p><b>Discussion:</b></p>
6529 <p>In 22.4.8 [facets.examples] paragraph 13, the do_truename() and
6530 do_falsename() functions in the example facet BoolNames should be
6531 const. The functions they are overriding in
6532 numpunct_byname&lt;char&gt; are const. </p>
6533
6534
6535 <p><b>Proposed resolution:</b></p>
6536 <p>In 22.4.8 [facets.examples] paragraph 13, insert "const" in
6537 two places:</p>
6538 <blockquote>
6539   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
6540   string do_falsename() const { return "Mais Non!"; }</tt></p>
6541 </blockquote>
6542
6543
6544
6545
6546 <hr>
6547 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
6548 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6549  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28 <b>Last modified:</b> 2010-10-29</p>
6550 <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>
6551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6552 <p><b>Discussion:</b></p>
6553 <p>Suppose that c and c1 are sequential containers and i is an
6554 iterator that refers to an element of c.  Then I can insert a copy of
6555 c1's elements into c ahead of element i by executing </p>
6556
6557 <blockquote>
6558
6559 <pre>c.insert(i, c1.begin(), c1.end());</pre>
6560
6561 </blockquote>
6562
6563 <p>If c is a vector, it is fairly easy for me to find out where the
6564 newly inserted elements are, even though i is now invalid: </p>
6565
6566 <blockquote>
6567
6568 <pre>size_t i_loc = i - c.begin();
6569 c.insert(i, c1.begin(), c1.end());</pre>
6570
6571 </blockquote>
6572
6573 <p>and now the first inserted element is at c.begin()+i_loc and one
6574 past the last is at c.begin()+i_loc+c1.size().<br>
6575 <br>
6576 But what if c is a list?  I can still find the location of one    past the last inserted element, because i is still valid.    To find the location of the first inserted element, though,    I must execute something like </p>
6577
6578 <blockquote>
6579
6580 <pre>for (size_t n = c1.size(); n; --n)
6581    --i;</pre>
6582
6583 </blockquote>
6584
6585 <p>because i is now no longer a random-access iterator.<br>
6586 <br>
6587 Alternatively, I might write something like </p>
6588
6589 <blockquote>
6590
6591 <pre>bool first = i == c.begin();
6592 list&lt;T&gt;::iterator j = i;
6593 if (!first) --j;
6594 c.insert(i, c1.begin(), c1.end());
6595 if (first)
6596    j = c.begin();
6597 else
6598    ++j;</pre>
6599
6600 </blockquote>
6601
6602 <p>which, although wretched, requires less overhead.<br>
6603 <br>
6604 But I think the right solution is to change the definition of insert
6605 so that instead of returning void, it returns an iterator that refers
6606 to the first element inserted, if any, and otherwise is a copy of its
6607 first argument.&nbsp; </p>
6608
6609 <p><i>[
6610 Summit:
6611 ]</i></p>
6612
6613
6614 <blockquote>
6615 Reopened by Alisdair.
6616 </blockquote>
6617
6618 <p><i>[
6619 Post Summit Alisdair adds:
6620 ]</i></p>
6621
6622
6623 <blockquote>
6624 <p>
6625 In addition to the original rationale for C++03, this change also gives a
6626 consistent interface for all container insert operations i.e. they all
6627 return an iterator to the (first) inserted item.
6628 </p>
6629
6630 <p>
6631 Proposed wording provided.
6632 </p>
6633 </blockquote>
6634
6635 <p><i>[
6636 2009-07 Frankfurt
6637 ]</i></p>
6638
6639
6640 <blockquote>
6641 <p>
6642 Q: why isn't this change also proposed for associative containers?
6643 </p>
6644
6645 <p>
6646 A: The returned iterator wouldn't necessarily point to a contiguous range.
6647 </p>
6648
6649 <p>
6650 Moved to Ready.
6651 </p>
6652 </blockquote>
6653
6654
6655
6656 <p><b>Proposed resolution:</b></p>
6657 <p>
6658 <sef ref="[sequence.reqmts]"> Table 83
6659 change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
6660 </sef></p>
6661
6662 <blockquote>
6663 <table border="1">
6664 <caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
6665 <tbody><tr>
6666 <th>Expression</th>
6667 <th>Return type</th>
6668 <th>Assertion/note pre-/post-condition</th>
6669 </tr>
6670 <tr>
6671 <td>
6672 <tt>a.insert(p,n,t)</tt>
6673 </td>
6674 <td>
6675 <tt><del>void</del> <ins>iterator</ins></tt>
6676 </td>
6677 <td>
6678 Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
6679 </td>
6680 </tr>
6681
6682 <tr>
6683 <td>
6684 <tt>a.insert(p,i,j)</tt>
6685 </td>
6686 <td>
6687 <tt><del>void</del> <ins>iterator</ins></tt>
6688 </td>
6689 <td>
6690 Each iterator in the range <tt>[i,j)</tt> shall be 
6691 dereferenced exactly once. 
6692 pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>. 
6693 Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
6694 </td>
6695 </tr>
6696
6697 <tr>
6698 <td>
6699 <tt>a.insert(p,il)</tt>
6700 </td>
6701 <td>
6702 <tt><del>void</del> <ins>iterator</ins></tt>
6703 </td>
6704 <td>
6705 <tt>a.insert(p, il.begin(), il.end())</tt>.
6706 </td>
6707 </tr>
6708 </tbody></table>
6709 </blockquote>
6710
6711 <p>
6712 Add after p6 23.2.3 [sequence.reqmts]:
6713 </p>
6714
6715 <blockquote>
6716 <p>-6- ...</p>
6717
6718 <p><ins>
6719 The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
6720 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
6721 </ins></p>
6722
6723 <p><ins>
6724 The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
6725 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
6726 </ins></p>
6727
6728 <p><ins>
6729 The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
6730 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
6731 </ins></p>
6732
6733 </blockquote>
6734
6735 <p>
6736 p2 23.3.2 [deque] Update class definition, change return type
6737 from <tt>void</tt> to <tt>iterator</tt>:
6738 </p>
6739
6740 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6741 template &lt;class InputIterator&gt;
6742   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6743   <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6744 </pre></blockquote>
6745
6746 <p>
6747 23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6748 </p>
6749
6750 <blockquote><pre>  <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6751 template &lt;class InputIterator&gt;
6752   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6753 </pre></blockquote>
6754
6755 <p>
6756 Add the following (missing) declaration
6757 </p>
6758
6759 <blockquote><pre><ins>iterator insert(const_iterator position, initializer_list&lt;T&gt;);</ins>
6760 </pre></blockquote>
6761
6762 <p>
6763 23.3.3 [forwardlist] Update class definition, change return type
6764 from <tt>void</tt> to <tt>iterator</tt>:
6765 </p>
6766
6767 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
6768 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
6769 template &lt;class InputIterator&gt;
6770   <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
6771 </pre></blockquote>
6772
6773 <p>
6774 p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
6775 </p>
6776
6777 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
6778 </pre></blockquote>
6779
6780 <p>
6781 Add paragraph:
6782 </p>
6783
6784 <blockquote>
6785 Returns: position.
6786 </blockquote>
6787
6788 <p>
6789 p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
6790 </p>
6791
6792 <blockquote><pre>template &lt;class InputIterator&gt;
6793   <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
6794 </pre></blockquote>
6795
6796 <p>
6797 Add paragraph:
6798 </p>
6799
6800 <blockquote>
6801 Returns: position.
6802 </blockquote>
6803
6804 <p>
6805 p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6806 </p>
6807
6808 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
6809 </pre></blockquote>
6810
6811 <p>
6812 change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6813 </p>
6814
6815 <p>
6816 p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6817 </p>
6818
6819 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6820
6821 template &lt;class InputIterator&gt;
6822 <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6823
6824 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6825 </pre></blockquote>
6826
6827 <p>
6828 23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6829 </p>
6830
6831 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6832
6833 template &lt;class InputIterator&gt;
6834   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6835 </pre></blockquote>
6836
6837 <p>
6838 Add the following (missing) declaration
6839 </p>
6840
6841 <blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
6842 </pre></blockquote>
6843
6844 <p>
6845 p2 23.4.1 [vector]
6846 </p>
6847
6848 <p>
6849 Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6850 </p>
6851
6852 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, T&amp;&amp; x);
6853
6854 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6855
6856 template &lt;class InputIterator&gt;
6857   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6858
6859 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6860 </pre></blockquote>
6861
6862 <p>
6863 23.4.1.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6864 </p>
6865
6866 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6867
6868 template &lt;class InputIterator&gt;
6869   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6870 </pre></blockquote>
6871
6872 <p>
6873 Add the following (missing) declaration
6874 </p>
6875
6876 <blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
6877 </pre></blockquote>
6878
6879
6880 <p>
6881 p1 23.4.2 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6882 </p>
6883
6884 <blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool&amp; x);
6885
6886 template &lt;class InputIterator&gt;
6887   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6888
6889   <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;bool&gt; il);
6890 </pre></blockquote>
6891
6892 <p>
6893 p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6894 </p>
6895
6896 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
6897
6898 template&lt;class InputIterator&gt;
6899   <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
6900
6901 <del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt;);
6902 </pre></blockquote>
6903
6904 <p>
6905 p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6906 </p>
6907
6908 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
6909 </pre></blockquote>
6910
6911 <p>
6912 Add paragraph:
6913 </p>
6914
6915 <blockquote>
6916 <i>Returns:</i> an iterator which refers to the copy of the first inserted
6917 character, or <tt>p</tt> if <tt>n == 0</tt>.
6918 </blockquote>
6919
6920 <p>
6921 p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6922 </p>
6923
6924 <blockquote><pre>template&lt;class InputIterator&gt;
6925   <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
6926 </pre></blockquote>
6927
6928 <p>
6929 Add paragraph:
6930 </p>
6931
6932 <blockquote>
6933 <i>Returns:</i> an iterator which refers to the copy of the first inserted
6934 character, or <tt>p</tt> if <tt>first == last</tt>.
6935 </blockquote>
6936
6937 <p>
6938 p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6939 </p>
6940
6941 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt; il);
6942 </pre></blockquote>
6943
6944 <p>
6945 Add paragraph:
6946 </p>
6947
6948 <blockquote>
6949 <i>Returns:</i> an iterator which refers to the copy of the first inserted
6950 character, or <tt>p</tt> if <tt>il</tt> is empty.
6951 </blockquote>
6952
6953
6954
6955 <p><b>Rationale:</b></p>
6956
6957 <p><i>[
6958 The following was the C++98/03 rationale and does not necessarily apply to the
6959 proposed resolution in the C++0X time frame:
6960 ]</i></p>
6961
6962
6963 <blockquote>
6964 <p>The LWG believes this was an intentional design decision and so is
6965 not a defect. It may be worth revisiting for the next standard.</p>
6966 </blockquote>
6967
6968
6969
6970
6971 <hr>
6972 <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
6973 <p><b>Section:</b> 25.2.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6974  <b>Submitter:</b> Matt McClure <b>Opened:</b> 1999-06-30 <b>Last modified:</b> 2010-10-29</p>
6975 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
6976 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
6977 <p><b>Discussion:</b></p>
6978
6979
6980 <p><b>Proposed resolution:</b></p>
6981 <p>Change 25.2.7 [alg.find.first.of] paragraph 2 from:</p>
6982
6983 <blockquote>
6984 <p>Returns: The first iterator i in the range [first1, last1) such
6985 that for some integer j in the range [first2, last2) ...</p>
6986 </blockquote>
6987
6988 <p>to:</p>
6989
6990 <blockquote>
6991 <p>Returns: The first iterator i in the range [first1, last1) such
6992 that for some iterator j in the range [first2, last2) ...</p>
6993 </blockquote>
6994
6995
6996
6997
6998 <hr>
6999 <h3><a name="151"></a>151. Can't currently clear() empty container</h3>
7000 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7001  <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-21 <b>Last modified:</b> 2010-10-29</p>
7002 <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>
7003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7004 <p><b>Discussion:</b></p>
7005 <p>For both sequences and associative containers, a.clear() has the
7006 semantics of erase(a.begin(),a.end()), which is undefined for an empty
7007 container since erase(q1,q2) requires that q1 be dereferenceable
7008 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
7009 not dereferenceable.<br>
7010 <br>
7011 The requirement that q1 be unconditionally dereferenceable causes many
7012 operations to be intuitively undefined, of which clearing an empty
7013 container is probably the most dire.<br>
7014 <br>
7015 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
7016 q2) is required to be a valid range, stating that q1 and q2 must be
7017 iterators or certain kinds of iterators is unnecessary.
7018 </p>
7019
7020
7021 <p><b>Proposed resolution:</b></p>
7022 <p>In 23.1.1, paragraph 3, change:</p>
7023 <blockquote>
7024   <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
7025 </blockquote>
7026 <p>to:</p>
7027 <blockquote>
7028   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
7029   in a</p>
7030 </blockquote>
7031 <p>In 23.1.2, paragraph 7, change:</p>
7032 <blockquote>
7033   <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
7034   iterators to a, [q1, q2) is a valid range</p>
7035 </blockquote>
7036 <p>to</p>
7037 <blockquote>
7038   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
7039   into a</p>
7040 </blockquote>
7041
7042
7043
7044
7045 <hr>
7046 <h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
7047 <p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7048  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7049 <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>
7050 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7051 <p><b>Discussion:</b></p>
7052 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
7053 because there is no function <tt>is()</tt> which only takes a character as
7054 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
7055 vague.</p>
7056
7057
7058 <p><b>Proposed resolution:</b></p>
7059 <p>In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
7060 clause from:</p>
7061 <blockquote>
7062   <p>"... such that <tt>is(*p)</tt>
7063 would..."</p>
7064 </blockquote>
7065 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
7066  would...."</p>
7067
7068
7069
7070
7071
7072 <hr>
7073 <h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
7074 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7075  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7076 <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>
7077 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7078 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
7079 <p><b>Discussion:</b></p>
7080 <p>The description of the array version of <tt>narrow()</tt> (in
7081 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
7082 takes only three arguments because in addition to the range a default
7083 character is needed.</p>
7084
7085 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
7086 two signatures followed by a <b>Returns</b> clause that only addresses
7087 one of them.</p>
7088
7089
7090
7091 <p><b>Proposed resolution:</b></p>
7092 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
7093 paragraph 10 from:</p>
7094 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
7095
7096 <p>to:</p>
7097 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
7098 respectively.</p>
7099
7100 <p>Change 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
7101 <pre>        char        narrow(char c, char /*dfault*/) const;
7102         const char* narrow(const char* low, const char* high,
7103                            char /*dfault*/, char* to) const;</pre>
7104 <pre>        Returns: do_narrow(low, high, to).</pre>
7105 <p>to:</p>
7106 <pre>        char        narrow(char c, char dfault) const;
7107         const char* narrow(const char* low, const char* high,
7108                            char dfault, char* to) const;</pre>
7109 <pre>        Returns: do_narrow(c, dfault) or
7110                  do_narrow(low, high, dfault, to), respectively.</pre>
7111
7112 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
7113 defined version could be different.]</i></p>
7114
7115
7116 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
7117 the LWG. He could find no other places the problem occurred. He
7118 asks for clarification of the Kona "a user defined
7119 version..." comment above.  Perhaps it was a circuitous way of
7120 saying "dfault" needed to be uncommented?]</i></p>
7121
7122
7123 <p><i>[Post-Toronto: the issues list maintainer has merged in the
7124 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
7125 same paragraphs.]</i></p>
7126
7127
7128
7129
7130
7131
7132 <hr>
7133 <h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
7134 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7135  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7136 <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>
7137 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7138 <p><b>Discussion:</b></p>
7139 <p>The table in paragraph 7 for the length modifier does not list the length
7140 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
7141 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
7142 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
7143 is actually a problem I found quite often in production code, too).</p>
7144
7145
7146 <p><b>Proposed resolution:</b></p>
7147 <p>In 22.4.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
7148 Modifier table to say that for <tt>double</tt> a length modifier
7149 <tt>l</tt> is to be used.</p>
7150
7151
7152 <p><b>Rationale:</b></p>
7153 <p>The standard makes an embarrassing beginner's mistake.</p>
7154
7155
7156
7157
7158 <hr>
7159 <h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
7160 <p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7161  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <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#iostream.objects">issues</a> in [iostream.objects].</p>
7163 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7164 <p><b>Discussion:</b></p>
7165 <p>There are conflicting statements about where the class
7166 <tt>Init</tt> is defined. According to 27.4 [iostream.objects] paragraph 2
7167 it is defined as <tt>basic_ios::Init</tt>, according to 27.5.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
7168
7169
7170 <p><b>Proposed resolution:</b></p>
7171 <p>Change 27.4 [iostream.objects] paragraph 2 from
7172 "<tt>basic_ios::Init"</tt> to
7173 "<tt>ios_base::Init"</tt>.</p>
7174
7175
7176 <p><b>Rationale:</b></p>
7177 <p>Although not strictly wrong, the standard was misleading enough to warrant
7178 the change.</p>
7179
7180
7181
7182
7183 <hr>
7184 <h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
7185 <p><b>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7186  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7187 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
7188 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7189 <p><b>Discussion:</b></p>
7190 <p>There is a small discrepancy between the declarations of
7191 <tt>imbue()</tt>: in 27.5.2 [ios.base] the argument is passed as
7192 <tt>locale const&amp;</tt> (correct), in 27.5.2.3 [ios.base.locales] it
7193 is passed as <tt>locale const</tt> (wrong).</p>
7194
7195
7196 <p><b>Proposed resolution:</b></p>
7197 <p>In 27.5.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
7198 from "<tt>locale const" to "locale
7199 const&amp;".</tt></p>
7200
7201
7202
7203
7204 <hr>
7205 <h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
7206 <p><b>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7207  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7208 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
7209 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7210 <p><b>Discussion:</b></p>
7211 <p>The default behavior of <tt>setbuf()</tt> is described only for the
7212 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
7213 namely to do nothing.  What has to be done in other situations&nbsp;
7214 is not described although there is actually only one reasonable
7215 approach, namely to do nothing, too.</p> 
7216
7217 <p>Since changing the buffer would almost certainly mess up most
7218 buffer management of derived classes unless these classes do it
7219 themselves, the default behavior of <tt>setbuf()</tt> should always be
7220 to do nothing.</p>
7221
7222
7223 <p><b>Proposed resolution:</b></p>
7224 <p>Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
7225 to: "Default behavior: Does nothing. Returns this."</p>
7226
7227
7228
7229
7230 <hr>
7231 <h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
7232 <p><b>Section:</b> 27.6.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7233  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7234 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7235 <p><b>Discussion:</b></p>
7236 <p>The description of the meaning of the result of
7237 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
7238 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
7239 this function only reads the current character but does not extract
7240 it, <tt>uflow()</tt> would extract the current character. This should
7241 be fixed to use <tt>sbumpc()</tt> instead.</p>
7242
7243
7244 <p><b>Proposed resolution:</b></p>
7245 <p>Change 27.6.2.4.3 [streambuf.virt.get] paragraph 1,
7246 <tt>showmanyc()</tt>returns clause, by replacing the word
7247 "supplied" with the words "extracted from the
7248 stream".</p>
7249
7250
7251
7252
7253 <hr>
7254 <h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
7255 <p><b>Section:</b> 27.7.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7256  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7257 <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>
7258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7259 <p><b>Discussion:</b></p>
7260 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
7261 is not defined. Probably, the referred function is
7262 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
7263
7264
7265 <p><b>Proposed resolution:</b></p>
7266 <p>In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1,
7267 27.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts],
7268 paragraph 1, change "<tt>exception()" to
7269 "exceptions()"</tt>.</p>
7270
7271 <p><i>[Note to Editor: "exceptions" with an "s"
7272 is the correct spelling.]</i></p>
7273
7274
7275
7276
7277
7278
7279 <hr>
7280 <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
7281 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7282  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7283 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
7284 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7285 <p><b>Discussion:</b></p>
7286 <p>The note in the second paragraph pretends that the first argument
7287 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
7288 an object of type <tt>istreambuf_iterator</tt>.</p>
7289
7290
7291 <p><b>Proposed resolution:</b></p>
7292 <p>Change 27.7.1.2.2 [istream.formatted.arithmetic] from:</p>
7293 <blockquote>
7294   <p>The first argument provides an object of the istream_iterator class...</p>
7295 </blockquote>
7296 <p>to</p>
7297 <blockquote>
7298   <p>The first argument provides an object of the istreambuf_iterator class...</p>
7299 </blockquote>
7300
7301
7302
7303
7304
7305 <hr>
7306 <h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
7307 <p><b>Section:</b> 22.4.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7308  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7309 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7310 <p><b>Discussion:</b></p>
7311 <p>In 22.4.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
7312 as taking a fill character as an argument, but the description of the
7313 function does not say whether the character is used at all and, if so,
7314 in which way. The same holds for any format control parameters that
7315 are accessible through the ios_base&amp; argument, such as the
7316 adjustment or the field width. Is strftime() supposed to use the fill
7317 character in any way? In any case, the specification of
7318 time_put.do_put() looks inconsistent to me.<br> <br> Is the
7319 signature of do_put() wrong, or is the effects clause incomplete?</p>
7320
7321
7322 <p><b>Proposed resolution:</b></p>
7323 <p>Add the following note after 22.4.5.3.2 [locale.time.put.virtuals]
7324 paragraph 2:</p>
7325 <blockquote>
7326   <p>  [Note: the <tt>fill</tt> argument may be used in the implementation-defined  formats, or by derivations.  A space character is a reasonable default
7327   for this argument. --end Note]</p>
7328 </blockquote>
7329
7330
7331 <p><b>Rationale:</b></p>
7332 <p>The LWG felt that while the normative text was correct,
7333 users need some guidance on what to pass for the <tt>fill</tt>
7334 argument since the standard doesn't say how it's used.</p>
7335
7336
7337
7338
7339 <hr>
7340 <h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
7341 <p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7342  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7343 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
7344 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7345 <p><b>Discussion:</b></p>
7346 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
7347 functions falling into one of the groups "formatted output functions"
7348 and "unformatted output functions" calls any stream buffer function
7349 which might call a virtual function other than <tt>overflow()</tt>. Basically
7350 this is fine but this implies that <tt>sputn()</tt> (this function would call
7351 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
7352 output functions. Is this really intended? At minimum it would be convenient to
7353 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
7354 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
7355 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
7356 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
7357 under "unformatted output functions").</p>
7358 <p>In addition, I guess that the sentence starting with "They may use other
7359 public members of <tt>basic_ostream</tt> ..." probably was intended to
7360 start with "They may use other public members of <tt>basic_streamuf</tt>..."
7361 although the problem with the virtual members exists in both cases.</p>
7362 <p>I see two obvious resolutions:</p>
7363 <ol>
7364   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
7365     called by any ostream member and that this is intended.</li>
7366   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
7367     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
7368 </ol>
7369
7370
7371 <p><b>Proposed resolution:</b></p>
7372 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
7373 <blockquote>
7374   <p>They may use other public members of basic_ostream except that they do not
7375   invoke any virtual members of rdbuf() except overflow().</p>
7376 </blockquote>
7377 <p>to:</p>
7378 <blockquote>
7379   <p>They may use other public members of basic_ostream except that they shall
7380   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
7381   sync().</p>
7382 </blockquote>
7383
7384 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
7385 PJP why the standard is written this way.]</i></p>
7386
7387
7388 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
7389 LWG. He comments: The rules can be made a little bit more specific if
7390 necessary be explicitly spelling out what virtuals are allowed to be
7391 called from what functions and eg to state specifically that flush()
7392 is allowed to call sync() while other functions are not.]</i></p>
7393
7394
7395
7396
7397
7398
7399 <hr>
7400 <h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
7401 <p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7402  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <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.inserters.character">issues</a> in [ostream.inserters.character].</p>
7404 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7405 <p><b>Discussion:</b></p>
7406 <p>Paragraph 4 states that the length is determined using
7407 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
7408 defined for example if the character type is <tt>wchar_t</tt> and the
7409 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
7410 the character type is <tt>char</tt> and the type of <tt>s</tt> is
7411 either <tt>signed char const*</tt> or <tt>unsigned char
7412 const*</tt>.</p>
7413
7414
7415 <p><b>Proposed resolution:</b></p>
7416 <p>Change 27.7.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
7417 <blockquote>
7418   <p>Effects: Behaves like an formatted inserter (as described in
7419   lib.ostream.formatted.reqmts) of out. After a sentry object is
7420   constructed it inserts characters. The number of characters starting
7421   at s to be inserted is traits::length(s). Padding is determined as
7422   described in lib.facet.num.put.virtuals. The traits::length(s)
7423   characters starting at s are widened using out.widen
7424   (lib.basic.ios.members). The widened characters and any required
7425   padding are inserted into out. Calls width(0).</p>
7426 </blockquote>
7427 <p>to:</p>
7428 <blockquote>
7429   <p>Effects: Behaves like a formatted inserter (as described in
7430   lib.ostream.formatted.reqmts) of out. After a sentry object is
7431   constructed it inserts <i>n</i> characters starting at <i>s</i>,
7432   where <i>n</i> is the number that would be computed as if by:</p>
7433   <ul>
7434   <li>traits::length(s) for the overload where the first argument is of
7435     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
7436     of type const charT*, and also for the overload where the first
7437     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
7438     the second is of type const char*.</li>
7439   <li>std::char_traits&lt;char&gt;::length(s) 
7440     for the overload where the first argument is of type 
7441     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
7442     const char*.</li>
7443   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s)) 
7444     for the other two overloads.</li>
7445   </ul>
7446   <p>Padding is determined as described in
7447   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
7448   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
7449   widened characters and any required padding are inserted into
7450   out. Calls width(0).</p>
7451 </blockquote>
7452
7453 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
7454
7455
7456 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
7457   number that would be computed as if by"]</i></p>
7458  
7459
7460
7461
7462 <p><b>Rationale:</b></p>
7463 <p>We have five separate cases.  In two of them we can use the
7464 user-supplied traits class without any fuss.  In the other three we
7465 try to use something as close to that user-supplied class as possible.
7466 In two cases we've got a traits class that's appropriate for
7467 char and what we've got is a const signed char* or a const
7468 unsigned char*; that's close enough so we can just use a reinterpret
7469 cast, and continue to use the user-supplied traits class.  Finally,
7470 there's one case where we just have to give up: where we've got a
7471 traits class for some arbitrary charT type, and we somehow have to
7472 deal with a const char*.  There's nothing better to do but fall back
7473 to char_traits&lt;char&gt;</p>
7474
7475
7476
7477
7478
7479 <hr>
7480 <h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
7481 <p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7482  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7483 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
7484 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7485 <p><b>Discussion:</b></p>
7486 <p>The first paragraph begins with a descriptions what has to be done
7487 in <i>formatted</i> output functions. Probably this is a typo and the
7488 paragraph really want to describe unformatted output functions...</p>
7489
7490
7491 <p><b>Proposed resolution:</b></p>
7492 <p>In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last
7493 sentences, change the word "formatted" to
7494 "unformatted":</p>
7495 <blockquote>
7496   <p>"Each <b>unformatted </b> output function begins ..."<br>
7497   "... value specified for the <b>unformatted </b>  output 
7498   function."</p>
7499 </blockquote>
7500
7501
7502
7503
7504 <hr>
7505 <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
7506 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7507  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
7509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7510 <p><b>Discussion:</b></p>
7511 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
7512 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
7513 especially in view of the restriction that <tt>basic_ostream</tt>
7514 member functions are not allowed to use <tt>xsputn()</tt> (see 27.7.2.1 [ostream]): For each character to be inserted, a new buffer
7515 is to be created.</p> 
7516 <p>Of course, the resolution below requires some handling of
7517 simultaneous input and output since it is no longer possible to update
7518 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
7519 solution is to handle this in <tt>underflow()</tt>.</p>
7520
7521
7522 <p><b>Proposed resolution:</b></p>
7523 <p>In 27.8.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
7524 "at least" as in the following:</p>
7525 <blockquote>
7526   <p>To make a write position available, the function reallocates (or initially
7527   allocates) an array object with a sufficient number of elements to hold the
7528   current array object (if any), plus <b>at least</b> one additional write
7529   position.</p>
7530 </blockquote>
7531
7532
7533
7534
7535 <hr>
7536 <h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
7537 <p><b>Section:</b> 27.8.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7538  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7539 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7540 <p><b>Discussion:</b></p>
7541 <p>The classes <tt>basic_stringstream</tt> (27.8.4 [stringstream]),
7542 <tt>basic_istringstream</tt> (27.8.2 [istringstream]), and
7543 <tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) are inconsistent
7544 in their definition of the type <tt>traits_type</tt>: For
7545 <tt>istringstream</tt>, this type is defined, for the other two it is
7546 not. This should be consistent.</p>
7547
7548
7549 <p><b>Proposed resolution:</b></p>
7550 <p><b>Proposed resolution:</b></p> <p>To the declarations of
7551 <tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) and
7552 <tt>basic_stringstream</tt> (27.8.4 [stringstream]) add:</p>
7553 <blockquote>
7554 <pre>typedef traits traits_type;</pre>
7555 </blockquote>
7556
7557
7558
7559
7560 <hr>
7561 <h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
7562 <p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7563  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
7564 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
7565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7566 <p><b>Discussion:</b></p>
7567 <p>Overridden virtual functions, seekpos()</p> <p>In 27.9.1.1 [filebuf] paragraph 3, it is stated that a joint input and
7568 output position is maintained by <tt>basic_filebuf</tt>. Still, the
7569 description of <tt>seekpos()</tt> seems to talk about different file
7570 positions. In particular, it is unclear (at least to me) what is
7571 supposed to happen to the output buffer (if there is one) if only the
7572 input position is changed. The standard seems to mandate that the
7573 output buffer is kept and processed as if there was no positioning of
7574 the output position (by changing the input position). Of course, this
7575 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
7576 set. However, I think, the standard should say something like
7577 this:</p>
7578 <ul>
7579   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
7580     changed and the call fails. Otherwise, the joint read and write position is
7581     altered to correspond to <tt>sp</tt>.</li>
7582   <li>If there is an output buffer, the output sequences is updated and any
7583     unshift sequence is written before the position is altered.</li>
7584   <li>If there is an input buffer, the input sequence is updated after the
7585     position is altered.</li>
7586 </ul>
7587 <p>Plus the appropriate error handling, that is...</p>
7588
7589
7590 <p><b>Proposed resolution:</b></p>
7591 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
7592 paragraph 14 from:</p>
7593 <blockquote>
7594   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
7595   ios_base::out);</p>
7596   <p>Alters the file position, if possible, to correspond to the position stored
7597   in sp (as described below).</p>
7598   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
7599   the input sequence</p>
7600   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
7601   any unshift sequence, and set the file position to sp.</p>
7602 </blockquote>
7603 <p>to:</p>
7604 <blockquote>
7605   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
7606   ios_base::out);</p>
7607   <p>Alters the file position, if possible, to correspond to the position stored
7608   in sp (as described below). Altering the file position performs as follows:</p>
7609   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
7610   write any unshift sequence;</p>
7611   <p>2. set the file position to sp;</p>
7612   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
7613   <p>where om is the open mode passed to the last call to open(). The operation
7614   fails if is_open() returns false.</p>
7615 </blockquote>
7616
7617 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
7618
7619 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
7620
7621
7622
7623
7624
7625
7626 <hr>
7627 <h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
7628 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7629  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7630 <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>
7631 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7632 <p><b>Discussion:</b></p>
7633 <p>In 27.7.1.1 [istream] the function
7634 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
7635 argument. However, in 27.7.1.3 [istream.unformatted]
7636 paragraph 23 the first argument is of type <tt>int.</tt></p>
7637
7638 <p>As far as I can see this is not really a contradiction because
7639 everything is consistent if <tt>streamsize</tt> is typedef to be
7640 <tt>int</tt>. However, this is almost certainly not what was
7641 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
7642 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
7643
7644 <p>Darin Adler also
7645 submitted this issue, commenting: Either 27.6.1.1 should be modified
7646 to show a first parameter of type int, or 27.6.1.3 should be modified
7647 to show a first parameter of type streamsize and use
7648 numeric_limits&lt;streamsize&gt;::max.</p>
7649
7650
7651 <p><b>Proposed resolution:</b></p>
7652 <p>In 27.7.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
7653 of <tt>int</tt> in the description of <tt>ignore()</tt> to
7654 <tt>streamsize</tt>.</p>
7655
7656
7657
7658
7659 <hr>
7660 <h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
7661 <p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7662  <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7663 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
7664 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7665 <p><b>Discussion:</b></p>
7666
7667 <p>
7668 In 27.9.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
7669 object of type <tt>streamsize</tt> as second argument. However, in
7670 27.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
7671 <tt>int</tt>.
7672 </p>
7673
7674 <p>
7675 As far as I can see this is not really a contradiction because
7676 everything is consistent if <tt>streamsize</tt> is typedef to be
7677 <tt>int</tt>. However, this is almost certainly not what was
7678 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
7679 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
7680 </p>
7681
7682
7683
7684 <p><b>Proposed resolution:</b></p>
7685 <p>In 27.9.1.5 [filebuf.virtuals] paragraph 9, change all uses of
7686 <tt>int</tt> in the description of <tt>setbuf()</tt> to
7687 <tt>streamsize</tt>.</p>
7688
7689
7690
7691
7692 <hr>
7693 <h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
7694 <p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7695  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7696 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
7697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7698 <p><b>Discussion:</b></p>
7699 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
7700 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
7701 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
7702
7703
7704 <p><b>Proposed resolution:</b></p>
7705 <p>Change D.8 [depr.ios.members] paragraph 1 from "<tt>typedef
7706 OFF_T streampos;</tt>" to "<tt>typedef POS_T
7707 streampos;</tt>"</p>
7708
7709
7710
7711
7712 <hr>
7713 <h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
7714 <p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7715  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7716 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
7717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7718 <p><b>Discussion:</b></p>
7719 <p>According to paragraph 8 of this section, the methods
7720 <tt>basic_streambuf::pubseekpos()</tt>,
7721 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
7722 "may" be overloaded by a version of this function taking the
7723 type <tt>ios_base::open_mode</tt> as last argument argument instead of
7724 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
7725 in this section to be an alias for one of the integral types). The
7726 clause specifies, that the last argument has a default argument in
7727 three cases.  However, this generates an ambiguity with the overloaded
7728 version because now the arguments are absolutely identical if the last
7729 argument is not specified.</p>
7730
7731
7732 <p><b>Proposed resolution:</b></p>
7733 <p>In D.8 [depr.ios.members] paragraph 8, remove the default arguments for
7734 <tt>basic_streambuf::pubseekpos()</tt>,
7735 <tt>basic_ifstream::open()</tt>, and
7736 <tt>basic_ofstream::open().</tt></p>
7737
7738
7739
7740
7741 <hr>
7742 <h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
7743 <p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7744  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
7745 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
7746 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
7747 <p><b>Discussion:</b></p>
7748 <p>The "overload" for the function <tt>exceptions()</tt> in
7749 paragraph 8 gives the impression that there is another function of
7750 this function defined in class <tt>ios_base</tt>. However, this is not
7751 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
7752 be implemented: "Call the corresponding member function specified
7753 in clause 27 [input.output]."</p>
7754
7755
7756 <p><b>Proposed resolution:</b></p>
7757 <p>In D.8 [depr.ios.members] paragraph 8, move the declaration of the
7758 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
7759
7760
7761
7762
7763 <hr>
7764 <h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
7765 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7766  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-07-02 <b>Last modified:</b> 2010-10-29</p>
7767 <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>
7768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7769 <p><b>Discussion:</b></p>
7770 <p>Currently the following will not compile on two well-known standard
7771 library implementations:</p>
7772
7773 <blockquote>
7774   <pre>#include &lt;set&gt;
7775 using namespace std;
7776
7777 void f(const set&lt;int&gt; &amp;s)
7778 {
7779   set&lt;int&gt;::iterator i;
7780   if (i==s.end()); // s.end() returns a const_iterator
7781 }</pre>
7782 </blockquote>
7783
7784 <p>
7785 The reason this doesn't compile is because operator== was implemented
7786 as a member function of the nested classes set:iterator and
7787 set::const_iterator, and there is no conversion from const_iterator to
7788 iterator. Surprisingly, (s.end() == i) does work, though, because of
7789 the conversion from iterator to const_iterator.
7790 </p>
7791
7792 <p>
7793 I don't see a requirement anywhere in the standard that this must
7794 work. Should there be one?  If so, I think the requirement would need
7795 to be added to the tables in section 24.1.1. I'm not sure about the
7796 wording.  If this requirement existed in the standard, I would think
7797 that implementors would have to make the comparison operators
7798 non-member functions.</p>
7799
7800 <p>This issues was also raised on comp.std.c++ by Darin
7801 Adler.&nbsp; The example given was:</p>
7802
7803 <blockquote>
7804   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
7805 std::deque&lt;int&gt;::const_iterator ci)
7806 {
7807 return i == ci;
7808 }</pre>
7809 </blockquote>
7810
7811 <p>Comment from John Potter:</p>
7812 <blockquote>
7813     <p>
7814     In case nobody has noticed, accepting it will break reverse_iterator.
7815     </p>
7816
7817     <p>
7818     The fix is to make the comparison operators templated on two types.
7819     </p>
7820
7821     <pre>    template &lt;class Iterator1, class Iterator2&gt;
7822     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
7823                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
7824     </pre>
7825
7826     <p>
7827     Obviously:  return x.base() == y.base();
7828     </p>
7829
7830     <p>
7831     Currently, no reverse_iterator to const_reverse_iterator compares are
7832     valid.
7833     </p>
7834
7835     <p>
7836     BTW, I think the issue is in support of bad code.  Compares should be
7837     between two iterators of the same type.  All std::algorithms require
7838     the begin and end iterators to be of the same type. 
7839     </p>
7840 </blockquote>
7841
7842
7843 <p><b>Proposed resolution:</b></p>
7844 <p>Insert this paragraph after 23.2 [container.requirements] paragraph 7:</p>
7845 <blockquote>
7846   <p>In the expressions</p>
7847   <pre>    i == j
7848     i != j
7849     i &lt; j
7850     i &lt;= j
7851     i &gt;= j
7852     i &gt; j
7853     i - j
7854   </pre>
7855   <p>Where i and j denote objects of a container's iterator type,
7856   either or both may be replaced by an object of the container's
7857   const_iterator type referring to the same element with no
7858   change in semantics.</p>
7859 </blockquote>
7860
7861 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
7862 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
7863 iterator comparison and difference operations.]</i></p>
7864
7865
7866 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
7867 explicitly listed expressions; there was concern that the previous
7868 proposed resolution was too informal.]</i></p>
7869
7870
7871
7872 <p><b>Rationale:</b></p>
7873 <p>
7874 The LWG believes it is clear that the above wording applies only to
7875 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
7876 where <tt>X</tt> is a container.  There is no requirement that
7877 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
7878 can be mixed.  If mixing them is considered important, that's a
7879 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
7880 </p>
7881
7882
7883
7884
7885 <hr>
7886 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
7887 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
7888  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 1999-07-01 <b>Last modified:</b> 2010-10-29</p>
7889 <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>
7890 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7891 <p><b>Discussion:</b></p>
7892 <p>It is the constness of the container which should control whether
7893 it can be modified through a member function such as erase(), not the
7894 constness of the iterators. The iterators only serve to give
7895 positioning information.</p>
7896
7897 <p>Here's a simple and typical example problem which is currently very
7898 difficult or impossible to solve without the change proposed
7899 below.</p>
7900
7901 <p>Wrap a standard container C in a class W which allows clients to
7902 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
7903 only modification clients are allowed to make to elements in this
7904 subrange is to erase them from C through the use of a member function
7905 of W.</p>
7906
7907 <p><i>[
7908 post Bellevue, Alisdair adds:
7909 ]</i></p>
7910
7911
7912 <blockquote>
7913 <p>
7914 This issue was implemented by
7915 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
7916 for everything but <tt>basic_string</tt>.
7917 </p>
7918
7919 <p>
7920 Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
7921 we forgot to amend in
7922 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
7923 so we might open this issue for that
7924 single container?
7925 </p>
7926 </blockquote>
7927
7928 <p><i>[
7929 Sophia Antipolis:
7930 ]</i></p>
7931
7932
7933 <blockquote>
7934 <p>
7935 This was a fix that was intended for all standard library containers,
7936 and has been done for other containers, but string was missed.
7937 </p>
7938 <p>
7939 The wording updated.
7940 </p>
7941 <p>
7942 We did not make the change in <tt>replace</tt>, because this change would affect
7943 the implementation because the string may be written into. This is an
7944 issue that should be taken up by concepts.
7945 </p>
7946 <p>
7947 We note that the supplied wording addresses the initializer list provided in
7948 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
7949 </p>
7950 </blockquote>
7951
7952
7953
7954 <p><b>Proposed resolution:</b></p>
7955 <p>
7956 Update the following signature in the <tt>basic_string</tt> class template definition in
7957 21.4 [basic.string], p5:
7958 </p>
7959 <blockquote><pre>namespace std {
7960   template&lt;class charT, class traits = char_traits&lt;charT&gt;,
7961     class Allocator = allocator&lt;charT&gt; &gt;
7962   class basic_string {
7963
7964     ...
7965
7966     iterator insert(<ins>const_</ins>iterator p, charT c);
7967     void insert(<ins>const_</ins>iterator p, size_type n, charT c);
7968     template&lt;class InputIterator&gt;
7969       void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
7970     void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
7971
7972     ...
7973
7974     iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
7975     iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
7976
7977     ...
7978
7979   };
7980 }
7981 </pre></blockquote>
7982
7983 <p>
7984 Update the following signatures in 21.4.6.4 [string::insert]:
7985 </p>
7986
7987 <blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
7988 void insert(<ins>const_</ins>iterator p, size_type n, charT c);
7989 template&lt;class InputIterator&gt;
7990   void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
7991 void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
7992 </pre></blockquote>
7993
7994 <p>
7995 Update the following signatures in 21.4.6.5 [string::erase]:
7996 </p>
7997
7998 <blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
7999 iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
8000 </pre></blockquote>
8001
8002
8003
8004 <p><b>Rationale:</b></p>
8005 <p>The issue was discussed at length. It was generally agreed that 1)
8006 There is no major technical argument against the change (although
8007 there is a minor argument that some obscure programs may break), and
8008 2) Such a change would not break const correctness. The concerns about
8009 making the change were 1) it is user detectable (although only in
8010 boundary cases), 2) it changes a large number of signatures, and 3) it
8011 seems more of a design issue that an out-and-out defect.</p>
8012
8013 <p>The LWG believes that this issue should be considered as part of a
8014 general review of const issues for the next revision of the
8015 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
8016
8017
8018
8019
8020 <hr>
8021 <h3><a name="181"></a>181. make_pair() unintended behavior</h3>
8022 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8023  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-03 <b>Last modified:</b> 2010-10-29</p>
8024 <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>
8025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
8026 <p><b>Discussion:</b></p>
8027 <p>The claim has surfaced in Usenet that expressions such as<br>
8028 <br>
8029 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
8030 <br>
8031 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
8032 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
8033 <br>
8034 I doubt anyone intended that behavior...
8035 </p>
8036
8037
8038 <p><b>Proposed resolution:</b></p>
8039 <p>In 20.3 [utility], paragraph 1 change the following
8040 declaration of make_pair():</p>
8041 <blockquote>
8042   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
8043 </blockquote>
8044 <p>to:</p>
8045 <blockquote>
8046   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
8047 </blockquote>
8048 <p>  In 20.3.5 [pairs] paragraph 7 and the line before, change:</p>
8049 <blockquote>
8050 <pre>template &lt;class T1, class T2&gt;
8051 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
8052 </blockquote>
8053 <p>to:</p>
8054 <blockquote>
8055 <pre>template &lt;class T1, class T2&gt;
8056 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
8057 </blockquote>
8058 <p>and add the following footnote to the effects clause:</p>
8059 <blockquote>
8060   <p> According to 12.8 [class.copy], an implementation is permitted
8061   to not perform a copy of an argument, thus avoiding unnecessary
8062   copies.</p>
8063 </blockquote>
8064
8065
8066 <p><b>Rationale:</b></p>
8067 <p>Two potential fixes were suggested by Matt Austern and Dietmar
8068 Kühl, respectively, 1) overloading with array arguments, and 2) use of
8069 a reference_traits class with a specialization for arrays.  Andy
8070 Koenig suggested changing to pass by value. In discussion, it appeared
8071 that this was a much smaller change to the standard that the other two
8072 suggestions, and any efficiency concerns were more than offset by the
8073 advantages of the solution. Two implementors reported that the
8074 proposed resolution passed their test suites.</p>
8075
8076
8077
8078
8079 <hr>
8080 <h3><a name="182"></a>182. Ambiguous references to size_t</h3>
8081 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8082  <b>Submitter:</b> Al Stevens <b>Opened:</b> 1999-08-15 <b>Last modified:</b> 2010-10-29</p>
8083 <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>
8084 <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>
8085 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8086 <p><b>Discussion:</b></p>
8087 <p>Many references to <tt> size_t</tt> throughout the document
8088 omit the <tt> std::</tt> namespace qualification.</p> <p>For
8089 example, 17.6.3.6 [replacement.functions] paragraph 2:</p>
8090 <blockquote>
8091 <pre> operator new(size_t)
8092  operator new(size_t, const std::nothrow_t&amp;)
8093  operator new[](size_t)
8094  operator new[](size_t, const std::nothrow_t&amp;)</pre>
8095 </blockquote>
8096
8097
8098 <p><b>Proposed resolution:</b></p>
8099 <p>   In 17.6.3.6 [replacement.functions] paragraph 2: replace:</p>
8100 <blockquote>
8101 <p><tt>     - operator new(size_t)<br>
8102      - operator new(size_t, const std::nothrow_t&amp;)<br>
8103      - operator new[](size_t)<br>
8104      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
8105 </blockquote>
8106 <p>    by:</p>
8107 <blockquote>
8108 <pre>- operator new(std::size_t)
8109 - operator new(std::size_t, const std::nothrow_t&amp;)
8110 - operator new[](std::size_t)
8111 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
8112 </blockquote>
8113 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
8114 <blockquote>
8115   <p>The typedef members pointer, const_pointer, size_type, and difference_type
8116   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
8117 </blockquote>
8118 <p>&nbsp;by:</p>
8119 <blockquote>
8120   <p>The typedef members pointer, const_pointer, size_type, and difference_type
8121   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
8122   respectively.</p>
8123 </blockquote>
8124 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
8125 <blockquote>
8126   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
8127   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
8128   is unspecified when or how often this function is called. The use of hint is
8129   unspecified, but intended as an aid to locality if an implementation so
8130   desires.</p>
8131 </blockquote>
8132 <p>by:</p>
8133 <blockquote>
8134   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
8135   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
8136   it is unspecified when or how often this function is called. The use of hint
8137   is unspecified, but intended as an aid to locality if an implementation so
8138   desires.</p>
8139 </blockquote>
8140 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
8141 <blockquote>
8142   <p>In Table 37, X denotes a Traits class defining types and functions for the
8143   character container type CharT; c and d denote values of type CharT; p and q
8144   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
8145   j denote values of type size_t; e and f denote values of type X::int_type; pos
8146   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
8147 </blockquote>
8148 <p>by:</p>
8149 <blockquote>
8150   <p>In Table 37, X denotes a Traits class defining types and functions for the
8151   character container type CharT; c and d denote values of type CharT; p and q
8152   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
8153   j denote values of type std::size_t; e and f denote values of type X::int_type;
8154   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
8155 </blockquote>
8156 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
8157 X::length(p): "size_t" by "std::size_t".</p>
8158 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
8159 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
8160     by:<br>
8161 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
8162 <p>   In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of    template &lt;class charT&gt; class ctype.<br>
8163 <br>
8164    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
8165 <br>
8166 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
8167 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
8168 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
8169
8170
8171 <p><b>Rationale:</b></p>
8172 <p>The LWG believes correcting names like <tt>size_t</tt> and
8173 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
8174 to be essentially editorial.  There there can't be another size_t or
8175 ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],</p>
8176
8177 <blockquote><p>
8178 For each type T from the Standard C library, the types ::T and std::T
8179 are reserved to the implementation and, when defined, ::T shall be
8180 identical to std::T.
8181 </p></blockquote>
8182
8183 <p>The issue is treated as a Defect Report to make explicit the Project
8184 Editor's authority to make this change.</p>
8185
8186 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
8187 request of the LWG.]</i></p>
8188
8189
8190 <p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
8191 address use of the name <tt>size_t</tt> in contexts outside of
8192 namespace std, such as in the description of <tt>::operator new</tt>.
8193 The proposed changes should be reviewed to make sure they are
8194 correct.]</i></p>
8195
8196
8197 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
8198 them to be correct.]</i></p>
8199
8200
8201
8202
8203
8204
8205
8206 <hr>
8207 <h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
8208 <p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8209  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-07-07 <b>Last modified:</b> 2010-10-29</p>
8210 <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>
8211 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8212 <p><b>Discussion:</b></p>
8213 <p>27.7.3 [std.manip] paragraph 3 says (clause numbering added for
8214 exposition):</p>
8215 <blockquote>
8216 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
8217 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
8218 called, and if [2] in is an (instance of) basic_istream then the expression
8219 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
8220 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
8221 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
8222 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
8223 has type istream&amp; and value in.</p>
8224 </blockquote>
8225 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
8226 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
8227 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
8228 ..."</p>
8229 <p>If the wording in the standard is correct, I can see no way of implementing
8230 any of the manipulators so that they will work with wide character streams.</p>
8231 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
8232 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
8233 doesn't).</p>
8234 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
8235 8. In addition, Para 6 [setfill] has a similar error, but relates only to
8236 ostreams.</p>
8237 <p>I'd be happier if there was a better way of saying this, to make it clear
8238 that the value of the expression is "the same specialization of
8239 basic_ostream as out"&amp;</p>
8240
8241
8242 <p><b>Proposed resolution:</b></p>
8243 <p>Replace section 27.7.3 [std.manip] except paragraph 1 with the
8244 following:</p>
8245 <blockquote>
8246 <p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
8247 function.<br>
8248 <br>
8249 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
8250 <br>
8251 -3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
8252 as if f(s, mask) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if
8253 f(s, mask) were called. The function f can be defined as:*<br>
8254 <br>
8255 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the
8256 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt; noskipws), and the expression cout &lt;&lt; resetiosflags(ios_base::showbase) clears
8257 ios_base::showbase in the format flags stored in the basic_ostream&lt;charT,traits&gt; object cout (the same as cout &lt;&lt;
8258 noshowbase). --- end footnote]<br>
8259 <br>
8260 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
8261 &nbsp;&nbsp; {<br>
8262 &nbsp;&nbsp; //  reset specified flags<br>
8263 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
8264 &nbsp;&nbsp; return str;<br>
8265 &nbsp;&nbsp; }<br>
8266 </tt><br>
8267 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8268 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8269 <br>
8270 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
8271 <br>
8272 -4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
8273 as if f(s, mask) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s,
8274 mask) were called. The function f can be defined as:<br>
8275 <br>
8276 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
8277 &nbsp;&nbsp; {<br>
8278 &nbsp;&nbsp; //  set specified flags<br>
8279 &nbsp;&nbsp; str.setf(mask);<br>
8280 &nbsp;&nbsp; return str;<br>
8281 &nbsp;&nbsp; }<br>
8282 </tt><br>
8283 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8284 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8285 <br>
8286 <tt>smanip setbase(int base);</tt><br>
8287 <br>
8288 -5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
8289 as if f(s, base) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s,
8290 base) were called. The function f can be defined as:<br>
8291 <br>
8292 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
8293 &nbsp;&nbsp; {<br>
8294 &nbsp;&nbsp; //  set  basefield<br>
8295 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
8296 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
8297 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
8298 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
8299 &nbsp;&nbsp; return str;<br>
8300 &nbsp;&nbsp; }<br>
8301 </tt><br>
8302 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8303 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8304 <br>
8305 <tt>smanip setfill(char_type c);<br>
8306 </tt><br>
8307 -6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream&lt;charT,traits&gt; and c has type charT then the
8308 expression out&lt;&lt;s behaves as if f(s, c) were called. The function f can be
8309 defined as:<br>
8310 <br>
8311 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
8312 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
8313 &nbsp;&nbsp; {<br>
8314 &nbsp;&nbsp; //  set fill character<br>
8315 &nbsp;&nbsp; str.fill(c);<br>
8316 &nbsp;&nbsp; return str;<br>
8317 &nbsp;&nbsp; }<br>
8318 </tt><br>
8319 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
8320 <br>
8321 <tt>smanip setprecision(int n);</tt><br>
8322 <br>
8323 -7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
8324 as if f(s, n) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s, n)
8325 were called. The function f can be defined as:<br>
8326 <br>
8327 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
8328 &nbsp;&nbsp; {<br>
8329 &nbsp;&nbsp; //  set precision<br>
8330 &nbsp;&nbsp; str.precision(n);<br>
8331 &nbsp;&nbsp; return str;<br>
8332 &nbsp;&nbsp; }<br>
8333 </tt><br>
8334 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8335 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
8336 .<br>
8337 <tt>smanip setw(int n);<br>
8338 </tt><br>
8339 -8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
8340 as if f(s, n) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s, n)
8341 were called. The function f can be defined as:<br>
8342 <br>
8343 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
8344 &nbsp;&nbsp; {<br>
8345 &nbsp;&nbsp; //  set width<br>
8346 &nbsp;&nbsp; str.width(n);<br>
8347 &nbsp;&nbsp; return str;<br>
8348 &nbsp;&nbsp; }<br>
8349 </tt><br>
8350 The expression out&lt;&lt;s has type
8351 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
8352 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
8353 in.
8354 </p>
8355 </blockquote>
8356
8357 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
8358 the proposed resolution.]</i></p>
8359
8360
8361 <p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
8362 the same paragraphs.]</i></p>
8363
8364
8365 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
8366 resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
8367 intertwined that dealing with them separately appear fraught with
8368 error.  The full text was supplied by Bill Plauger; it was cross
8369 checked against changes supplied by Andy Sawyer. It should be further
8370 checked by the LWG.]</i></p>
8371
8372
8373
8374
8375
8376
8377 <hr>
8378 <h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
8379 <p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8380  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-07-21 <b>Last modified:</b> 2010-10-29</p>
8381 <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>
8382 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8383 <p><b>Discussion:</b></p>
8384 <p>bools are defined by the standard to be of integer types, as per
8385 3.9.1 [basic.fundamental] paragraph 7.  However "integer types"
8386 seems to have a special meaning for the author of 18.2. The net effect
8387 is an unclear and confusing specification for
8388 numeric_limits&lt;bool&gt; as evidenced below.</p>
8389
8390 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
8391 types, the number of non-sign bits in the representation.</p>
8392
8393 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
8394 arithmetical value converts to true.</p>
8395
8396 <p>I don't think it makes sense at all to require
8397 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
8398 be meaningful.</p>
8399
8400 <p>The standard defines what constitutes a signed (resp. unsigned) integer
8401 types. It doesn't categorize bool as being signed or unsigned. And the set of
8402 values of bool type has only two elements.</p>
8403
8404 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
8405 to be meaningful.</p>
8406
8407 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
8408 <blockquote>
8409   <p>For integer types, specifies the base of the representation.186)</p>
8410 </blockquote>
8411
8412 <p>This disposition is at best misleading and confusing for the standard
8413 requires a "pure binary numeration system" for integer types as per
8414 3.9.1/7</p>
8415
8416 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
8417 BCD)."&nbsp; This also erroneous as the standard never defines any integer
8418 types with base representation other than 2.</p>
8419
8420 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
8421 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
8422
8423
8424 <p><b>Proposed resolution:</b></p>
8425 <p>Append to the end of 18.3.1.5 [numeric.special]:</p>
8426 <blockquote>
8427   <p>The specialization for bool shall be provided as follows:</p>
8428   <pre>    namespace std {
8429        template&lt;&gt; class numeric_limits&lt;bool&gt; {
8430        public:
8431          static const bool is_specialized = true;
8432          static bool min() throw() { return false; }
8433          static bool max() throw() { return true; }
8434
8435          static const int  digits = 1;
8436          static const int  digits10 = 0;
8437          static const bool is_signed = false;
8438          static const bool is_integer = true;
8439          static const bool is_exact = true;
8440          static const int  radix = 2;
8441          static bool epsilon() throw() { return 0; }
8442          static bool round_error() throw() { return 0; }
8443
8444          static const int  min_exponent = 0;
8445          static const int  min_exponent10 = 0;
8446          static const int  max_exponent = 0;
8447          static const int  max_exponent10 = 0;
8448
8449          static const bool has_infinity = false;
8450          static const bool has_quiet_NaN = false;
8451          static const bool has_signaling_NaN = false;
8452          static const float_denorm_style has_denorm = denorm_absent;
8453          static const bool has_denorm_loss = false;
8454          static bool infinity() throw() { return 0; }
8455          static bool quiet_NaN() throw() { return 0; }
8456          static bool signaling_NaN() throw() { return 0; }
8457          static bool denorm_min() throw() { return 0; }
8458
8459          static const bool is_iec559 = false;
8460          static const bool is_bounded = true;
8461          static const bool is_modulo = false;
8462
8463          static const bool traps = false;
8464          static const bool tinyness_before = false;
8465          static const float_round_style round_style = round_toward_zero;
8466        };
8467      }</pre>
8468 </blockquote>
8469
8470 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
8471 rather than more general wording in the original proposed
8472 resolution.]</i></p>
8473
8474
8475 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
8476 Josuttis provided the above wording.]</i></p>
8477
8478
8479
8480
8481
8482
8483 <hr>
8484 <h3><a name="185"></a>185. Questionable use of term "inline"</h3>
8485 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8486  <b>Submitter:</b> UK Panel <b>Opened:</b> 1999-07-26 <b>Last modified:</b> 2010-10-29</p>
8487 <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>
8488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8489 <p><b>Discussion:</b></p>
8490 <p>Paragraph 4 of 20.8 [function.objects] says:</p>
8491 <blockquote>
8492   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
8493   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
8494   the addition and the negation. end example]</p>
8495 </blockquote>
8496 <p>(Note: The "addition" referred to in the above is in para 3) we can
8497 find no other wording, except this (non-normative) example which suggests that
8498 any "inlining" will take place in this case.</p>
8499 <p>Indeed both:</p>
8500 <blockquote>
8501   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
8502   unspecified whether any global functions in the C++ Standard Library
8503   are defined as inline (7.1.2).</p>
8504 </blockquote>
8505 <p>and</p>
8506 <blockquote>
8507   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
8508   unspecified whether any member functions in the C++ Standard Library
8509   are defined as inline (7.1.2).</p>
8510 </blockquote>
8511 <p>take care to state that this may indeed NOT be the case.</p>
8512 <p>Thus the example "mandates" behavior that is explicitly
8513 not required elsewhere.</p>
8514
8515
8516 <p><b>Proposed resolution:</b></p>
8517 <p>In 20.8 [function.objects] paragraph 1, remove the sentence:</p>
8518 <blockquote>
8519 <p>They are important for the effective use of the library.</p>
8520 </blockquote>
8521 <p>Remove 20.8 [function.objects] paragraph 2, which reads:</p>
8522 <blockquote>
8523   <p> Using function objects together with function templates
8524   increases the expressive power of the library as well as making the
8525   resulting code much more efficient.</p>
8526 </blockquote>
8527 <p>In 20.8 [function.objects] paragraph 4, remove the sentence:</p>
8528 <blockquote>
8529   <p>The corresponding functions will inline the addition and the
8530   negation.</p>
8531 </blockquote>
8532
8533 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
8534
8535 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
8536
8537
8538
8539
8540
8541
8542 <hr>
8543 <h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
8544 <p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8545  <b>Submitter:</b> Darin Adler <b>Opened:</b> 1999-08-13 <b>Last modified:</b> 2010-10-29</p>
8546 <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>
8547 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8548 <p><b>Discussion:</b></p>
8549 <p>In section 20.5.2 [bitset.members], paragraph 13 defines the
8550 bitset::set operation to take a second parameter of type int. The
8551 function tests whether this value is non-zero to determine whether to
8552 set the bit to true or false. The type of this second parameter should
8553 be bool. For one thing, the intent is to specify a Boolean value. For
8554 another, the result type from test() is bool. In addition, it's
8555 possible to slice an integer that's larger than an int. This can't
8556 happen with bool, since conversion to bool has the semantic of
8557 translating 0 to false and any non-zero value to true.</p>
8558
8559
8560 <p><b>Proposed resolution:</b></p>
8561 <p>In 20.5 [template.bitset] Para 1 Replace:</p>
8562 <blockquote>
8563 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
8564 </blockquote>
8565 <p>With:</p>
8566 <blockquote>
8567   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
8568 </blockquote>
8569 <p>In 20.5.2 [bitset.members] Para 12(.5) Replace:</p>
8570 <blockquote>
8571   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
8572 </blockquote>
8573 <p>With:</p>
8574 <blockquote>
8575   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
8576 </blockquote>
8577
8578 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
8579 on better P/R wording.]</i></p>
8580
8581 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
8582
8583
8584
8585 <p><b>Rationale:</b></p>
8586 <p><tt>bool</tt> is a better choice.  It is believed that binary
8587 compatibility is not an issue, because this member function is
8588 usually implemented as <tt>inline</tt>, and because it is already
8589 the case that users cannot rely on the type of a pointer to a
8590 nonvirtual member of a standard library class.</p>
8591
8592
8593
8594
8595
8596 <hr>
8597 <h3><a name="187"></a>187. iter_swap underspecified</h3>
8598 <p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8599  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-14 <b>Last modified:</b> 2010-10-29</p>
8600 <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>
8601 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8602 <p><b>Discussion:</b></p>
8603 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
8604 ``exchanges the values'' of the objects to which two iterators
8605 refer.<br> <br> What it doesn't say is whether it does so using swap
8606 or using the assignment operator and copy constructor.<br> <br> This
8607 question is an important one to answer, because swap is specialized to
8608 work efficiently for standard containers.<br> For example:</p>
8609 <blockquote>
8610 <pre>vector&lt;int&gt; v1, v2;
8611 iter_swap(&amp;v1, &amp;v2);</pre>
8612 </blockquote>
8613 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
8614 Or is it equivalent to</p>
8615 <blockquote>
8616 <pre>{
8617 vector&lt;int&gt; temp = v1;
8618 v1 = v2;
8619 v2 = temp;
8620 }</pre>
8621 </blockquote>
8622 <p>The first alternative is O(1); the second is O(n).</p>
8623 <p>A LWG member, Dave Abrahams, comments:</p>
8624 <blockquote>
8625 <p>Not an objection necessarily, but I want to point out the cost of
8626 that requirement:</p>
8627   <blockquote>
8628 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
8629   </blockquote>
8630 <p>can currently be specialized to be more efficient than
8631 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
8632 make that optimization illegal.&nbsp;</p>
8633 </blockquote>
8634
8635 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
8636 which are no longer permitted.]</i></p>
8637
8638
8639
8640 <p><b>Proposed resolution:</b></p>
8641 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
8642 <blockquote>
8643 <p>Exchanges the values pointed to by the two iterators a and b.</p>
8644 </blockquote>
8645 <p>to</p>
8646 <blockquote>
8647 <p><tt>swap(*a, *b)</tt>.</p>
8648 </blockquote>
8649
8650
8651
8652 <p><b>Rationale:</b></p>
8653 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
8654   some iterators for which we want to specialize <tt>iter_swap</tt>,
8655   but the fully general version should have a general specification.</p>
8656
8657 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
8658 iter_swap should not be specialized as suggested above.  That would do
8659 much more than exchanging the two iterators' values: it would change
8660 predecessor/successor relationships, possibly moving the iterator from
8661 one list to another.  That would surely be inappropriate.</p>
8662
8663
8664
8665
8666
8667 <hr>
8668 <h3><a name="189"></a>189. setprecision() not specified correctly</h3>
8669 <p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8670  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-25 <b>Last modified:</b> 2010-10-29</p>
8671 <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>
8672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
8673 <p><b>Discussion:</b></p>
8674 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
8675 and includes a parenthetical note saying that it is the number of
8676 digits after the decimal point.<br>
8677 <br>
8678 This claim is not strictly correct.  For example, in the default
8679 floating-point output format, setprecision sets the number of
8680 significant digits printed, not the number of digits after the decimal
8681 point.<br>
8682 <br>
8683 I would like the committee to look at the definition carefully and
8684 correct the statement in 27.4.2.2</p>
8685
8686
8687 <p><b>Proposed resolution:</b></p>
8688 <p>Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text
8689 "(number of digits after the decimal point)".</p>
8690
8691
8692
8693
8694 <hr>
8695 <h3><a name="193"></a>193. Heap operations description incorrect</h3>
8696 <p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8697  <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 1999-09-24 <b>Last modified:</b> 2010-10-29</p>
8698 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
8699 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
8700 <p><b>Discussion:</b></p>
8701 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
8702 is<br>
8703 <br>
8704 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
8705 <br>
8706 I think this is incorrect and should be changed to the wording in the proposed
8707 resolution.</p>
8708 <p>Actually there are two independent changes:</p>
8709 <blockquote>
8710   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
8711   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
8712   <p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions  could not be used for a
8713   priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects  priority AND time).</p>
8714 </blockquote>
8715
8716
8717 <p><b>Proposed resolution:</b></p>
8718 <p>Change 25.4.6 [alg.heap.operations] property (1) from:</p>
8719 <blockquote>
8720   <p>(1) *a is the largest element</p>
8721 </blockquote>
8722 <p>to:</p>
8723 <blockquote>
8724   <p>(1) There is no element greater than <tt>*a</tt></p>
8725 </blockquote>
8726
8727
8728
8729
8730
8731 <hr>
8732 <h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
8733 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8734  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-10-13 <b>Last modified:</b> 2010-10-29</p>
8735 <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>
8736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
8737 <p><b>Discussion:</b></p>
8738 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
8739 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
8740 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
8741 should set failbit. Should it set eofbit as well?  The standard
8742 doesn't seem to answer that question.</p>
8743
8744 <p>On the one hand, nothing in 27.7.1.1.3 [istream::sentry] says that
8745 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
8746 other hand, 27.7.1.1 [istream] paragraph 4 says that if
8747 extraction from a <tt>streambuf</tt> "returns
8748 <tt>traits::eof()</tt>, then the input function, except as explicitly
8749 noted otherwise, completes its actions and does
8750 <tt>setstate(eofbit)"</tt>.  So the question comes down to
8751 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
8752 input function.</p>
8753
8754 <p>Comments from Jerry Schwarz:</p>
8755 <blockquote>
8756 <p>It was always my intention that eofbit should be set any time that a
8757 virtual returned something to indicate eof, no matter what reason
8758 iostream code had for calling the virtual.</p>
8759 <p>
8760 The motivation for this is that I did not want to require streambufs
8761 to behave consistently if their virtuals are called after they have
8762 signaled eof.</p>
8763 <p>
8764 The classic case is a streambuf reading from a UNIX file.  EOF isn't
8765 really a state for UNIX file descriptors.  The convention is that a
8766 read on UNIX returns 0 bytes to indicate "EOF", but the file
8767 descriptor isn't shut down in any way and future reads do not
8768 necessarily also return 0 bytes.  In particular, you can read from
8769 tty's on UNIX even after they have signaled "EOF".  (It
8770 isn't always understood that a ^D on UNIX is not an EOF indicator, but
8771 an EOL indicator.  By typing a "line" consisting solely of
8772 ^D you cause a read to return 0 bytes, and by convention this is
8773 interpreted as end of file.)</p>
8774 </blockquote>
8775
8776
8777 <p><b>Proposed resolution:</b></p>
8778 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
8779 <blockquote>
8780 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
8781 returns <tt>traits::eof()</tt>, the function calls
8782 <tt>setstate(failbit | eofbit)</tt> (which may throw
8783 <tt>ios_base::failure</tt>).
8784 </p>
8785 </blockquote>
8786
8787
8788
8789
8790 <hr>
8791 <h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
8792 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8793  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1999-11-03 <b>Last modified:</b> 2010-10-29</p>
8794 <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>
8795 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8796 <p><b>Discussion:</b></p>
8797 <p>
8798 Is a pointer or reference obtained from an iterator still valid after
8799 destruction of the iterator?
8800 </p>
8801 <p>
8802 Is a pointer or reference obtained from an iterator still valid after the value
8803 of the iterator changes?
8804 </p>
8805 <blockquote>
8806 <pre>#include &lt;iostream&gt;
8807 #include &lt;vector&gt;
8808 #include &lt;iterator&gt;
8809
8810 int main()
8811 {
8812     typedef std::vector&lt;int&gt; vec_t;
8813     vec_t v;
8814     v.push_back( 1 );
8815
8816     // Is a pointer or reference obtained from an iterator still
8817     // valid after destruction of the iterator?
8818     int * p = &amp;*v.begin();
8819     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
8820
8821     // Is a pointer or reference obtained from an iterator still
8822     // valid after the value of the iterator changes?
8823     vec_t::iterator iter( v.begin() );
8824     p = &amp;*iter++;
8825     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
8826
8827     return 0;
8828 }
8829 </pre>
8830 </blockquote>
8831
8832 <p>The standard doesn't appear to directly address these
8833 questions. The standard needs to be clarified. At least two real-world
8834 cases have been reported where library implementors wasted
8835 considerable effort because of the lack of clarity in the
8836 standard. The question is important because requiring pointers and
8837 references to remain valid has the effect for practical purposes of
8838 prohibiting iterators from pointing to cached rather than actual
8839 elements of containers.</p>
8840
8841 <p>The standard itself assumes that pointers and references obtained
8842 from an iterator are still valid after iterator destruction or
8843 change. The definition of reverse_iterator::operator*(), 24.5.1.3.3 [reverse.iter.conv], which returns a reference, defines
8844 effects:</p>
8845
8846 <blockquote>
8847   <pre>Iterator tmp = current;
8848 return *--tmp;</pre>
8849 </blockquote>
8850 <p>The definition of reverse_iterator::operator-&gt;(), 24.5.1.3.4 [reverse.iter.op.star], which returns a pointer, defines effects:</p>
8851 <blockquote>
8852   <pre>return &amp;(operator*());</pre>
8853 </blockquote>
8854
8855 <p>Because the standard itself assumes pointers and references remain
8856 valid after iterator destruction or change, the standard should say so
8857 explicitly. This will also reduce the chance of user code breaking
8858 unexpectedly when porting to a different standard library
8859 implementation.</p>
8860
8861
8862 <p><b>Proposed resolution:</b></p>
8863 <p>Add a new paragraph to X [iterator.concepts]:</p>
8864 <blockquote><p>
8865 Destruction of an iterator may invalidate pointers and references
8866 previously obtained from that iterator.
8867 </p></blockquote>
8868
8869 <p>Replace paragraph 1 of 24.5.1.3.3 [reverse.iter.conv] with:</p>
8870
8871 <blockquote>
8872 <p><b>Effects:</b></p>
8873 <pre>  this-&gt;tmp = current;
8874   --this-&gt;tmp;
8875   return *this-&gt;tmp;
8876 </pre>
8877
8878 <p>
8879 [<i>Note:</i> This operation must use an auxiliary member variable,
8880 rather than a temporary variable, to avoid returning a reference that
8881 persists beyond the lifetime of its associated iterator.  (See
8882 X [iterator.concepts].)  The name of this member variable is shown for
8883 exposition only.  <i>--end note</i>]
8884 </p>
8885 </blockquote>
8886
8887 <p><i>[Post-Tokyo: The issue has been reformulated purely
8888 in terms of iterators.]</i></p>
8889
8890
8891 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
8892 assumption by reverse_iterator. The issue and proposed resolution was
8893 reformulated yet again to reflect this reality.]</i></p>
8894
8895
8896 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
8897 assumes its underlying iterator has persistent pointers and
8898 references.  Andy Koenig pointed out that it is possible to rewrite
8899 reverse_iterator so that it no longer makes such an assupmption.
8900 However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>.  If we
8901 decide it is intentional that <tt>p[n]</tt> may return by value
8902 instead of reference when <tt>p</tt> is a Random Access Iterator,
8903 other changes in reverse_iterator will be necessary.]</i></p>
8904
8905
8906
8907 <p><b>Rationale:</b></p>
8908 <p>This issue has been discussed extensively.  Note that it is
8909 <i>not</i> an issue about the behavior of predefined iterators.  It is
8910 asking whether or not user-defined iterators are permitted to have
8911 transient pointers and references.  Several people presented examples
8912 of useful user-defined iterators that have such a property; examples
8913 include a B-tree iterator, and an "iota iterator" that doesn't point
8914 to memory.  Library implementors already seem to be able to cope with
8915 such iterators: they take pains to avoid forming references to memory
8916 that gets iterated past.  The only place where this is a problem is
8917 <tt>reverse_iterator</tt>, so this issue changes
8918 <tt>reverse_iterator</tt> to make it work.</p>
8919
8920 <p>This resolution does not weaken any guarantees provided by
8921 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
8922 Clause 23 should be reviewed to make sure that guarantees for
8923 predefined iterators are as strong as users expect.</p>
8924
8925
8926
8927
8928
8929
8930 <hr>
8931 <h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
8932 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8933  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2010-10-29</p>
8934 <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>
8935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
8936 <p><b>Discussion:</b></p>
8937 <p>
8938 Suppose that <tt>A</tt> is a class that conforms to the
8939 Allocator requirements of Table 32, and <tt>a</tt> is an
8940 object of class <tt>A</tt>  What should be the return
8941 value of <tt>a.allocate(0)</tt>?  Three reasonable
8942 possibilities: forbid the argument <tt>0</tt>, return
8943 a null pointer, or require that the return value be a
8944 unique non-null pointer.
8945 </p>
8946
8947
8948 <p><b>Proposed resolution:</b></p>
8949 <p>
8950 Add a note to the <tt>allocate</tt> row of Table 32:
8951 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
8952
8953
8954 <p><b>Rationale:</b></p>
8955 <p>A key to understanding this issue is that the ultimate use of
8956 allocate() is to construct an iterator, and that iterator for zero
8957 length sequences must be the container's past-the-end
8958 representation.  Since this already implies special case code, it
8959 would be over-specification to mandate the return value.
8960 </p>
8961
8962
8963
8964
8965 <hr>
8966 <h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
8967 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8968  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2010-10-29</p>
8969 <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>
8970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8971 <p><b>Discussion:</b></p>
8972 <p>
8973 In table 74, the return type of the expression <tt>*a</tt> is given
8974 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
8975 For constant iterators, however, this is wrong.  ("Value type"
8976 is never defined very precisely, but it is clear that the value type
8977 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
8978 <tt>int</tt>, not <tt>const int</tt>.)
8979 </p>
8980
8981
8982 <p><b>Proposed resolution:</b></p>
8983 <p>
8984 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
8985 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
8986 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
8987 In the <tt>a-&gt;m</tt> row, change the return type from
8988 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
8989 otherwise <tt>const U&amp;</tt>".
8990 </p>
8991
8992 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
8993 there are multiple const problems with the STL portion of the library
8994 and that these should be addressed as a single package.&nbsp; Note
8995 that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a> has already been declared NAD Future for
8996 that very reason.]</i></p>
8997
8998
8999 <p><i>[Redmond: the LWG thinks this is separable from other constness
9000 issues.  This issue is just cleanup; it clarifies language that was
9001 written before we had iterator_traits.  Proposed resolution was
9002 modified: the original version only discussed *a.  It was pointed out
9003 that we also need to worry about *r++ and a-&gt;m.]</i></p>
9004
9005
9006
9007
9008
9009
9010
9011 <hr>
9012 <h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
9013 <p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
9014  <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 1999-12-21 <b>Last modified:</b> 2010-10-29</p>
9015 <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>
9016 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9017 <p><b>Discussion:</b></p>
9018 <p>
9019 In some places in this section, the terms "fundamental types" and
9020 "scalar types" are used when the term "arithmetic types" is intended.
9021 The current usage is incorrect because void is a fundamental type and
9022 pointers are scalar types, neither of which should have
9023 specializations of numeric_limits.
9024 </p>
9025 <p><i>[Lillehammer: it remains true that numeric_limits is using
9026   imprecise language. However, none of the proposals for changed
9027   wording are clearer.  A redesign of numeric_limits is needed, but this
9028   is more a task than an open issue.]</i></p>
9029
9030
9031
9032 <p><b>Proposed resolution:</b></p>
9033
9034 <p>
9035 Change 18.3 [support.limits] to:
9036 </p>
9037
9038 <blockquote>
9039 <p>
9040 -1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
9041 <tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
9042 characteristics of implementation-dependent <del>fundamental</del>
9043 <ins>arithmetic</ins> types (3.9.1).
9044 </p>
9045 </blockquote>
9046
9047 <p>
9048 Change 18.3.1 [limits] to:
9049 </p>
9050
9051 <blockquote>
9052 <p>
9053 -1- The <tt>numeric_limits</tt> component provides a C++ program with
9054 information about various properties of the implementation's
9055 representation of the <del>fundamental</del> <ins>arithmetic</ins>
9056 types.
9057 </p>
9058 <p>
9059 -2- Specializations shall be provided for each <del>fundamental</del>
9060 <ins>arithmetic</ins> type, both floating point and integer, including
9061 <tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
9062 for all such specializations of <tt>numeric_limits</tt>.
9063 </p>
9064 <p>
9065 -4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
9066 as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
9067 </p>
9068 </blockquote>
9069
9070 <p>
9071 Change 18.3.1.1 [numeric.limits] to:
9072 </p>
9073
9074 <blockquote>
9075 <p>
9076 <del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
9077 between fundamental types, which have specializations, and non-scalar types,
9078 which do not.</del>
9079 </p>
9080 </blockquote>
9081
9082
9083
9084
9085
9086
9087 <hr>
9088 <h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
9089 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
9090  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-01-13 <b>Last modified:</b> 2010-10-29</p>
9091 <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>
9092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9093 <p><b>Discussion:</b></p>
9094 <p>
9095 What should unique() do if you give it a predicate that is not an
9096 equivalence relation?  There are at least two plausible answers:
9097 </p>
9098
9099 <blockquote>
9100
9101 <p>
9102    1. You can't, because 25.2.8 says that it it "eliminates all but
9103    the first element from every consecutive group of equal
9104    elements..." and it wouldn't make sense to interpret "equal" as
9105    meaning anything but an equivalence relation.  [It also doesn't
9106    make sense to interpret "equal" as meaning ==, because then there
9107    would never be any sense in giving a predicate as an argument at
9108    all.]
9109 </p>
9110
9111 <p>
9112    2. The word "equal" should be interpreted to mean whatever the
9113    predicate says, even if it is not an equivalence relation
9114    (and in particular, even if it is not transitive).
9115 </p>
9116
9117 </blockquote>
9118
9119 <p>
9120 The example that raised this question is from Usenet:
9121 </p>
9122
9123 <blockquote>
9124
9125 <pre>int f[] = { 1, 3, 7, 1, 2 };
9126 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
9127
9128 </blockquote>
9129
9130 <p>
9131 If one blindly applies the definition using the predicate
9132 greater&lt;int&gt;, and ignore the word "equal", you get:
9133 </p>
9134
9135 <blockquote>
9136
9137 <p>
9138     Eliminates all but the first element from every consecutive group    
9139     of elements referred to by the iterator i in the range [first, last)    
9140     for which *i &gt; *(i - 1).
9141 </p>
9142
9143 </blockquote>
9144
9145 <p>
9146 The first surprise is the order of the comparison.  If we wanted to
9147 allow for the predicate not being an equivalence relation, then we
9148 should surely compare elements the other way: pred(*(i - 1), *i).  If
9149 we do that, then the description would seem to say: "Break the
9150 sequence into subsequences whose elements are in strictly increasing
9151 order, and keep only the first element of each subsequence".  So the
9152 result would be 1, 1, 2.  If we take the description at its word, it
9153 would seem to call for strictly DEcreasing order, in which case the
9154 result should be 1, 3, 7, 2.<br>
9155 <br>
9156 In fact, the SGI implementation of unique() does neither: It yields 1,
9157 3, 7.
9158 </p>
9159
9160
9161 <p><b>Proposed resolution:</b></p>
9162 <p>Change 25.3.9 [alg.unique] paragraph 1 to:</p>
9163 <blockquote><p>
9164 For a nonempty range, eliminates all but the first element from every
9165 consecutive group of equivalent elements referred to by the iterator
9166 <tt>i</tt> in the range [first+1, last) for which the following
9167 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
9168 false</tt>.
9169 </p></blockquote>
9170
9171 <p>
9172 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
9173 comparison function must be an equivalence relation."
9174 </p>
9175
9176 <p><i>[Redmond: discussed arguments for and against requiring the
9177 comparison function to be an equivalence relation.  Straw poll:
9178 14-2-5.  First number is to require that it be an equivalence
9179 relation, second number is to explicitly not require that it be an
9180 equivalence relation, third number is people who believe they need
9181 more time to consider the issue.  A separate issue: Andy Sawyer
9182 pointed out that "i-1" is incorrect, since "i" can refer to the first
9183 iterator in the range.  Matt provided wording to address this
9184 problem.]</i></p>
9185
9186
9187 <p><i>[Curaçao: The LWG changed "... the range (first,
9188 last)..." to "...  the range [first+1, last)..." for
9189 clarity. They considered this change close enough to editorial to not
9190 require another round of review.]</i></p>
9191
9192
9193
9194
9195 <p><b>Rationale:</b></p>
9196 <p>The LWG also considered an alternative resolution: change 
9197 25.3.9 [alg.unique] paragraph 1 to:</p>
9198
9199 <blockquote><p>
9200 For a nonempty range, eliminates all but the first element from every
9201 consecutive group of elements referred to by the iterator
9202 <tt>i</tt> in the range (first, last) for which the following
9203 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
9204 false</tt>.
9205 </p></blockquote>
9206
9207 <p>
9208 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
9209 comparison function need not be an equivalence relation."
9210 </p>
9211
9212
9213 <p>Informally: the proposed resolution imposes an explicit requirement
9214 that the comparison function be an equivalence relation.  The
9215 alternative resolution does not, and it gives enough information so
9216 that the behavior of unique() for a non-equivalence relation is
9217 specified.  Both resolutions are consistent with the behavior of
9218 existing implementations.</p>
9219
9220
9221
9222
9223
9224 <hr>
9225 <h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
9226 <p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
9227  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-08-29 <b>Last modified:</b> 2010-10-29</p>
9228 <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>
9229 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9230 <p><b>Discussion:</b></p>
9231 <p>As specified, the implementation of the nothrow version of operator
9232 new does not necessarily call the ordinary operator new, but may
9233 instead simply call the same underlying allocator and return a null
9234 pointer instead of throwing an exception in case of failure.</p>
9235
9236 <p>Such an implementation breaks code that replaces the ordinary
9237 version of new, but not the nothrow version. If the ordinary version
9238 of new/delete is replaced, and if the replaced delete is not
9239 compatible with pointers returned from the library versions of new,
9240 then when the replaced delete receives a pointer allocated by the
9241 library new(nothrow), crash follows.</p>
9242
9243 <p>The fix appears to be that the lib version of new(nothrow) must
9244 call the ordinary new. Thus when the ordinary new gets replaced, the
9245 lib version will call the replaced ordinary new and things will
9246 continue to work.</p>
9247
9248 <p>An alternative would be to have the ordinary new call
9249 new(nothrow). This seems sub-optimal to me as the ordinary version of
9250 new is the version most commonly replaced in practice. So one would
9251 still need to replace both ordinary and nothrow versions if one wanted
9252 to replace the ordinary version.</p>
9253
9254 <p>Another alternative is to put in clear text that if one version is
9255 replaced, then the other must also be replaced to maintain
9256 compatibility. Then the proposed resolution below would just be a
9257 quality of implementation issue. There is already such text in
9258 paragraph 7 (under the new(nothrow) version). But this nuance is
9259 easily missed if one reads only the paragraphs relating to the
9260 ordinary new.</p>
9261
9262 <p>
9263 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
9264 has been written explaining the rationale for the proposed resolution below.
9265 </p>
9266
9267
9268
9269 <p><b>Proposed resolution:</b></p>
9270 <p>
9271 Change 18.5.1.1 [new.delete.single]:
9272 </p>
9273
9274 <blockquote>
9275 <pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
9276 </pre>
9277 <blockquote>
9278 <p>
9279 -5- <i>Effects:</i> Same as above, except that it is called by a placement
9280 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
9281 an error indication, instead of a <tt>bad_alloc</tt> exception.
9282 </p>
9283
9284 <p>
9285 -6- <i>Replaceable:</i> a C++ program may define a function with this function
9286 signature that displaces the default version defined by the C++ Standard
9287 library.
9288 </p>
9289
9290 <p>
9291 -7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
9292 storage (3.7.4), or else return a null pointer. This nothrow version of operator
9293 new returns a pointer obtained as if acquired from the <ins>(possibly
9294 replaced)</ins> ordinary version. This requirement is binding on a replacement
9295 version of this function.
9296 </p>
9297
9298 <p>
9299 -8- <i>Default behavior:</i>
9300 </p>
9301 <ul>
9302 <li><ins>
9303 Calls <tt>operator new(<i>size</i>)</tt>.
9304 </ins></li>
9305 <li><ins>
9306 If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
9307 the result of that call, else
9308 </ins></li>
9309 <li><ins>
9310 if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
9311 a null pointer.
9312 </ins></li>
9313 <li><del>
9314 Executes a loop: Within the loop, the function first attempts to allocate the
9315 requested storage. Whether the attempt involves a call to the Standard C library
9316 function <tt>malloc</tt> is unspecified.
9317 </del></li>
9318 <li><del>
9319 Returns a pointer to the allocated storage if the attempt is successful.
9320 Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
9321 pointer, return a null pointer.
9322 </del></li>
9323 <li><del>
9324 Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
9325 called function returns, the loop repeats.
9326 </del></li>
9327 <li><del>
9328 The loop terminates when an attempt to allocate the requested storage is
9329 successful or when a called <i>new_handler</i> function does not return. If the
9330 called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
9331 exception</tt>, the function returns a null pointer.
9332 </del></li>
9333 </ul>
9334 <p>
9335 -9- [<i>Example:</i>
9336 </p>
9337 <blockquote><pre>T* p1 = new T;                 <i>// throws bad_alloc if it fails</i>
9338 T* p2 = new(nothrow) T;        <i>// returns 0 if it fails</i>
9339 </pre></blockquote>
9340 <p>
9341 --<i>end example</i>]
9342 </p>
9343 </blockquote>
9344
9345 <pre>void operator delete(void* <i>ptr</i>) throw();
9346 <del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
9347 </pre>
9348
9349 <blockquote>
9350 <p>
9351 -10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
9352 <i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
9353 </p>
9354 <p>
9355 -11- <i>Replaceable:</i> a C++ program may define a function with this function
9356 signature that displaces the default version defined by the C++ Standard
9357 library.
9358 </p>
9359 <p>
9360 -12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
9361 returned by an earlier call to the <del>default</del> <ins>(possibly
9362 replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
9363 new(std::size_t, const std::nothrow_t&amp;)</tt>.
9364 </p>
9365 <p>
9366 -13- <i>Default behavior:</i>
9367 </p>
9368 <ul>
9369 <li>
9370 For a null value of <tt><i>ptr</i></tt>, do nothing.
9371 </li>
9372 <li>
9373 Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
9374 call to the default <tt>operator new</tt>, which was not invalidated by an
9375 intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
9376 non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
9377 call to the default <tt>operator new</tt>.
9378 </li>
9379 </ul>
9380 <p>
9381 -14- <i>Remarks:</i>  It is unspecified under what conditions part or all of
9382 such reclaimed storage is allocated by a subsequent call to <tt>operator
9383 new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
9384 declared in <tt>&lt;cstdlib&gt;</tt>.
9385 </p>
9386 </blockquote>
9387
9388 <pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
9389 </pre>
9390
9391 <blockquote>
9392 <p><ins>
9393 -15- <i>Effects:</i> Same as above, except that it is called by the
9394 implementation when an exception propagates from a nothrow placement version
9395 of the <i>new-expression</i> (i.e. when the constructor throws an exception).
9396 </ins></p>
9397 <p><ins>
9398 -16- <i>Replaceable:</i> a C++ program may define a function with this function
9399 signature that displaces the default version defined by the C++ Standard
9400 library.
9401 </ins></p>
9402 <p><ins>
9403 -17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
9404 value returned by an earlier call to the (possibly replaced) <tt>operator
9405 new(std::size_t)</tt> or <tt>operator new(std::size_t, const
9406 std::nothrow_t&amp;)</tt>. </ins></p>
9407 <p><ins>
9408 -18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
9409 </ins></p>
9410 </blockquote>
9411
9412 </blockquote>
9413
9414 <p>
9415 Change 18.5.1.2 [new.delete.array]
9416 </p>
9417
9418 <blockquote>
9419 <pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
9420 </pre>
9421
9422 <blockquote>
9423 <p>
9424 -5- <i>Effects:</i> Same as above, except that it is called by a placement
9425 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
9426 an error indication, instead of a <tt>bad_alloc</tt> exception.
9427 </p>
9428
9429 <p>
9430 -6- <i>Replaceable:</i>  a C++ program can define a function with this function
9431 signature that displaces the default version defined by the C++ Standard
9432 library.
9433 </p>
9434
9435 <p>
9436 -7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
9437 const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
9438 returns a pointer obtained as if acquired from the ordinary version.</del>
9439 <ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
9440 return a null pointer. This nothrow version of operator new returns a pointer
9441 obtained as if acquired from the (possibly replaced) <tt>operator
9442 new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
9443 replacement version of this function.</ins>
9444 </p>
9445
9446 <p>
9447 -8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
9448 nothrow)</tt>.</del>
9449 </p>
9450
9451 <ul>
9452 <li><ins>
9453 Calls <tt>operator new[](<i>size</i>)</tt>.
9454 </ins></li>
9455 <li><ins>
9456 If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
9457 the result of that call, else
9458 </ins></li>
9459 <li><ins>
9460 if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
9461 a null pointer.
9462 </ins></li>
9463 </ul>
9464 </blockquote>
9465
9466 <pre>void operator delete[](void* <i>ptr</i>) throw(); 
9467 void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
9468 </pre>
9469
9470 <blockquote>
9471 <p>
9472 -9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
9473 array form of a <i>delete-expression</i> to render the value of
9474 <tt><i>ptr</i></tt> invalid.
9475 </p>
9476
9477 <p>
9478 -10- <i>Replaceable:</i> a C++ program can define a function with this function
9479 signature that displaces the default version defined by the C++ Standard
9480 library.
9481 </p>
9482
9483 <p>
9484 -11- <i>Requires:</i> the value of
9485 <tt><i>ptr</i></tt> is null or the value returned by an earlier call to
9486 <tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
9487 std::nothrow_t&amp;)</tt>.
9488 </p>
9489
9490 <p>
9491 -12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
9492 <tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
9493 </p>
9494 </blockquote>
9495
9496 </blockquote>
9497
9498
9499
9500 <p><b>Rationale:</b></p>
9501 <p>Yes, they may become unlinked, and that is by design. If a user
9502 replaces one, the user should also replace the other.</p>
9503
9504 <p><i>[
9505 Reopened due to a gcc conversation between Howard, Martin and Gaby.  Forwarding
9506 or not is visible behavior to the client and it would be useful for the client
9507 to know which behavior it could depend on.
9508 ]</i></p>
9509
9510
9511 <p><i>[
9512 Batavia: Robert voiced serious reservations about backwards compatibility for
9513 his customers.
9514 ]</i></p>
9515
9516
9517
9518
9519
9520
9521 <hr>
9522 <h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
9523 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9524  <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 2000-02-02 <b>Last modified:</b> 2010-10-29</p>
9525 <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>
9526 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9527 <p><b>Discussion:</b></p>
9528 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
9529 past-the-end values are always non-singular."</p>
9530 <p>This places an unnecessary restriction on past-the-end iterators for
9531 containers with forward iterators (for example, a singly-linked list). If the
9532 past-the-end value on such a container was a well-known singular value, it would
9533 still satisfy all forward iterator requirements.</p>
9534 <p>Removing this restriction would allow, for example, a singly-linked list
9535 without a "footer" node.</p>
9536 <p>This would have an impact on existing code that expects past-the-end
9537 iterators obtained from different (generic) containers being not equal.</p>
9538
9539
9540 <p><b>Proposed resolution:</b></p>
9541 <p>Change X [iterator.concepts] paragraph 5, the last sentence, from:</p>
9542 <blockquote>
9543 <p>Dereferenceable and past-the-end values are always non-singular.</p>
9544 </blockquote>
9545 <p>to:</p>
9546 <blockquote>
9547 <p>Dereferenceable values are always non-singular.&nbsp;</p>
9548 </blockquote>
9549
9550
9551 <p><b>Rationale:</b></p>
9552 <p>For some kinds of containers, including singly linked lists and
9553 zero-length vectors, null pointers are perfectly reasonable past-the-end
9554 iterators.  Null pointers are singular.
9555 </p>
9556
9557
9558
9559
9560 <hr>
9561 <h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
9562 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9563  <b>Submitter:</b> Igor Stauder <b>Opened:</b> 2000-02-11 <b>Last modified:</b> 2010-10-29</p>
9564 <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>
9565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9566 <p><b>Discussion:</b></p>
9567 <p>In Section 21.4 [basic.string] the basic_string member function
9568 declarations use a consistent style except for the following functions:</p>
9569 <blockquote>
9570   <pre>void push_back(const charT);
9571 basic_string&amp; assign(const basic_string&amp;);
9572 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
9573 </blockquote>
9574 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
9575 - push_back: use of const with charT (i.e. POD type passed by value
9576 not by reference - should be charT or const charT&amp; )<br>
9577 - swap: redundant use of template parameters in argument
9578 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
9579
9580
9581 <p><b>Proposed resolution:</b></p>
9582 <p>In Section 21.4 [basic.string] change the basic_string member
9583 function declarations push_back, assign, and swap to:</p>
9584 <blockquote>
9585   <pre>void push_back(charT c); 
9586
9587 basic_string&amp; assign(const basic_string&amp; str);
9588 void swap(basic_string&amp; str);</pre>
9589 </blockquote>
9590
9591
9592 <p><b>Rationale:</b></p>
9593 <p>Although the standard is in general not consistent in declaration
9594 style, the basic_string declarations are consistent other than the
9595 above.  The LWG felt that this was sufficient reason to merit the
9596 change.
9597 </p>
9598
9599
9600
9601
9602 <hr>
9603 <h3><a name="210"></a>210. distance first and last confused</h3>
9604 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9605  <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-15 <b>Last modified:</b> 2010-10-29</p>
9606 <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>
9607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9608 <p><b>Discussion:</b></p>
9609 <p>In paragraph 9 of section 25 [algorithms], it is written:</p>
9610 <blockquote>
9611   <p>      In the description of the algorithms operators + and - are used
9612            for some of the iterator categories for which they do not have to
9613            be defined. In these cases the semantics of [...] a-b is the same
9614            as of<br>
9615   <br>
9616   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
9617 </blockquote>
9618
9619
9620 <p><b>Proposed resolution:</b></p>
9621 <p>On the last line of paragraph 9 of section 25 [algorithms] change
9622 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
9623
9624
9625 <p><b>Rationale:</b></p>
9626 <p>There are two ways to fix the defect; change the description to b-a
9627 or change the return to distance(b,a).  The LWG preferred the
9628 former for consistency.</p>
9629
9630
9631
9632
9633 <hr>
9634 <h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
9635 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9636  <b>Submitter:</b> Scott Snyder <b>Opened:</b> 2000-02-04 <b>Last modified:</b> 2010-10-29</p>
9637 <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>
9638 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9639 <p><b>Discussion:</b></p>
9640 <p>The description of the stream extraction operator for std::string (section
9641 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
9642 the case that the operator fails to extract any characters from the input
9643 stream.</p>
9644 <p>This implies that the typical construction</p>
9645 <blockquote>
9646   <pre>std::istream is;
9647 std::string str;
9648 ...
9649 while (is &gt;&gt; str) ... ;</pre>
9650 </blockquote>
9651 <p>(which tests failbit) is not required to terminate at EOF.</p>
9652 <p>Furthermore, this is inconsistent with other extraction operators,
9653 which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.1.3 [istream.unformatted]), where this
9654 requirement is present, either explicitly or implicitly, for the
9655 extraction operators. It is also present explicitly in the description
9656 of getline (istream&amp;, string&amp;, charT) in section 21.4.8.9 [string.io] paragraph 8.)</p>
9657
9658
9659 <p><b>Proposed resolution:</b></p>
9660 <p>Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:</p>
9661 <blockquote>
9662
9663 <p>If the function extracts no characters, it calls
9664 is.setstate(ios::failbit) which may throw ios_base::failure
9665 (27.4.4.3).</p>
9666 </blockquote>
9667
9668
9669
9670
9671 <hr>
9672 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
9673 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9674  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2010-10-29</p>
9675 <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>
9676 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9677 <p><b>Discussion:</b></p>
9678 <p>The standard doesn't specify what min_element() and max_element() shall
9679 return if the range is empty (first equals last). The usual implementations
9680 return last. This problem seems also apply to partition(), stable_partition(),
9681 next_permutation(), and prev_permutation().</p>
9682
9683
9684 <p><b>Proposed resolution:</b></p>
9685 <p>In 25.4.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
9686 9, append: Returns last if first==last.</p>
9687
9688
9689 <p><b>Rationale:</b></p>
9690 <p>The LWG looked in some detail at all of the above mentioned
9691 algorithms, but believes that except for min_element() and
9692 max_element() it is already clear that last is returned if first ==
9693 last.</p>
9694
9695
9696
9697
9698 <hr>
9699 <h3><a name="214"></a>214. set::find() missing const overload</h3>
9700 <p><b>Section:</b> 23.6.3 [set], 23.6.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
9701  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-28 <b>Last modified:</b> 2010-10-29</p>
9702 <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>
9703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9704 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
9705 <p><b>Discussion:</b></p>
9706 <p>The specification for the associative container requirements in
9707 Table 69 state that the find member function should "return
9708 iterator; const_iterator for constant a". The map and multimap
9709 container descriptions have two overloaded versions of find, but set
9710 and multiset do not, all they have is:</p>
9711 <blockquote>
9712   <pre>iterator find(const key_type &amp; x) const;</pre>
9713 </blockquote>
9714
9715
9716 <p><b>Proposed resolution:</b></p>
9717 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
9718 equal_range() in section 23.6.3 [set] and section 23.6.4 [multiset] to each have two overloads:</p>
9719 <blockquote>
9720   <pre>iterator find(const key_type &amp; x);
9721 const_iterator find(const key_type &amp; x) const;</pre>
9722   <pre>iterator lower_bound(const key_type &amp; x);
9723 const_iterator lower_bound(const key_type &amp; x) const;</pre>
9724   <pre>iterator upper_bound(const key_type &amp; x);
9725 const_iterator upper_bound(const key_type &amp; x) const;</pre>
9726   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
9727 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
9728 </blockquote>
9729
9730 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
9731 extending the proposed resolution to lower_bound, upper_bound, and
9732 equal_range.]</i></p>
9733
9734
9735
9736
9737
9738
9739 <hr>
9740 <h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
9741 <p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9742  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2010-10-29</p>
9743 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
9744 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9745 <p><b>Discussion:</b></p>
9746 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
9747 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
9748 must be const in order for it to be callable on a const object (a reference to
9749 which which is what std::use_facet&lt;&gt;() returns).</p>
9750 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
9751 name of the namespace `My'.</p>
9752 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
9753 in main(), the name of the facet is misspelled: it should read `My::JCtype'
9754 rather than `My::JCType'.</p>
9755
9756
9757 <p><b>Proposed resolution:</b></p>
9758 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
9759 paragraph 11 with the following:</p>
9760 <pre>#include &lt;locale&gt;</pre>
9761 <pre>namespace My {
9762     using namespace std;
9763     class JCtype : public locale::facet {
9764     public:
9765         static locale::id id;     //  required for use as a new locale facet
9766         bool is_kanji (wchar_t c) const;
9767         JCtype() {}
9768     protected:
9769         ~JCtype() {}
9770     };
9771 }</pre>
9772 <pre>//  file:  filt.C
9773 #include &lt;iostream&gt;
9774 #include &lt;locale&gt;
9775 #include "jctype"                 //  above
9776 std::locale::id My::JCtype::id;   //  the static  JCtype  member
9777 declared above.</pre>
9778 <pre>int main()
9779 {
9780     using namespace std;
9781     typedef ctype&lt;wchar_t&gt; wctype;
9782     locale loc(locale(""),              //  the user's preferred locale...
9783                new My::JCtype);         //  and a new feature ...
9784     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
9785     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
9786         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
9787     return 0;
9788 }</pre>
9789
9790
9791
9792
9793 <hr>
9794 <h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
9795 <p><b>Section:</b> 27.5.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9796  <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13 <b>Last modified:</b> 2010-10-29</p>
9797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9798 <p><b>Discussion:</b></p>
9799 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
9800 paragraph 2:</p>
9801 <blockquote>
9802   <p>Effects: Destroys an object of class ios_base. Calls each registered
9803   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
9804   time that any ios_base member function called from within fn has well defined
9805   results.</p>
9806 </blockquote>
9807 <p>But what is not clear is: If no callback functions were ever registered, does
9808 it matter whether the ios_base members were ever initialized?</p>
9809 <p>For instance, does this program have defined behavior:</p>
9810 <blockquote>
9811   <pre>#include &lt;ios&gt;</pre>
9812   <pre>class D : public std::ios_base { };</pre>
9813   <pre>int main() { D d; }</pre>
9814 </blockquote>
9815 <p>It seems that registration of a callback function would surely affect the
9816 state of an ios_base. That is, when you register a callback function with an
9817 ios_base, the ios_base must record that fact somehow.</p>
9818 <p>But if after construction the ios_base is in an indeterminate state, and that
9819 state is not made determinate before the destructor is called, then how would
9820 the destructor know if any callbacks had indeed been registered? And if the
9821 number of callbacks that had been registered is indeterminate, then is not the
9822 behavior of the destructor undefined?</p>
9823 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
9824 it explicit that destruction before initialization results in undefined
9825 behavior.</p>
9826
9827
9828 <p><b>Proposed resolution:</b></p>
9829 <p>Modify 27.4.2.7 paragraph 1 from</p>
9830 <blockquote>
9831   <p>Effects: Each ios_base member has an indeterminate value after
9832   construction.</p>
9833 </blockquote>
9834 <p>to</p>
9835 <blockquote>
9836   <p>Effects: Each ios_base member has an indeterminate value after
9837   construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
9838   have taken place, the behavior is undefined.</p>
9839 </blockquote>
9840
9841
9842
9843
9844 <hr>
9845 <h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
9846 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
9847  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-03-14 <b>Last modified:</b> 2010-10-29</p>
9848 <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>
9849 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9850 <p><b>Discussion:</b></p>
9851 <p>Stage 2 processing of numeric conversion is broken.</p>
9852
9853 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
9854 conversion specifier is %i. A %i specifier determines a number's base
9855 by its prefix (0 for octal, 0x for hex), so the intention is clearly
9856 that a 0x prefix is allowed.  Paragraph 8 in the same section,
9857 however, describes very precisely how characters are processed. (It
9858 must be done "as if" by a specified code fragment.) That
9859 description does not allow a 0x prefix to be recognized.</p>
9860
9861 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
9862 ct to a char, not by using narrow but by looking it up in a
9863 translation table that was created by widening the string literal
9864 "0123456789abcdefABCDEF+-". The character "x" is
9865 not found in that table, so it can't be recognized by stage 2
9866 processing.</p>
9867
9868
9869 <p><b>Proposed resolution:</b></p>
9870 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
9871 <blockquote>
9872   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
9873 </blockquote>
9874 <p>with the line:</p>
9875 <blockquote>
9876   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
9877 </blockquote>
9878
9879
9880 <p><b>Rationale:</b></p>
9881 <p>If we're using the technique of widening a string literal, the
9882 string literal must contain every character we wish to recognize.
9883 This technique has the consequence that alternate representations
9884 of digits will not be recognized.  This design decision was made
9885 deliberately, with full knowledge of that limitation.</p>
9886
9887
9888
9889
9890
9891 <hr>
9892 <h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
9893 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9894  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-03-17 <b>Last modified:</b> 2010-10-29</p>
9895 <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>
9896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9897 <p><b>Discussion:</b></p>
9898 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
9899 <blockquote>
9900   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
9901
9902 int compare(size_type pos1, size_type n1,
9903                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
9904                 size_type  pos2 , size_type  n2 ) const;
9905
9906 -4- Returns: 
9907
9908     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
9909                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
9910 </blockquote>
9911 <p>and the constructor that's implicitly called by the above is
9912 defined to throw an out-of-range exception if pos &gt; str.size(). See
9913 section 21.4.1 [string.require] paragraph 4.</p>
9914
9915 <p>On the other hand, the compare function descriptions themselves don't have
9916 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
9917 that do not apply to a function are omitted.</p>
9918 <p>So it seems there is an inconsistency in the standard -- are the
9919 "Effects" clauses correct, or are the "Throws" clauses
9920 missing?</p>
9921
9922
9923 <p><b>Proposed resolution:</b></p>
9924 <p>In 17.5.1.4 [structure.specifications] paragraph 3, the footnote 148 attached to
9925 the sentence "Descriptions of function semantics contain the
9926 following elements (as appropriate):", insert the word
9927 "further" so that the foot note reads:</p>
9928 <blockquote>
9929   <p>To save space, items that do not apply to a function are
9930   omitted. For example, if a function does not specify any further
9931   preconditions, there will be no "Requires" paragraph.</p>
9932 </blockquote>
9933
9934
9935 <p><b>Rationale:</b></p>
9936 <p>The standard is somewhat inconsistent, but a failure to note a
9937 throw condition in a throws clause does not grant permission not to
9938 throw.  The inconsistent wording is in a footnote, and thus
9939 non-normative. The proposed resolution from the LWG clarifies the
9940 footnote.</p>
9941
9942
9943
9944
9945 <hr>
9946 <h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
9947 <p><b>Section:</b> 25.3.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9948  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-03-21 <b>Last modified:</b> 2010-10-29</p>
9949 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9950 <p><b>Discussion:</b></p>
9951 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
9952
9953
9954 <p><b>Proposed resolution:</b></p>
9955 <p>In 25.3.10 [alg.reverse], replace:</p>
9956   <blockquote><p>
9957   Effects: For each non-negative integer i &lt;= (last - first)/2, 
9958   applies swap to all pairs of iterators first + i, (last - i) - 1.
9959   </p></blockquote>
9960 <p>with:</p>
9961   <blockquote><p>
9962   Effects: For each non-negative integer i &lt;= (last - first)/2, 
9963   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
9964   </p></blockquote>
9965
9966
9967
9968
9969 <hr>
9970 <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
9971 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9972  <b>Submitter:</b> Ed Brey <b>Opened:</b> 2000-03-23 <b>Last modified:</b> 2010-10-29</p>
9973 <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>
9974 <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>
9975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
9976 <p><b>Discussion:</b></p>
9977 <p>In the associative container requirements table in 23.1.2 paragraph 7,
9978 a.clear() has complexity "log(size()) + N". However, the meaning of N
9979 is not defined.</p>
9980
9981
9982 <p><b>Proposed resolution:</b></p>
9983 <p>In the associative container requirements table in 23.1.2 paragraph
9984 7, the complexity of a.clear(), change "log(size()) + N" to
9985 "linear in <tt>size()</tt>".</p>
9986
9987
9988 <p><b>Rationale:</b></p>
9989 <p>It's the "log(size())", not the "N", that is in
9990 error: there's no difference between <i>O(N)</i> and <i>O(N +
9991 log(N))</i>.  The text in the standard is probably an incorrect
9992 cut-and-paste from the range version of <tt>erase</tt>.</p>
9993
9994
9995
9996
9997 <hr>
9998 <h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
9999 <p><b>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10000  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2010-10-29</p>
10001 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
10002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10003 <p><b>Discussion:</b></p>
10004 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
10005 user namespaces might be found through Koenig lookup?</p>
10006 <p>For example, a popular standard library implementation includes this
10007 implementation of std::unique:</p>
10008 <blockquote>
10009 <pre>namespace std {
10010     template &lt;class _ForwardIter&gt;
10011     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
10012       __first = adjacent_find(__first, __last);
10013       return unique_copy(__first, __last, __first);
10014     }
10015     }</pre>
10016 </blockquote>
10017 <p>Imagine two users on opposite sides of town, each using unique on his own
10018 sequences bounded by my_iterators . User1 looks at his standard library
10019 implementation and says, "I know how to implement a more efficient
10020 unique_copy for my_iterators", and writes:</p>
10021 <blockquote>
10022 <pre>namespace user1 {
10023     class my_iterator;
10024     // faster version for my_iterator
10025     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
10026     }</pre>
10027 </blockquote>
10028 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
10029 <p>User2 has other needs, and writes:</p>
10030 <blockquote>
10031 <pre>namespace user2 {
10032     class my_iterator;
10033     // Returns true iff *c is a unique copy of *a and *b.
10034     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
10035     }</pre>
10036 </blockquote>
10037 <p>User2 is shocked to find later that his fully-qualified use of
10038 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
10039 compile (if he's lucky). Looking in the standard, he sees the following Effects
10040 clause for unique():</p>
10041 <blockquote>
10042   <p>Effects: Eliminates all but the first element from every consecutive group
10043   of equal elements referred to by the iterator i in the range [first, last) for
10044   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
10045   *(i - 1)) != false</p>
10046 </blockquote>
10047 <p>The standard gives user2 absolutely no reason to think he can interfere with
10048 std::unique by defining names in namespace user2. His standard library has been
10049 built with the template export feature, so he is unable to inspect the
10050 implementation. User1 eventually compiles his code with another compiler, and
10051 his version of unique_copy silently stops being called. Eventually, he realizes
10052 that he was depending on an implementation detail of his library and had no
10053 right to expect his unique_copy() to be called portably.</p>
10054 <p>On the face of it, and given above scenario, it may seem obvious that the
10055 implementation of unique() shown is non-conforming because it uses unique_copy()
10056 rather than ::std::unique_copy(). Most standard library implementations,
10057 however, seem to disagree with this notion.</p>
10058 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
10059 the core working group indicates that "std::" is sufficient;&nbsp;
10060 leading "::" qualification is not required because any namespace
10061 qualification is sufficient to suppress Koenig lookup.]</i></p>
10062
10063
10064 <p><b>Proposed resolution:</b></p>
10065 <p>Add a paragraph and a note at the end of 
10066 17.6.4.4 [global.functions]:</p>
10067 <blockquote>
10068
10069 <p>Unless otherwise specified, no global or non-member function in the
10070 standard library shall use a function from another namespace which is
10071 found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
10072
10073 <p>[Note: the phrase "unless otherwise specified" is intended to
10074 allow Koenig lookup in cases like that of ostream_iterators:<br>
10075
10076 <br>
10077   Effects:</p>
10078   <blockquote>
10079 <p>*out_stream &lt;&lt; value;<br>
10080       if(delim != 0) *out_stream &lt;&lt; delim;<br>
10081       return (*this);</p>
10082     <p>--end note]</p>
10083   </blockquote>
10084 </blockquote>
10085
10086 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
10087 is as yet unsure if the proposed resolution is the best
10088 solution. Furthermore, the LWG believes that the same problem of
10089 unqualified library names applies to wording in the standard itself,
10090 and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
10091 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
10092 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
10093
10094
10095 <p><i>[Toronto: The LWG is not sure if this is a defect in the
10096 standard.  Most LWG members believe that an implementation of
10097 <tt>std::unique</tt> like the one quoted in this issue is already
10098 illegal, since, under certain circumstances, its semantics are not
10099 those specified in the standard.  The standard's description of
10100 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
10101 should have any effect.]</i></p>
10102
10103
10104 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
10105 225, 226, and 229.  Their conclusion was that the issues should be
10106 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10107 EWG portion (Dave will write a proposal). The LWG and EWG had
10108 (separate) discussions of this plan the next day.  The proposed
10109 resolution for this issue is in accordance with Howard's paper.]</i></p>
10110
10111
10112
10113
10114 <p><b>Rationale:</b></p>
10115 <p>It could be argued that this proposed isn't strictly necessary,
10116   that the Standard doesn't grant implementors license to write a
10117   standard function that behaves differently than specified in the
10118   Standard just because of an unrelated user-defined name in some
10119   other namespace.  However, this is at worst a clarification.  It is
10120   surely right that algorithsm shouldn't pick up random names, that
10121   user-defined names should have no effect unless otherwise specified.
10122   Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
10123   appropriate for the standard to explicitly specify otherwise.</p>
10124
10125
10126
10127
10128
10129 <hr>
10130 <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
10131 <p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10132  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2010-10-29</p>
10133 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
10134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10135 <p><b>Discussion:</b></p>
10136 <p>The issues are:&nbsp;</p>
10137 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
10138 algorithm which is specialized to work with his own class template?&nbsp;</p>
10139 <p>2. How can another library implementor (lib2) write a generic algorithm which 
10140 will take advantage of the specialized algorithm in lib1?</p>
10141 <p>This appears to be the only viable answer under current language rules:</p>
10142 <blockquote>
10143   <pre>namespace lib1
10144 {
10145     // arbitrary-precision numbers using T as a basic unit
10146     template &lt;class T&gt;
10147     class big_num { //...
10148     };
10149     </pre>
10150   <pre>    // defining this in namespace std is illegal (it would be an
10151     // overload), so we hope users will rely on Koenig lookup
10152     template &lt;class T&gt;
10153     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
10154 }</pre>
10155   <pre>#include &lt;algorithm&gt;
10156 namespace lib2
10157 {
10158     template &lt;class T&gt;
10159     void generic_sort(T* start, T* end)
10160     {
10161             ...
10162         // using-declaration required so we can work on built-in types
10163         using std::swap;
10164         // use Koenig lookup to find specialized algorithm if available
10165         swap(*x, *y);
10166     }
10167 }</pre>
10168 </blockquote>
10169 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
10170 and somewhat slippery. The implementor needs to remember to write the
10171 using-declaration, or generic_sort will fail to compile when T is a built-in
10172 type. The second drawback is that the use of this style in lib2 effectively
10173 "reserves" names in any namespace which defines types which may
10174 eventually be used with lib2. This may seem innocuous at first when applied to
10175 names like swap, but consider more ambiguous names like unique_copy() instead.
10176 It is easy to imagine the user wanting to define these names differently in his
10177 own namespace. A definition with semantics incompatible with the standard
10178 library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
10179 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
10180 because the language doesn't allow for partial specialization of function
10181 templates. If you write:</p>
10182 <blockquote>
10183   <pre>namespace std
10184 {
10185     template &lt;class T&gt;
10186     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
10187 }</pre>
10188 </blockquote>
10189 <p>You have just overloaded std::swap, which is illegal under the current
10190 language rules. On the other hand, the following full specialization is legal:</p>
10191 <blockquote>
10192   <pre>namespace std
10193 {
10194     template &lt;&gt;
10195     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
10196 }</pre>
10197 </blockquote>
10198
10199 <p>This issue reflects concerns raised by the "Namespace issue
10200 with specialized swap" thread on comp.lang.c++.moderated. A
10201 similar set of concerns was earlier raised on the boost.org mailing
10202 list and the ACCU-general mailing list.  Also see library reflector
10203 message c++std-lib-7354.</p>
10204
10205 <p>
10206 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
10207 fact: it's impossible to output a container of std::pair's using copy
10208 and an ostream_iterator, as long as both pair-members are built-in or
10209 std:: types.  That's because a user-defined operator&lt;&lt; for (for
10210 example) std::pair&lt;const std::string, int&gt; will not be found:
10211 lookup for operator&lt;&lt; will be performed only in namespace std.
10212 Opinions differed on whether or not this was a defect, and, if so,
10213 whether the defect is that something is wrong with user-defined
10214 functionality and std, or whether it's that the standard library does
10215 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
10216 </p>
10217
10218
10219
10220 <p><b>Proposed resolution:</b></p>
10221
10222 <p>Adopt the wording proposed in Howard Hinnant's paper
10223   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
10224
10225
10226 <p><i>[Tokyo: Summary, "There is no conforming way to extend
10227 std::swap for user defined templates."&nbsp; The LWG agrees that
10228 there is a problem.  Would like more information before
10229 proceeding. This may be a core issue.  Core issue 229 has been opened
10230 to discuss the core aspects of this problem. It was also noted that
10231 submissions regarding this issue have been received from several
10232 sources, but too late to be integrated into the issues list.
10233 ]</i></p>
10234
10235
10236 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
10237 J16/00-0029==WG21/N1252, "Shades of namespace std functions
10238 " by Alan Griffiths, is in the Post-Tokyo mailing. It
10239 should be considered a part of this issue.]</i></p>
10240
10241
10242 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
10243 resolution that involves core changes: it would add partial
10244 specialization of function template.  The Core Working Group is
10245 reluctant to add partial specialization of function templates.  It is
10246 viewed as a large change, CWG believes that proposal presented leaves
10247 some syntactic issues unanswered; if the CWG does add partial
10248 specialization of function templates, it wishes to develop its own
10249 proposal.  The LWG continues to believe that there is a serious
10250 problem: there is no good way for users to force the library to use
10251 user specializations of generic standard library functions, and in
10252 certain cases (e.g. transcendental functions called by
10253 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
10254 lookup isn't adequate, since names within the library must be
10255 qualified with <tt>std</tt> (see issue 225), specialization doesn't
10256 work (we don't have partial specialization of function templates), and
10257 users aren't permitted to add overloads within namespace std.
10258 ]</i></p>
10259
10260
10261 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
10262 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
10263 focused on four options. (1) Relax restrictions on overloads within
10264 namespace std. (2) Mandate that the standard library use unqualified
10265 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
10266 helper class templates for <tt>swap</tt> and possibly other functions.
10267 (4) Introduce partial specialization of function templates.  Every
10268 option had both support and opposition.  Straw poll (first number is
10269 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
10270 (4) 4, 4.]</i></p>
10271
10272
10273 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
10274 argument that a user who is defining a type <tt>T</tt> with an
10275 associated <tt>swap</tt> should not be expected to put that
10276 <tt>swap</tt> in namespace std, either by overloading or by partial
10277 specialization.  The argument is that <tt>swap</tt> is part of
10278 <tt>T</tt>'s interface, and thus should to in the same namespace as
10279 <tt>T</tt> and only in that namespace.  If we accept this argument,
10280 the consequence is that standard library functions should use
10281 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
10282 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
10283 try to put together a proposal before the next meeting.]</i></p>
10284
10285
10286 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
10287 225, 226, and 229.  Their conclusion was that the issues should be
10288 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10289 EWG portion (Dave will write a proposal). The LWG and EWG had
10290 (separate) discussions of this plan the next day.  The proposed
10291 resolution is the one proposed by Howard.]</i></p>
10292
10293
10294 <p><i>[Santa Cruz: the LWG agreed with the general direction of
10295   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
10296   we say otherwise; this issue is about when we do say otherwise.)
10297   However, there were concerns about wording.  Howard will provide new
10298   wording.  Bill and Jeremy will review it.]</i></p>
10299
10300
10301 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
10302   proposed resolution.]</i></p>
10303
10304
10305
10306
10307 <p><b>Rationale:</b></p>
10308 <p>Informally: introduce a Swappable concept, and specify that the
10309   value types of the iterators passed to certain standard algorithms
10310   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
10311   to that concept.  The Swappable concept will make it clear that
10312   these algorithms use unqualified lookup for the calls
10313   to <tt>swap</tt>.  Also, in 26.6.3.3 [valarray.transcend] paragraph 1,
10314   state that the valarray transcendentals use unqualified lookup.</p>
10315
10316
10317
10318
10319
10320 <hr>
10321 <h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
10322 <p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
10323  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-09 <b>Last modified:</b> 2010-10-29</p>
10324 <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>
10325 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
10326 <p><b>Discussion:</b></p>
10327 <p>25.2.2 reads:</p>
10328 <blockquote>
10329   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
10330   <br>
10331   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
10332   Effects:    Exchanges values stored in two locations.</p>
10333 </blockquote>
10334 <p>The only reasonable** generic implementation of swap requires construction of a 
10335    new temporary copy of one of its arguments:</p>
10336 <blockquote>
10337 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
10338   {
10339       T tmp(a);
10340       a = b;
10341       b = tmp;
10342   }</pre>
10343 </blockquote>
10344 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
10345 <p>**Yes, there's also an unreasonable implementation which would require T to be 
10346    DefaultConstructible instead of CopyConstructible. I don't think this is worthy 
10347    of consideration:</p>
10348 <blockquote>
10349 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
10350 {
10351     T tmp;
10352     tmp = a;
10353     a = b;
10354     b = tmp;
10355 }</pre>
10356 </blockquote>
10357
10358
10359 <p><b>Proposed resolution:</b></p>
10360 <p>Change 25.2.2 paragraph 1 from:</p>
10361 <blockquote>
10362 <p>  Requires: Type T is Assignable (23.1).</p>
10363 </blockquote>
10364 <p>to:</p>
10365 <blockquote>
10366 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
10367 </blockquote>
10368
10369
10370
10371
10372
10373 <hr>
10374 <h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
10375 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10376  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-20 <b>Last modified:</b> 2010-10-29</p>
10377 <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>
10378 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10379 <p><b>Discussion:</b></p>
10380 <p>The sections 22.4.1.2 [locale.ctype.byname], 22.4.1.5 [locale.codecvt.byname],
10381 sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2 [locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4 [locale.moneypunct.byname], and 22.4.7.2 [locale.messages.byname] overspecify the
10382 definitions of the "..._byname" classes by listing a bunch
10383 of virtual functions. At the same time, no semantics of these
10384 functions are defined. Real implementations do not define these
10385 functions because the functional part of the facets is actually
10386 implemented in the corresponding base classes and the constructor of
10387 the "..._byname" version just provides suitable date used by
10388 these implementations. For example, the 'numpunct' methods just return
10389 values from a struct. The base class uses a statically initialized
10390 struct while the derived version reads the contents of this struct
10391 from a table.  However, no virtual function is defined in
10392 'numpunct_byname'.</p>
10393
10394 <p>For most classes this does not impose a problem but specifically
10395 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
10396 is required because otherwise the semantics would change due to the
10397 virtual functions defined in the general version for 'ctype_byname':
10398 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
10399 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
10400 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
10401 this class is specialized or not under the current specification:
10402 Without the specialization, 'do_is()' is virtual while with
10403 specialization it is not virtual.</p>
10404
10405
10406 <p><b>Proposed resolution:</b></p>
10407 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
10408 <pre>     namespace std {
10409        template &lt;class charT&gt;
10410        class ctype_byname : public ctype&lt;charT&gt; {
10411        public:
10412          typedef ctype&lt;charT&gt;::mask mask;
10413          explicit ctype_byname(const char*, size_t refs = 0);
10414        protected:
10415         ~ctype_byname();             //  virtual
10416        };
10417      }</pre>
10418 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
10419 <pre>    namespace std {
10420       template &lt;class internT, class externT, class stateT&gt;
10421       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
10422       public:
10423        explicit codecvt_byname(const char*, size_t refs = 0);
10424       protected:
10425       ~codecvt_byname();             //  virtual
10426        };
10427      }
10428 </pre>
10429 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
10430 <pre>     namespace std {
10431        template &lt;class charT&gt;
10432        class numpunct_byname : public numpunct&lt;charT&gt; {
10433      //  this class is specialized for  char  and  wchar_t.
10434        public:
10435          typedef charT                char_type;
10436          typedef basic_string&lt;charT&gt;  string_type;
10437          explicit numpunct_byname(const char*, size_t refs = 0);
10438        protected:
10439         ~numpunct_byname();          //  virtual
10440        };
10441      }</pre>
10442 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
10443 <pre>     namespace std {
10444        template &lt;class charT&gt;
10445        class collate_byname : public collate&lt;charT&gt; {
10446        public:
10447          typedef basic_string&lt;charT&gt; string_type;
10448          explicit collate_byname(const char*, size_t refs = 0);
10449        protected:
10450         ~collate_byname();           //  virtual
10451        };
10452      }</pre>
10453 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
10454 <pre>     namespace std {
10455        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
10456        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
10457        public:
10458          typedef time_base::dateorder dateorder;
10459          typedef InputIterator        iter_type</pre>
10460 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
10461        protected:
10462         ~time_get_byname();          //  virtual
10463        };
10464      }</pre>
10465 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
10466 <pre>     namespace std {
10467        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
10468        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
10469        {
10470        public:
10471          typedef charT          char_type;
10472          typedef OutputIterator iter_type;</pre>
10473 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
10474        protected:
10475         ~time_put_byname();          //  virtual
10476        };
10477      }"</pre>
10478 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
10479 <pre>     namespace std {
10480        template &lt;class charT, bool Intl = false&gt;
10481        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
10482        public:
10483          typedef money_base::pattern pattern;
10484          typedef basic_string&lt;charT&gt; string_type;</pre>
10485 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
10486        protected:
10487         ~moneypunct_byname();        //  virtual
10488        };
10489      }</pre>
10490 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
10491 <pre>     namespace std {
10492        template &lt;class charT&gt;
10493        class messages_byname : public messages&lt;charT&gt; {
10494        public:
10495          typedef messages_base::catalog catalog;
10496          typedef basic_string&lt;charT&gt;    string_type;</pre>
10497 <pre>         explicit messages_byname(const char*, size_t refs = 0);
10498        protected:
10499         ~messages_byname();          //  virtual
10500        };
10501      }</pre>
10502 <p>Remove section 22.4.1.4 [locale.codecvt] completely (because in
10503 this case only those members are defined to be virtual which are
10504 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
10505
10506 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
10507 the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
10508
10509
10510 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
10511 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
10512
10513
10514
10515
10516
10517
10518
10519 <hr>
10520 <h3><a name="229"></a>229. Unqualified references of other library entities</h3>
10521 <p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10522  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2000-04-19 <b>Last modified:</b> 2010-10-29</p>
10523 <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>
10524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10525 <p><b>Discussion:</b></p>
10526 <p>Throughout the library chapters, the descriptions of library entities refer
10527 to other library entities without necessarily qualifying the names.</p>
10528
10529 <p>For example, section 25.2.2 "Swap" describes the effect of
10530 swap_ranges in terms of the unqualified name "swap". This section
10531 could reasonably be interpreted to mean that the library must be implemented so
10532 as to do a lookup of the unqualified name "swap", allowing users to
10533 override any ::std::swap function when Koenig lookup applies.</p>
10534
10535 <p>Although it would have been best to use explicit qualification with
10536 "::std::" throughout, too many lines in the standard would have to be
10537 adjusted to make that change in a Technical Corrigendum.</p>
10538
10539 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
10540 <tt>size_t</tt>, is a special case of this.
10541 </p>
10542
10543
10544 <p><b>Proposed resolution:</b></p>
10545 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
10546 <blockquote>
10547   <p>Whenever a name x defined in the standard library is mentioned, the name x
10548   is assumed to be fully qualified as ::std::x, unless explicitly described
10549   otherwise. For example, if the Effects section for library function F is
10550   described as calling library function G, the function ::std::G is meant.</p>
10551 </blockquote>
10552
10553 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
10554 the LWG to solve a problem in the standard itself similar to the
10555 problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
10556 coordinated with the resolution of this issue.]</i></p>
10557
10558
10559 <p><i>[post-Toronto: Howard is undecided about whether it is
10560 appropriate for all standard library function names referred to in
10561 other standard library functions to be explicitly qualified by
10562 <tt>std</tt>: it is common advice that users should define global
10563 functions that operate on their class in the same namespace as the 
10564 class, and this requires argument-dependent lookup if those functions
10565 are intended to be called by library code.  Several LWG members are
10566 concerned that valarray appears to require argument-dependent lookup,
10567 but that the wording may not be clear enough to fall under
10568 "unless explicitly described otherwise".]</i></p>
10569
10570
10571 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
10572 225, 226, and 229.  Their conclusion was that the issues should be
10573 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10574 EWG portion (Dave will write a proposal). The LWG and EWG had
10575 (separate) discussions of this plan the next day.  This paper resolves
10576 issues 225 and 226.  In light of that resolution, the proposed
10577 resolution for the current issue makes sense.]</i></p>
10578
10579
10580
10581
10582
10583
10584
10585 <hr>
10586 <h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
10587 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10588  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-04-26 <b>Last modified:</b> 2010-10-29</p>
10589 <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>
10590 <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>
10591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10592 <p><b>Discussion:</b></p>
10593 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
10594 Assignable was specified without also specifying
10595 CopyConstructible. The LWG asked that the standard be searched to
10596 determine if the same defect existed elsewhere.</p>
10597
10598 <p>There are a number of places (see proposed resolution below) where
10599 Assignable is specified without also specifying
10600 CopyConstructible. There are also several cases where both are
10601 specified. For example, 26.5.1 [rand.req].</p>
10602
10603
10604 <p><b>Proposed resolution:</b></p>
10605 <p>In  23.2 [container.requirements] table 65 for value_type:
10606 change "T is Assignable" to "T is CopyConstructible and
10607 Assignable"
10608 </p>
10609
10610 <p>In 23.2.4 [associative.reqmts] table 69 X::key_type; change
10611 "Key is Assignable" to "Key is
10612 CopyConstructible and Assignable"<br>
10613 </p>
10614
10615 <p>In 24.2.4 [output.iterators] paragraph 1, change:
10616 </p>
10617 <blockquote>
10618 <p> A class or a built-in type X satisfies the requirements of an
10619 output iterator if X is an Assignable type (23.1) and also the
10620 following expressions are valid, as shown in Table 73:
10621 </p>
10622 </blockquote>
10623 <p>to:
10624 </p>
10625 <blockquote>
10626 <p> A class or a built-in type X satisfies the requirements of an
10627 output iterator if X is a CopyConstructible (20.1.3) and Assignable
10628 type (23.1) and also the following expressions are valid, as shown in
10629 Table 73:
10630 </p>
10631 </blockquote>
10632
10633 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
10634 the LWG.  He asks that the 25.3.5 [alg.replace] and 25.3.6 [alg.fill] changes be studied carefully, as it is not clear that
10635 CopyConstructible is really a requirement and may be
10636 overspecification.]</i></p>
10637
10638
10639 <p><i>[Portions of the resolution for issue 230 have been superceded by
10640 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
10641
10642
10643
10644
10645 <p><b>Rationale:</b></p>
10646 <p>The original proposed resolution also included changes to input
10647 iterator, fill, and replace.  The LWG believes that those changes are
10648 not necessary.  The LWG considered some blanket statement, where an
10649 Assignable type was also required to be Copy Constructible, but
10650 decided against this because fill and replace really don't require the
10651 Copy Constructible property.</p>
10652
10653
10654
10655
10656 <hr>
10657 <h3><a name="231"></a>231. Precision in iostream?</h3>
10658 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10659  <b>Submitter:</b> James Kanze, Stephen Clamage <b>Opened:</b> 2000-04-25 <b>Last modified:</b> 2010-10-29</p>
10660 <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>
10661 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10662 <p><b>Discussion:</b></p>
10663 <p>What is the following program supposed to output?</p>
10664 <pre>#include &lt;iostream&gt;
10665
10666     int
10667     main()
10668     {
10669         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
10670         std::cout.precision( 0 ) ;
10671         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
10672         return 0 ;
10673     }</pre>
10674 <p>From my C experience, I would expect "1e+00"; this is what 
10675 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs 
10676 "1.000000e+00".</p>
10677
10678 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
10679 where it says "For conversion from a floating-point type, if
10680 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
10681 str.precision() is specified in the conversion specification."
10682 This is an obvious error, however, fixed is not a mask for a field,
10683 but a value that a multi-bit field may take -- the results of and'ing
10684 fmtflags with ios::fixed are not defined, at least not if
10685 ios::scientific has been set. G++'s behavior corresponds to what might
10686 happen if you do use (flags &amp; fixed) != 0 with a typical
10687 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
10688 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
10689
10690 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
10691 (flags &amp; floatfield) == fixed; the first gives something more or
10692 less like the effect of precision in a printf floating point
10693 conversion. Only more or less, of course. In order to implement printf
10694 formatting correctly, you must know whether the precision was
10695 explicitly set or not. Say by initializing it to -1, instead of 6, and
10696 stating that for floating point conversions, if precision &lt; -1, 6
10697 will be used, for fixed point, if precision &lt; -1, 1 will be used,
10698 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
10699 0, 1 should be = used. But it probably isn't necessary to emulate all
10700 of the anomalies of printf:-).</p>
10701
10702
10703 <p><b>Proposed resolution:</b></p>
10704 <p>
10705 Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following 
10706 sentence:
10707 </p>
10708 <blockquote><p>
10709 For conversion from a floating-point type,
10710 <tt><i>str</i>.precision()</tt> is specified in the conversion
10711 specification.
10712 </p></blockquote>
10713
10714
10715 <p><b>Rationale:</b></p>
10716 <p>The floatfield determines whether numbers are formatted as if
10717 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
10718 if <tt>scientific</tt> it's %e, and if both bits are set, or 
10719 neither, it's %g.</p>
10720 <p>Turning to the C standard, a precision of 0 is meaningful
10721 for %f and %e.  For %g, precision 0 is taken to be the same as 
10722 precision 1.</p>
10723 <p>The proposed resolution has the effect that if neither
10724 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
10725 specifying a precision of 0, which will be internally
10726 turned into 1.  There's no need to call it out as a special
10727 case.</p>
10728 <p>The output of the above program will be "1e+00".</p>
10729
10730 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
10731 where precision is 0 and mode is %g.]</i></p>
10732
10733
10734
10735
10736
10737
10738
10739 <hr>
10740 <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
10741 <p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10742  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-04-18 <b>Last modified:</b> 2010-10-29</p>
10743 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
10744 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10745 <p><b>Discussion:</b></p>
10746 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
10747 specializations of standard templates to those that "depend on a
10748 user-defined name of external linkage."</p>
10749 <p>This term, however, is not adequately defined, making it possible to
10750 construct a specialization that is, I believe, technically legal according to
10751 17.4.3.1/1, but that specializes a standard template for a built-in type such as
10752 'int'.</p>
10753 <p>The following code demonstrates the problem:</p>
10754 <blockquote>
10755   <pre>#include &lt;algorithm&gt;</pre>
10756   <pre>template&lt;class T&gt; struct X
10757 {
10758  typedef T type;
10759 };</pre>
10760   <pre>namespace std
10761 {
10762  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
10763 }</pre>
10764 </blockquote>
10765
10766
10767 <p><b>Proposed resolution:</b></p>
10768 <p>Change "user-defined name" to "user-defined
10769 type".</p>
10770
10771
10772 <p><b>Rationale:</b></p>
10773 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
10774 Programming Language</i>.  It disallows the example in the issue,
10775 since the underlying type itself is not user-defined.  The only
10776 possible problem I can see is for non-type templates, but there's no
10777 possible way for a user to come up with a specialization for bitset,
10778 for example, that might not have already been specialized by the
10779 implementor?</p>
10780
10781 <p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
10782
10783
10784 <p><i>[post-Toronto: Judy provided the above proposed resolution and
10785 rationale.]</i></p>
10786
10787
10788
10789
10790
10791
10792 <hr>
10793 <h3><a name="233"></a>233. Insertion hints in associative containers</h3>
10794 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10795  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-04-30 <b>Last modified:</b> 2010-10-29</p>
10796 <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>
10797 <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>
10798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10799 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p>
10800 <p><b>Discussion:</b></p>
10801 <p>
10802 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
10803 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
10804 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
10805 to where it should go.  Table 69 claims that the execution time is
10806 amortized constant if the insert winds up taking place adjacent to
10807 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
10808 happen.  All it says it that <tt>p</tt> is a hint as to where to
10809 insert.
10810 </p>
10811 <p>
10812 The question is whether there is any guarantee about the relationship
10813 between <tt>p</tt> and the insertion point, and, if so, what it
10814 is.
10815 </p>
10816 <p>
10817 I believe the present state is that there is no guarantee: The user
10818 can supply <tt>p</tt>, and the implementation is allowed to
10819 disregard it entirely.
10820 </p>
10821
10822 <p><b>Additional comments from Nathan:</b><br>
10823
10824 The vote [in Redmond] was on whether to elaborately specify the use of
10825 the hint, or to require behavior only if the value could be inserted
10826 adjacent to the hint.  I would like to ensure that we have a chance to
10827 vote for a deterministic treatment: "before, if possible, otherwise
10828 after, otherwise anywhere appropriate", as an alternative to the
10829 proposed "before or after, if possible, otherwise [...]".
10830 </p>
10831
10832 <p><i>[Toronto: there was general agreement that this is a real defect:
10833 when inserting an element x into a multiset that already contains
10834 several copies of x, there is no way to know whether the hint will be
10835 used.  The proposed resolution was that the new element should always
10836 be inserted as close to the hint as possible.  So, for example, if
10837 there is a subsequence of equivalent values, then providing a.begin()
10838 as the hint means that the new element should be inserted before the
10839 subsequence even if a.begin() is far away.  JC van Winkel supplied
10840 precise wording for this proposed resolution, and also for an
10841 alternative resolution in which hints are only used when they are
10842 adjacent to the insertion point.]</i></p>
10843
10844
10845 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
10846 in which an insertion hint would be used even when it is far from the
10847 insertion point.  This was contingent on seeing a example
10848 implementation showing that it is possible to implement this
10849 requirement without loss of efficiency.  John Potter provided such a
10850 example implementation.]</i></p>
10851
10852
10853 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
10854 emerged from Copenhagen: it seemed excessively complicated, and went
10855 beyond fixing the defect that we identified in Toronto.  PJP provided
10856 the new wording described in this issue.  Nathan agrees that we
10857 shouldn't adopt the more detailed semantics, and notes: "we know that
10858 you can do it efficiently enough with a red-black tree, but there are
10859 other (perhaps better) balanced tree techniques that might differ
10860 enough to make the detailed semantics hard to satisfy."]</i></p>
10861
10862
10863 <p><i>[Curaçao: Nathan should give us the alternative wording he
10864 suggests so the LWG can decide between the two options.]</i></p>
10865
10866
10867 <p><i>[Lillehammer: The LWG previously rejected the more detailed
10868   semantics, because it seemed more loike a new feature than like
10869   defect fixing.  We're now more sympathetic to it, but we (especially
10870   Bill) are still worried about performance.  N1780 describes a naive
10871   algorithm, but it's not clear whether there is a non-naive
10872   implementation. Is it possible to implement this as efficently as
10873   the current version of insert?]</i></p>
10874
10875
10876 <p><i>[Post Lillehammer:
10877 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
10878 updated in post meeting mailing with
10879 feedback from Lillehammer with more information regarding performance.
10880 ]</i></p>
10881
10882
10883 <p><i>[
10884 Batavia:
10885 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
10886 accepted with minor wording changes in the proposed wording (reflected in the
10887 proposed resolution below).  Concerns about the performance of the algorithm
10888 were satisfactorily met by
10889 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
10890 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
10891 and so that part of the resolution from
10892 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
10893 is no longer needed (or reflected in the proposed wording below).
10894 ]</i></p>
10895
10896
10897
10898
10899 <p><b>Proposed resolution:</b></p>
10900
10901 <p>
10902 Change the indicated rows of the "Associative container requirements" Table in
10903 23.2.4 [associative.reqmts] to:
10904 </p>
10905
10906 <p></p><center>
10907 <table border="1">
10908 <caption>Associative container requirements</caption>
10909 <tbody><tr><th>expression</th> <th>return type</th>
10910 <th>assertion/note<br>pre/post-condition</th>
10911 <th>complexity</th></tr>
10912 <tr><td><tt>a_eq.insert(t)</tt></td>
10913 <td><tt>iterator</tt></td>
10914 <td>
10915 inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
10916 element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
10917 <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
10918 </td>
10919 <td>
10920 logarithmic
10921 </td></tr>
10922 <tr><td><tt>a.insert(p,t)</tt></td>
10923 <td><tt>iterator</tt></td>
10924 <td>
10925 inserts <tt>t</tt> if and only if there is no element with key equivalent to the
10926 key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
10927 with equivalent keys. always returns the iterator pointing to the element with key
10928 equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
10929 the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
10930 to the position just prior to <tt>p</tt>.</ins>
10931 </td>
10932 <td>
10933 logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
10934  <ins>before</ins> <tt>p</tt>.
10935 </td></tr>
10936 </tbody></table>
10937 </center><p></p>
10938
10939
10940
10941
10942
10943
10944 <hr>
10945 <h3><a name="234"></a>234. Typos in allocator definition</h3>
10946 <p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10947  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
10948 <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>
10949 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10950 <p><b>Discussion:</b></p>
10951 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
10952 <tt>destruct()</tt> are described as returns but the functions actually
10953 return <tt>void</tt>.</p>
10954
10955
10956 <p><b>Proposed resolution:</b></p>
10957 <p>Substitute "Returns" by "Effect".</p>
10958
10959
10960
10961
10962 <hr>
10963 <h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
10964 <p><b>Section:</b> 24.5.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10965  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
10966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10967 <p><b>Discussion:</b></p>
10968 <p>The declaration of <tt>reverse_iterator</tt> lists a default
10969 constructor.  However, no specification is given what this constructor
10970 should do.</p>
10971
10972
10973 <p><b>Proposed resolution:</b></p>
10974   <p>In section 24.5.1.3.1 [reverse.iter.cons] add the following
10975   paragraph:</p>
10976       <blockquote>
10977       <p><tt>reverse_iterator()</tt></p>
10978
10979       <p>Default initializes <tt>current</tt>. Iterator operations
10980       applied to the resulting iterator have defined behavior if and
10981       only if the corresponding operations are defined on a default
10982       constructed iterator of type <tt>Iterator</tt>.</p>
10983       </blockquote>
10984   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
10985   resolution.]</i></p>
10986
10987
10988
10989
10990
10991
10992 <hr>
10993 <h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
10994 <p><b>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10995  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
10996 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
10997 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10998 <p><b>Discussion:</b></p>
10999 <p>The complexity specification in paragraph 6 says that the complexity
11000 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
11001 defined on iterators this term is in general undefined because it
11002 would have to be <tt>last - first</tt>.</p>
11003
11004
11005 <p><b>Proposed resolution:</b></p>
11006   <p>Change paragraph 6 from</p>
11007      <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
11008   <p>to become</p>
11009      <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
11010
11011
11012
11013
11014 <hr>
11015 <h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
11016 <p><b>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11017  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-05-11 <b>Last modified:</b> 2010-10-29</p>
11018 <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>
11019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11020 <p><b>Discussion:</b></p>
11021 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
11022 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
11023 that far but consider this code:</p>
11024
11025 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
11026   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
11027 </pre>
11028
11029 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
11030 the output sequence nor the input sequence is initialized and
11031 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
11032 returns the input or the output sequence. None of them is initialized,
11033 ie. both are empty, in which case the return from <tt>str()</tt> is
11034 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
11035
11036 <p>However, probably only test cases in some testsuites will detect this
11037 "problem"...</p>
11038
11039
11040 <p><b>Proposed resolution:</b></p>
11041 <p>Remove 27.7.1.1 paragraph 4.</p>
11042
11043
11044 <p><b>Rationale:</b></p>
11045 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
11046 we fixed it, it would say just the same thing as text that's already
11047 in the standard.</p>
11048
11049
11050
11051
11052 <hr>
11053 <h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
11054 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11055  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
11056 <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>
11057 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11058 <p><b>Discussion:</b></p>
11059 <p>The complexity of unique and unique_copy are inconsistent with each
11060 other and inconsistent with the implementations.&nbsp; The standard
11061 specifies:</p>
11062
11063 <p>for unique():</p>
11064
11065 <blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
11066 (last - first) - 1 applications of the corresponding predicate, otherwise
11067 no applications of the predicate.</p></blockquote>
11068
11069 <p>for unique_copy():</p>
11070
11071 <blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
11072 predicate.</p></blockquote>
11073
11074 <p>
11075 The implementations do it the other way round: unique() applies the
11076 predicate last-first times and unique_copy() applies it last-first-1
11077 times.</p>
11078
11079 <p>As both algorithms use the predicate for pair-wise comparison of
11080 sequence elements I don't see a justification for unique_copy()
11081 applying the predicate last-first times, especially since it is not
11082 specified to which pair in the sequence the predicate is applied
11083 twice.</p>
11084
11085
11086 <p><b>Proposed resolution:</b></p>
11087 <p>Change both complexity sections in 25.3.9 [alg.unique] to:</p>
11088
11089 <blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
11090 applications of the corresponding predicate.</p></blockquote>
11091
11092
11093
11094
11095
11096
11097 <hr>
11098 <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
11099 <p><b>Section:</b> 25.2.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11100  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
11101 <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>
11102 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11103 <p><b>Discussion:</b></p>
11104 <p>The complexity section of adjacent_find is defective:</p>
11105
11106 <blockquote>
11107 <pre>template &lt;class ForwardIterator&gt;
11108 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
11109                               BinaryPredicate pred);
11110 </pre>
11111
11112 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
11113 the range [first, last) for which the following corresponding
11114 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
11115 last if no such iterator is found.</p>
11116
11117 <p>-2- Complexity: Exactly find(first, last, value) - first applications
11118 of the corresponding predicate.
11119 </p>
11120 </blockquote>
11121
11122 <p>In the Complexity section, it is not defined what "value"
11123 is supposed to mean. My best guess is that "value" means an
11124 object for which one of the conditions pred(*i,value) or
11125 pred(value,*i) is true, where i is the iterator defined in the Returns
11126 section. However, the value type of the input sequence need not be
11127 equality-comparable and for this reason the term find(first, last,
11128 value) - first is meaningless.</p>
11129
11130 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
11131 find_if(first, last, bind1st(pred,*i)) - first might come closer to
11132 the intended specification.  Binders can only be applied to function
11133 objects that have the function call operator declared const, which is
11134 not required of predicates because they can have non-const data
11135 members. For this reason, a specification using a binder could only be
11136 an "as-if" specification.</p>
11137
11138
11139 <p><b>Proposed resolution:</b></p>
11140 <p>Change the complexity section in 25.2.8 [alg.adjacent.find] to:</p>
11141 <blockquote><p>
11142 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
11143 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
11144 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
11145 return value.
11146 </p></blockquote>
11147
11148 <p><i>[Copenhagen: the original resolution specified an upper
11149 bound.  The LWG preferred an exact count.]</i></p>
11150
11151
11152
11153
11154
11155
11156
11157 <hr>
11158 <h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
11159 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11160  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
11161 <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>
11162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11163 <p><b>Discussion:</b></p>
11164
11165 <p>Some popular implementations of unique_copy() create temporary
11166 copies of values in the input sequence, at least if the input iterator
11167 is a pointer.  Such an implementation is built on the assumption that
11168 the value type is CopyConstructible and Assignable.</p>
11169
11170 <p>It is common practice in the standard that algorithms explicitly
11171 specify any additional requirements that they impose on any of the
11172 types used by the algorithm. An example of an algorithm that creates
11173 temporary copies and correctly specifies the additional requirements
11174 is accumulate(), 26.5.1 [rand.req].</p>
11175
11176 <p>Since the specifications of unique() and unique_copy() do not
11177 require CopyConstructible and Assignable of the InputIterator's value
11178 type the above mentioned implementations are not standard-compliant. I
11179 cannot judge whether this is a defect in the standard or a defect in
11180 the implementations.</p>
11181
11182
11183 <p><b>Proposed resolution:</b></p>
11184 <p>In 25.2.8 change:</p>
11185
11186 <blockquote><p>
11187 -4- Requires: The ranges [first, last) and [result, result+(last-first))
11188 shall not overlap.
11189 </p></blockquote>
11190
11191 <p>to:</p>
11192
11193 <blockquote>
11194   <p>-4- Requires: The ranges [first, last) and [result,
11195   result+(last-first)) shall not overlap. The expression *result =
11196   *first must be valid. If neither InputIterator nor OutputIterator
11197   meets the requirements of forward iterator then the value type of
11198   InputIterator must be copy constructible. Otherwise copy
11199   constructible is not required. </p>
11200 </blockquote>
11201
11202 <p><i>[Redmond: the original proposed resolution didn't impose an
11203 explicit requirement that the iterator's value type must be copy
11204 constructible, on the grounds that an input iterator's value type must
11205 always be copy constructible.  Not everyone in the LWG thought that
11206 this requirement was clear from table 72.  It has been suggested that
11207 it might be possible to implement <tt>unique_copy</tt> without
11208 requiring assignability, although current implementations do impose
11209 that requirement.  Howard provided new wording.]</i></p>
11210
11211
11212 <p><i>[
11213 Curaçao: The LWG changed the PR editorially to specify
11214 "neither...nor...meet..." as clearer than
11215 "both...and...do not meet...". Change believed to be so
11216 minor as not to require re-review.
11217 ]</i></p>
11218
11219
11220
11221
11222
11223
11224
11225
11226 <hr>
11227 <h3><a name="242"></a>242. Side effects of function objects</h3>
11228 <p><b>Section:</b> 25.3.4 [alg.transform], 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11229  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
11230 <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>
11231 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11232 <p><b>Discussion:</b></p>
11233 <p>The algorithms transform(), accumulate(), inner_product(),
11234 partial_sum(), and adjacent_difference() require that the function
11235 object supplied to them shall not have any side effects.</p>
11236
11237 <p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
11238 <blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
11239 modifying an object, calling a library I/O function, or calling a function
11240 that does any of those operations are all side effects, which are changes
11241 in the state of the execution environment.</p></blockquote>
11242
11243 <p>As a consequence, the function call operator of a function object supplied
11244 to any of the algorithms listed above cannot modify data members, cannot
11245 invoke any function that has a side effect, and cannot even create and
11246 modify temporary objects.&nbsp; It is difficult to imagine a function object
11247 that is still useful under these severe limitations. For instance, any
11248 non-trivial transformator supplied to transform() might involve creation
11249 and modification of temporaries, which is prohibited according to the current
11250 wording of the standard.</p>
11251
11252 <p>On the other hand, popular implementations of these algorithms exhibit
11253 uniform and predictable behavior when invoked with a side-effect-producing
11254 function objects. It looks like the strong requirement is not needed for
11255 efficient implementation of these algorithms.</p>
11256
11257 <p>The requirement of&nbsp; side-effect-free function objects could be
11258 replaced by a more relaxed basic requirement (which would hold for all
11259 function objects supplied to any algorithm in the standard library):</p>
11260 <blockquote><p>A function objects supplied to an algorithm shall not invalidate
11261 any iterator or sequence that is used by the algorithm. Invalidation of
11262 the sequence includes destruction of the sorting order if the algorithm
11263 relies on the sorting order (see section 25.3 - Sorting and related operations
11264 [lib.alg.sorting]).</p></blockquote>
11265
11266 <p>I can't judge whether it is intended that the function objects supplied
11267 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
11268 shall not modify sequence elements through dereferenced iterators.</p>
11269
11270 <p>It is debatable whether this issue is a defect or a change request.
11271 Since the consequences for user-supplied function objects are drastic and
11272 limit the usefulness of the algorithms significantly I would consider it
11273 a defect.</p>
11274
11275
11276 <p><b>Proposed resolution:</b></p>
11277
11278 <p><i>Things to notice about these changes:</i></p>
11279
11280 <ol>
11281 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
11282      are intentional. we want to prevent side-effects from
11283      invalidating the end iterators.</i></li>
11284
11285 <li> <i>That has the unintentional side-effect of prohibiting
11286      modification of the end element as a side-effect. This could
11287      conceivably be significant in some cases.</i></li>
11288
11289 <li> <i>The wording also prevents side-effects from modifying elements
11290      of the output sequence. I can't imagine why anyone would want
11291      to do this, but it is arguably a restriction that implementors
11292      don't need to place on users.</i></li>
11293
11294 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
11295      and simple, but would require more verbiage.</i></li>
11296 </ol>
11297
11298 <p>Change 25.2.3/2 from:</p>
11299
11300 <blockquote><p>
11301    -2- Requires: op and binary_op shall not have any side effects.
11302 </p></blockquote>
11303
11304 <p>to:</p>
11305
11306 <blockquote><p>
11307   -2- Requires: in the ranges [first1, last1], [first2, first2 +
11308   (last1 - first1)] and [result, result + (last1- first1)], op and
11309   binary_op shall neither modify elements nor invalidate iterators or
11310   subranges.
11311   [Footnote: The use of fully closed ranges is intentional --end footnote]
11312 </p></blockquote>
11313
11314
11315 <p>Change 25.2.3/2 from:</p>
11316
11317 <blockquote><p>
11318    -2- Requires: op and binary_op shall not have any side effects. 
11319 </p></blockquote>
11320
11321 <p>to:</p>
11322
11323 <blockquote><p>
11324   -2- Requires: op and binary_op shall not invalidate iterators or
11325    subranges, or modify elements in the ranges [first1, last1],
11326    [first2, first2 + (last1 - first1)], and [result, result + (last1
11327    - first1)].
11328   [Footnote: The use of fully closed ranges is intentional --end footnote]
11329 </p></blockquote>
11330
11331
11332 <p>Change 26.4.1/2 from:</p>
11333
11334 <blockquote><p>
11335   -2- Requires: T must meet the requirements of CopyConstructible
11336    (lib.copyconstructible) and Assignable (lib.container.requirements)
11337    types. binary_op shall not cause side effects.
11338 </p></blockquote>
11339
11340 <p>to:</p>
11341
11342 <blockquote><p>
11343   -2- Requires: T must meet the requirements of CopyConstructible
11344    (lib.copyconstructible) and Assignable
11345    (lib.container.requirements) types. In the range [first, last],
11346    binary_op shall neither modify elements nor invalidate iterators
11347    or subranges.
11348   [Footnote: The use of a fully closed range is intentional --end footnote]
11349 </p></blockquote>
11350
11351 <p>Change 26.4.2/2 from:</p>
11352
11353 <blockquote><p>
11354   -2- Requires: T must meet the requirements of CopyConstructible
11355    (lib.copyconstructible) and Assignable (lib.container.requirements)
11356    types. binary_op1 and binary_op2 shall not cause side effects.
11357 </p></blockquote>
11358
11359 <p>to:</p>
11360
11361 <blockquote><p>
11362   -2- Requires: T must meet the requirements of CopyConstructible
11363    (lib.copyconstructible) and Assignable (lib.container.requirements)
11364    types. In the ranges [first, last] and [first2, first2 + (last -
11365    first)], binary_op1 and binary_op2 shall neither modify elements
11366    nor invalidate iterators or subranges.
11367   [Footnote: The use of fully closed ranges is intentional --end footnote]
11368 </p></blockquote>
11369
11370
11371 <p>Change 26.4.3/4 from:</p>
11372
11373 <blockquote><p>
11374   -4- Requires: binary_op is expected not to have any side effects.
11375 </p></blockquote>
11376
11377 <p>to:</p>
11378
11379 <blockquote><p>
11380   -4- Requires: In the ranges [first, last] and [result, result +
11381    (last - first)], binary_op shall neither modify elements nor
11382    invalidate iterators or subranges.
11383   [Footnote: The use of fully closed ranges is intentional --end footnote]
11384 </p></blockquote>
11385
11386 <p>Change 26.4.4/2 from:</p>
11387
11388 <blockquote><p>
11389   -2- Requires: binary_op shall not have any side effects.
11390 </p></blockquote>
11391
11392 <p>to:</p>
11393
11394 <blockquote><p>
11395   -2- Requires: In the ranges [first, last] and [result, result +
11396    (last - first)], binary_op shall neither modify elements nor
11397    invalidate iterators or subranges.
11398   [Footnote: The use of fully closed ranges is intentional --end footnote]
11399 </p></blockquote>
11400
11401 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
11402
11403
11404 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
11405 added footnotes pointing out that the use of closed ranges was
11406 intentional.]</i></p>
11407
11408
11409
11410
11411
11412
11413
11414 <hr>
11415 <h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
11416 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11417  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
11418 <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>
11419 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11420 <p><b>Discussion:</b></p>
11421 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
11422 are unclear with respect to the behavior and side-effects of the named
11423 functions in case of an error.</p>
11424
11425 <p>27.6.1.3, p1 states that "... If the sentry object returns
11426 true, when converted to a value of type bool, the function endeavors
11427 to obtain the requested input..." It is not clear from this (or
11428 the rest of the paragraph) what precisely the behavior should be when
11429 the sentry ctor exits by throwing an exception or when the sentry
11430 object returns false.  In particular, what is the number of characters
11431 extracted that gcount() returns supposed to be?</p>
11432
11433 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
11434 "...  In any case, it then stores a null character (using
11435 charT()) into the next successive location of the array." Is not
11436 clear whether this sentence applies if either of the conditions above
11437 holds (i.e., when sentry fails).</p>
11438
11439
11440 <p><b>Proposed resolution:</b></p>
11441 <p>Add to 27.6.1.3, p1 after the sentence</p>
11442
11443 <blockquote><p>
11444 "... If the sentry object returns true, when converted to a value of
11445 type bool, the function endeavors to obtain the requested input."
11446 </p></blockquote>
11447
11448 <p>the following</p>
11449
11450
11451 <blockquote><p>
11452 "Otherwise, if the sentry constructor exits by throwing an exception or
11453 if the sentry object returns false, when converted to a value of type
11454 bool, the function returns without attempting to obtain any input. In
11455 either case the number of extracted characters is set to 0; unformatted
11456 input functions taking a character array of non-zero size as an argument
11457 shall also store a null character (using charT()) in the first location
11458 of the array."
11459 </p></blockquote>
11460
11461
11462 <p><b>Rationale:</b></p>
11463 <p>Although the general philosophy of the input functions is that the
11464 argument should not be modified upon failure, <tt>getline</tt>
11465 historically added a terminating null unconditionally.  Most
11466 implementations still do that.  Earlier versions of the draft standard
11467 had language that made this an unambiguous requirement; those words
11468 were moved to a place where their context made them less clear.  See
11469 Jerry Schwarz's message c++std-lib-7618.</p>
11470
11471
11472
11473
11474 <hr>
11475 <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
11476 <p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11477  <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-06-06 <b>Last modified:</b> 2010-10-29</p>
11478 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
11479 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11480 <p><b>Discussion:</b></p>
11481 <p>Paragraph 2 of 23.4.1.4 [vector.modifiers] describes the complexity
11482 of <tt>vector::insert</tt>:</p>
11483
11484    <blockquote><p>
11485    Complexity: If first and last are forward iterators, bidirectional
11486    iterators, or random access iterators, the complexity is linear in
11487    the number of elements in the range [first, last) plus the distance
11488    to the end of the vector. If they are input iterators, the complexity
11489    is proportional to the number of elements in the range [first, last)
11490    times the distance to the end of the vector.
11491    </p></blockquote>
11492
11493 <p>First, this fails to address the non-iterator forms of
11494 <tt>insert</tt>.</p>
11495
11496 <p>Second, the complexity for input iterators misses an edge case --
11497 it requires that an arbitrary number of elements can be added at
11498 the end of a <tt>vector</tt> in constant time.</p>
11499
11500 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
11501 surprised to find that <tt>deque</tt> places no requirement on the
11502 complexity of inserting multiple elements (23.3.2.3 [deque.modifiers],
11503 paragraph 3):</p>
11504
11505    <blockquote><p>
11506    Complexity: In the worst case, inserting a single element into a
11507    deque takes time linear in the minimum of the distance from the
11508    insertion point to the beginning of the deque and the distance
11509    from the insertion point to the end of the deque. Inserting a
11510    single element either at the beginning or end of a deque always
11511    takes constant time and causes a single call to the copy constructor
11512    of T.
11513    </p></blockquote>
11514
11515
11516 <p><b>Proposed resolution:</b></p>
11517
11518 <p>Change Paragraph 2 of 23.4.1.4 [vector.modifiers] to</p>
11519    <blockquote><p>
11520    Complexity: The complexity is linear in the number of elements 
11521    inserted plus the distance to the end of the vector.
11522    </p></blockquote>
11523
11524    <p><i>[For input iterators, one may achieve this complexity by first
11525    inserting at the end of the <tt>vector</tt>, and then using
11526    <tt>rotate</tt>.]</i></p>
11527
11528
11529 <p>Change 23.3.2.3 [deque.modifiers], paragraph 3, to:</p>
11530
11531    <blockquote><p>
11532    Complexity: The complexity is linear in the number of elements 
11533    inserted plus the shorter of the distances to the beginning and
11534    end of the deque.  Inserting a single element at either the
11535    beginning or the end of a deque causes a single call to the copy
11536    constructor of T.
11537    </p></blockquote>
11538
11539
11540
11541 <p><b>Rationale:</b></p>
11542 <p>This is a real defect, and proposed resolution fixes it: some
11543   complexities aren't specified that should be.  This proposed
11544   resolution does constrain deque implementations (it rules out the
11545   most naive possible implementations), but the LWG doesn't see a
11546   reason to permit that implementation.</p>
11547
11548
11549
11550
11551
11552 <hr>
11553 <h3><a name="248"></a>248. time_get fails to set eofbit</h3>
11554 <p><b>Section:</b> 22.4.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11555  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-06-22 <b>Last modified:</b> 2010-10-29</p>
11556 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11557 <p><b>Discussion:</b></p>
11558 <p>There is no requirement that any of time_get member functions set
11559 ios::eofbit when they reach the end iterator while parsing their input.
11560 Since members of both the num_get and money_get facets are required to
11561 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
11562 should follow the same requirement for consistency.</p>
11563
11564
11565 <p><b>Proposed resolution:</b></p>
11566 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
11567
11568 <blockquote><p>
11569 If the end iterator is reached during parsing by any of the get()
11570 member functions, the member sets ios_base::eofbit in err.
11571 </p></blockquote>
11572
11573
11574 <p><b>Rationale:</b></p>
11575 <p>Two alternative resolutions were proposed.  The LWG chose this one
11576 because it was more consistent with the way eof is described for other
11577 input facets.</p>
11578
11579
11580
11581
11582 <hr>
11583 <h3><a name="250"></a>250. splicing invalidates iterators</h3>
11584 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11585  <b>Submitter:</b> Brian Parker  <b>Opened:</b> 2000-07-14 <b>Last modified:</b> 2010-10-29</p>
11586 <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>
11587 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11588 <p><b>Discussion:</b></p>
11589 <p>
11590 Section 23.3.4.4 [list.ops] states that
11591 </p>
11592 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
11593 </pre>
11594 <p>
11595 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
11596 </p>
11597
11598 <p>
11599 This is unnecessary and defeats an important feature of splice. In
11600 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
11601 after <tt>splice</tt>.
11602 </p>
11603
11604
11605 <p><b>Proposed resolution:</b></p>
11606
11607 <p>Add a footnote to 23.3.4.4 [list.ops], paragraph 1:</p>
11608 <blockquote><p>
11609 [<i>Footnote:</i> As specified in  [default.con.req], paragraphs
11610 4-5, the semantics described in this clause applies only to the case
11611 where allocators compare equal.  --end footnote]
11612 </p></blockquote>
11613
11614 <p>In 23.3.4.4 [list.ops], replace paragraph 4 with:</p>
11615 <blockquote><p>
11616 Effects: Inserts the contents of x before position and x becomes 
11617 empty.  Pointers and references to the moved elements of x now refer to 
11618 those same elements but as members of *this.  Iterators referring to the 
11619 moved elements will continue to refer to their elements, but they now 
11620 behave as iterators into *this, not into x.
11621 </p></blockquote>
11622
11623 <p>In 23.3.4.4 [list.ops], replace paragraph 7 with:</p>
11624 <blockquote><p>
11625 Effects: Inserts an element pointed to by i from list x before 
11626 position and removes the element from x. The result is unchanged if 
11627 position == i or position == ++i.  Pointers and references to *i continue 
11628 to refer to this same element but as a member of *this.  Iterators to *i 
11629 (including i itself) continue to refer to the same element, but now 
11630 behave as iterators into *this, not into x.
11631 </p></blockquote>
11632
11633 <p>In 23.3.4.4 [list.ops], replace paragraph 12 with:</p>
11634 <blockquote><p>
11635 Requires: [first, last) is a valid range in x. The result is 
11636 undefined if position is an iterator in the range [first, last).  
11637 Pointers and references to the moved elements of x now refer to those 
11638 same elements but as members of *this.  Iterators referring to the moved 
11639 elements will continue to refer to their elements, but they now behave as 
11640 iterators into *this, not into x.
11641 </p></blockquote>
11642
11643 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
11644
11645
11646
11647 <p><b>Rationale:</b></p>
11648 <p>The original proposed resolution said that iterators and references
11649 would remain "valid".  The new proposed resolution clarifies what that
11650 means.  Note that this only applies to the case of equal allocators.
11651 From  [default.con.req] paragraph 4, the behavior of list when
11652 allocators compare nonequal is outside the scope of the standard.</p>
11653
11654
11655
11656
11657 <hr>
11658 <h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
11659 <p><b>Section:</b> 27.8.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11660  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2010-10-29</p>
11661 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11662 <p><b>Discussion:</b></p>
11663 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
11664 doesn't list a typedef for the template parameter
11665 <tt>Allocator</tt>. This makes it impossible to determine the type of
11666 the allocator at compile time. It's also inconsistent with all other
11667 template classes in the library that do provide a typedef for the
11668 <tt>Allocator</tt> parameter.</p>
11669
11670
11671 <p><b>Proposed resolution:</b></p>
11672 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
11673 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and 
11674 basic_stringstream (27.7.4) the typedef:</p>
11675 <pre>  typedef Allocator allocator_type;
11676 </pre>
11677
11678
11679
11680
11681 <hr>
11682 <h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
11683 <p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11684  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2010-10-29</p>
11685 <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>
11686 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11687 <p><b>Discussion:</b></p>
11688 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
11689 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
11690 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
11691 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
11692 the cast altogether.</p>
11693
11694 <p>C-style casts have not been deprecated, so the first part of this
11695 issue is stylistic rather than a matter of correctness.</p>
11696
11697
11698 <p><b>Proposed resolution:</b></p>
11699 <p>In 27.7.2.2, p1 replace </p>
11700 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
11701
11702 <p>with</p>
11703 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11704
11705
11706 <p>In 27.7.3.2, p1 replace</p>
11707 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
11708
11709 <p>with</p>
11710 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11711
11712 <p>In 27.7.6, p1, replace</p>
11713 <pre>  -1- Returns: &amp;sb</pre>
11714
11715 <p>with</p>
11716 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11717
11718 <p>In D.7.2.2, p1 replace</p>
11719 <pre>  -2- Returns: &amp;sb. </pre>
11720
11721 <p>with</p>
11722 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
11723
11724
11725
11726
11727 <hr>
11728 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
11729 <p><b>Section:</b> 26.6.2.1 [valarray.cons], 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11730  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2000-07-31 <b>Last modified:</b> 2010-10-29</p>
11731 <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>
11732 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11733 <p><b>Discussion:</b></p>
11734 <p>This discussion is adapted from message c++std-lib-7056 posted
11735 November 11, 1999.  I don't think that anyone can reasonably claim
11736 that the problem described below is NAD.</p>
11737
11738 <p>These valarray constructors can never be called:</p>
11739
11740 <pre>   template &lt;class T&gt;
11741          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
11742    template &lt;class T&gt;
11743          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
11744    template &lt;class T&gt;
11745          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
11746    template &lt;class T&gt;
11747          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
11748 </pre>
11749
11750 <p>Similarly, these valarray assignment operators cannot be
11751 called:</p>
11752
11753 <pre>     template &lt;class T&gt;
11754      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
11755      template &lt;class T&gt;
11756      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
11757      template &lt;class T&gt;
11758      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
11759      template &lt;class T&gt;
11760      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
11761 </pre>
11762
11763 <p>Please consider the following example:</p>
11764
11765 <pre>   #include &lt;valarray&gt;
11766    using namespace std;
11767
11768    int main()
11769    {
11770        valarray&lt;double&gt; va1(12);
11771        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
11772    }
11773 </pre>
11774
11775
11776 <p>Since the valarray va1 is non-const, the result of the sub-expression
11777 va1[slice(1,4,3)] at line 1 is an rvalue of type const
11778 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
11779 construct va2.  The constructor that is used to construct va2 is
11780 declared like this:</p>
11781
11782 <pre>     template &lt;class T&gt;
11783      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
11784 </pre>
11785
11786 <p>Notice the constructor's const reference parameter.  When the
11787 constructor is called, a slice_array must be bound to this reference.
11788 The rules for binding an rvalue to a const reference are in 8.5.3,
11789 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
11790 indicates that a second slice_array rvalue is constructed (in this
11791 case copy-constructed) from the first one; it is this second rvalue
11792 that is bound to the reference parameter.  Paragraph 5 also requires
11793 that the constructor that is used for this purpose be callable,
11794 regardless of whether the second rvalue is elided.  The
11795 copy-constructor in this case is not callable, however, because it is
11796 private.  Therefore, the compiler should report an error.</p>
11797
11798 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
11799 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
11800 same reasoning applies to the three other constructors and the four
11801 assignment operators that are listed at the beginning of this post.
11802 Furthermore, since these functions cannot be called, the valarray helper
11803 classes are almost entirely useless.</p>
11804
11805
11806 <p><b>Proposed resolution:</b></p>
11807 <p>slice_array:</p>
11808 <ul>
11809 <li> Make the copy constructor and copy-assignment operator declarations
11810      public in the slice_array class template definition in 26.6.5 [template.slice.array] </li>
11811 <li> remove paragraph 3 of 26.6.5 [template.slice.array]</li>
11812 <li> remove the copy constructor declaration from  [cons.slice.arr]</li>
11813 <li> change paragraph 1 of  [cons.slice.arr] to read "This constructor is declared
11814     to be private.  This constructor need not be defined."</li>
11815 <li> remove the first sentence of paragraph 1 of 26.6.5.1 [slice.arr.assign]</li>
11816 <li> Change the first three words of the second sentence of paragraph 1 of
11817     26.6.5.1 [slice.arr.assign] to "These assignment operators have"</li>
11818 </ul>
11819
11820 <p>gslice_array:</p>
11821 <ul>
11822 <li> Make the copy constructor and copy-assignment operator declarations
11823     public in the gslice_array class template definition in 26.6.7 [template.gslice.array] </li>
11824 <li> remove the note in paragraph 3 of 26.6.7 [template.gslice.array]</li>
11825 <li> remove the copy constructor declaration from  [gslice.array.cons]</li>
11826 <li> change paragraph 1 of  [gslice.array.cons] to read "This constructor is declared
11827     to be private.  This constructor need not be defined."</li>
11828 <li> remove the first sentence of paragraph 1 of 26.6.7.1 [gslice.array.assign]</li>
11829 <li> Change the first three words of the second sentence of paragraph 1 of
11830     26.6.7.1 [gslice.array.assign] to "These assignment operators have"</li>
11831 </ul>
11832
11833 <p>mask_array:</p>
11834 <ul>
11835 <li> Make the copy constructor and copy-assignment operator declarations
11836     public in the mask_array class template definition in 26.6.8 [template.mask.array] </li>
11837 <li> remove the note in paragraph 2 of 26.6.8 [template.mask.array]</li>
11838 <li> remove the copy constructor declaration from  [mask.array.cons]</li>
11839 <li> change paragraph 1 of  [mask.array.cons] to read "This constructor is declared
11840     to be private.  This constructor need not be defined."</li>
11841 <li> remove the first sentence of paragraph 1 of 26.6.8.1 [mask.array.assign]</li>
11842 <li> Change the first three words of the second sentence of paragraph 1 of
11843     26.6.8.1 [mask.array.assign] to "These assignment operators have"</li>
11844 </ul>
11845
11846 <p>indirect_array:</p>
11847 <ul>
11848 <li>Make the copy constructor and copy-assignment operator declarations
11849     public in the indirect_array class definition in 26.6.9 [template.indirect.array]</li>
11850 <li> remove the note in paragraph 2 of 26.6.9 [template.indirect.array]</li>
11851 <li> remove the copy constructor declaration from  [indirect.array.cons]</li>
11852 <li> change the descriptive text in  [indirect.array.cons] to read "This constructor is
11853     declared to be private.  This constructor need not be defined."</li>
11854 <li> remove the first sentence of paragraph 1 of 26.6.9.1 [indirect.array.assign]</li>
11855 <li> Change the first three words of the second sentence of paragraph 1 of
11856     26.6.9.1 [indirect.array.assign] to "These assignment operators have"</li>
11857 </ul>
11858 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
11859 copy constructor and copy assignment operators public, instead of
11860 removing them.]</i></p>
11861
11862
11863
11864 <p><b>Rationale:</b></p>
11865 <p>Keeping the valarray constructors private is untenable.  Merely
11866 making valarray a friend of the helper classes isn't good enough,
11867 because access to the copy constructor is checked in the user's
11868 environment.</p>
11869
11870 <p>Making the assignment operator public is not strictly necessary to
11871 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
11872 believed we should make the assignment operators public, in addition
11873 to the copy constructors, for reasons of symmetry and user
11874 expectation.</p>
11875
11876
11877
11878
11879
11880 <hr>
11881 <h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
11882 <p><b>Section:</b> 19.2 [std.exceptions], 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11883  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-08-01 <b>Last modified:</b> 2010-10-29</p>
11884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11885 <p><b>Discussion:</b></p>
11886 <p>
11887 Many of the standard exception types which implementations are
11888 required to throw are constructed with a const std::string&amp;
11889 parameter. For example:
11890 </p>
11891
11892 <pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
11893      namespace std {
11894        class out_of_range : public logic_error {
11895        public:
11896          explicit out_of_range(const string&amp; what_arg);
11897        };
11898      }
11899
11900    1 The class out_of_range defines the type of objects  thrown  as  excep-
11901      tions to report an argument value not in its expected range.
11902
11903      out_of_range(const string&amp; what_arg);
11904
11905      Effects:
11906        Constructs an object of class out_of_range.
11907      Postcondition:
11908        strcmp(what(), what_arg.c_str()) == 0.
11909 </pre>
11910
11911 <p>
11912 There are at least two problems with this:
11913 </p>
11914 <ol>
11915 <li>A program which is low on memory may end up throwing
11916 std::bad_alloc instead of out_of_range because memory runs out while
11917 constructing the exception object.</li>
11918 <li>An obvious implementation which stores a std::string data member
11919 may end up invoking terminate() during exception unwinding because the
11920 exception object allocates memory (or rather fails to) as it is being
11921 copied.</li>
11922 </ol>
11923
11924 <p>
11925 There may be no cure for (1) other than changing the interface to
11926 out_of_range, though one could reasonably argue that (1) is not a
11927 defect. Personally I don't care that much if out-of-memory is reported
11928 when I only have 20 bytes left, in the case when out_of_range would
11929 have been reported. People who use exception-specifications might care
11930 a lot, though.
11931 </p>
11932
11933 <p>
11934 There is a cure for (2), but it isn't completely obvious. I think a
11935 note for implementors should be made in the standard. Avoiding
11936 possible termination in this case shouldn't be left up to chance.  The
11937 cure is to use a reference-counted "string" implementation
11938 in the exception object. I am not necessarily referring to a
11939 std::string here; any simple reference-counting scheme for a NTBS
11940 would do.
11941 </p>
11942
11943 <p><b>Further discussion, in email:</b></p>
11944
11945 <p>
11946 ...I'm not so concerned about (1). After all, a library implementation
11947 can add const char* constructors as an extension, and users don't
11948 <i>need</i> to avail themselves of the standard exceptions, though this is
11949 a lame position to be forced into.  FWIW, std::exception and
11950 std::bad_alloc don't require a temporary basic_string.
11951 </p>
11952
11953 <p>
11954 ...I don't think the fixed-size buffer is a solution to the problem,
11955 strictly speaking, because you can't satisfy the postcondition
11956 <br>
11957     <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
11958 <br>
11959 For all values of what_arg (i.e. very long values). That means that
11960 the only truly conforming solution requires a dynamic allocation.
11961 </p>
11962
11963 <p><b>Further discussion, from Redmond:</b></p>
11964
11965 <p>The most important progress we made at the Redmond meeting was
11966 realizing that there are two separable issues here: the const
11967 string&amp; constructor, and the copy constructor.  If a user writes
11968 something like <tt>throw std::out_of_range("foo")</tt>, the const
11969 string&amp; constructor is invoked before anything gets thrown.  The
11970 copy constructor is potentially invoked during stack unwinding.</p>
11971
11972 <p>The copy constructor is a more serious problem, becuase failure
11973 during stack unwinding invokes <tt>terminate</tt>.  The copy
11974 constructor must be nothrow. <i>Curaçao: Howard thinks this
11975 requirement may already be present.</i></p>
11976
11977 <p>The fundamental problem is that it's difficult to get the nothrow
11978 requirement to work well with the requirement that the exception
11979 objects store a string of unbounded size, particularly if you also try
11980 to make the const string&amp; constructor nothrow.  Options discussed
11981 include:</p>
11982
11983 <ul>
11984 <li>Limit the size of a string that exception objects are required to
11985 throw: change the postconditions of 19.2.2 [domain.error] paragraph 3
11986 and 19.2.6 [runtime.error] paragraph 3 to something like this:
11987 "strncmp(what(), what_arg._str(), N) == 0, where N is an
11988 implementation defined constant no smaller than 256".</li>
11989 <li>Allow the const string&amp; constructor to throw, but not the
11990 copy constructor.  It's the implementor's responsibility to get it
11991 right.  (An implementor might use a simple refcount class.)</li>
11992 <li>Compromise between the two: an implementation is not allowed to
11993 throw if the string's length is less than some N, but, if it doesn't
11994 throw, the string must compare equal to the argument.</li>
11995 <li>Add a new constructor that takes a const char*</li>
11996 </ul>
11997
11998 <p>(Not all of these options are mutually exclusive.)</p>
11999
12000
12001
12002 <p><b>Proposed resolution:</b></p>
12003
12004 <p>
12005 Change 19.2.1 [logic.error]
12006 </p>
12007
12008 <blockquote>
12009 <pre>namespace std {
12010   class logic_error : public exception {
12011   public:
12012     explicit logic_error(const string&amp; <i>what_arg</i>);
12013     <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
12014   };
12015 }
12016 </pre>
12017 <p>...</p>
12018 <p>
12019 <ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
12020 </p>
12021 <blockquote>
12022 <p><ins>
12023 -4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
12024 </ins></p>
12025 <p><ins>
12026 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12027 </ins></p>
12028 </blockquote>
12029
12030 </blockquote>
12031
12032 <p>
12033 Change 19.2.2 [domain.error]
12034 </p>
12035
12036 <blockquote>
12037 <pre>namespace std {
12038   class domain_error : public logic_error {
12039   public:
12040     explicit domain_error(const string&amp; <i>what_arg</i>);
12041     <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
12042   };
12043 }
12044 </pre>
12045 <p>...</p>
12046 <p>
12047 <ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
12048 </p>
12049 <blockquote>
12050 <p><ins>
12051 -4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
12052 </ins></p>
12053 <p><ins>
12054 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12055 </ins></p>
12056
12057 </blockquote>
12058 </blockquote>
12059
12060 <p>
12061 Change 19.2.3 [invalid.argument]
12062 </p>
12063
12064 <blockquote>
12065 <pre>namespace std {
12066   class invalid_argument : public logic_error {
12067   public:
12068     explicit invalid_argument(const string&amp; <i>what_arg</i>);
12069     <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
12070   };
12071 }
12072 </pre>
12073 <p>...</p>
12074 <p>
12075 <ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
12076 </p>
12077 <blockquote>
12078 <p><ins>
12079 -4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
12080 </ins></p>
12081 <p><ins>
12082 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12083 </ins></p>
12084 </blockquote>
12085
12086 </blockquote>
12087
12088 <p>
12089 Change 19.2.4 [length.error]
12090 </p>
12091
12092 <blockquote>
12093 <pre>namespace std {
12094   class length_error : public logic_error {
12095   public:
12096     explicit length_error(const string&amp; <i>what_arg</i>);
12097     <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
12098   };
12099 }
12100 </pre>
12101 <p>...</p>
12102 <p>
12103 <ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
12104 </p>
12105 <blockquote>
12106 <p><ins>
12107 -4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
12108 </ins></p>
12109 <p><ins>
12110 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12111 </ins></p>
12112 </blockquote>
12113
12114 </blockquote>
12115
12116 <p>
12117 Change 19.2.5 [out.of.range]
12118 </p>
12119
12120 <blockquote>
12121 <pre>namespace std {
12122   class out_of_range : public logic_error {
12123   public:
12124     explicit out_of_range(const string&amp; <i>what_arg</i>);
12125     <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
12126   };
12127 }
12128 </pre>
12129 <p>...</p>
12130 <p>
12131 <ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
12132 </p>
12133 <blockquote>
12134 <p><ins>
12135 -4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
12136 </ins></p>
12137 <p><ins>
12138 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12139 </ins></p>
12140 </blockquote>
12141
12142 </blockquote>
12143
12144 <p>
12145 Change 19.2.6 [runtime.error]
12146 </p>
12147
12148 <blockquote>
12149 <pre>namespace std {
12150   class runtime_error : public exception {
12151   public:
12152     explicit runtime_error(const string&amp; <i>what_arg</i>);
12153     <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
12154   };
12155 }
12156 </pre>
12157 <p>...</p>
12158 <p>
12159 <ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
12160 </p>
12161 <blockquote>
12162 <p><ins>
12163 -4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
12164 </ins></p>
12165 <p><ins>
12166 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12167 </ins></p>
12168 </blockquote>
12169
12170 </blockquote>
12171
12172 <p>
12173 Change 19.2.7 [range.error]
12174 </p>
12175
12176 <blockquote>
12177 <pre>namespace std {
12178   class range_error : public runtime_error {
12179   public:
12180     explicit range_error(const string&amp; <i>what_arg</i>);
12181     <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
12182   };
12183 }
12184 </pre>
12185 <p>...</p>
12186 <p>
12187 <ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
12188 </p>
12189 <blockquote>
12190 <p><ins>
12191 -4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
12192 </ins></p>
12193 <p><ins>
12194 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12195 </ins></p>
12196 </blockquote>
12197
12198 </blockquote>
12199
12200 <p>
12201 Change 19.2.8 [overflow.error]
12202 </p>
12203
12204 <blockquote>
12205 <pre>namespace std {
12206   class overflow_error : public runtime_error {
12207   public:
12208     explicit overflow_error(const string&amp; <i>what_arg</i>);
12209     <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
12210   };
12211 }
12212 </pre>
12213 <p>...</p>
12214 <p>
12215 <ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
12216 </p>
12217 <blockquote>
12218 <p><ins>
12219 -4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
12220 </ins></p>
12221 <p><ins>
12222 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12223 </ins></p>
12224 </blockquote>
12225
12226 </blockquote>
12227
12228 <p>
12229 Change 19.2.9 [underflow.error]
12230 </p>
12231
12232 <blockquote>
12233 <pre>namespace std {
12234   class underflow_error : public runtime_error {
12235   public:
12236     explicit underflow_error(const string&amp; <i>what_arg</i>);
12237     <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
12238   };
12239 }
12240 </pre>
12241 <p>...</p>
12242 <p>
12243 <ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
12244 </p>
12245 <blockquote>
12246 <p><ins>
12247 -4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
12248 </ins></p>
12249 <p><ins>
12250 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12251 </ins></p>
12252 </blockquote>
12253
12254 </blockquote>
12255
12256 <p>
12257 Change 27.5.2.1.1 [ios::failure]
12258 </p>
12259
12260 <blockquote>
12261 <pre>namespace std {
12262   class ios_base::failure : public exception {
12263   public:
12264     explicit failure(const string&amp; <i>msg</i>);
12265     <ins>explicit failure(const char* <i>msg</i>);</ins>
12266     virtual const char* what() const throw();
12267 };
12268 }
12269 </pre>
12270 <p>...</p>
12271 <p>
12272 <ins><tt>failure(const char* <i>msg</i>);</tt></ins>
12273 </p>
12274 <blockquote>
12275 <p><ins>
12276 -4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
12277 </ins></p>
12278 <p><ins>
12279 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
12280 </ins></p>
12281 </blockquote>
12282
12283 </blockquote>
12284
12285
12286
12287 <p><b>Rationale:</b></p>
12288
12289 <p>Throwing a bad_alloc while trying to construct a message for another
12290 exception-derived class is not necessarily a bad thing.  And the
12291 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
12292
12293 <p><b>Future:</b></p>
12294
12295 <p>All involved would like to see const char* constructors added, but
12296 this should probably be done for C++0X as opposed to a DR.</p>
12297
12298 <p>I believe the no throw specs currently decorating these functions
12299 could be improved by some kind of static no throw spec checking
12300 mechanism (in a future C++ language).  As they stand, the copy
12301 constructors might fail via a call to unexpected.  I think what is
12302 intended here is that the copy constructors can't fail.</p>
12303
12304 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
12305   Post-Redmond: James Kanze noticed that the copy constructors of
12306   exception-derived classes do not have nothrow clauses.  Those
12307   classes have no copy constructors declared, meaning the
12308   compiler-generated implicit copy constructors are used, and those
12309   compiler-generated constructors might in principle throw anything.]</i></p>
12310
12311
12312 <p><i>[
12313 Batavia:  Merged copy constructor and assignment operator spec into <tt>exception</tt>
12314 and added <tt>ios::failure</tt> into the proposed resolution.
12315 ]</i></p>
12316
12317
12318 <p><i>[
12319 Oxford:  The proposed resolution simply addresses the issue of constructing
12320 the exception objects with <tt>const char*</tt> and string literals without
12321 the need to explicit include or construct a <tt>std::string</tt>.
12322 ]</i></p>
12323
12324
12325
12326
12327
12328
12329
12330 <hr>
12331 <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
12332 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12333  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-21 <b>Last modified:</b> 2010-10-29</p>
12334 <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>
12335 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12336 <p><b>Discussion:</b></p>
12337 <p>
12338 27.4.4.2, p17 says
12339 </p>
12340
12341 <blockquote><p>
12342 -17- Before copying any parts of rhs, calls each registered callback
12343 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
12344 exceptions() have been replaced, calls each callback pair that was
12345 copied from rhs as (*fn)(copy_event,*this,index). 
12346 </p></blockquote>
12347
12348 <p>
12349 The name copy_event isn't defined anywhere. The intended name was
12350 copyfmt_event.
12351 </p>
12352
12353
12354 <p><b>Proposed resolution:</b></p>
12355 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
12356
12357
12358
12359
12360 <hr>
12361 <h3><a name="258"></a>258. Missing allocator requirement</h3>
12362 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12363  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-08-22 <b>Last modified:</b> 2010-10-29</p>
12364 <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>
12365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12366 <p><b>Discussion:</b></p>
12367 <p>
12368 From lib-7752:
12369 </p>
12370
12371 <p>
12372 I've been assuming (and probably everyone else has been assuming) that
12373 allocator instances have a particular property, and I don't think that
12374 property can be deduced from anything in Table 32.
12375 </p>
12376
12377 <p>
12378 I think we have to assume that allocator type conversion is a
12379 homomorphism.  That is, if x1 and x2 are of type X, where
12380 X::value_type is T, and if type Y is X::template
12381 rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
12382 </p>
12383
12384 <p>
12385 Further discussion: Howard Hinnant writes, in lib-7757:
12386 </p>
12387
12388 <p>
12389 I think I can prove that this is not provable by Table 32.  And I agree 
12390 it needs to be true except for the "and only if".  If x1 != x2, I see no 
12391 reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't 
12392 think of a practical instance where this would happen, or be valuable.  
12393 But I also don't see a need to add that extra restriction.  I think we 
12394 only need:
12395 </p>
12396
12397 <blockquote><p>
12398      if (x1 == x2) then Y(x1) == Y(x2)
12399 </p></blockquote>
12400
12401 <p>
12402 If we decide that == on allocators is transitive, then I think I can 
12403 prove the above.  But I don't think == is necessarily transitive on 
12404 allocators.  That is:
12405 </p>
12406
12407 <p>
12408 Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
12409 </p>
12410
12411 <p>Example:</p>
12412
12413 <blockquote>
12414 <p>
12415 x1 can deallocate pointers from:  x1, x2, x3    <br>
12416 x2 can deallocate pointers from:  x1, x2, x4    <br>
12417 x3 can deallocate pointers from:  x1, x3        <br>
12418 x4 can deallocate pointers from:  x2, x4 
12419 </p>
12420
12421 <p>
12422 x1 == x2, and x2 == x4, but x1 != x4
12423 </p>
12424 </blockquote>
12425 <p><i>[Toronto: LWG members offered multiple opinions.  One
12426 opinion is that it should not be required that <tt>x1 == x2</tt>
12427 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
12428 required that <tt>X(x1) == x1</tt>.  Another opinion is that 
12429 the second line from the bottom in table 32 already implies the
12430 desired property.  This issue should be considered in light of
12431 other issues related to allocator instances.]</i></p>
12432
12433
12434
12435 <p><b>Proposed resolution:</b></p>
12436 <p>
12437 Accept proposed wording from
12438 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
12439 </p>
12440
12441
12442 <p><i>[Lillehammer: Same conclusion as before: this should be
12443   considered as part of an allocator redesign, not solved on its own.]</i></p>
12444
12445
12446 <p><i>[
12447 Batavia:  An allocator redesign is not forthcoming and thus we fixed this one issue.
12448 ]</i></p>
12449
12450
12451 <p><i>[
12452 Toronto:  Reopened at the request of the project editor (Pete) because the proposed
12453 wording did not fit within the indicated table.  The intent of the resolution remains
12454 unchanged.  Pablo to work with Pete on improved wording.
12455 ]</i></p>
12456
12457
12458 <p><i>[
12459 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
12460 was subsequently split out into a separate paper N2436 for the purposes of voting.
12461 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
12462 issue to Ready status to be voted into the WP at Kona.
12463 ]</i></p>
12464
12465
12466
12467
12468
12469 <hr>
12470 <h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
12471 <p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12472  <b>Submitter:</b> Chris Newton  <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
12473 <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>
12474 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12475 <p><b>Discussion:</b></p>
12476 <p>
12477 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
12478 </p>
12479
12480 <p>
12481 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
12482 seems to violate const correctness.
12483 </p>
12484
12485 <p>
12486 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
12487 returns <tt>data()[pos]</tt>." The types don't work.  The
12488 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
12489 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
12490 </p>
12491
12492
12493 <p><b>Proposed resolution:</b></p>
12494 <p>
12495 In section 21.3.4, paragraph 1, change
12496 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
12497 <i>pos</i>)</tt>".
12498 </p>
12499
12500
12501
12502
12503 <hr>
12504 <h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
12505 <p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12506  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
12507 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
12508 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12509 <p><b>Discussion:</b></p>
12510 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
12511 it as returning the iterator by value. 24.5.1.2, p5 shows the same
12512 operator as returning the iterator by reference. That's incorrect
12513 given the Effects clause below (since a temporary is returned). The
12514 `&amp;' is probably just a typo.</p>
12515
12516
12517 <p><b>Proposed resolution:</b></p>
12518 <p>Change the declaration in 24.5.1.2, p5 from</p>
12519  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
12520  </pre>
12521 <p>to</p>
12522  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
12523  </pre>
12524 <p>(that is, remove the `&amp;').</p>
12525
12526
12527
12528
12529 <hr>
12530 <h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
12531 <p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12532  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
12533 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
12534 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12535 <p><b>Discussion:</b></p>
12536 <p>
12537 24.5.1, p3 lists the synopsis for
12538 </p>
12539
12540 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
12541         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
12542                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
12543 </pre>
12544
12545 <p>
12546 but there is no description of what the operator does (i.e., no Effects
12547 or Returns clause) in 24.5.1.2.
12548 </p>
12549
12550
12551 <p><b>Proposed resolution:</b></p>
12552 <p>
12553 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
12554 </p>
12555
12556 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
12557         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
12558                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
12559 </pre>
12560
12561 <p>-7- Returns: !(x == y).</p>
12562
12563
12564
12565
12566 <hr>
12567 <h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
12568 <p><b>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12569  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-09-03 <b>Last modified:</b> 2010-10-29</p>
12570 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitmask.types">issues</a> in [bitmask.types].</p>
12571 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12572 <p><b>Discussion:</b></p>
12573 <p>
12574 The ~ operation should be applied after the cast to int_type.
12575 </p>
12576
12577
12578 <p><b>Proposed resolution:</b></p>
12579 <p>
12580 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
12581 </p>
12582
12583 <pre>   bitmask operator~ ( bitmask X )
12584      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
12585 </pre>
12586
12587 <p>
12588 to:
12589 </p>
12590
12591 <pre>   bitmask operator~ ( bitmask X )
12592      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
12593 </pre>
12594
12595
12596
12597
12598 <hr>
12599 <h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
12600 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12601  <b>Submitter:</b> Kevlin Henney <b>Opened:</b> 2000-09-04 <b>Last modified:</b> 2010-10-29</p>
12602 <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>
12603 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12604 <p><b>Discussion:</b></p>
12605 <p>
12606 The note in paragraph 6 suggests that the invalidation rules for
12607 references, pointers, and iterators in paragraph 5 permit a reference-
12608 counted implementation (actually, according to paragraph 6, they permit
12609 a "reference counted implementation", but this is a minor editorial fix).
12610 </p>
12611
12612 <p>
12613 However, the last sub-bullet is so worded as to make a reference-counted
12614 implementation unviable. In the following example none of the
12615 conditions for iterator invalidation are satisfied:
12616 </p>
12617
12618 <pre>    // first example: "*******************" should be printed twice
12619     string original = "some arbitrary text", copy = original;
12620     const string &amp; alias = original;
12621
12622     string::const_iterator i = alias.begin(), e = alias.end();
12623     for(string::iterator j = original.begin(); j != original.end(); ++j)
12624         *j = '*';
12625     while(i != e)
12626         cout &lt;&lt; *i++;
12627     cout &lt;&lt; endl;
12628     cout &lt;&lt; original &lt;&lt; endl;
12629 </pre>
12630
12631 <p>
12632 Similarly, in the following example:
12633 </p>
12634
12635 <pre>    // second example: "some arbitrary text" should be printed out
12636     string original = "some arbitrary text", copy = original;
12637     const string &amp; alias = original;
12638
12639     string::const_iterator i = alias.begin();
12640     original.begin();
12641     while(i != alias.end())
12642         cout &lt;&lt; *i++;
12643 </pre>
12644
12645 <p>
12646 I have tested this on three string implementations, two of which were
12647 reference counted. The reference-counted implementations gave
12648 "surprising behavior" because they invalidated iterators on
12649 the first call to non-const begin since construction. The current
12650 wording does not permit such invalidation because it does not take
12651 into account the first call since construction, only the first call
12652 since various member and non-member function calls.
12653 </p>
12654
12655
12656 <p><b>Proposed resolution:</b></p>
12657 <p>
12658 Change the following sentence in 21.3 paragraph 5 from
12659 </p>
12660
12661 <blockquote><p>
12662     Subsequent to any of the above uses except the forms of insert() and
12663     erase() which return iterators, the first call to non-const member
12664     functions operator[](), at(), begin(), rbegin(), end(), or rend().
12665 </p></blockquote>
12666
12667 <p>to</p>
12668
12669 <blockquote><p>
12670     Following construction or any of the above uses, except the forms of
12671     insert() and erase() that return iterators, the first call to non-
12672     const member functions operator[](), at(), begin(), rbegin(), end(),
12673     or rend().
12674 </p></blockquote>
12675
12676
12677
12678
12679 <hr>
12680 <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
12681 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12682  <b>Submitter:</b> John Potter <b>Opened:</b> 2000-09-07 <b>Last modified:</b> 2010-10-29</p>
12683 <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>
12684 <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>
12685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12686 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
12687 <p><b>Discussion:</b></p>
12688 <p>
12689 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
12690 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
12691 integers in the same range.
12692 </p>
12693
12694 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
12695
12696
12697 <p><b>Proposed resolution:</b></p>
12698 <p>
12699 In Table 69, in section 23.1.2, change the complexity clause for
12700 insertion of a range from "N log(size() + N) (N is the distance
12701 from i to j) in general; linear if [i, j) is sorted according to
12702 value_comp()" to "N log(size() + N), where N is the distance
12703 from i to j".
12704 </p>
12705
12706 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
12707 parens in the revised wording.]</i></p>
12708
12709
12710
12711
12712 <p><b>Rationale:</b></p>
12713 <p>
12714 Testing for valid insertions could be less efficient than simply
12715 inserting the elements when the range is not both sorted and between
12716 two adjacent existing elements; this could be a QOI issue.
12717 </p>
12718
12719 <p> 
12720 The LWG considered two other options: (a) specifying that the
12721 complexity was linear if [i, j) is sorted according to value_comp()
12722 and between two adjacent existing elements; or (b) changing to
12723 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
12724 number of elements which do not insert immediately after the previous
12725 element from [i, j) including the first).  The LWG felt that, since
12726 we can't guarantee linear time complexity whenever the range to be
12727 inserted is sorted, it's more trouble than it's worth to say that it's
12728 linear in some special cases.
12729 </p>
12730
12731
12732
12733
12734 <hr>
12735 <h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
12736 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12737  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-11 <b>Last modified:</b> 2010-10-29</p>
12738 <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>
12739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12740 <p><b>Discussion:</b></p>
12741 <p>
12742 I don't see any requirements on the types of the elements of the
12743 std::pair container in 20.2.2. From the descriptions of the member
12744 functions it appears that they must at least satisfy the requirements of
12745 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
12746 the case of the [in]equality operators also the requirements of 20.1.1
12747 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
12748 </p>
12749
12750 <p>
12751 I believe that the the CopyConstructible requirement is unnecessary in
12752 the case of 20.2.2, p2.
12753 </p>
12754
12755
12756 <p><b>Proposed resolution:</b></p>
12757 <p>Change the Effects clause in 20.2.2, p2 from</p>
12758
12759 <blockquote><p>
12760 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
12761 first(T1()), second(T2()) {} </tt>
12762 </p></blockquote>
12763
12764 <p>to</p>
12765
12766 <blockquote><p>
12767 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
12768 first(), second() {} </tt>
12769 </p></blockquote>
12770
12771
12772 <p><b>Rationale:</b></p>
12773 <p>The existing specification of pair's constructor appears to be a
12774 historical artifact: there was concern that pair's members be properly
12775 zero-initialized when they are built-in types.  At one time there was
12776 uncertainty about whether they would be zero-initialized if the
12777 default constructor was written the obvious way.  This has been
12778 clarified by core issue 178, and there is no longer any doubt that
12779 the straightforward implementation is correct.</p>
12780
12781
12782
12783
12784 <hr>
12785 <h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
12786 <p><b>Section:</b> 18.8.2 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12787  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-24 <b>Last modified:</b> 2010-10-29</p>
12788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12789 <p><b>Discussion:</b></p>
12790 <p>
12791 The synopsis for std::bad_exception lists the function ~bad_exception()
12792 but there is no description of what the function does (the Effects
12793 clause is missing).
12794 </p>
12795
12796
12797 <p><b>Proposed resolution:</b></p>
12798 <p>
12799 Remove the destructor from the class synopses of 
12800 <tt>bad_alloc</tt> (18.6.2.1 [bad.alloc]),
12801 <tt>bad_cast</tt> (18.7.2 [bad.cast]),
12802 <tt>bad_typeid</tt> (18.7.3 [bad.typeid]),
12803 and <tt>bad_exception</tt> (18.8.2 [bad.exception]).
12804 </p>
12805
12806
12807 <p><b>Rationale:</b></p>
12808 <p>
12809 This is a general problem with the exception classes in clause 18. 
12810 The proposed resolution is to remove the destructors from the class
12811 synopses, rather than to document the destructors' behavior, because
12812 removing them is more consistent with how exception classes are
12813 described in clause 19.
12814 </p>
12815
12816
12817
12818
12819 <hr>
12820 <h3><a name="268"></a>268. Typo in locale synopsis</h3>
12821 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12822  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2010-10-29</p>
12823 <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>
12824 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12825 <p><b>Discussion:</b></p>
12826 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
12827 the semicolons after the declarations of the default ctor
12828 locale::locale() and the copy ctor locale::locale(const locale&amp;)
12829 are missing.</p>
12830
12831
12832 <p><b>Proposed resolution:</b></p>
12833 <p>Add the missing semicolons, i.e., change</p>
12834
12835 <pre>    //  construct/copy/destroy:
12836         locale() throw()
12837         locale(const locale&amp; other) throw()
12838 </pre>
12839
12840 <p>in the synopsis in 22.1.1 to</p>
12841
12842 <pre>    //  construct/copy/destroy:
12843         locale() throw();
12844         locale(const locale&amp; other) throw();
12845 </pre>
12846
12847
12848
12849
12850 <hr>
12851 <h3><a name="270"></a>270. Binary search requirements overly strict</h3>
12852 <p><b>Section:</b> 25.4.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12853  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-10-18 <b>Last modified:</b> 2010-10-29</p>
12854 <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>
12855 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12856 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
12857 <p><b>Discussion:</b></p>
12858 <p>
12859 Each of the four binary search algorithms (lower_bound, upper_bound,
12860 equal_range, binary_search) has a form that allows the user to pass a
12861 comparison function object.  According to 25.3, paragraph 2, that
12862 comparison function object has to be a strict weak ordering.
12863 </p>
12864
12865 <p>
12866 This requirement is slightly too strict.  Suppose we are searching
12867 through a sequence containing objects of type X, where X is some
12868 large record with an integer key.  We might reasonably want to look
12869 up a record by key, in which case we would want to write something
12870 like this:
12871 </p>
12872 <pre>    struct key_comp {
12873       bool operator()(const X&amp; x, int n) const {
12874         return x.key() &lt; n;
12875       }
12876     }
12877
12878     std::lower_bound(first, last, 47, key_comp());
12879 </pre>
12880
12881 <p>
12882 key_comp is not a strict weak ordering, but there is no reason to
12883 prohibit its use in lower_bound.
12884 </p>
12885
12886 <p>
12887 There's no difficulty in implementing lower_bound so that it allows
12888 the use of something like key_comp.  (It will probably work unless an
12889 implementor takes special pains to forbid it.)  What's difficult is
12890 formulating language in the standard to specify what kind of
12891 comparison function is acceptable.  We need a notion that's slightly
12892 more general than that of a strict weak ordering, one that can encompass
12893 a comparison function that involves different types.  Expressing that
12894 notion may be complicated.
12895 </p>
12896
12897 <p><i>Additional questions raised at the Toronto meeting:</i></p>
12898 <ul>
12899 <li> Do we really want to specify what ordering the implementor must
12900      use when calling the function object?  The standard gives 
12901      specific expressions when describing these algorithms, but it also
12902      says that other expressions (with different argument order) are
12903      equivalent.</li>
12904 <li> If we are specifying ordering, note that the standard uses both
12905      orderings when describing <tt>equal_range</tt>.</li>
12906 <li> Are we talking about requiring these algorithms to work properly
12907      when passed a binary function object whose two argument types
12908      are not the same, or are we talking about requirements when
12909      they are passed a binary function object with several overloaded
12910      versions of <tt>operator()</tt>?</li>
12911 <li> The definition of a strict weak ordering does not appear to give
12912      any guidance on issues of overloading; it only discusses expressions,
12913      and all of the values in these expressions are of the same type.
12914      Some clarification would seem to be in order.</li>
12915 </ul>
12916
12917 <p><i>Additional discussion from Copenhagen:</i></p>
12918 <ul>
12919 <li>It was generally agreed that there is a real defect here: if
12920 the predicate is merely required to be a Strict Weak Ordering, then
12921 it's possible to pass in a function object with an overloaded
12922 operator(), where the version that's actually called does something
12923 completely inappropriate.  (Such as returning a random value.)</li>
12924
12925 <li>An alternative formulation was presented in a paper distributed by
12926 David Abrahams at the meeting, "Binary Search with Heterogeneous
12927 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
12928 predicate as a Strict Weak Ordering acting on a sorted sequence, view
12929 the predicate/value pair as something that partitions a sequence.
12930 This is almost equivalent to saying that we should view binary search
12931 as if we are given a unary predicate and a sequence, such that f(*p)
12932 is true for all p below a specific point and false for all p above it.
12933 The proposed resolution is based on that alternative formulation.</li>
12934 </ul>
12935
12936
12937 <p><b>Proposed resolution:</b></p>
12938
12939 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
12940
12941 <blockquote><p>
12942   3 For all algorithms that take Compare, there is a version that uses
12943   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
12944   *j != false. For the algorithms to work correctly, comp has to
12945   induce a strict weak ordering on the values.
12946 </p></blockquote>
12947
12948 <p>to:</p>
12949
12950 <blockquote><p>
12951   3 For all algorithms that take Compare, there is a version that uses
12952   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
12953   &lt; *j != false. For algorithms other than those described in
12954   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
12955   a strict weak ordering on the values.
12956 </p></blockquote>
12957
12958 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
12959
12960 <blockquote><p>
12961   -6- A sequence [start, finish) is partitioned with respect to an
12962   expression f(e) if there exists an integer n such that
12963   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
12964   and only if i &lt; n.
12965 </p></blockquote>
12966
12967 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
12968
12969 <blockquote><p>
12970   -1- All of the algorithms in this section are versions of binary
12971    search and assume that the sequence being searched is in order
12972    according to the implied or explicit comparison function. They work
12973    on non-random access iterators minimizing the number of
12974    comparisons, which will be logarithmic for all types of
12975    iterators. They are especially appropriate for random access
12976    iterators, because these algorithms do a logarithmic number of
12977    steps through the data structure. For non-random access iterators
12978    they execute a linear number of steps.
12979 </p></blockquote>
12980
12981 <p>to:</p>
12982
12983 <blockquote><p>
12984    -1- All of the algorithms in this section are versions of binary
12985     search and assume that the sequence being searched is partitioned
12986     with respect to an expression formed by binding the search key to
12987     an argument of the implied or explicit comparison function. They
12988     work on non-random access iterators minimizing the number of
12989     comparisons, which will be logarithmic for all types of
12990     iterators. They are especially appropriate for random access
12991     iterators, because these algorithms do a logarithmic number of
12992     steps through the data structure. For non-random access iterators
12993     they execute a linear number of steps.
12994 </p></blockquote>
12995
12996 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
12997
12998 <blockquote><p>
12999    -1- Requires: Type T is LessThanComparable
13000     (lib.lessthancomparable). 
13001 </p></blockquote>
13002
13003 <p>to:</p>
13004
13005 <blockquote><p>
13006    -1- Requires: The elements e of [first, last) are partitioned with
13007    respect to the expression e &lt; value or comp(e, value)
13008 </p></blockquote>
13009
13010
13011 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
13012
13013 <blockquote><p>
13014    -2- Effects: Finds the first position into which value can be
13015     inserted without violating the ordering. 
13016 </p></blockquote>
13017
13018 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
13019
13020 <blockquote><p>
13021   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
13022 </p></blockquote>
13023
13024 <p>to:</p>
13025
13026 <blockquote><p>
13027    -1- Requires: The elements e of [first, last) are partitioned with
13028    respect to the expression !(value &lt; e) or !comp(value, e)
13029 </p></blockquote>
13030
13031 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
13032
13033 <blockquote><p>
13034    -2- Effects: Finds the furthermost position into which value can be
13035     inserted without violating the ordering.
13036 </p></blockquote>
13037
13038 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
13039
13040 <blockquote><p>
13041    -1- Requires: Type T is LessThanComparable
13042     (lib.lessthancomparable).
13043 </p></blockquote>
13044
13045 <p>to:</p>
13046
13047 <blockquote><p>
13048    -1- Requires: The elements e of [first, last) are partitioned with
13049    respect to the expressions e &lt; value and !(value &lt; e) or
13050    comp(e, value) and !comp(value, e).  Also, for all elements e of
13051    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
13052    value) implies !comp(value, e)
13053 </p></blockquote>
13054
13055 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
13056
13057 <blockquote><p>
13058    -2- Effects: Finds the largest subrange [i, j) such that the value
13059     can be inserted at any iterator k in it without violating the
13060     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
13061     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
13062     false.
13063 </p></blockquote>
13064
13065 <p>to:</p>
13066
13067 <pre>   -2- Returns: 
13068          make_pair(lower_bound(first, last, value),
13069                    upper_bound(first, last, value))
13070        or
13071          make_pair(lower_bound(first, last, value, comp),
13072                    upper_bound(first, last, value, comp))
13073 </pre>
13074
13075 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
13076
13077 <blockquote><p>
13078    -1- Requires: Type T is LessThanComparable
13079     (lib.lessthancomparable).
13080 </p></blockquote>
13081
13082 <p>to:</p>
13083
13084 <blockquote><p>
13085    -1- Requires: The elements e of [first, last) are partitioned with
13086    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
13087    value) and !comp(value, e). Also, for all elements e of [first,
13088    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
13089    !comp(value, e)
13090 </p></blockquote>
13091
13092 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
13093
13094
13095 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
13096 changed the "other than those described in" wording.) Also, the LWG
13097 decided to accept the "optional" part.]</i></p>
13098
13099
13100
13101
13102 <p><b>Rationale:</b></p>
13103 <p>The proposed resolution reinterprets binary search. Instead of
13104 thinking about searching for a value in a sorted range, we view that
13105 as an important special case of a more general algorithm: searching
13106 for the partition point in a partitioned range.</p>
13107
13108 <p>We also add a guarantee that the old wording did not: we ensure
13109 that the upper bound is no earlier than the lower bound, that
13110 the pair returned by equal_range is a valid range, and that the first
13111 part of that pair is the lower bound.</p>
13112
13113
13114
13115
13116
13117 <hr>
13118 <h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
13119 <p><b>Section:</b> 27.7.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13120  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
13121 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13122 <p><b>Discussion:</b></p>
13123 <p>
13124 Class template basic_iostream has no typedefs.  The typedefs it
13125 inherits from its base classes can't be used, since (for example)
13126 basic_iostream&lt;T&gt;::traits_type is ambiguous.
13127 </p>
13128
13129
13130 <p><b>Proposed resolution:</b></p>
13131
13132 <p>Add the following to basic_iostream's class synopsis in 
13133 27.7.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
13134
13135 <pre>  // types:
13136   typedef charT                     char_type;
13137   typedef typename traits::int_type int_type;
13138   typedef typename traits::pos_type pos_type;
13139   typedef typename traits::off_type off_type;
13140   typedef traits                    traits_type;
13141 </pre>
13142
13143
13144
13145
13146 <hr>
13147 <h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
13148 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13149  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
13150 <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>
13151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13152 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
13153 <p><b>Discussion:</b></p>
13154 <p>
13155 27.4.4.3, p4 says about the postcondition of the function: If
13156 rdbuf()!=0 then state == rdstate(); otherwise
13157 rdstate()==state|ios_base::badbit.
13158 </p>
13159
13160 <p>
13161 The expression on the right-hand-side of the operator==() needs to be
13162 parenthesized in order for the whole expression to ever evaluate to
13163 anything but non-zero.
13164 </p>
13165
13166
13167 <p><b>Proposed resolution:</b></p>
13168 <p>
13169 Add parentheses like so: rdstate()==(state|ios_base::badbit).
13170 </p>
13171
13172
13173
13174
13175 <hr>
13176 <h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
13177 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13178  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
13179 <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>
13180 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13181 <p><b>Discussion:</b></p>
13182 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
13183 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
13184 That's incorrect since the names are members of a dependent base
13185 class (14.6.2 [temp.dep]) and thus not visible.</p>
13186
13187
13188 <p><b>Proposed resolution:</b></p>
13189 <p>Qualify the names with the name of the class of which they are
13190 members, i.e., ios_base.</p>
13191
13192
13193
13194
13195 <hr>
13196 <h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
13197 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13198  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
13199 <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>
13200 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13201 <p><b>Discussion:</b></p>
13202 <p>
13203 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
13204 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
13205 be overloaded on reference and const_reference, which is ill-formed for
13206 all T = const U. In other words, this won't work:
13207 </p>
13208
13209 <p>
13210 template class std::allocator&lt;const int&gt;;
13211 </p>
13212
13213 <p>
13214 The obvious solution is to disallow specializations of allocators on
13215 const types. However, while containers' elements are required to be
13216 assignable (which rules out specializations on const T's), I think that
13217 allocators might perhaps be potentially useful for const values in other
13218 contexts. So if allocators are to allow const types a partial
13219 specialization of std::allocator&lt;const T&gt; would probably have to be
13220 provided.
13221 </p>
13222
13223
13224 <p><b>Proposed resolution:</b></p>
13225 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
13226
13227     <blockquote><p>
13228     any type
13229     </p></blockquote>
13230
13231 <p>to</p>
13232     <blockquote><p>
13233     any non-const, non-reference type
13234     </p></blockquote>
13235
13236 <p><i>[Redmond: previous proposed resolution was "any non-const,
13237 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
13238
13239
13240
13241
13242 <p><b>Rationale:</b></p>
13243 <p>
13244 Two resolutions were originally proposed: one that partially
13245 specialized std::allocator for const types, and one that said an
13246 allocator's value type may not be const.  The LWG chose the second.
13247 The first wouldn't be appropriate, because allocators are intended for
13248 use by containers, and const value types don't work in containers.
13249 Encouraging the use of allocators with const value types would only
13250 lead to unsafe code.
13251 </p>
13252 <p>
13253 The original text for proposed resolution 2 was modified so that it
13254 also forbids volatile types and reference types.
13255 </p>
13256
13257 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
13258 excluded from the PR.]</i></p>
13259
13260
13261
13262
13263
13264
13265
13266 <hr>
13267 <h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
13268 <p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13269  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
13270 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
13271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13272 <p><b>Discussion:</b></p>
13273 <p>
13274 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
13275 There are eight overloads, all of which are identical except for the
13276 last parameter.  The overloads are: 
13277 </p>
13278 <ul>
13279 <li> long&amp; </li>
13280 <li> unsigned short&amp; </li>
13281 <li> unsigned int&amp; </li>
13282 <li> unsigned long&amp; </li>
13283 <li> short&amp; </li>
13284 <li> double&amp; </li>
13285 <li> long double&amp; </li>
13286 <li> void*&amp; </li>
13287 </ul>
13288
13289 <p>
13290 There is a similar list, in 22.2.2.1.2, of overloads for
13291 num_get&lt;&gt;::do_get().  In this list, the last parameter has
13292 the types: 
13293 </p>
13294 <ul>
13295 <li> long&amp; </li>
13296 <li> unsigned short&amp; </li>
13297 <li> unsigned int&amp; </li>
13298 <li> unsigned long&amp; </li>
13299 <li> float&amp; </li>
13300 <li> double&amp; </li>
13301 <li> long double&amp; </li>
13302 <li> void*&amp; </li>
13303 </ul>
13304
13305 <p>
13306 These two lists are not identical.  They should be, since
13307 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
13308 the arguments it was given.
13309 </p>
13310
13311
13312 <p><b>Proposed resolution:</b></p>
13313 <p>In 22.4.2.1.1 [facet.num.get.members], change</p>
13314 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
13315                 ios_base::iostate&amp; err, short&amp; val) const;
13316 </pre>
13317 <p>to</p>
13318 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
13319                 ios_base::iostate&amp; err, float&amp; val) const;
13320 </pre>
13321
13322
13323
13324
13325 <hr>
13326 <h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
13327 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13328  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-11-07 <b>Last modified:</b> 2010-10-29</p>
13329 <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>
13330 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13331 <p><b>Discussion:</b></p>
13332 <p>
13333 23.1/3 states that the objects stored in a container must be
13334 Assignable.  23.6.1 [map], paragraph 2,
13335 states that map satisfies all requirements for a container, while in
13336 the same time defining value_type as pair&lt;const Key, T&gt; - a type
13337 that is not Assignable.
13338 </p>
13339
13340 <p>
13341 It should be noted that there exists a valid and non-contradictory
13342 interpretation of the current text. The wording in 23.1/3 avoids 
13343 mentioning value_type, referring instead to "objects stored in a
13344 container." One might argue that map does not store objects of
13345 type map::value_type, but of map::mapped_type instead, and that the
13346 Assignable requirement applies to map::mapped_type, not
13347 map::value_type.
13348 </p>
13349
13350 <p>
13351 However, this makes map a special case (other containers store objects of
13352 type value_type) and the Assignable requirement is needlessly restrictive in
13353 general.
13354 </p>
13355
13356 <p>
13357 For example, the proposed resolution of active library issue 
13358 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
13359 means that no set operations can exploit the fact that the stored
13360 objects are Assignable.
13361 </p>
13362
13363 <p>
13364 This is related to, but slightly broader than, closed issue
13365 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
13366 </p>
13367
13368
13369 <p><b>Proposed resolution:</b></p>
13370 <p>23.1/3: Strike the trailing part of the sentence:</p>
13371     <blockquote><p>
13372     , and the additional requirements of Assignable types from 23.1/3
13373     </p></blockquote>
13374 <p>so that it reads:</p>
13375     <blockquote><p>
13376     -3- The type of objects stored in these components must meet the 
13377     requirements of CopyConstructible types (lib.copyconstructible).
13378     </p></blockquote>
13379
13380 <p>23.1/4: Modify to make clear that this requirement is not for all 
13381 containers.  Change to:</p>
13382
13383 <blockquote><p>
13384 -4- Table 64 defines the Assignable requirement.  Some containers 
13385 require this property of the types to be stored in the container.  T is 
13386 the type used to instantiate the container. t is a value of T, and u is 
13387 a value of (possibly const) T.
13388 </p></blockquote>
13389
13390 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
13391 CopyConstructible".</p>
13392
13393 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
13394
13395 <blockquote><p>
13396 -2- A deque satisfies all of the requirements of a container and of a 
13397 reversible container (given in tables in lib.container.requirements) and 
13398 of a sequence, including the optional sequence requirements 
13399 (lib.sequence.reqmts).  In addition to the requirements on the stored 
13400 object described in 23.1[lib.container.requirements], the stored object 
13401 must also meet the requirements of Assignable.  Descriptions are 
13402 provided here only for operations on deque that are not described in one 
13403 of these tables or for operations where there is additional semantic 
13404 information.
13405 </p></blockquote>
13406
13407 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.  
13408 Change to:</p>
13409
13410 <blockquote>
13411 <p>-2- A list satisfies all of the requirements of a container and of a 
13412 reversible container (given in two tables in lib.container.requirements) 
13413 and of a sequence, including most of the the optional sequence 
13414 requirements (lib.sequence.reqmts). The exceptions are the operator[] 
13415 and at member functions, which are not provided. 
13416
13417 [Footnote: These member functions are only provided by containers whose 
13418 iterators are random access iterators. --- end foonote]
13419 </p>
13420
13421 <p>list does not require the stored type T to be Assignable unless the 
13422 following methods are instantiated:
13423
13424 [Footnote: Implementors are permitted but not required to take advantage 
13425 of T's Assignable properties for these methods. -- end foonote]
13426 </p>
13427 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
13428      template &lt;class InputIterator&gt;
13429        void assign(InputIterator first, InputIterator last);
13430      void assign(size_type n, const T&amp; t);
13431 </pre>
13432
13433
13434 <p>Descriptions are provided here only for operations on list that are not 
13435 described in one of these tables or for operations where there is 
13436 additional semantic information.</p>
13437 </blockquote>
13438
13439 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
13440
13441 <blockquote><p>
13442 -2- A vector satisfies all of the requirements of a container and of a 
13443 reversible container (given in two tables in lib.container.requirements) 
13444 and of a sequence, including most of the optional sequence requirements 
13445 (lib.sequence.reqmts). The exceptions are the push_front and pop_front 
13446 member functions, which are not provided.  In addition to the 
13447 requirements on the stored object described in 
13448 23.1[lib.container.requirements], the stored object must also meet the 
13449 requirements of Assignable.  Descriptions are provided here only for 
13450 operations on vector that are not described in one of these tables or 
13451 for operations where there is additional semantic information.
13452 </p></blockquote>
13453
13454
13455 <p><b>Rationale:</b></p>
13456 <p>list, set, multiset, map, multimap are able to store non-Assignables.
13457 However, there is some concern about <tt>list&lt;T&gt;</tt>:
13458 although in general there's no reason for T to be Assignable, some
13459 implementations of the member functions <tt>operator=</tt> and
13460 <tt>assign</tt> do rely on that requirement.  The LWG does not want
13461 to forbid such implementations.</p>
13462
13463 <p>Note that the type stored in a standard container must still satisfy
13464 the requirements of the container's allocator; this rules out, for
13465 example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
13466 for more details.
13467 </p>
13468
13469 <p>In principle we could also relax the "Assignable" requirement for
13470 individual <tt>vector</tt> member functions, such as
13471 <tt>push_back</tt>.  However, the LWG did not see great value in such
13472 selective relaxation.  Doing so would remove implementors' freedom to
13473 implement <tt>vector::push_back</tt> in terms of
13474 <tt>vector::insert</tt>.</p>
13475
13476
13477
13478
13479
13480 <hr>
13481 <h3><a name="278"></a>278. What does iterator validity mean?</h3>
13482 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13483  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2010-10-29</p>
13484 <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>
13485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13486 <p><b>Discussion:</b></p>
13487 <p>
13488 Section 23.3.4.4 [list.ops] states that
13489 </p>
13490 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
13491 </pre>
13492 <p>
13493 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
13494 </p>
13495
13496 <p>
13497 But what does the C++ Standard mean by "invalidate"?  You
13498 can still dereference the iterator to a spliced list element, but
13499 you'd better not use it to delimit a range within the original
13500 list. For the latter operation, it has definitely lost some of its
13501 validity.
13502 </p>
13503
13504 <p>
13505 If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
13506 then we'd better clarify that a "valid" iterator need no
13507 longer designate an element within the same container as it once did.
13508 We then have to clarify what we mean by invalidating a past-the-end
13509 iterator, as when a vector or string grows by reallocation. Clearly,
13510 such an iterator has a different kind of validity. Perhaps we should
13511 introduce separate terms for the two kinds of "validity."
13512 </p>
13513
13514
13515 <p><b>Proposed resolution:</b></p>
13516 <p>Add the following text to the end of section X [iterator.concepts],
13517 after paragraph 5:</p>
13518 <blockquote><p>
13519 An <i>invalid</i> iterator is an iterator that may be
13520 singular. [Footnote: This definition applies to pointers, since
13521 pointers are iterators. The effect of dereferencing an iterator that
13522 has been invalidated is undefined.]
13523 </p></blockquote>
13524
13525 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
13526
13527
13528 <p><i>[Redmond: General agreement with the intent, some objections to
13529 the wording.  Dave provided new wording.]</i></p>
13530
13531
13532
13533 <p><b>Rationale:</b></p>
13534 <p>This resolution simply defines a term that the Standard uses but
13535   never defines, "invalid", in terms of a term that is defined,
13536   "singular".</p>
13537
13538 <p>Why do we say "may be singular", instead of "is singular"?  That's
13539   becuase a valid iterator is one that is known to be nonsingular.
13540   Invalidating an iterator means changing it in such a way that it's
13541   no longer known to be nonsingular.  An example: inserting an
13542   element into the middle of a vector is correctly said to invalidate
13543   all iterators pointing into the vector.  That doesn't necessarily
13544   mean they all become singular.</p>
13545
13546
13547
13548
13549
13550 <hr>
13551 <h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
13552 <p><b>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13553  <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2010-10-29</p>
13554 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13555 <p><b>Discussion:</b></p>
13556 <p>
13557 This came from an email from Steve Cleary to Fergus in reference to
13558 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
13559 this in Toronto and believed it should be a separate issue.  There was
13560 also some reservations about whether this was a worthwhile problem to
13561 fix.
13562 </p>
13563
13564 <p>
13565 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
13566 (and should) be changed to preserve these additional
13567 requirements." He also said in email that it can be done without
13568 breaking user's code: "If you take a look at my suggested
13569 solution, reverse_iterator doesn't have to take two parameters; there
13570 is no danger of breaking existing code, except someone taking the
13571 address of one of the reverse_iterator global operator functions, and
13572 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
13573 case they have, you can leave the old global functions in as well --
13574 they won't interfere with the two-template-argument functions.  With
13575 that, I don't see how <i>any</i> user code could break."
13576 </p>
13577
13578
13579 <p><b>Proposed resolution:</b></p>
13580 <p>
13581 <b>Section:</b> 24.5.1.1 [reverse.iterator]
13582 add/change the following declarations:</p>
13583 <pre>  A) Add a templated assignment operator, after the same manner
13584         as the templated copy constructor, i.e.:
13585
13586   template &lt; class U &gt;
13587   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
13588
13589   B) Make all global functions (except the operator+) have
13590   two template parameters instead of one, that is, for
13591   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
13592
13593        template &lt; class Iterator &gt;
13594        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
13595                  const reverse_iterator&lt; Iterator &gt;&amp; x,
13596                  const reverse_iterator&lt; Iterator &gt;&amp; y);
13597
13598   with:
13599
13600       template &lt; class Iterator1, class Iterator2 &gt;
13601       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
13602                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
13603                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
13604 </pre>
13605 <p>
13606 Also make the addition/changes for these signatures in 
13607 24.5.1.3 [reverse.iter.ops].
13608 </p>
13609
13610 <p><i>[
13611 Copenhagen: The LWG is concerned that the proposed resolution 
13612 introduces new overloads.  Experience shows that introducing
13613 overloads is always risky, and that it would be inappropriate to
13614 make this change without implementation experience.  It may be
13615 desirable to provide this feature in a different way.
13616 ]</i></p>
13617
13618
13619 <p><i>[
13620 Lillehammer: We now have implementation experience, and agree that
13621 this solution is safe and correct.
13622 ]</i></p>
13623
13624
13625
13626
13627
13628
13629
13630 <hr>
13631 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
13632 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13633  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-02 <b>Last modified:</b> 2010-10-29</p>
13634 <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>
13635 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13636 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
13637 <p><b>Discussion:</b></p>
13638 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
13639 requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
13640 and <tt>CopyConstructible</tt> (20.2.1 [utility.arg.requirements]).
13641 Since the functions take and return their arguments and result by
13642 const reference, I believe the <tt>CopyConstructible</tt> requirement
13643 is unnecessary.
13644 </p>
13645
13646
13647 <p><b>Proposed resolution:</b></p>
13648 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
13649 25.3.7, p1 with</p>
13650 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt> 
13651 ( [lessthancomparable]).
13652 </p>
13653 <p>and replace 25.3.7, p4 with</p>
13654 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt> 
13655 ( [lessthancomparable]).
13656 </p>
13657
13658
13659
13660
13661 <hr>
13662 <h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
13663 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13664  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2000-12-05 <b>Last modified:</b> 2010-10-29</p>
13665 <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>
13666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13667 <p><b>Discussion:</b></p>
13668 <p>
13669 Paragraph 16 mistakenly singles out integral types for inserting 
13670 thousands_sep() characters.  This conflicts with the syntax for floating 
13671 point numbers described under 22.2.3.1/2.
13672 </p>
13673
13674
13675 <p><b>Proposed resolution:</b></p>
13676 <p>Change paragraph 16 from:</p>
13677
13678 <blockquote><p>
13679 For integral types, punct.thousands_sep() characters are inserted into 
13680 the sequence as determined by the value returned by punct.do_grouping() 
13681 using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
13682 </p></blockquote>
13683
13684 <p>To:</p>
13685
13686 <blockquote><p>
13687 For arithmetic types, punct.thousands_sep() characters are inserted into 
13688 the sequence as determined by the value returned by punct.do_grouping() 
13689 using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
13690 </p></blockquote>
13691
13692 <p><i>[
13693 Copenhagen: Opinions were divided about whether this is actually an
13694 inconsistency, but at best it seems to have been unintentional.  This
13695 is only an issue for floating-point output: The standard is
13696 unambiguous that implementations must parse thousands_sep characters
13697 when performing floating-point.  The standard is also unambiguous that
13698 this requirement does not apply to the "C" locale.
13699 ]</i></p>
13700
13701
13702 <p><i>[
13703 A survey of existing practice is needed; it is believed that some
13704 implementations do insert thousands_sep characters for floating-point
13705 output and others fail to insert thousands_sep characters for 
13706 floating-point input even though this is unambiguously required by the
13707 standard.
13708 ]</i></p>
13709
13710
13711 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
13712 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
13713
13714
13715
13716
13717
13718
13719 <hr>
13720 <h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
13721 <p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13722  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-15 <b>Last modified:</b> 2010-10-29</p>
13723 <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>
13724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13725 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
13726 <p><b>Discussion:</b></p>
13727 <p>
13728 (revision of the further discussion)
13729 There are a number of problems with the requires clauses for the
13730 algorithms in 25.1 and 25.2. The requires clause of each algorithm
13731 should describe the necessary and sufficient requirements on the inputs
13732 to the algorithm such that the algorithm compiles and runs properly.
13733 Many of the requires clauses fail to do this. Here is a summary of the kinds
13734 of mistakes:
13735 </p>
13736
13737 <ol>
13738 <li>
13739 Use of EqualityComparable, which only puts requirements on a single
13740 type, when in fact an equality operator is required between two
13741 different types, typically either T and the iterator's value type
13742 or between the value types of two different iterators.
13743 </li>
13744 <li>
13745 Use of Assignable for T when in fact what was needed is Assignable
13746 for the value_type of the iterator, and convertability from T to the
13747 value_type of the iterator. Or for output iterators, the requirement
13748 should be that T is writable to the iterator (output iterators do
13749 not have value types).
13750 </li>
13751 </ol>
13752
13753 <p>
13754 Here is the list of algorithms that contain mistakes:
13755 </p>
13756
13757 <ul>
13758 <li>25.1.2 std::find</li>
13759 <li>25.1.6 std::count</li>
13760 <li>25.1.8 std::equal</li>
13761 <li>25.1.9 std::search, std::search_n</li>
13762 <li>25.2.4 std::replace, std::replace_copy</li>
13763 <li>25.2.5 std::fill</li>
13764 <li>25.2.7 std::remove, std::remove_copy</li>
13765 </ul>
13766
13767 <p>
13768 Also, in the requirements for EqualityComparable, the requirement that
13769 the operator be defined for const objects is lacking.
13770 </p>
13771
13772
13773
13774 <p><b>Proposed resolution:</b></p>
13775
13776 <p>20.1.1 Change p1 from</p>
13777
13778 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
13779 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
13780 values of type <tt>T</tt>.
13781 </p>
13782
13783 <p>to</p>
13784
13785 <p>
13786 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
13787 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
13788 values of type <tt>const T</tt>.
13789 </p>
13790
13791 <p>25 Between p8 and p9</p>
13792
13793 <p>Add the following sentence:</p>
13794
13795 <p>When the description of an algorithm gives an expression such as
13796 <tt>*first == value</tt> for a condition, it is required that the expression
13797 evaluate to either true or false in boolean contexts.</p>
13798
13799 <p>25.1.2 Change p1 by deleting the requires clause.</p>
13800
13801 <p>25.1.6 Change p1 by deleting the requires clause.</p>
13802
13803 <p>25.1.9</p>
13804
13805 <p>Change p4 from</p>
13806
13807 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
13808 (20.1.1), type Size is convertible to integral type (4.7.12.3).
13809 </p>
13810
13811 <p>to</p>
13812
13813 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
13814 type (4.7.12.3).</p>
13815
13816 <p>25.2.4 Change p1 from</p>
13817
13818 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
13819
13820 <p>to</p>
13821
13822 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
13823
13824 <p>and change p4 from</p>
13825
13826 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
13827 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
13828 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
13829 (last - first))</tt> shall not overlap.</p>
13830
13831 <p>to</p>
13832
13833 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
13834 <tt>new_value</tt> must be writable to the result output iterator. The
13835 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
13836 first))</tt> shall not overlap.</p>
13837
13838
13839 <p>25.2.5 Change p1 from</p>
13840
13841 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
13842 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
13843
13844 <p>to</p>
13845
13846 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
13847 the output iterator. The type <tt>Size</tt> is convertible to an
13848 integral type (4.7.12.3).</p>
13849
13850 <p>25.2.7 Change p1 from</p>
13851
13852 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
13853
13854 <p>to</p>
13855
13856 <p>
13857 -1- Requires: The value type of the iterator must be
13858 <tt>Assignable</tt> (23.1).
13859 </p>
13860
13861
13862
13863 <p><b>Rationale:</b></p>
13864 <p>
13865 The general idea of the proposed solution is to remove the faulty
13866 requires clauses and let the returns and effects clauses speak for
13867 themselves. That is, the returns clauses contain expressions that must
13868 be valid, and therefore already imply the correct requirements. In
13869 addition, a sentence is added at the beginning of chapter 25 saying
13870 that expressions given as conditions must evaluate to true or false in
13871 a boolean context. An alternative would be to say that the type of
13872 these condition expressions must be literally bool, but that would be
13873 imposing a greater restriction that what the standard currently says
13874 (which is convertible to bool).
13875 </p>
13876
13877
13878
13879
13880
13881 <hr>
13882 <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
13883 <p><b>Section:</b> 20.8.6 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13884  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-26 <b>Last modified:</b> 2010-10-29</p>
13885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13886 <p><b>Discussion:</b></p>
13887 <p>The example in 20.8.6 [comparisons], p6 shows how to use the C
13888 library function <tt>strcmp()</tt> with the function pointer adapter
13889 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
13890 functions have <tt>extern "C"</tt> or <tt>extern
13891 "C++"</tt> linkage [17.6.2.3 [using.linkage]], and since
13892 function pointers with different the language linkage specifications
13893 (7.5 [dcl.link]) are incompatible, whether this example is
13894 well-formed is unspecified.
13895 </p>
13896
13897
13898 <p><b>Proposed resolution:</b></p>
13899 <p>Change 20.8.6 [comparisons] paragraph 6 from:</p>
13900 <blockquote>
13901   <p>[<i>Example:</i></p>
13902   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
13903   </pre>
13904   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
13905 </blockquote>
13906
13907
13908 <p>to:</p>
13909 <blockquote>
13910   <p>[<i>Example:</i></p>
13911   <pre>    int compare(const char*, const char*);
13912     replace_if(v.begin(), v.end(),
13913                not1(bind2nd(ptr_fun(compare), "abc")), "def");
13914   </pre>
13915   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
13916 </blockquote>
13917
13918 <p>Also, remove footnote 215 in that same paragraph.</p>
13919
13920 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
13921 issue deals in part with C and C++ linkage, it was believed to be too
13922 confusing for the strings in the example to be "C" and "C++".
13923 ]</i></p>
13924
13925
13926 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
13927 seems to make a sweeping normative requirement, even though footnotes
13928 aren't normative), and changed the sentence after the footnote so that
13929 it corresponds to the new code fragment.]</i></p>
13930
13931
13932
13933
13934
13935
13936 <hr>
13937 <h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
13938 <p><b>Section:</b> 27.9.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13939  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-31 <b>Last modified:</b> 2010-10-29</p>
13940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13941 <p><b>Discussion:</b></p>
13942 <p>27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and
13943 27.9.1.15 [fstream.cons], p2 say about the effects of each constructor:
13944 </p>
13945
13946 <p>... If that function returns a null pointer, calls
13947 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
13948 </p>
13949
13950 <p>The parenthetical note doesn't apply since the ctors cannot throw an
13951 exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3 
13952 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
13953 </p>
13954
13955
13956 <p><b>Proposed resolution:</b></p>
13957 <p>
13958 Strike the parenthetical note from the Effects clause in each of the
13959 paragraphs mentioned above.
13960 </p>
13961
13962
13963
13964
13965 <hr>
13966 <h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
13967 <p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13968  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
13969 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
13970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13971 <p><b>Discussion:</b></p>
13972 <p>
13973 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
13974 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
13975 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
13976 require the typedef size_t. Yet size_t is not listed in the
13977 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
13978 </p>
13979
13980
13981 <p><b>Proposed resolution:</b></p>
13982 <p>
13983 Add the type size_t to Table 78 (section 25.4) and add
13984 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
13985 </p>
13986
13987
13988 <p><b>Rationale:</b></p>
13989 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
13990
13991
13992
13993
13994
13995 <hr>
13996 <h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
13997 <p><b>Section:</b> 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13998  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
13999 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14000 <p><b>Discussion:</b></p>
14001 <p>
14002 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
14003 of macros defined in &lt;errno.h&gt; is adjusted to include a new
14004 macro, EILSEQ"
14005 </p>
14006
14007 <p>
14008 ISO/IEC 14882:1998(E) section 19.3 does not refer
14009 to the above amendment.
14010 </p>
14011
14012
14013
14014 <p><b>Proposed resolution:</b></p>
14015 <p>
14016 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
14017 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
14018 </p>
14019
14020
14021
14022
14023
14024 <hr>
14025 <h3><a name="291"></a>291. Underspecification of set algorithms</h3>
14026 <p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14027  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2010-10-29</p>
14028 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
14029 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14030 <p><b>Discussion:</b></p>
14031 <p>
14032 The standard library contains four algorithms that compute set
14033 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
14034 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
14035 of these algorithms takes two sorted ranges as inputs, and writes the
14036 output of the appropriate set operation to an output range.  The elements
14037 in the output range are sorted.
14038 </p>
14039
14040 <p>
14041 The ordinary mathematical definitions are generalized so that they
14042 apply to ranges containing multiple copies of a given element.  Two
14043 elements are considered to be "the same" if, according to an
14044 ordering relation provided by the user, neither one is less than the
14045 other.  So, for example, if one input range contains five copies of an
14046 element and another contains three, the output range of <tt>set_union</tt>
14047 will contain five copies, the output range of
14048 <tt>set_intersection</tt> will contain three, the output range of
14049 <tt>set_difference</tt> will contain two, and the output range of
14050 <tt>set_symmetric_difference</tt> will contain two.
14051 </p>
14052
14053 <p>
14054 Because two elements can be "the same" for the purposes
14055 of these set algorithms, without being identical in other respects
14056 (consider, for example, strings under case-insensitive comparison),
14057 this raises a number of unanswered questions:
14058 </p>
14059
14060 <ul>
14061 <li>If we're copying an element that's present in both of the
14062 input ranges, which one do we copy it from?</li>
14063 <li>If there are <i>n</i> copies of an element in the relevant
14064 input range, and the output range will contain fewer copies (say
14065 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
14066 <i>m</i>, or something else?</li>
14067 <li>Are these operations stable?  That is, does a run of equivalent
14068 elements appear in the output range in the same order as as it
14069 appeared in the input range(s)?</li>
14070 </ul>
14071
14072 <p>
14073 The standard should either answer these questions, or explicitly
14074 say that the answers are unspecified.  I prefer the former option,
14075 since, as far as I know, all existing implementations behave the
14076 same way.
14077 </p>
14078
14079
14080
14081 <p><b>Proposed resolution:</b></p>
14082
14083 <p>Add the following to the end of 25.4.5.2 [set.union] paragraph 5:</p>
14084 <blockquote><p>
14085 If [first1, last1) contains <i>m</i> elements that are equivalent to
14086 each other and [first2, last2) contains <i>n</i> elements that are
14087 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
14088 will be copied to the output range: all <i>m</i> of these elements
14089 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
14090 [first2, last2), in that order.
14091 </p></blockquote>
14092
14093 <p>Add the following to the end of 25.4.5.3 [set.intersection] paragraph 5:</p>
14094 <blockquote><p>
14095 If [first1, last1) contains <i>m</i> elements that are equivalent to each
14096 other and [first2, last2) contains <i>n</i> elements that are
14097 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those 
14098 elements from [first1, last1) are copied to the output range.
14099 </p></blockquote>
14100
14101 <p>Add a new paragraph, <b>Notes</b>, after 25.4.5.4 [set.difference]
14102 paragraph 4:</p>
14103 <blockquote><p>
14104 If [first1, last1) contains <i>m</i> elements that are equivalent to each
14105 other and [first2, last2) contains <i>n</i> elements that are
14106 equivalent to them, the last max(<i>m-n</i>, 0) elements from 
14107 [first1, last1) are copied to the output range.
14108 </p></blockquote>
14109
14110 <p>Add a new paragraph, <b>Notes</b>, after 25.4.5.5 [set.symmetric.difference]
14111 paragraph 4:</p>
14112 <blockquote><p>
14113 If [first1, last1) contains <i>m</i> elements that are equivalent to
14114 each other and [first2, last2) contains <i>n</i> elements that are
14115 equivalent to them, then |<i>m - n</i>| of those elements will be
14116 copied to the output range: the last <i>m - n</i> of these elements
14117 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
14118 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
14119 </p></blockquote>
14120
14121 <p><i>[Santa Cruz: it's believed that this language is clearer than
14122   what's in the Standard.  However, it's also believed that the
14123   Standard may already make these guarantees (although not quite in
14124   these words).  Bill and Howard will check and see whether they think
14125   that some or all of these changes may be redundant.  If so, we may
14126   close this issue as NAD.]</i></p>
14127
14128
14129
14130
14131 <p><b>Rationale:</b></p>
14132 <p>For simple cases, these descriptions are equivalent to what's
14133   already in the Standard.  For more complicated cases, they describe
14134   the behavior of existing implementations.</p>
14135
14136
14137
14138
14139
14140 <hr>
14141 <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
14142 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14143  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-05 <b>Last modified:</b> 2010-10-29</p>
14144 <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>
14145 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14146 <p><b>Discussion:</b></p>
14147 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
14148 27.4.4.2, p15 doesn't consider the case where the left-hand side
14149 argument is identical to the argument on the right-hand side, that is
14150 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
14151 is no need to copy any of the data members or call any callbacks
14152 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
14153 points out in message c++std-lib-8149 it appears to be incorrect to
14154 allow the object to fire <tt>erase_event</tt> followed by
14155 <tt>copyfmt_event</tt> since the callback handling the latter event
14156 may inadvertently attempt to access memory freed by the former.
14157 </p>
14158
14159
14160 <p><b>Proposed resolution:</b></p>
14161 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
14162
14163 <blockquote><p>
14164 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
14165 the corresponding member objects of <tt>rhs</tt>, except that...
14166 </p></blockquote>
14167
14168 <p>to</p>
14169
14170 <blockquote><p>
14171 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
14172 assigns to the member objects of <tt>*this</tt> the corresponding member
14173 objects of <tt>rhs</tt>, except that...
14174 </p></blockquote>
14175
14176
14177
14178
14179 <hr>
14180 <h3><a name="294"></a>294. User defined macros and standard headers</h3>
14181 <p><b>Section:</b> 17.6.3.3.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14182  <b>Submitter:</b> James Kanze <b>Opened:</b> 2001-01-11 <b>Last modified:</b> 2010-10-29</p>
14183 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#macro.names">issues</a> in [macro.names].</p>
14184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14185 <p><b>Discussion:</b></p>
14186 <p>Paragraph 2 of 17.6.3.3.1 [macro.names] reads: "A
14187 translation unit that includes a header shall not contain any macros
14188 that define names declared in that header." As I read this, it
14189 would mean that the following program is legal:</p>
14190
14191 <pre>  #define npos 3.14
14192   #include &lt;sstream&gt;
14193 </pre>
14194
14195 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
14196 in &lt;string&gt;, and it is hard to imagine an implementation in
14197 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
14198
14199 <p>I think that this phrase was probably formulated before it was
14200 decided that a standard header may freely include other standard
14201 headers.  The phrase would be perfectly appropriate for C, for
14202 example.  In light of 17.6.4.2 [res.on.headers] paragraph 1, however,
14203 it isn't stringent enough.</p>
14204
14205
14206 <p><b>Proposed resolution:</b></p>
14207 <p>For 17.6.3.3.1 [macro.names], replace the current wording, which reads:</p>
14208 <blockquote>
14209      <p>Each name defined as a macro in a header is reserved to the
14210      implementation for any use if the translation unit includes
14211      the header.168)</p>
14212
14213      <p>A translation unit that includes a header shall not contain any
14214      macros that define names declared or defined in that header. Nor shall
14215      such a translation unit define macros for names lexically
14216      identical to keywords.</p>
14217
14218      <p>168) It is not permissible to remove a library macro definition by
14219      using the #undef directive.</p>
14220 </blockquote>
14221
14222 <p>with the wording:</p>
14223
14224 <blockquote>
14225      <p>A translation unit that includes a standard library header shall not
14226      #define or #undef names declared in any standard library header.</p>
14227
14228      <p>A translation unit shall not #define or #undef names lexically
14229      identical to keywords.</p>
14230 </blockquote>
14231
14232 <p><i>[Lillehammer: Beman provided new wording]</i></p>
14233
14234
14235
14236
14237
14238
14239 <hr>
14240 <h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
14241 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14242  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2001-01-12 <b>Last modified:</b> 2010-10-29</p>
14243 <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>
14244 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14245 <p><b>Discussion:</b></p>
14246 <p>
14247 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
14248 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added 
14249 signatures present in &lt;cmath&gt;, does say that several overloads
14250 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
14251 </p>
14252
14253
14254 <p><b>Proposed resolution:</b></p>
14255 <p>
14256 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
14257 of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray],
14258 paragraph 1.
14259 </p>
14260
14261 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
14262 rid of that vestigial list of functions in paragraph 1.]</i></p>
14263
14264
14265
14266
14267 <p><b>Rationale:</b></p>
14268 <p>All this DR does is fix a typo; it's uncontroversial.  A 
14269 separate question is whether we're doing the right thing in 
14270 putting some overloads in &lt;cmath&gt; that we aren't also 
14271 putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
14272
14273
14274
14275
14276
14277 <hr>
14278 <h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
14279 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14280  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-14 <b>Last modified:</b> 2010-10-29</p>
14281 <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>
14282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14283 <p><b>Discussion:</b></p>
14284 <p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.3 [utility]
14285 lists the complete set of equality and relational operators for <tt>pair</tt>
14286 but the section describing the template and the operators only describes
14287 <tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
14288 any requirements on the template arguments. The remaining operators are
14289 not mentioned at all.
14290 </p>
14291
14292 <p><i>[
14293 2009-09-27 Alisdair reopens.
14294 ]</i></p>
14295
14296
14297 <blockquote>
14298 <p>
14299 The issue is a lack of wording specifying the semantics of <tt>std::pair</tt>
14300 relational operators.  The rationale is that this is covered by
14301 catch-all wording in the relops component, and that as relops directly
14302 precedes <tt>pair</tt> in the document this is an easy connection to make.
14303 </p>
14304
14305 <p>
14306 Reading the current working paper I make two observations:
14307 </p>
14308
14309 <ol type="i">
14310 <li>
14311 relops no longer immediately precedes <tt>pair</tt> in the order of
14312 specification.  However, even if it did, there is a lot of <tt>pair</tt>
14313 specification itself between the (apparently) unrelated relops and the
14314 relational operators for <tt>pair</tt>.  (The catch-all still requires
14315 <tt>operator==</tt> and <tt>operator&lt;</tt> to be specified
14316 explicitly)
14317 </li>
14318
14319 <li>
14320 No other library component relies on the catch-all clause. The following
14321 all explicitly document all six relational operators, usually in a
14322 manner that could have deferred to the relops clause.
14323 </li>
14324 </ol>
14325
14326 <blockquote><pre>tuple
14327 unique_ptr
14328 duration
14329 time_point
14330 basic_string
14331 queue
14332 stack
14333 move_iterator
14334 reverse_iterator 
14335 regex submatch
14336 thread::id
14337 </pre></blockquote>
14338
14339 <p>
14340 The container components provide their own (equivalent) definition in
14341 23.2.1 [container.requirements.general] Table 90 -- Container
14342 requirements and do so do not defer to relops.
14343 </p>
14344
14345 <p>
14346 <tt>Shared_ptr</tt> explicitly documents <tt>operator!=</tt> and does
14347 not supply the other 3 missing operators
14348 (<tt>&gt;</tt>,<tt>&gt;=</tt>,<tt>&lt;=</tt>) so does not meet the
14349 reqirements of the relops clause.
14350 </p>
14351
14352 <p>
14353 <tt>Weak_ptr</tt> only supports <tt>operator&lt;</tt> so would not be
14354 covered by relops.
14355 </p>
14356
14357 <p>
14358 At the very least I would request a note pointing to the relops clause
14359 we rely on to provide this definition.  If this route is taken, I would
14360 recommend reducing many of the above listed clauses to a similar note
14361 rather than providing redundant specification.
14362 </p>
14363
14364 <p>
14365 My preference would be to supply the 4 missing specifications consistent
14366 with the rest of the library.
14367 </p>
14368
14369 </blockquote>
14370
14371 <p><i>[
14372 2009-10-11 Daniel opens <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a> which deals with the same issue as
14373 it pertains to <tt>unique_ptr</tt>.
14374 ]</i></p>
14375
14376
14377 <p><i>[
14378 2009-10 Santa Cruz:
14379 ]</i></p>
14380
14381
14382 <blockquote>
14383 Move to Ready
14384 </blockquote>
14385
14386
14387
14388 <p><b>Proposed resolution:</b></p>
14389 <p>
14390 After p20 20.3.5 [pairs] add:
14391 </p>
14392
14393 <blockquote><pre>template &lt;class T1, class T2&gt;
14394 bool operator!=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
14395 </pre>
14396
14397 <blockquote>
14398 <i>Returns:</i> <tt>!(x==y)</tt>
14399 </blockquote>
14400
14401 <pre>template &lt;class T1, class T2&gt;
14402 bool operator&gt; (const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
14403 </pre>
14404
14405 <blockquote>
14406 <i>Returns:</i> <tt>y &lt; x</tt>
14407 </blockquote>
14408
14409 <pre>template &lt;class T1, class T2&gt;
14410 bool operator&gt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
14411 </pre>
14412
14413 <blockquote>
14414 <i>Returns:</i> <tt>!(x &lt; y)</tt>
14415 </blockquote>
14416
14417 <pre>template &lt;class T1, class T2&gt;
14418 bool operator&lt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
14419 </pre>
14420
14421 <blockquote>
14422 <i>Returns:</i> <tt>!(y &lt; x)</tt>
14423 </blockquote>
14424 </blockquote>
14425
14426
14427 <p><b>Rationale:</b></p>
14428 <p>20.3.1 [operators] paragraph 10 already specifies the semantics.
14429 That paragraph says that, if declarations of operator!=, operator&gt;,
14430 operator&lt;=, and operator&gt;= appear without definitions, they are
14431 defined as specified in 20.3.1 [operators].  There should be no user
14432 confusion, since that paragraph happens to immediately precede the
14433 specification of <tt>pair</tt>.</p>
14434
14435
14436
14437
14438
14439 <hr>
14440 <h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
14441 <p><b>Section:</b> 20.8.7 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14442  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-06 <b>Last modified:</b> 2010-10-29</p>
14443 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14444 <p><b>Discussion:</b></p>
14445 <p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
14446 <tt>const_mem_fun1_t</tt>
14447 in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
14448 <tt>binary_function&lt;T*,
14449 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
14450 <tt>first_argument_type</tt>
14451 members, respectively, are both defined to be <tt>T*</tt> (non-const).
14452 However, their function call member operator takes a <tt>const T*</tt>
14453 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
14454 T*</tt> instead, so that one can easily refer to it in generic code. The
14455 example below derived from existing code fails to compile due to the
14456 discrepancy:
14457 </p>
14458
14459 <p><tt>template &lt;class T&gt;</tt>
14460 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
14461 <br><tt>{</tt>
14462 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
14463 T::argument_type)
14464 const =&nbsp;&nbsp; // #2</tt>
14465 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
14466 <br><tt>}</tt>
14467 </p>
14468
14469 <p><tt>struct X { /* ... */ };</tt></p>
14470
14471 <p><tt>int main ()</tt>
14472 <br><tt>{</tt>
14473 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
14474 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
14475 &gt;(&amp;x);&nbsp;&nbsp;
14476 // #3</tt>
14477 <br><tt>}</tt>
14478 </p>
14479
14480 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
14481 <br>#2 the type of the pointer is incompatible with the type of the member
14482 function
14483 <br>#3 the address of a constant being passed to a function taking a non-const
14484 <tt>X*</tt>
14485 </p>
14486
14487
14488 <p><b>Proposed resolution:</b></p>
14489 <p>Replace the top portion of the definition of the class template
14490 const_mem_fun_t in 20.5.8, p8
14491 </p>
14492 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
14493 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14494 unary_function&lt;T*, S&gt; {</tt>
14495 </p>
14496 <p>with</p>
14497 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
14498 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14499 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
14500 </p>
14501 <p>Also replace the top portion of the definition of the class template
14502 const_mem_fun1_t in 20.5.8, p9</p>
14503 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
14504 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14505 binary_function&lt;T*, A, S&gt; {</tt>
14506 </p>
14507 <p>with</p>
14508 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
14509 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14510 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
14511 </p>
14512
14513
14514 <p><b>Rationale:</b></p>
14515 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
14516 and the argument type itself, are not the same.</p>
14517
14518
14519
14520
14521
14522 <hr>
14523 <h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
14524 <p><b>Section:</b> 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14525  <b>Submitter:</b> John A. Pedretti <b>Opened:</b> 2001-01-10 <b>Last modified:</b> 2010-10-29</p>
14526 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14527 <p><b>Discussion:</b></p>
14528 <p>
14529 The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
14530 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
14531 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
14532 correct in all cases. Since the specified <tt>operator new[]</tt> default
14533 behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
14534 replaced, along with <tt>operator delete</tt>, by the user, to implement their
14535 own memory management, the specified default behavior of<tt> operator
14536 delete[]</tt> must be to call <tt>operator delete</tt>.
14537 </p>
14538
14539
14540 <p><b>Proposed resolution:</b></p>
14541 <p>Change 18.5.1.2, p12 from</p>
14542 <blockquote><p>
14543 <b>-12-</b> <b>Default behavior:</b></p>
14544 <ul>
14545 <li>
14546 For a null value of <i><tt>ptr</tt></i> , does nothing.
14547 </li>
14548 <li>
14549 Any other value of <i><tt>ptr</tt></i> shall be a value returned
14550 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
14551 [Footnote: The value must not have been invalidated by an intervening
14552 call to <tt>operator delete[](void*)</tt> (17.6.3.9 [res.on.arguments]).
14553 --- end footnote]
14554 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
14555 allocated by the earlier call to the default <tt>operator new[]</tt>.
14556 </li>
14557 </ul>
14558 </blockquote>
14559
14560 <p>to</p>
14561
14562 <blockquote><p>
14563 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
14564 delete(</tt><i>ptr</i>)
14565 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
14566 </p></blockquote>
14567 <p>and expunge paragraph 13.</p>
14568
14569
14570
14571
14572 <hr>
14573 <h3><a name="300"></a>300. list::merge() specification incomplete</h3>
14574 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14575  <b>Submitter:</b> John Pedretti <b>Opened:</b> 2001-01-23 <b>Last modified:</b> 2010-10-29</p>
14576 <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>
14577 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14578 <p><b>Discussion:</b></p>
14579 <p>
14580 The "Effects" clause for list::merge() (23.3.4.4 [list.ops], p23)
14581 appears to be incomplete: it doesn't cover the case where the argument
14582 list is identical to *this (i.e., this == &amp;x). The requirement in the
14583 note in p24 (below) is that x be empty after the merge which is surely
14584 unintended in this case.
14585 </p>
14586
14587
14588 <p><b>Proposed resolution:</b></p>
14589 <p>In 23.3.4.4 [list.ops], replace paragraps 23-25 with:</p>
14590 <blockquote>
14591 <p>
14592 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
14593 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
14594 is a range in which the elements will be sorted in non-decreasing
14595 order according to the ordering defined by comp; that is, for every
14596 iterator i in the range other than the first, the condition comp(*i,
14597 *(i - 1)) will be false.
14598 </p>
14599
14600 <p>
14601 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
14602 two original ranges, the elements from the original range [begin(),
14603 end()) always precede the elements from the original range [x.begin(),
14604 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
14605 after the merge.
14606 </p>
14607
14608 <p>
14609 25 Complexity: At most size() + x.size() - 1 applications of comp if
14610 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
14611 an exception is thrown other than by a comparison there are no
14612 effects.
14613 </p>
14614
14615 </blockquote>
14616
14617 <p><i>[Copenhagen: The original proposed resolution did not fix all of
14618 the problems in 23.3.4.4 [list.ops], p22-25.  Three different
14619 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
14620 Changing p23, without changing the other two, appears to introduce
14621 contradictions.  Additionally, "merges the argument list into the
14622 list" is excessively vague.]</i></p>
14623
14624
14625 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
14626
14627
14628
14629
14630
14631
14632
14633 <hr>
14634 <h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
14635 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14636  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-27 <b>Last modified:</b> 2010-10-29</p>
14637 <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>
14638 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14639 <p><b>Discussion:</b></p>
14640 <p>
14641 The effects clause for the basic_string template ctor in 21.3.1, p15
14642 leaves out the third argument of type Allocator. I believe this to be
14643 a mistake.
14644 </p>
14645
14646
14647 <p><b>Proposed resolution:</b></p>
14648 <p>Replace</p>
14649
14650 <blockquote>
14651     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
14652     type, equivalent to</p>
14653
14654     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
14655     static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
14656 </blockquote>
14657
14658 <p>with</p>
14659
14660 <blockquote>
14661     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
14662     type, equivalent to</p>
14663
14664     <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
14665     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
14666 </blockquote>
14667
14668
14669
14670
14671 <hr>
14672 <h3><a name="303"></a>303. Bitset input operator underspecified</h3>
14673 <p><b>Section:</b> 20.5.4 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14674  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-02-05 <b>Last modified:</b> 2010-10-29</p>
14675 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14676 <p><b>Discussion:</b></p>
14677 <p>
14678 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
14679 "Extracts up to <i>N</i> (single-byte) characters from
14680 <i>is</i>.", where <i>is</i> is a stream of type
14681 <tt>basic_istream&lt;charT, traits&gt;</tt>.
14682 </p>
14683
14684 <p>
14685 The standard does not say what it means to extract single byte
14686 characters from a stream whose character type, <tt>charT</tt>, is in
14687 general not a single-byte character type.  Existing implementations
14688 differ.
14689 </p>
14690
14691 <p>
14692 A reasonable solution will probably involve <tt>widen()</tt> and/or
14693 <tt>narrow()</tt>, since they are the supplied mechanism for
14694 converting a single character between <tt>char</tt> and 
14695 arbitrary <tt>charT</tt>.
14696 </p>
14697
14698 <p>Narrowing the input characters is not the same as widening the
14699 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
14700 locales in which more than one wide character maps to the narrow
14701 character <tt>'0'</tt>.  Narrowing means that alternate
14702 representations may be used for bitset input, widening means that
14703 they may not be.</p>
14704
14705 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
14706 (22.2.2.1.2/8) compares input characters to widened version of narrow
14707 character literals.</p>
14708
14709 <p>From Pete Becker, in c++std-lib-8224:</p>
14710 <blockquote>
14711 <p>
14712 Different writing systems can have different representations for the
14713 digits that represent 0 and 1. For example, in the Unicode representation
14714 of the Devanagari script (used in many of the Indic languages) the digit 0
14715 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
14716 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
14717 0x0031 for for the Latin representations of '0' and '1', as well as code
14718 points for the same numeric values in several other scripts (Tamil has no
14719 character for 0, but does have the digits 1-9), and any of these values
14720 would also be narrowed to '0' and '1'.
14721 </p>
14722
14723 <p>...</p>
14724
14725 <p>
14726 It's fairly common to intermix both native and Latin
14727 representations of numbers in a document. So I think the rule has to be
14728 that if a wide character represents a digit whose value is 0 then the bit
14729 should be cleared; if it represents a digit whose value is 1 then the bit
14730 should be set; otherwise throw an exception. So in a Devanagari locale,
14731 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
14732 would set it. Widen can't do that. It would pick one of those two values,
14733 and exclude the other one.
14734 </p>
14735
14736 </blockquote>
14737
14738 <p>From Jens Maurer, in c++std-lib-8233:</p>
14739
14740 <blockquote>
14741 <p>
14742 Whatever we decide, I would find it most surprising if
14743 bitset conversion worked differently from int conversion
14744 with regard to alternate local representations of
14745 numbers.
14746 </p>
14747
14748 <p>Thus, I think the options are:</p>
14749 <ul>
14750  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
14751 require the use of narrow().</li>
14752
14753  <li> Have a defect issue for bitset() which describes clearly
14754 that widen() is to be used.</li>
14755 </ul>
14756 </blockquote>
14757
14758
14759
14760 <p><b>Proposed resolution:</b></p>
14761
14762     <p>Replace the first two sentences of paragraph 5 with:</p>
14763
14764     <blockquote><p>
14765     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
14766     characters in a temporary object <i>str</i> of type
14767     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
14768     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
14769     </p></blockquote>
14770
14771     <p>Replace the third bullet item in paragraph 5 with:</p>
14772     <ul><li>
14773     the next input character is neither <tt><i>is</i>.widen(0)</tt>
14774     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
14775     is not extracted).
14776     </li></ul>
14777
14778
14779
14780 <p><b>Rationale:</b></p>
14781 <p>Input for <tt>bitset</tt> should work the same way as numeric
14782 input.  Using <tt>widen</tt> does mean that alternative digit
14783 representations will not be recognized, but this was a known 
14784 consequence of the design choice.</p>
14785
14786
14787
14788
14789
14790 <hr>
14791 <h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
14792 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14793  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-01-24 <b>Last modified:</b> 2010-10-29</p>
14794 <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>
14795 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14796 <p><b>Discussion:</b></p>
14797 <p>22.2.1.5/3 introduces codecvt in part with:</p>
14798
14799 <blockquote><p>
14800   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
14801   character sets for tiny and wide characters. Instantiations on
14802   mbstate_t perform conversion between encodings known to the library
14803   implementor.
14804 </p></blockquote>
14805
14806 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
14807
14808 <blockquote><p>
14809   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and 
14810   (from_end-from).
14811 </p></blockquote>
14812
14813 <p>
14814 The semantics of do_in and do_length are linked.  What one does must
14815 be consistent with what the other does.  22.2.1.5/3 leads me to
14816 believe that the vendor is allowed to choose the algorithm that
14817 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
14818 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
14819 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
14820 return.  And thus indirectly specifies the algorithm that
14821 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
14822 that this is not what was intended and is a defect.
14823 </p>
14824
14825 <p>Discussion from the -lib reflector:
14826
14827 <br>This proposal would have the effect of making the semantics of
14828 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
14829 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
14830 do we want to mandate specific behavior for the base class virtuals
14831 and leave the implementation specified behavior for the codecvt_byname
14832 derived class?  The tradeoff is that former allows implementors to
14833 write a base class that actually does something useful, while the
14834 latter gives users a way to get known and specified---albeit
14835 useless---behavior, and is consistent with the way the standard
14836 handles other facets.  It is not clear what the original intention
14837 was.</p>
14838
14839 <p>
14840 Nathan has suggest a compromise: a character that is a widened version
14841 of the characters in the basic execution character set must be
14842 converted to a one-byte sequence, but there is no such requirement
14843 for characters that are not part of the basic execution character set.
14844 </p>
14845
14846
14847 <p><b>Proposed resolution:</b></p>
14848 <p>
14849 Change 22.2.1.5.2/5 from:
14850 </p>
14851 <p>
14852 The instantiations required in Table 51 (lib.locale.category), namely
14853 codecvt&lt;wchar_t,char,mbstate_t&gt; and
14854 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
14855 than (to_limit-to) destination elements. It always leaves the to_next
14856 pointer pointing one beyond the last element successfully stored.
14857 </p>
14858 <p>
14859 to:
14860 </p>
14861 <p>
14862 Stores no more than (to_limit-to) destination elements, and leaves the
14863 to_next pointer pointing one beyond the last element successfully
14864 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
14865 </p>
14866
14867 <p>Change 22.2.1.5.2/10 from:</p>
14868
14869 <blockquote><p>
14870 -10- Returns: (from_next-from) where from_next is the largest value in
14871 the range [from,from_end] such that the sequence of values in the
14872 range [from,from_next) represents max or fewer valid complete
14873 characters of type internT. The instantiations required in Table 51
14874 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
14875 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
14876 (from_end-from).
14877 </p></blockquote>
14878
14879 <p>to:</p>
14880
14881 <blockquote><p>
14882 -10- Returns: (from_next-from) where from_next is the largest value in 
14883 the range [from,from_end] such that the sequence of values in the range 
14884 [from,from_next) represents max or fewer valid complete characters of 
14885 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns 
14886 the lesser of max and (from_end-from). 
14887 </p></blockquote>
14888
14889 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
14890 above, but require that, in the default encoding, a character from the
14891 basic execution character set would map to a single external
14892 character.  The straw poll was 8-1 in favor of the proposed
14893 resolution.]</i></p>
14894
14895
14896
14897
14898 <p><b>Rationale:</b></p>
14899 <p>The default encoding should be whatever users of a given platform
14900 would expect to be the most natural.  This varies from platform to
14901 platform.  In many cases there is a preexisting C library, and users
14902 would expect the default encoding to be whatever C uses in the default
14903 "C" locale.  We could impose a guarantee like the one Nathan suggested
14904 (a character from the basic execution character set must map to a
14905 single external character), but this would rule out important
14906 encodings that are in common use: it would rule out JIS, for
14907 example, and it would rule out a fixed-width encoding of UCS-4.</p>
14908
14909 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
14910 "shift-JIS" changed to "JIS".]</i></p>
14911
14912
14913
14914
14915
14916
14917
14918 <hr>
14919 <h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
14920 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14921  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-02-21 <b>Last modified:</b> 2010-10-29</p>
14922 <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>
14923 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14924 <p><b>Discussion:</b></p> 
14925 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
14926
14927 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
14928 accepts a restricted set of <i>type</i> arguments in this
14929 International Standard. <i>type</i> shall be a POD structure or a POD
14930 union (clause 9). The result of applying the offsetof macro to a field
14931 that is a static data member or a function member is
14932 undefined."</p>
14933
14934 <p>For the POD requirement, it doesn't say "no diagnostic
14935 required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
14936 It's not clear whether this requirement was intended.  While it's
14937 possible to provide such a diagnostic, the extra complication doesn't
14938 seem to add any value.
14939 </p>
14940
14941
14942 <p><b>Proposed resolution:</b></p>
14943 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
14944 structure or a POD union the results are undefined."</p>
14945
14946 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
14947 agreed that requiring a diagnostic was inadvertent, but some LWG
14948 members thought that diagnostics should be required whenever
14949 possible.]</i></p>
14950
14951
14952
14953
14954
14955
14956 <hr>
14957 <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
14958 <p><b>Section:</b> 23.3.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14959  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-03-13 <b>Last modified:</b> 2010-10-29</p>
14960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14961 <p><b>Discussion:</b></p>
14962
14963 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
14964
14965 <p>
14966 The standard is currently inconsistent in 23.3.4.2 [list.capacity]
14967 paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1.
14968 23.2.3.3/1, for example, says:
14969 </p>
14970
14971 <blockquote><p>
14972 -1- Any sequence supporting operations back(), push_back() and pop_back() 
14973 can be used to instantiate stack. In particular, vector (lib.vector), list 
14974 (lib.list) and deque (lib.deque) can be used. 
14975 </p></blockquote>
14976
14977 <p>But this is false: vector&lt;bool&gt; can not be used, because the
14978 container adaptors return a T&amp; rather than using the underlying
14979 container's reference type.</p>
14980
14981 <p>This is a contradiction that can be fixed by:</p>
14982
14983 <ol>
14984 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
14985     is an exception.</li>
14986 <li>Removing the vector&lt;bool&gt; specialization.</li>
14987 <li>Changing the return types of stack and priority_queue to use 
14988     reference typedef's.</li>
14989 </ol>
14990
14991 <p>
14992 I propose 3.  This does not preclude option 2 if we choose to do it
14993 later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>); the issues are independent.  Option
14994 3 offers a small step towards support for proxied containers.  This
14995 small step fixes a current contradiction, is easy for vendors to
14996 implement, is already implemented in at least one popular lib, and
14997 does not break any code.
14998 </p>
14999
15000
15001
15002 <p><b>Proposed resolution:</b></p>
15003 <p>Summary: Add reference and const_reference typedefs to queue,
15004 priority_queue and stack.  Change return types of "value_type&amp;" to
15005 "reference".  Change return types of "const value_type&amp;" to
15006 "const_reference".  Details:</p>
15007
15008 <p>Change 23.2.3.1/1 from:</p>
15009
15010 <pre>  namespace std {
15011     template &lt;class T, class Container = deque&lt;T&gt; &gt;
15012     class queue {
15013     public:
15014       typedef typename Container::value_type            value_type;
15015       typedef typename Container::size_type             size_type;
15016       typedef          Container                        container_type;
15017     protected:
15018       Container c;
15019
15020     public:
15021       explicit queue(const Container&amp; = Container());
15022
15023       bool      empty() const             { return c.empty(); }
15024       size_type size()  const             { return c.size(); }
15025       value_type&amp;       front()           { return c.front(); }
15026       const value_type&amp; front() const     { return c.front(); }
15027       value_type&amp;       back()            { return c.back(); }
15028       const value_type&amp; back() const      { return c.back(); }
15029       void push(const value_type&amp; x)      { c.push_back(x); }
15030       void pop()                          { c.pop_front(); }
15031     };
15032 </pre>
15033
15034 <p>to:</p>
15035
15036 <pre>  namespace std {
15037     template &lt;class T, class Container = deque&lt;T&gt; &gt;
15038     class queue {
15039     public:
15040       typedef typename Container::value_type            value_type;
15041       typedef typename Container::reference             reference;
15042       typedef typename Container::const_reference       const_reference;
15043       typedef typename Container::value_type            value_type;
15044       typedef typename Container::size_type             size_type;
15045       typedef          Container                        container_type;
15046     protected:
15047       Container c;
15048
15049     public:
15050       explicit queue(const Container&amp; = Container());
15051
15052       bool      empty() const             { return c.empty(); }
15053       size_type size()  const             { return c.size(); }
15054       reference         front()           { return c.front(); }
15055       const_reference   front() const     { return c.front(); }
15056       reference         back()            { return c.back(); }
15057       const_reference   back() const      { return c.back(); }
15058       void push(const value_type&amp; x)      { c.push_back(x); }
15059       void pop()                          { c.pop_front(); }
15060     };
15061 </pre>
15062
15063 <p>Change 23.2.3.2/1 from:</p>
15064
15065 <pre>  namespace std {
15066     template &lt;class T, class Container = vector&lt;T&gt;,
15067               class Compare = less&lt;typename Container::value_type&gt; &gt;
15068     class priority_queue {
15069     public:
15070       typedef typename Container::value_type            value_type;
15071       typedef typename Container::size_type             size_type;
15072       typedef          Container                        container_type;
15073     protected:
15074       Container c;
15075       Compare comp;
15076
15077     public:
15078       explicit priority_queue(const Compare&amp; x = Compare(),
15079                               const Container&amp; = Container());
15080       template &lt;class InputIterator&gt;
15081         priority_queue(InputIterator first, InputIterator last,
15082                        const Compare&amp; x = Compare(),
15083                        const Container&amp; = Container());
15084
15085       bool      empty() const       { return c.empty(); }
15086       size_type size()  const       { return c.size(); }
15087       const value_type&amp; top() const { return c.front(); }
15088       void push(const value_type&amp; x);
15089       void pop();
15090     };
15091                                   //  no equality is provided
15092   }
15093 </pre>
15094
15095 <p>to:</p>
15096
15097 <pre>  namespace std {
15098     template &lt;class T, class Container = vector&lt;T&gt;,
15099               class Compare = less&lt;typename Container::value_type&gt; &gt;
15100     class priority_queue {
15101     public:
15102       typedef typename Container::value_type            value_type;
15103       typedef typename Container::reference             reference;
15104       typedef typename Container::const_reference       const_reference;
15105       typedef typename Container::size_type             size_type;
15106       typedef          Container                        container_type;
15107     protected:
15108       Container c;
15109       Compare comp;
15110
15111     public:
15112       explicit priority_queue(const Compare&amp; x = Compare(),
15113                               const Container&amp; = Container());
15114       template &lt;class InputIterator&gt;
15115         priority_queue(InputIterator first, InputIterator last,
15116                        const Compare&amp; x = Compare(),
15117                        const Container&amp; = Container());
15118
15119       bool      empty() const       { return c.empty(); }
15120       size_type size()  const       { return c.size(); }
15121       const_reference   top() const { return c.front(); }
15122       void push(const value_type&amp; x);
15123       void pop();
15124     };
15125                                   //  no equality is provided
15126   }
15127 </pre>
15128
15129 <p>And change 23.2.3.3/1 from:</p>
15130
15131 <pre>  namespace std {
15132     template &lt;class T, class Container = deque&lt;T&gt; &gt;
15133     class stack {
15134     public:
15135       typedef typename Container::value_type            value_type;
15136       typedef typename Container::size_type             size_type;
15137       typedef          Container                        container_type;
15138     protected:
15139       Container c;
15140
15141     public:
15142       explicit stack(const Container&amp; = Container());
15143
15144       bool      empty() const             { return c.empty(); }
15145       size_type size()  const             { return c.size(); }
15146       value_type&amp;       top()             { return c.back(); }
15147       const value_type&amp; top() const       { return c.back(); }
15148       void push(const value_type&amp; x)      { c.push_back(x); }
15149       void pop()                          { c.pop_back(); }
15150     };
15151
15152     template &lt;class T, class Container&gt;
15153       bool operator==(const stack&lt;T, Container&gt;&amp; x,
15154                       const stack&lt;T, Container&gt;&amp; y);
15155     template &lt;class T, class Container&gt;
15156       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
15157                       const stack&lt;T, Container&gt;&amp; y);
15158     template &lt;class T, class Container&gt;
15159       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
15160                       const stack&lt;T, Container&gt;&amp; y);
15161     template &lt;class T, class Container&gt;
15162       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
15163                       const stack&lt;T, Container&gt;&amp; y);
15164     template &lt;class T, class Container&gt;
15165       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
15166                       const stack&lt;T, Container&gt;&amp; y);
15167     template &lt;class T, class Container&gt;
15168       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
15169                       const stack&lt;T, Container&gt;&amp; y);
15170   }
15171 </pre>
15172
15173 <p>to:</p>
15174
15175 <pre>  namespace std {
15176     template &lt;class T, class Container = deque&lt;T&gt; &gt;
15177     class stack {
15178     public:
15179       typedef typename Container::value_type            value_type;
15180       typedef typename Container::reference             reference;
15181       typedef typename Container::const_reference       const_reference;
15182       typedef typename Container::size_type             size_type;
15183       typedef          Container                        container_type;
15184     protected:
15185       Container c;
15186
15187     public:
15188       explicit stack(const Container&amp; = Container());
15189
15190       bool      empty() const             { return c.empty(); }
15191       size_type size()  const             { return c.size(); }
15192       reference         top()             { return c.back(); }
15193       const_reference   top() const       { return c.back(); }
15194       void push(const value_type&amp; x)      { c.push_back(x); }
15195       void pop()                          { c.pop_back(); }
15196     };
15197
15198     template &lt;class T, class Container&gt;
15199       bool operator==(const stack&lt;T, Container&gt;&amp; x,
15200                       const stack&lt;T, Container&gt;&amp; y);
15201     template &lt;class T, class Container&gt;
15202       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
15203                       const stack&lt;T, Container&gt;&amp; y);
15204     template &lt;class T, class Container&gt;
15205       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
15206                       const stack&lt;T, Container&gt;&amp; y);
15207     template &lt;class T, class Container&gt;
15208       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
15209                       const stack&lt;T, Container&gt;&amp; y);
15210     template &lt;class T, class Container&gt;
15211       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
15212                       const stack&lt;T, Container&gt;&amp; y);
15213     template &lt;class T, class Container&gt;
15214       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
15215                       const stack&lt;T, Container&gt;&amp; y);
15216   }
15217 </pre>
15218
15219 <p><i>[Copenhagen: This change was discussed before the IS was released
15220 and it was deliberately not adopted.  Nevertheless, the LWG believes
15221 (straw poll: 10-2) that it is a genuine defect.]</i></p>
15222
15223
15224
15225
15226
15227
15228 <hr>
15229 <h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
15230 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15231  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-15 <b>Last modified:</b> 2010-10-29</p>
15232 <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>
15233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15234 <p><b>Discussion:</b></p>
15235 <p>
15236 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
15237 streams (27.8 [string.streams]) and the headers &lt;cstdio&gt; and
15238 &lt;cwchar&gt; for File streams (27.9 [file.streams]). It's not clear
15239 why these headers are mentioned in this context since they do not
15240 define any of the library entities described by the
15241 subclauses. According to 17.6.1.1 [contents], only such headers
15242 are to be listed in the summary.
15243 </p>
15244
15245
15246 <p><b>Proposed resolution:</b></p>
15247 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
15248 Table 82.</p>
15249
15250 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
15251 original proposed resolution also said to remove &lt;cstdio&gt; from
15252 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
15253 section 27.9 [file.streams], including 27.9.2 [c.files].]</i></p>
15254
15255
15256
15257
15258
15259
15260 <hr>
15261 <h3><a name="310"></a>310. Is errno a macro?</h3>
15262 <p><b>Section:</b> 17.6.1.2 [headers], 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15263  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2010-10-29</p>
15264 <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>
15265 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15266 <p><b>Discussion:</b></p>
15267   <p>
15268   Exactly how should errno be declared in a conforming C++ header?
15269   </p>
15270
15271   <p>
15272   The C standard says in 7.1.4 that it is unspecified whether errno is a
15273   macro or an identifier with external linkage.  In some implementations
15274   it can be either, depending on compile-time options.  (E.g., on
15275   Solaris in multi-threading mode, errno is a macro that expands to a
15276   function call, but is an extern int otherwise.  "Unspecified" allows
15277   such variability.)
15278   </p>
15279
15280   <p>The C++ standard:</p>
15281   <ul>
15282   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
15283   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 
15284       name (true), and implies that it is an identifier.</li>
15285   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
15286       on to say that the contents of of C++ &lt;errno.h&gt; are the
15287       same as in C, begging the question.</li>
15288   <li>C.2, table 95 lists errno as a macro, without comment.</li>
15289   </ul>
15290
15291   <p>I find no other references to errno.</p>
15292
15293   <p>We should either explicitly say that errno must be a macro, even
15294   though it need not be a macro in C, or else explicitly leave it
15295   unspecified.  We also need to say something about namespace std. 
15296   A user who includes &lt;cerrno&gt; needs to know whether to write
15297   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
15298   else &lt;cerrno&gt; is useless.</p>
15299
15300   <p>Two acceptable fixes:</p>
15301   <ul>
15302     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
15303         &nbsp;&nbsp;#define errno (::std::errno)<br>
15304         to the headers if errno is not already a macro. You then always
15305         write errno without any scope qualification, and it always expands
15306         to a correct reference. Since it is always a macro, you know to
15307         avoid using errno as a local identifer.</p></li>
15308     <li><p>errno is in the global namespace. This fix is inferior, because
15309         ::errno is not guaranteed to be well-formed.</p></li>
15310   </ul>
15311
15312   <p><i>[
15313     This issue was first raised in 1999, but it slipped through 
15314     the cracks.
15315   ]</i></p>
15316
15317
15318
15319 <p><b>Proposed resolution:</b></p>
15320   <p>Change the Note in section 17.4.1.2p5 from</p>
15321
15322     <blockquote><p>
15323     Note: the names defined as macros in C include the following:
15324     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
15325     </p></blockquote>
15326
15327   <p>to</p>
15328
15329     <blockquote><p>
15330     Note: the names defined as macros in C include the following:
15331     assert, offsetof, setjmp, va_arg, va_end, and va_start.
15332     </p></blockquote>
15333
15334   <p>In section 19.3, change paragraph 2 from</p>
15335
15336     <blockquote><p>
15337     The contents are the same as the Standard C library header
15338     &lt;errno.h&gt;.
15339     </p></blockquote>
15340
15341   <p>to</p>
15342
15343     <blockquote><p>
15344     The contents are the same as the Standard C library header 
15345     &lt;errno.h&gt;, except that errno shall be defined as a macro.
15346     </p></blockquote>
15347
15348
15349 <p><b>Rationale:</b></p>
15350 <p>C++ must not leave it up to the implementation to decide whether or
15351 not a name is a macro; it must explicitly specify exactly which names
15352 are required to be macros.  The only one that really works is for it
15353 to be a macro.</p>
15354
15355 <p><i>[Curaçao: additional rationale added.]</i></p>
15356
15357
15358
15359
15360
15361
15362
15363 <hr>
15364 <h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
15365 <p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15366  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2010-10-29</p>
15367 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
15368 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15369 <p><b>Discussion:</b></p>
15370
15371 <p>In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:</p>
15372
15373 <pre>  // partial specializationss
15374   template&lt;class traits&gt;
15375     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
15376                                             const char * );
15377 </pre>
15378
15379 <p>Problems:</p>
15380 <ul>
15381 <li>Too many 's's at the end of "specializationss" </li>
15382 <li>This is an overload, not a partial specialization</li>
15383 </ul>
15384
15385
15386
15387 <p><b>Proposed resolution:</b></p>
15388 <p>In the synopsis in 27.7.2.1 [ostream], remove the 
15389 <i>// partial specializationss</i> comment.  Also remove the same 
15390 comment (correctly spelled, but still incorrect) from the synopsis in 
15391 27.7.2.6.4 [ostream.inserters.character].
15392 </p>
15393
15394 <p><i>[
15395 Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's
15396 comment in c++std-lib-8939.
15397 ]</i></p>
15398
15399
15400
15401
15402
15403
15404
15405 <hr>
15406 <h3><a name="312"></a>312. Table 27 is missing headers</h3>
15407 <p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15408  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-29 <b>Last modified:</b> 2010-10-29</p>
15409 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
15410 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15411 <p><b>Discussion:</b></p>
15412 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
15413 Memory (lib.memory) but neglects to mention the headers
15414 &lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.7.6 [meta.rel].</p>
15415
15416
15417 <p><b>Proposed resolution:</b></p>
15418 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
15419 as &lt;memory&gt;.</p>
15420
15421
15422
15423
15424
15425 <hr>
15426 <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
15427 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15428  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-05-01 <b>Last modified:</b> 2010-10-29</p>
15429 <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>
15430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15431 <p><b>Discussion:</b></p>
15432 <p>
15433 23.3.4.4 [list.ops], Para 21 describes the complexity of
15434 list::unique as: "If the range (last - first) is not empty, exactly
15435 (last - first) -1 applications of the corresponding predicate,
15436 otherwise no applications of the predicate)".
15437 </p>
15438
15439 <p>
15440 "(last - first)" is not a range.
15441 </p>
15442
15443
15444 <p><b>Proposed resolution:</b></p>
15445 <p>
15446 Change the "range" from (last - first) to [first, last).
15447 </p>
15448
15449
15450
15451
15452 <hr>
15453 <h3><a name="316"></a>316. Vague text in Table 69</h3>
15454 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15455  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2010-10-29</p>
15456 <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>
15457 <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>
15458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15459 <p><b>Discussion:</b></p>
15460 <p>Table 69 says this about a_uniq.insert(t):</p>
15461
15462 <blockquote><p>
15463 inserts t if and only if there is no element in the container with key
15464 equivalent to the key of t. The bool component of the returned pair 
15465 indicates whether the insertion takes place and the iterator component of the
15466 pair points to the element with key equivalent to the key of t.
15467 </p></blockquote>
15468
15469 <p>The description should be more specific about exactly how the bool component
15470 indicates whether the insertion takes place.</p>
15471
15472
15473 <p><b>Proposed resolution:</b></p>
15474 <p>Change the text in question to</p>
15475
15476 <blockquote><p>
15477 ...The bool component of the returned pair is true if and only if the insertion
15478 takes place...
15479 </p></blockquote>
15480
15481
15482
15483
15484
15485 <hr>
15486 <h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
15487 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15488  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2010-10-29</p>
15489 <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>
15490 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15491 <p><b>Discussion:</b></p>
15492 <p>
15493 The localization section of the standard refers to specializations of
15494 the facet templates as instantiations even though the required facets
15495 are typically specialized rather than explicitly (or implicitly)
15496 instantiated. In the case of ctype&lt;char&gt; and
15497 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
15498 actually required to be specialized. The terminology should be
15499 corrected to make it clear that the standard doesn't mandate explicit
15500 instantiation (the term specialization encompasses both explicit
15501 instantiations and specializations).
15502 </p>
15503
15504
15505 <p><b>Proposed resolution:</b></p>
15506 <p>
15507 In the following paragraphs, replace all occurrences of the word
15508 instantiation or instantiations with specialization or specializations,
15509 respectively:
15510 </p>
15511
15512 <blockquote><p>
15513 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
15514 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
15515 22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
15516 Footnote 242.
15517 </p></blockquote>
15518
15519 <p>And change the text in 22.1.1.1.1, p4 from</p>
15520
15521 <blockquote><p>
15522     An implementation is required to provide those instantiations
15523     for facet templates identified as members of a category, and
15524     for those shown in Table 52:
15525 </p></blockquote>
15526
15527 <p>to</p>
15528
15529 <blockquote><p>
15530     An implementation is required to provide those specializations...
15531 </p></blockquote>
15532
15533 <p><i>[Nathan will review these changes, and will look for places where
15534 explicit specialization is necessary.]</i></p>
15535
15536
15537
15538
15539 <p><b>Rationale:</b></p>
15540 <p>This is a simple matter of outdated language.  The language to
15541 describe templates was clarified during the standardization process,
15542 but the wording in clause 22 was never updated to reflect that
15543 change.</p>
15544
15545
15546
15547
15548
15549
15550
15551 <hr>
15552 <h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
15553 <p><b>Section:</b> 22.4.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15554  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-12 <b>Last modified:</b> 2010-10-29</p>
15555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15556 <p><b>Discussion:</b></p>
15557 <p>The definition of the numpunct_byname template contains the following
15558 comment:</p>
15559
15560 <pre>    namespace std {
15561         template &lt;class charT&gt;
15562         class numpunct_byname : public numpunct&lt;charT&gt; {
15563     // this class is specialized for char and wchar_t.
15564         ...
15565 </pre>
15566
15567 <p>There is no documentation of the specializations and it seems
15568 conceivable that an implementation will not explicitly specialize the
15569 template at all, but simply provide the primary template.</p>
15570
15571
15572 <p><b>Proposed resolution:</b></p>
15573 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
15574 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
15575
15576
15577
15578
15579 <hr>
15580 <h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
15581 <p><b>Section:</b> 18.6.1.1 [new.delete.single], 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15582  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2001-05-15 <b>Last modified:</b> 2010-10-29</p>
15583 <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>
15584 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15585 <p><b>Discussion:</b></p>
15586 <p>The standard specifies 17.5.1.4 [structure.specifications] that "Required
15587 behavior" elements describe "the semantics of a function definition
15588 provided by either the implementation or a C++ program."</p>
15589
15590 <p>The standard specifies 17.5.1.4 [structure.specifications] that "Requires"
15591 elements describe "the preconditions for calling the function."</p>
15592
15593 <p>In the sections noted below, the current wording specifies
15594 "Required Behavior" for what are actually preconditions, and thus
15595 should be specified as "Requires".</p>
15596
15597
15598
15599 <p><b>Proposed resolution:</b></p>
15600
15601 <p>In 18.6.1.1 [new.delete.single] Para 12 Change:</p>
15602 <blockquote>
15603   <p>Required behavior: accept a value of ptr that is null or that was
15604   returned by an earlier call ...</p>
15605 </blockquote>
15606 <p>to:</p>
15607 <blockquote>
15608   <p>Requires: the value of ptr is null or the value returned by an
15609   earlier call ...</p>
15610 </blockquote>
15611
15612 <p>In 18.6.1.2 [new.delete.array] Para 11 Change:</p>
15613 <blockquote>
15614   <p>Required behavior: accept a value of ptr that is null or that was
15615   returned by an earlier call ...</p>
15616 </blockquote>
15617 <p>to:</p>
15618 <blockquote>
15619   <p>Requires: the value of ptr is null or the value returned by an
15620   earlier call ...</p>
15621 </blockquote>
15622
15623
15624
15625
15626
15627 <hr>
15628 <h3><a name="320"></a>320. list::assign overspecified</h3>
15629 <p><b>Section:</b> 23.3.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15630  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
15631 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
15632 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15633 <p><b>Discussion:</b></p>
15634 <p>
15635 Section 23.3.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
15636 the "effects" of a call to erase followed by a call to insert.
15637 </p>
15638
15639 <p>
15640 I would like to document that implementers have the freedom to implement 
15641 assign by other methods, as long as the end result is the same and the 
15642 exception guarantee is as good or better than the basic guarantee.
15643 </p>
15644
15645 <p>
15646 The motivation for this is to use T's assignment operator to recycle
15647 existing nodes in the list instead of erasing them and reallocating
15648 them with new values.  It is also worth noting that, with careful
15649 coding, most common cases of assign (everything but assignment with
15650 true input iterators) can elevate the exception safety to strong if
15651 T's assignment has a nothrow guarantee (with no extra memory cost).
15652 Metrowerks does this.  However I do not propose that this subtlety be
15653 standardized.  It is a QoI issue.  </p>
15654
15655 <p>Existing practise:
15656 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
15657 </p>
15658
15659
15660 <p><b>Proposed resolution:</b></p>
15661 <p>Change 23.3.4.1 [list.cons]/7 from:</p>
15662
15663 <blockquote>
15664 <p>Effects:</p>
15665
15666 <pre>   erase(begin(), end());
15667    insert(begin(), first, last);
15668 </pre>
15669 </blockquote>
15670
15671 <p>to:</p>
15672
15673 <blockquote>
15674 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
15675 </blockquote>
15676
15677 <p>In 23.2.3 [sequence.reqmts], in Table 67 (sequence requirements), 
15678 add two new rows:</p>
15679 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
15680                                   Replaces elements in a with a copy
15681                                   of [i, j).
15682
15683       a.assign(n,t)     void      pre: t is not a reference into a.
15684                                   Replaces elements in a with n copies
15685                                   of t.
15686 </pre>
15687
15688 <p>Change 23.3.4.1 [list.cons]/8 from:</p>
15689
15690 <blockquote>
15691 <p>Effects:</p>
15692 <pre>   erase(begin(), end());
15693    insert(begin(), n, t);
15694 </pre>
15695 </blockquote>
15696 <p>to:</p>
15697
15698 <blockquote>
15699 <p>Effects: Replaces the contents of the list with n copies of t.</p>
15700 </blockquote>
15701
15702 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
15703 version made explicit statement about exception safety, which wasn't
15704 consistent with the way exception safety is expressed elsewhere.
15705 Also, the change in the sequence requirements is new.  Without that
15706 change, the proposed resolution would have required that assignment of
15707 a subrange would have to work.  That too would have been
15708 overspecification; it would effectively mandate that assignment use a
15709 temporary.  Howard provided wording.
15710 ]</i></p>
15711
15712
15713 <p><i>[Curaçao: Made editorial improvement in wording; changed
15714 "Replaces elements in a with copies of elements in [i, j)."
15715 with "Replaces the elements of a with a copy of [i, j)."
15716 Changes not deemed serious enough to requre rereview.]</i></p>
15717
15718
15719
15720
15721
15722
15723
15724 <hr>
15725 <h3><a name="321"></a>321. Typo in num_get</h3>
15726 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15727  <b>Submitter:</b> Kevin Djang <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
15728 <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>
15729 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15730 <p><b>Discussion:</b></p>
15731 <p>
15732 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
15733 the conversion function, if needed, as indicated in Table 56."
15734 However, Table 56 uses the term "length modifier", not "length
15735 specifier".
15736 </p>
15737
15738
15739 <p><b>Proposed resolution:</b></p>
15740 <p>
15741 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
15742 to be "A length modifier is added ..."
15743 </p>
15744
15745
15746 <p><b>Rationale:</b></p>
15747 <p>C uses the term "length modifier".  We should be consistent.</p>
15748
15749
15750
15751
15752
15753
15754 <hr>
15755 <h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
15756 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15757  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
15758 <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>
15759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15760 <p><b>Discussion:</b></p>
15761 <p>
15762 It's widely assumed that, if X is a container,
15763 iterator_traits&lt;X::iterator&gt;::value_type and
15764 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
15765 X::value_type.  However, this is nowhere stated.  The language in
15766 Table 65 is not precise about the iterators' value types (it predates
15767 iterator_traits), and could even be interpreted as saying that
15768 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
15769 X::value_type".
15770 </p>
15771
15772 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
15773
15774
15775 <p><b>Proposed resolution:</b></p>
15776 <p>In Table 65 ("Container Requirements"), change the return type for
15777 X::iterator to "iterator type whose value type is T".  Change the
15778 return type for X::const_iterator to "constant iterator type whose
15779 value type is T".</p>
15780
15781
15782 <p><b>Rationale:</b></p>
15783 <p>
15784 This belongs as a container requirement, rather than an iterator
15785 requirement, because the whole notion of iterator/const_iterator
15786 pairs is specific to containers' iterator.
15787 </p>
15788 <p>
15789 It is existing practice that (for example) 
15790 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
15791 is "int", rather than "const int".  This is consistent with
15792 the way that const pointers are handled: the standard already 
15793 requires that iterator_traits&lt;const int*&gt;::value_type is int.
15794 </p>
15795
15796
15797
15798
15799
15800 <hr>
15801 <h3><a name="324"></a>324. Do output iterators have value types?</h3>
15802 <p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15803  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-07 <b>Last modified:</b> 2010-10-29</p>
15804 <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>
15805 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15806 <p><b>Discussion:</b></p>
15807
15808 <p>Table 73 suggests that output iterators have value types.  It 
15809 requires the expression "*a = t".  Additionally, although Table 73
15810 never lists "a = t" or "X(a) = t" in the "expressions" column, it
15811 contains a note saying that "a = t" and "X(a) = t" have equivalent
15812 (but nowhere specified!) semantics.</p>
15813
15814 <p>According to 24.1/9, t is supposed to be "a value of value type
15815 T":</p>
15816
15817     <blockquote><p>
15818     In the following sections, a and b denote values of X, n denotes a
15819     value of the difference type Distance, u, tmp, and m denote
15820     identifiers, r denotes a value of X&amp;, t denotes a value of
15821     value type T.
15822     </p></blockquote>
15823
15824 <p>Two other parts of the standard that are relevant to whether
15825 output iterators have value types:</p>
15826
15827 <ul>
15828     <li>24.1/1 says "All iterators i support the expression *i,
15829     resulting in a value of some class, enumeration, or built-in type
15830     T, called the value type of the iterator".</li>
15831
15832     <li>
15833     24.3.1/1, which says "In the case of an output iterator, the types
15834     iterator_traits&lt;Iterator&gt;::difference_type
15835     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
15836     </li>
15837 </ul>
15838
15839 <p>The first of these passages suggests that "*i" is supposed to
15840 return a useful value, which contradicts the note in 24.1.2/2 saying
15841 that the only valid use of "*i" for output iterators is in an
15842 expression of the form "*i = t".  The second of these passages appears
15843 to contradict Table 73, because it suggests that "*i"'s return value
15844 should be void.  The second passage is also broken in the case of a an
15845 iterator type, like non-const pointers, that satisfies both the output
15846 iterator requirements and the forward iterator requirements.</p>
15847
15848 <p>What should the standard say about <tt>*i</tt>'s return value when
15849 i is an output iterator, and what should it say about that t is in the
15850 expression "*i = t"?  Finally, should the standard say anything about
15851 output iterators' pointer and reference types?</p>
15852
15853
15854
15855 <p><b>Proposed resolution:</b></p>
15856 <p>24.1 p1, change</p>
15857
15858 <blockquote>
15859 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
15860 in a value of some class, enumeration, or built-in type <tt>T</tt>,
15861 called the value type of the iterator.</p>
15862 </blockquote>
15863
15864 <p>to</p>
15865
15866 <blockquote>
15867 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
15868 resulting in a value of some class, enumeration, or built-in type
15869 <tt>T</tt>, called the value type of the iterator. All output
15870 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
15871 value of some type that is in the set of types that are <i>writable</i> to
15872 the particular iterator type of <tt>i</tt>.
15873 </p>
15874 </blockquote>
15875
15876 <p>24.1 p9, add</p>
15877
15878 <blockquote>
15879 <p><tt>o</tt> denotes a value of some type that is writable to the
15880 output iterator.
15881 </p>
15882 </blockquote>
15883
15884 <p>Table 73, change</p>
15885
15886 <blockquote>
15887 <pre>*a = t
15888 </pre>
15889 </blockquote>
15890
15891 <p>to</p>
15892
15893 <blockquote>
15894 <pre>*r = o
15895 </pre>
15896 </blockquote>
15897
15898 <p>and change</p>
15899
15900 <blockquote>
15901 <pre>*r++ = t
15902 </pre>
15903 </blockquote>
15904
15905 <p>to</p>
15906
15907 <blockquote>
15908 <pre>*r++ = o
15909 </pre>
15910 </blockquote>
15911
15912 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
15913
15914
15915
15916
15917 <p><b>Rationale:</b></p>
15918 <p>The LWG considered two options: change all of the language that
15919 seems to imply that output iterators have value types, thus making it
15920 clear that output iterators have no value types, or else define value
15921 types for output iterator consistently.  The LWG chose the former
15922 option, because it seems clear that output iterators were never
15923 intended to have value types.  This was a deliberate design decision,
15924 and any language suggesting otherwise is simply a mistake.</p>
15925
15926 <p>A future revision of the standard may wish to revisit this design
15927 decision.</p>
15928
15929
15930
15931
15932
15933 <hr>
15934 <h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
15935 <p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15936  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-02 <b>Last modified:</b> 2010-10-29</p>
15937 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
15938 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15939 <p><b>Discussion:</b></p>
15940 <p>The Returns clause in 22.2.6.3.2, p3 says about
15941 moneypunct&lt;charT&gt;::do_grouping()
15942 </p>
15943
15944 <blockquote><p>
15945     Returns: A pattern defined identically as the result of
15946     numpunct&lt;charT&gt;::do_grouping().241)
15947 </p></blockquote>
15948
15949 <p>Footnote 241 then reads</p>
15950
15951 <blockquote><p>
15952     This is most commonly the value "\003" (not "3").
15953 </p></blockquote>
15954
15955 <p>
15956 The returns clause seems to imply that the two member functions must
15957 return an identical value which in reality may or may not be true,
15958 since the facets are usually implemented in terms of struct std::lconv
15959 and return the value of the grouping and mon_grouping, respectively.
15960 The footnote also implies that the member function of the moneypunct
15961 facet (rather than the overridden virtual functions in moneypunct_byname)
15962 most commonly return "\003", which contradicts the C standard which
15963 specifies the value of "" for the (most common) C locale.
15964 </p>
15965
15966
15967
15968 <p><b>Proposed resolution:</b></p>
15969 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
15970
15971 <blockquote><p>
15972     Returns: A pattern defined identically as, but not necessarily
15973     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
15974 </p></blockquote>
15975
15976 <p>and replace the text in Footnote 241 with the following:</p>
15977
15978 <blockquote><p>
15979     To specify grouping by 3s the value is "\003", not "3".
15980 </p></blockquote>
15981
15982
15983 <p><b>Rationale:</b></p>
15984 <p>
15985 The fundamental problem is that the description of the locale facet
15986 virtuals serves two purposes: describing the behavior of the base
15987 class, and describing the meaning of and constraints on the behavior
15988 in arbitrary derived classes.  The new wording makes that separation a
15989 little bit clearer.  The footnote (which is nonnormative) is not
15990 supposed to say what the grouping is in the "C" locale or in any other
15991 locale. It is just a reminder that the values are interpreted as small
15992 integers, not ASCII characters.
15993 </p>
15994
15995
15996
15997
15998 <hr>
15999 <h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
16000 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16001  <b>Submitter:</b> Tiki Wan <b>Opened:</b> 2001-07-06 <b>Last modified:</b> 2010-10-29</p>
16002 <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>
16003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16004 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
16005 <p><b>Discussion:</b></p>
16006 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
16007 <tt>time_get_byname</tt> are listed incorrectly in table 52,
16008 required instantiations.  In both cases the second template
16009 parameter is given as OutputIterator.  It should instead be
16010 InputIterator, since these are input facets.</p>
16011
16012
16013 <p><b>Proposed resolution:</b></p>
16014 <p>
16015 In table 52, required instantiations, in 
16016 22.3.1.1.1 [locale.category], change</p>
16017 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
16018     time_get_byname&lt;wchar_t, OutputIterator&gt;
16019 </pre>
16020 <p>to</p>
16021 <pre>    time_get&lt;wchar_t, InputIterator&gt;
16022     time_get_byname&lt;wchar_t, InputIterator&gt;
16023 </pre>
16024
16025 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
16026 a typo, wchart instead of wchar_t.]</i></p>
16027
16028
16029
16030
16031
16032
16033 <hr>
16034 <h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
16035 <p><b>Section:</b> 22.4.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16036  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-07 <b>Last modified:</b> 2010-10-29</p>
16037 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16038 <p><b>Discussion:</b></p>
16039 <p>The sprintf format string , "%.01f" (that's the digit one), in the
16040 description of the do_put() member functions of the money_put facet in
16041 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
16042 for values of type long double, and second, the precision of 01
16043 doesn't seem to make sense. What was most likely intended was
16044 "%.0Lf"., that is a precision of zero followed by the L length
16045 modifier.</p>
16046
16047
16048 <p><b>Proposed resolution:</b></p>
16049 <p>Change the format string to "%.0Lf".</p>
16050
16051
16052 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16053
16054
16055
16056
16057 <hr>
16058 <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
16059 <p><b>Section:</b> 23.4.1.2 [vector.capacity], 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16060  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-07-13 <b>Last modified:</b> 2010-10-29</p>
16061 <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>
16062 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16063 <p><b>Discussion:</b></p>
16064 <p>
16065 There is an apparent contradiction about which circumstances can cause
16066 a reallocation of a vector in Section 23.4.1.2 [vector.capacity] and
16067 section 23.4.1.4 [vector.modifiers].
16068 </p>
16069
16070 <p>23.4.1.2 [vector.capacity],p5 says:</p>
16071 <blockquote><p>
16072 Notes: Reallocation invalidates all the references, pointers, and iterators
16073 referring to the elements in the sequence. It is guaranteed that no
16074 reallocation takes place during insertions that happen after a call to
16075 reserve() until the time when an insertion would make the size of the vector
16076 greater than the size specified in the most recent call to reserve().
16077 </p></blockquote>
16078
16079 <p>Which implies if I do</p>
16080
16081 <pre>  std::vector&lt;int&gt; vec;
16082   vec.reserve(23);
16083   vec.reserve(0);
16084   vec.insert(vec.end(),1);
16085 </pre>
16086
16087 <p>then the implementation may reallocate the vector for the insert,
16088 as the size specified in the previous call to reserve was zero.</p>
16089
16090 <p>However, the previous paragraphs (23.4.1.2 [vector.capacity], p1-2) state:</p>
16091 <blockquote>
16092 <p>
16093 (capacity) Returns: The total number of elements the vector
16094 can hold without requiring reallocation
16095 </p>
16096 <p>
16097 ...After reserve(), capacity() is greater or equal to the
16098 argument of reserve if reallocation happens; and equal to the previous value
16099 of capacity() otherwise...
16100 </p>
16101 </blockquote>
16102
16103 <p>
16104 This implies that vec.capacity() is still 23, and so the insert()
16105 should not require a reallocation, as vec.size() is 0. This is backed
16106 up by 23.4.1.4 [vector.modifiers], p1:
16107 </p>
16108 <blockquote><p>
16109 (insert) Notes: Causes reallocation if the new size is greater than the old
16110 capacity.
16111 </p></blockquote>
16112
16113 <p>
16114 Though this doesn't rule out reallocation if the new size is less
16115 than the old capacity, I think the intent is clear.
16116 </p>
16117
16118
16119
16120 <p><b>Proposed resolution:</b></p>
16121 <p>Change the wording of 23.4.1.2 [vector.capacity] paragraph 5 to:</p>
16122
16123 <blockquote><p>
16124 Notes: Reallocation invalidates all the references, pointers, and
16125 iterators referring to the elements in the sequence. It is guaranteed
16126 that no reallocation takes place during insertions that happen after a
16127 call to reserve() until the time when an insertion would make the size
16128 of the vector greater than the value of capacity().
16129 </p></blockquote>
16130
16131 <p><i>[Redmond: original proposed resolution was modified slightly.  In
16132 the original, the guarantee was that there would be no reallocation
16133 until the size would be greater than the value of capacity() after the
16134 most recent call to reserve().  The LWG did not believe that the
16135 "after the most recent call to reserve()" added any useful
16136 information.]</i></p>
16137
16138
16139
16140
16141 <p><b>Rationale:</b></p>
16142 <p>There was general agreement that, when reserve() is called twice in
16143 succession and the argument to the second invocation is smaller than
16144 the argument to the first, the intent was for the second invocation to
16145 have no effect.  Wording implying that such cases have an effect on
16146 reallocation guarantees was inadvertant.</p>
16147
16148
16149
16150
16151
16152 <hr>
16153 <h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
16154 <p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16155  <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-23 <b>Last modified:</b> 2010-10-29</p>
16156 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
16157 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16158 <p><b>Discussion:</b></p>
16159 <p>
16160 With the change in 17.6.4.12 [res.on.exception.handling] to state
16161    "An implementation may strengthen the exception-specification for a 
16162     non-virtual function by removing listed exceptions."
16163 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
16164 and the following declaration of ~failure() in ios_base::failure
16165 </p>
16166 <pre>    namespace std {
16167        class ios_base::failure : public exception {
16168        public:
16169            ...
16170            virtual ~failure();
16171            ...
16172        };
16173      }
16174 </pre>
16175 <p>the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty
16176 exception specification:</p>
16177 <pre>    namespace std {
16178        class exception {
16179        public:
16180          ...
16181          virtual ~exception() throw();
16182          ...
16183        };
16184      }
16185 </pre>
16186
16187
16188 <p><b>Proposed resolution:</b></p>
16189 <p>Remove the declaration of ~failure().</p>
16190
16191
16192 <p><b>Rationale:</b></p>
16193 <p>The proposed resolution is consistent with the way that destructors
16194 of other classes derived from <tt>exception</tt> are handled.</p>
16195
16196
16197
16198
16199
16200
16201
16202 <hr>
16203 <h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
16204 <p><b>Section:</b> 27.7.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16205  <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2010-10-29</p>
16206 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16207 <p><b>Discussion:</b></p>
16208 <p>A footnote in 27.7.2.8 [ostream.manip] states:</p>
16209 <blockquote><p>
16210     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a 
16211      newline character in the output sequence controlled by cout, then 
16212      synchronize it with any external file with which it might be 
16213      associated. --- end foonote]
16214 </p></blockquote>
16215
16216 <p>
16217 Does the term "file" here refer to the external device?
16218 This leads to some implementation ambiguity on systems with fully 
16219 buffered files where a newline does not cause a flush to the device.
16220 </p>
16221
16222 <p>
16223 Choosing to sync with the device leads to significant performance
16224 penalties for each call to endl, while not sync-ing leads to
16225 errors under special circumstances.
16226 </p>
16227
16228 <p>
16229 I could not find any other statement that explicitly defined
16230 the behavior one way or the other.
16231 </p>
16232
16233
16234 <p><b>Proposed resolution:</b></p>
16235 <p>Remove footnote 300 from section 27.7.2.8 [ostream.manip].</p>
16236
16237
16238 <p><b>Rationale:</b></p>
16239 <p>We already have normative text saying what <tt>endl</tt> does: it
16240 inserts a newline character and calls <tt>flush</tt>.  This footnote
16241 is at best redundant, at worst (as this issue says) misleading,
16242 because it appears to make promises about what <tt>flush</tt>
16243 does.</p>
16244
16245
16246
16247
16248
16249
16250
16251 <hr>
16252 <h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
16253 <p><b>Section:</b> 23.6.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16254  <b>Submitter:</b> Andrea Griffini <b>Opened:</b> 2001-09-02 <b>Last modified:</b> 2010-10-29</p>
16255 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
16256 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16257 <p><b>Discussion:</b></p>
16258 <p>
16259 The current standard describes map::operator[] using a
16260 code example. That code example is however quite
16261 inefficient because it requires several useless copies
16262 of both the passed key_type value and of default
16263 constructed mapped_type instances.
16264 My opinion is that was not meant by the comitee to
16265 require all those temporary copies. 
16266 </p>
16267
16268 <p>Currently map::operator[] behaviour is specified as: </p>
16269 <pre>  Returns:
16270     (*((insert(make_pair(x, T()))).first)).second.
16271 </pre>
16272   
16273 <p>
16274 This specification however uses make_pair that is a
16275 template function of which parameters in this case
16276 will be deduced being of type const key_type&amp; and
16277 const T&amp;. This will create a pair&lt;key_type,T&gt; that
16278 isn't the correct type expected by map::insert so
16279 another copy will be required using the template
16280 conversion constructor available in pair to build
16281 the required pair&lt;const key_type,T&gt; instance.
16282 </p>
16283
16284 <p>If we consider calling of key_type copy constructor
16285 and mapped_type default constructor and copy
16286 constructor as observable behaviour (as I think we
16287 should) then the standard is in this place requiring
16288 two copies of a key_type element plus a default
16289 construction and two copy construction of a mapped_type
16290 (supposing the addressed element is already present
16291 in the map; otherwise at least another copy
16292 construction for each type). 
16293 </p>
16294
16295 <p>A simple (half) solution would be replacing the description with:</p>
16296 <pre>  Returns:
16297     (*((insert(value_type(x, T()))).first)).second.
16298 </pre>
16299
16300 <p>This will remove the wrong typed pair construction that
16301 requires one extra copy of both key and value.</p>
16302
16303 <p>However still the using of map::insert requires temporary
16304 objects while the operation, from a logical point of view,
16305 doesn't require any. </p>
16306
16307 <p>I think that a better solution would be leaving free an
16308 implementer to use a different approach than map::insert
16309 that, because of its interface, forces default constructed
16310 temporaries and copies in this case.
16311 The best solution in my opinion would be just requiring
16312 map::operator[] to return a reference to the mapped_type
16313 part of the contained element creating a default element
16314 with the specified key if no such an element is already
16315 present in the container. Also a logarithmic complexity
16316 requirement should be specified for the operation.
16317 </p>
16318
16319 <p>
16320 This would allow library implementers to write alternative
16321 implementations not using map::insert and reaching optimal
16322 performance in both cases of the addressed element being
16323 present or absent from the map (no temporaries at all and
16324 just the creation of a new pair inside the container if
16325 the element isn't present).
16326 Some implementer has already taken this option but I think
16327 that the current wording of the standard rules that as
16328 non-conforming. 
16329 </p>
16330
16331
16332
16333 <p><b>Proposed resolution:</b></p>
16334
16335 <p>
16336 Replace 23.6.1.2 [map.access] paragraph 1 with
16337 </p>
16338 <blockquote>
16339 <p>
16340 -1- Effects:  If there is no key equivalent to x in the map, inserts 
16341 value_type(x, T()) into the map.
16342 </p>
16343 <p>
16344 -2- Returns: A reference to the mapped_type corresponding to x in *this.
16345 </p>
16346 <p>
16347 -3- Complexity: logarithmic.
16348 </p>
16349 </blockquote>
16350
16351 <p><i>[This is the second option mentioned above.  Howard provided
16352 wording.  We may also wish to have a blanket statement somewhere in
16353 clause 17 saying that we do not intend the semantics of sample code
16354 fragments to be interpreted as specifing exactly how many copies are
16355 made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
16356
16357
16358
16359
16360 <p><b>Rationale:</b></p>
16361 <p>
16362 This is the second solution described above; as noted, it is
16363 consistent with existing practice.
16364 </p>
16365
16366 <p>Note that we now need to specify the complexity explicitly, because
16367 we are no longer defining <tt>operator[]</tt> in terms of
16368 <tt>insert</tt>.</p>
16369
16370
16371
16372
16373
16374 <hr>
16375 <h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
16376 <p><b>Section:</b> 21.2.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16377  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-09-06 <b>Last modified:</b> 2010-10-29</p>
16378 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16379 <p><b>Discussion:</b></p>
16380 <p>
16381 Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
16382 as:
16383 </p>
16384 <pre>  X::assign(c,d)   assigns c = d.
16385 </pre>
16386
16387 <p>And para 1 says:</p>
16388
16389 <blockquote><p>
16390  [...] c and d denote values of type CharT [...]
16391 </p></blockquote>
16392
16393 <p>
16394 Naturally, if c and d are <i>values</i>, then the assignment is
16395 (effectively) meaningless. It's clearly intended that (in the case of
16396 assign, at least), 'c' is intended to be a reference type.
16397 </p>
16398
16399 <p>I did a quick survey of the four implementations I happened to have
16400 lying around, and sure enough they all have signatures:</p>
16401 <pre>    assign( charT&amp;, const charT&amp; );
16402 </pre>
16403
16404 <p>(or the equivalent). It's also described this way in Nico's book.
16405 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
16406 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
16407 </p>
16408
16409
16410 <p><b>Proposed resolution:</b></p>
16411 <p>Add the following to 21.1.1 para 1:</p>
16412 <blockquote><p>
16413  r denotes an lvalue of CharT
16414 </p></blockquote>
16415
16416 <p>and change the description of assign in the table to:</p>
16417 <pre>  X::assign(r,d)   assigns r = d
16418 </pre>
16419
16420
16421
16422
16423
16424 <hr>
16425 <h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
16426 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16427  <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-05 <b>Last modified:</b> 2010-10-29</p>
16428 <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>
16429 <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>
16430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16431 <p><b>Discussion:</b></p>
16432 <p>From c++std-edit-873:</p>
16433
16434 <p>17.6.1.2 [headers], Table 11.  In this table, the header
16435 &lt;strstream&gt; is missing.</p>
16436
16437 <p>This shows a general problem: The whole clause 17 refers quite
16438 often to clauses 18 through 27, but D.7 is also a part of the standard
16439 library (though a deprecated one).</p>
16440
16441
16442
16443 <p><b>Proposed resolution:</b></p>
16444
16445 <p>To 17.6.1.2 [headers] Table 11, C++ Library Headers, add
16446 "&lt;strstream&gt;".</p>
16447
16448 <p>In the following places, change "clauses 17 through 27" to "clauses
16449 17 through 27 and Annex D":</p>
16450
16451 <ul>
16452 <li>1.2 [intro.refs] Normative references/1/footnote 1</li>
16453 <li>1.3 [intro.defs] Definitions/1</li>
16454 <li>7 [dcl.dcl] Library introduction/9</li>
16455 <li>17.5 [description] Method of description (Informative)/1</li>
16456 <li>17.5.2.1.4 [character.seq] Character sequences/1/bullet 2</li>
16457 <li>17.5.2.2 [functions.within.classes] Functions within classes/1</li>
16458 <li>17.5.2.3 [objects.within.classes] Private members/1/(2 places)</li>
16459 <li>17.6 [requirements] Library-wide requirements/1</li>
16460 <li>17.6.1.2 [headers] Headers/4</li>
16461 <li>17.6.3.6 [replacement.functions] Replacement functions/1</li>
16462 <li>17.6.4.4 [global.functions] Global or non-member functions/2</li>
16463 <li>17.6.4.10 [protection.within.classes] Protection within classes/1</li>
16464 </ul>
16465
16466
16467
16468
16469
16470
16471
16472 <hr>
16473 <h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
16474 <p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16475  <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-07 <b>Last modified:</b> 2010-10-29</p>
16476 <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>
16477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16478 <p><b>Discussion:</b></p>
16479 <p>From c++std-edit-876:</p>
16480
16481 <p>
16482 In section 25.3.5 [alg.replace] before p4: The name of the first
16483 parameter of template replace_copy_if should be "InputIterator"
16484 instead of "Iterator".  According to 17.5.2.1 [type.descriptions] p1 the
16485 parameter name conveys real normative meaning.
16486 </p>
16487
16488
16489 <p><b>Proposed resolution:</b></p>
16490 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
16491
16492
16493
16494
16495
16496 <hr>
16497 <h3><a name="338"></a>338.  is whitespace allowed between `-' and a digit?</h3>
16498 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16499  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2010-10-29</p>
16500 <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>
16501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16502 <p><b>Discussion:</b></p>
16503 <p>
16504 From Stage 2 processing in 22.4.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
16505 original text or the text corrected by the proposed resolution of
16506 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
16507 within a number, but 22.4.3.1 [locale.numpunct], p2, which gives the
16508 format for integer and floating point values, says that whitespace is
16509 optional between a plusminus and a sign.
16510 </p>
16511
16512 <p>
16513 The text needs to be clarified to either consistently allow or
16514 disallow whitespace between a plusminus and a sign. It might be
16515 worthwhile to consider the fact that the C library stdio facility does
16516 not permit whitespace embedded in numbers and neither does the C or
16517 C++ core language (the syntax of integer-literals is given in 2.14.2 [lex.icon], that of floating-point-literals in 2.14.4 [lex.fcon] of the C++ standard).
16518 </p>
16519
16520
16521 <p><b>Proposed resolution:</b></p>
16522 <p>Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:</p>
16523 <blockquote>
16524 <p>
16525 The syntax for number formats is as follows, where <tt>digit</tt>
16526 represents the radix set specified by the <tt>fmtflags</tt> argument
16527 value, <tt>whitespace</tt> is as determined by the facet
16528 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
16529 <tt>decimal-point</tt> are the results of corresponding
16530 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
16531 format:
16532 </p>
16533 <pre>  integer   ::= [sign] units
16534   sign      ::= plusminus [whitespace]
16535   plusminus ::= '+' | '-'
16536   units     ::= digits [thousands-sep units]
16537   digits    ::= digit [digits]
16538 </pre>
16539 </blockquote>
16540 <p>to:</p>
16541 <blockquote>
16542 <p>
16543 The syntax for number formats is as follows, where <tt>digit</tt>
16544 represents the radix set specified by the <tt>fmtflags</tt> argument
16545 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
16546 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
16547 Integer values have the format:
16548 </p>
16549 <pre>  integer   ::= [sign] units
16550   sign      ::= plusminus
16551   plusminus ::= '+' | '-'
16552   units     ::= digits [thousands-sep units]
16553   digits    ::= digit [digits]
16554 </pre>
16555 </blockquote>
16556
16557
16558 <p><b>Rationale:</b></p>
16559 <p>It's not clear whether the format described in 22.4.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
16560 standard says how, or whether, it's used.  However, there's no reason
16561 for it to differ gratuitously from the very specific description of
16562 numeric processing in 22.4.2.1.2 [facet.num.get.virtuals].  The proposed
16563 resolution removes all mention of "whitespace" from that format.</p>
16564
16565
16566
16567
16568
16569 <hr>
16570 <h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
16571 <p><b>Section:</b> 22.4.1 [category.ctype], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16572  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2010-10-29</p>
16573 <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>
16574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16575 <p><b>Discussion:</b></p>
16576 <p>
16577 The ctype_category::mask type is declared to be an enum in 22.4.1 [category.ctype] with p1 then stating that it is a bitmask type, most
16578 likely referring to the definition of bitmask type in 17.5.2.1.3 [bitmask.types], p1. However, the said definition only applies to
16579 clause 27, making the reference in 22.2.1 somewhat dubious.
16580 </p>
16581
16582
16583 <p><b>Proposed resolution:</b></p>
16584 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
16585     <blockquote><p>
16586     Several types defined in clause 27 are bitmask types. Each bitmask type
16587     can be implemented as an enumerated type that overloads certain operators,
16588     as an integer type, or as a bitset (20.5 [template.bitset]).
16589     </p></blockquote>
16590 <p>to read</p>
16591     <blockquote><p>
16592     Several types defined in clauses lib.language.support through 
16593     lib.input.output and Annex D are bitmask types. Each bitmask type can
16594     be implemented as an enumerated type that overloads certain operators,
16595     as an integer  type, or as a bitset (lib.template.bitset).
16596     </p></blockquote>
16597
16598 <p>
16599 Additionally, change the definition in 22.2.1 to adopt the same
16600 convention as in clause 27 by replacing the existing text with the
16601 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
16602 22.2.1, p1):
16603 </p>
16604
16605 <blockquote>
16606 <p>22.2.1 The ctype category [lib.category.ctype]</p>
16607 <pre>namespace std {
16608     class ctype_base {
16609     public:
16610         typedef <b><i>T</i></b> mask;
16611
16612         // numeric values are for exposition only.
16613         static const mask space = 1 &lt;&lt; 0;
16614         static const mask print = 1 &lt;&lt; 1;
16615         static const mask cntrl = 1 &lt;&lt; 2;
16616         static const mask upper = 1 &lt;&lt; 3;
16617         static const mask lower = 1 &lt;&lt; 4;
16618         static const mask alpha = 1 &lt;&lt; 5;
16619         static const mask digit = 1 &lt;&lt; 6;
16620         static const mask punct = 1 &lt;&lt; 7;
16621         static const mask xdigit = 1 &lt;&lt; 8;
16622         static const mask alnum = alpha | digit;
16623         static const mask graph = alnum | punct;
16624     };
16625 }
16626 </pre>
16627
16628 <p>The type <tt>mask</tt> is a bitmask type (17.5.2.1.3 [bitmask.types]).</p>
16629 </blockquote>
16630
16631 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
16632 consistent with the rest of the standard.]</i></p>
16633
16634
16635
16636
16637
16638
16639
16640
16641
16642 <hr>
16643 <h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
16644 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16645  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-18 <b>Last modified:</b> 2010-10-29</p>
16646 <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>
16647 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16648 <p><b>Discussion:</b></p>
16649 <p>
16650 It's unclear whether 22.1.1.1.1, p3 says that
16651 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
16652 from Table 51 or whether it includes Table 52 as well:
16653 </p>
16654
16655 <blockquote><p>
16656 For any locale <tt>loc</tt> either constructed, or returned by
16657 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
16658 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
16659 locale member function which takes a <tt>locale::category</tt>
16660 argument operates on the corresponding set of facets.
16661 </p></blockquote>
16662
16663 <p>
16664 It seems that it comes down to which facets are considered to be members of a
16665 standard category. Intuitively, I would classify all the facets in Table 52 as
16666 members of their respective standard categories, but there are an unbounded set
16667 of them...
16668 </p>
16669
16670 <p>
16671 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
16672 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
16673 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
16674 &gt;(loc)</tt> would have to return a reference to a distinct object for each
16675 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
16676 clearly impossible.
16677 </p>
16678
16679 <p>
16680 On the other hand, if none of the facets in Table 52 is a member of a standard
16681 category then none of the locale member functions that operate on entire
16682 categories of facets will work properly.
16683 </p>
16684
16685 <p>
16686 It seems that what p3 should mention that it's required (permitted?)
16687 to hold only for specializations of <tt>Facet</tt> from Table 52 on
16688 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
16689 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
16690 {
16691 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
16692 }.
16693 </p>
16694
16695
16696 <p><b>Proposed resolution:</b></p>
16697 <p>In 22.3.1.1.1 [locale.category], paragraph 3, change
16698 "that is a member of a standard category" to "shown in Table 51".</p>
16699
16700
16701 <p><b>Rationale:</b></p>
16702 <p>The facets in Table 52 are an unbounded set.  Locales should not be
16703 required to contain an infinite number of facets.</p> 
16704
16705 <p>It's not necessary to talk about which values of InputIterator and
16706 OutputIterator must be supported.  Table 51 already contains a
16707 complete list of the ones we need.</p>
16708
16709
16710
16711
16712
16713
16714 <hr>
16715 <h3><a name="341"></a>341. Vector reallocation and swap</h3>
16716 <p><b>Section:</b> 23.4.1.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16717  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-09-27 <b>Last modified:</b> 2010-10-29</p>
16718 <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>
16719 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16720 <p><b>Discussion:</b></p>
16721 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
16722 an empty one:</p>
16723 <pre>  std::vector&lt;SomeType&gt; vec;
16724   // fill vec with data
16725   std::vector&lt;SomeType&gt;().swap(vec);
16726   // vec is now empty, with minimal capacity
16727 </pre>
16728
16729 <p>However, the wording of 23.4.1.2 [vector.capacity]paragraph 5 prevents
16730 the capacity of a vector being reduced, following a call to
16731 reserve(). This invalidates the idiom, as swap() is thus prevented
16732 from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
16733 requires the temporary to be expanded to cater for the contents of
16734 vec, and the contents be copied across. This is a linear-time
16735 operation.</p>
16736
16737 <p>However, the container requirements state that swap must have constant
16738 complexity (23.2 [container.requirements] note to table 65).</p>
16739
16740 <p>This is an important issue, as reallocation affects the validity of
16741 references and iterators.</p>
16742
16743 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
16744 references and iterators remain valid after a call to swap, if they refer to
16745 an element before the new end() of the vector into which they originally
16746 pointed, in which case they refer to the element at the same index position.
16747 Iterators and references that referred to an element whose index position
16748 was beyond the new end of the vector are invalidated.</p>
16749
16750 <p>If the note to table 65 is taken as the desired intent, then there are two
16751 possibilities with regard to iterators and references:</p>
16752
16753 <ol>
16754 <li>All Iterators and references into both vectors are invalidated.</li>
16755 <li>Iterators and references into either vector remain valid, and remain
16756 pointing to the same element. Consequently iterators and references that
16757 referred to one vector now refer to the other, and vice-versa.</li>
16758 </ol>
16759
16760
16761 <p><b>Proposed resolution:</b></p>
16762 <p>Add a new paragraph after 23.4.1.2 [vector.capacity] paragraph 5:</p>
16763 <blockquote>
16764 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
16765 </pre>
16766 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
16767 with that of <tt>x</tt>.</p>
16768 <p><b>Complexity:</b> Constant time.</p>
16769 </blockquote>
16770
16771 <p><i>[This solves the problem reported for this issue.  We may also
16772 have a problem with a circular definition of swap() for other
16773 containers.]</i></p>
16774
16775
16776
16777
16778 <p><b>Rationale:</b></p>
16779 <p>
16780 swap should be constant time.  The clear intent is that it should just
16781 do pointer twiddling, and that it should exchange all properties of
16782 the two vectors, including their reallocation guarantees.
16783 </p>
16784
16785
16786
16787
16788
16789 <hr>
16790 <h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
16791 <p><b>Section:</b> 21.7 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16792  <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2001-10-19 <b>Last modified:</b> 2010-10-29</p>
16793 <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>
16794 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16795 <p><b>Discussion:</b></p>
16796 <p>
16797 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
16798 declares struct tm as an incomplete type. However, table 48 in 21.7 [c.strings] does not mention the type tm as being declared in
16799 &lt;cwchar&gt;. Is this omission intentional or accidental?
16800 </p>
16801
16802
16803 <p><b>Proposed resolution:</b></p>
16804 <p>In section 21.7 [c.strings], add "tm" to table 48.</p>
16805
16806
16807
16808
16809
16810 <hr>
16811 <h3><a name="346"></a>346. Some iterator member functions should be const</h3>
16812 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16813  <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 2001-10-20 <b>Last modified:</b> 2010-10-29</p>
16814 <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>
16815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16816 <p><b>Discussion:</b></p>
16817 <p>Iterator member functions and operators that do not change the state
16818 of the iterator should be defined as const member functions or as
16819 functions that take iterators either by const reference or by
16820 value. The standard does not explicitly state which functions should
16821 be const.  Since this a fairly common mistake, the following changes
16822 are suggested to make this explicit.</p>
16823
16824 <p>The tables almost indicate constness properly through naming: r
16825 for non-const and a,b for const iterators. The following changes
16826 make this more explicit and also fix a couple problems.</p>
16827
16828
16829 <p><b>Proposed resolution:</b></p>
16830 <p>In X [iterator.concepts] Change the first section of p9 from
16831 "In the following sections, a and b denote values of X..." to
16832 "In the following sections, a and b denote values of type const X...".</p>
16833
16834 <p>In Table 73, change</p>
16835 <pre>    a-&gt;m   U&amp;         ...
16836 </pre>
16837
16838 <p>to</p>
16839
16840 <pre>    a-&gt;m   const U&amp;   ...
16841     r-&gt;m   U&amp;         ...
16842 </pre>
16843
16844 <p>In Table 73 expression column, change</p>
16845
16846 <pre>    *a = t
16847 </pre>
16848
16849 <p>to</p>
16850
16851 <pre>    *r = t
16852 </pre>
16853
16854 <p><i>[Redmond: The container requirements should be reviewed to see if
16855 the same problem appears there.]</i></p>
16856
16857
16858
16859
16860
16861
16862
16863 <hr>
16864 <h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
16865 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16866  <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2010-10-29</p>
16867 <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>
16868 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16869 <p><b>Discussion:</b></p>
16870 <p>
16871 In 22.3.1.1.1 [locale.category] paragraph 1, the category members
16872 are described as bitmask elements.  In fact, the bitmask requirements
16873 in 17.5.2.1.3 [bitmask.types] don't seem quite right: <tt>none</tt>
16874 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
16875
16876 <p>In particular, the requirements for <tt>none</tt> interact poorly
16877 with the requirement that the LC_* constants from the C library must
16878 be recognizable as C++ locale category constants.  LC_* values should
16879 not be mixed with these values to make category values.</p>
16880
16881 <p>We have two options for the proposed resolution.  Informally:
16882 option 1 removes the requirement that LC_* values be recognized as
16883 category arguments.  Option 2 changes the category type so that this
16884 requirement is implementable, by allowing <tt>none</tt> to be some
16885 value such as 0x1000 instead of 0.</p>
16886
16887 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
16888 re-expresses the status quo more clearly, without introducing any
16889 changes beyond resolving the DR.</p>
16890
16891
16892
16893 <p><b>Proposed resolution:</b></p>
16894 <p>Replace the first two paragraphs of 22.3.1.1 [locale.types] with:</p>
16895 <blockquote>
16896 <pre>    typedef int category;
16897 </pre>
16898
16899 <p>Valid category values include the <tt>locale</tt> member bitmask
16900 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
16901 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
16902 represents a single locale category. In addition, <tt>locale</tt> member
16903 bitmask constant <tt>none</tt> is defined as zero and represents no
16904 category. And locale member bitmask constant <tt>all</tt> is defined such that
16905 the expression</p>
16906 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
16907 </pre>
16908 <p>
16909 is <tt>true</tt>, and represents the union of all categories.  Further
16910 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
16911 represent a single category, represents the union of the two
16912 categories.
16913 </p>
16914
16915 <p>
16916 <tt>locale</tt> member functions expecting a <tt>category</tt>
16917 argument require one of the <tt>category</tt> values defined above, or
16918 the union of two or more such values. Such a <tt>category</tt>
16919 argument identifies a set of locale categories. Each locale category,
16920 in turn, identifies a set of locale facets, including at least those
16921 shown in Table 51:
16922 </p>
16923 </blockquote>
16924 <p><i>[Curaçao: need input from locale experts.]</i></p>
16925
16926
16927
16928
16929 <p><b>Rationale:</b></p>
16930
16931 <p>The LWG considered, and rejected, an alternate proposal (described
16932   as "Option 2" in the discussion).  The main reason for rejecting it
16933   was that library implementors were concerened about implementation
16934   difficult, given that getting a C++ library to work smoothly with a
16935   separately written C library is already a delicate business.  Some
16936   library implementers were also concerned about the issue of adding
16937   extra locale categories.</p>
16938
16939 <blockquote>
16940 <p><b>Option 2:</b> <br>
16941 Replace the first paragraph of 22.3.1.1 [locale.types] with:</p>
16942 <blockquote>
16943 <p>
16944 Valid category values include the enumerated values.  In addition, the
16945 result of applying commutative operators | and &amp; to any two valid 
16946 values is valid, and results in the setwise union and intersection, 
16947 respectively, of the argument categories.  The values <tt>all</tt> and 
16948 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
16949 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
16950 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are 
16951 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
16952 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
16953 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
16954 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of 
16955 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
16956 [Footnote: it is not required that <tt>all</tt> equal the setwise union
16957 of the other enumerated values; implementations may add extra categories.]
16958 </p>
16959 </blockquote>
16960 </blockquote>
16961
16962
16963
16964
16965
16966 <hr>
16967 <h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
16968 <p><b>Section:</b> 24.6.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16969  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-24 <b>Last modified:</b> 2010-10-29</p>
16970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16971 <p><b>Discussion:</b></p>
16972 <p>24.5.2 [lib.ostream.iterator] states:</p>
16973 <pre>    [...]
16974
16975     private:
16976     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
16977     // const char* delim; exposition only
16978 </pre>
16979
16980 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
16981 should be of type 'const charT*'.</p>
16982
16983
16984 <p><b>Proposed resolution:</b></p>
16985 <p>
16986 In 24.6.2 [ostream.iterator], replace <tt>const char* delim</tt> with
16987 <tt>const charT* delim</tt>.
16988 </p>
16989
16990
16991
16992
16993
16994 <hr>
16995 <h3><a name="352"></a>352. missing fpos requirements</h3>
16996 <p><b>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16997  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2010-10-29</p>
16998 <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>
16999 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17000 <p><b>Discussion:</b></p>
17001 <p>
17002 <i>(1)</i>
17003 There are no requirements on the <tt>stateT</tt> template parameter of
17004 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
17005 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
17006 and I think also DefaultConstructible (to implement the operations in
17007 Table 88).
17008 </p>
17009 <p>
17010 21.1.2, p3, however, only requires that
17011 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
17012 CopyConstructible types.
17013 </p>
17014 <p>
17015 <i>(2)</i>
17016 Additionally, the <tt>stateT</tt> template argument has no
17017 corresponding typedef in fpos which might make it difficult to use in
17018 generic code.
17019 </p>
17020
17021
17022 <p><b>Proposed resolution:</b></p>
17023 <p>
17024 Modify 21.1.2, p4 from
17025 </p>
17026 <p>
17027     Requires: <tt>state_type</tt> shall meet the requirements of
17028               CopyConstructible types (20.1.3).
17029 </p>
17030 <p>
17031     Requires: state_type shall meet the requirements of Assignable
17032               (23.1, p4), CopyConstructible (20.1.3), and
17033               DefaultConstructible  (20.1.4) types.
17034 </p>
17035
17036
17037
17038 <p><b>Rationale:</b></p>
17039 <p>The LWG feels this is two issues, as indicated above. The first is
17040 a defect---std::basic_fstream is unimplementable without these
17041 additional requirements---and the proposed resolution fixes it.  The
17042 second is questionable; who would use that typedef?  The class
17043 template fpos is used only in a very few places, all of which know the
17044 state type already.  Unless motivation is provided, the second should
17045 be considered NAD.</p>
17046
17047
17048
17049
17050
17051 <hr>
17052 <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
17053 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
17054  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2010-11-19</p>
17055 <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>
17056 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
17057 <p><b>Discussion:</b></p>
17058 <p>
17059 The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
17060 no template assignment operator. This may lead to inefficient code since
17061 assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
17062 where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
17063 <tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
17064 ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
17065 followed by an ordinary (perhaps implicitly defined) assignment operator,
17066 instead of just a straight assignment.
17067 </p>
17068
17069
17070 <p><b>Proposed resolution:</b></p>
17071 <p>
17072 Add the following declaration to the definition of <tt>std::pair</tt>:
17073 </p>
17074 <pre>    template&lt;class U, class V&gt;
17075     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
17076 </pre>
17077 <p>
17078 And also add a paragraph describing the effects of the function template to the
17079 end of 20.2.2:
17080 </p>
17081 <pre>    template&lt;class U, class V&gt;
17082     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
17083 </pre>
17084 <p>
17085     <b>Effects</b>: <tt>first = p.first;</tt>
17086                     <tt>second = p.second;</tt>
17087     <b>Returns</b>: <tt>*this</tt>
17088 </p>
17089
17090 <p><i>[Curaçao: There is no indication this is was anything other than
17091 a design decision, and thus NAD.&nbsp; May be appropriate for a future
17092 standard.]</i></p>
17093
17094
17095 <p><i>[
17096 Pre Bellevue:  It was recognized that this was taken care of by
17097 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
17098 and thus moved from NAD Future to <del>NAD Editorial</del><ins>Resolved</ins>.
17099 ]</i></p>
17100
17101
17102
17103
17104
17105
17106 <hr>
17107 <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
17108 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17109  <b>Submitter:</b> Hans Aberg <b>Opened:</b> 2001-12-17 <b>Last modified:</b> 2010-10-29</p>
17110 <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>
17111 <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>
17112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17113 <p><b>Discussion:</b></p>
17114 <p>
17115 Discussions in the thread "Associative container lower/upper bound
17116 requirements" on comp.std.c++ suggests that there is a defect in the
17117 C++ standard, Table 69 of section 23.1.2, "Associative containers",
17118 [lib.associative.reqmts].  It currently says:</p>
17119
17120 <blockquote>
17121 <p>
17122 a.find(k): returns an iterator pointing to an element with the key equivalent to
17123 k, or a.end() if such an element is not found.
17124 </p>
17125
17126 <p>
17127 a.lower_bound(k): returns an iterator pointing to the first element with
17128 key not less than k.
17129 </p>
17130
17131 <p>
17132 a.upper_bound(k): returns an iterator pointing to the first element with
17133 key greater than k.
17134 </p>
17135 </blockquote>
17136
17137 <p>
17138 We have "or a.end() if such an element is not found" for
17139 <tt>find</tt>, but not for <tt>upper_bound</tt> or
17140 <tt>lower_bound</tt>.  As the text stands, one would be forced to
17141 insert a new element into the container and return an iterator to that
17142 in case the sought iterator does not exist, which does not seem to be
17143 the intention (and not possible with the "const" versions).
17144 </p>
17145
17146
17147 <p><b>Proposed resolution:</b></p>
17148
17149 <p>Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries
17150 to:</p>
17151
17152 <blockquote>
17153 <p>
17154 a.lower_bound(k): returns an iterator pointing to the first element with
17155 key not less than k, or a.end() if such an element is not found.
17156 </p>
17157
17158 <p>
17159 a.upper_bound(k): returns an iterator pointing to the first element with
17160 key greater than k, or a.end() if such an element is not found.
17161 </p>
17162 </blockquote>
17163
17164 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
17165
17166
17167
17168
17169
17170
17171
17172
17173 <hr>
17174 <h3><a name="355"></a>355. Operational semantics for a.back()</h3>
17175 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17176  <b>Submitter:</b> Yaroslav Mironov <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2010-10-29</p>
17177 <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>
17178 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17179 <p><b>Discussion:</b></p>
17180
17181 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
17182 specifies operational semantics for "a.back()" as
17183 "*--a.end()", which may be ill-formed <i>[because calling
17184 operator-- on a temporary (the return) of a built-in type is
17185 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
17186 (this is almost always the case for std::vector::end(), for
17187 example). Thus, the specification is not only incorrect, it
17188 demonstrates a dangerous construct: "--a.end()" may
17189 successfully compile and run as intended, but after changing the type
17190 of the container or the mode of compilation it may produce
17191 compile-time error. </p>
17192
17193
17194
17195 <p><b>Proposed resolution:</b></p>
17196 <p>Change the specification in table 68 "Optional Sequence
17197 Operations" in 23.1.1/12 for "a.back()" from</p>
17198
17199
17200 <blockquote><pre>*--a.end()
17201 </pre></blockquote>
17202
17203 <p>to</p>
17204
17205 <blockquote><pre>  { iterator tmp = a.end(); --tmp; return *tmp; }
17206 </pre></blockquote>
17207
17208 <p>and the specification for "a.pop_back()" from</p>
17209
17210 <blockquote><pre>a.erase(--a.end())
17211 </pre></blockquote>
17212
17213 <p>to</p>
17214
17215 <blockquote><pre>  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
17216 </pre></blockquote>
17217
17218 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
17219 a.end(); return *--tmp; }" to "*a.rbegin()", and from
17220 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
17221 "a.erase(rbegin())".]</i></p>
17222
17223
17224 <p><i>[There is a second possible defect; table 68 "Optional
17225 Sequence Operations" in the "Operational Semantics"
17226 column uses operations present only in the "Reversible
17227 Container" requirements, yet there is no stated dependency
17228 between these separate requirements tables. Ask in Santa Cruz if the
17229 LWG would like a new issue opened.]</i></p>
17230
17231
17232 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
17233   the current standard: erase is undefined for reverse iterator.  If
17234   we're going to make the change, we need to define a temporary and
17235   use operator--.  Additionally, we don't know how prevalent this is:
17236   do we need to make this change in more than one place?  Martin has
17237   volunteered to review the standard and see if this problem occurs
17238   elsewhere.]</i></p>
17239
17240
17241 <p><i>[Oxford: Matt provided new wording to address the concerns raised
17242   in Santa Cruz.  It does not appear that this problem appears
17243   anywhere else in clauses 23 or 24.]</i></p>
17244
17245
17246 <p><i>[Kona: In definition of operational semantics of back(), change
17247 "*tmp" to "return *tmp;"]</i></p>
17248
17249
17250
17251
17252
17253
17254
17255 <hr>
17256 <h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
17257 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17258  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
17259 <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>
17260 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17261 <p><b>Discussion:</b></p>
17262 <p>
17263 I don't think <tt>thousands_sep</tt> is being treated correctly after
17264 decimal_point has been seen. Since grouping applies only to the
17265 integral part of the number, the first such occurrence should, IMO,
17266 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
17267 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
17268 interpreted in the fractional part of a number.)
17269 </p>
17270
17271 <p>
17272 The easiest change I can think of that resolves this issue would be
17273 something like below.
17274 </p>
17275
17276
17277 <p><b>Proposed resolution:</b></p>
17278 <p>
17279 Change the first sentence of 22.2.2.1.2, p9 from
17280 </p>
17281
17282 <blockquote><p>
17283     If discard is true then the position of the character is
17284     remembered, but the character is otherwise ignored. If it is not
17285     discarded, then a check is made to determine if c is allowed as
17286     the next character of an input field of the conversion specifier
17287     returned by stage 1. If so it is accumulated.
17288 </p></blockquote>
17289
17290 <p>to</p>
17291
17292 <blockquote><p>
17293     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
17294     accumulated, then the position of the character is remembered, but
17295     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
17296     already been accumulated, the character is discarded and Stage 2
17297      terminates. ...
17298 </p></blockquote>
17299
17300
17301
17302 <p><b>Rationale:</b></p>
17303 <p>We believe this reflects the intent of the Standard.  Thousands sep
17304   characters after the decimal point are not useful in any locale.
17305   Some formatting conventions do group digits that follow the decimal
17306   point, but they usually introduce a different grouping character
17307   instead of reusing the thousand sep character.  If we want to add
17308   support for such conventions, we need to do so explicitly.</p>
17309
17310
17311
17312
17313
17314
17315 <hr>
17316 <h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
17317 <p><b>Section:</b> 22.4.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17318  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
17319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17320 <p><b>Discussion:</b></p>
17321 <p>22.2.2.2.1, p1:</p>
17322
17323     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
17324                    bool val) const;
17325     ...
17326
17327     1   Returns: do_put (out, str, fill, val).
17328     </pre>
17329
17330 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
17331 however, 22.2.2.2.2, p23:</p>
17332
17333 <blockquote>
17334 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
17335                bool val) const;
17336 </pre>
17337
17338
17339         <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
17340              out = do_put(out, str, fill, (int)val)
17341            Otherwise do</p>
17342 <pre>             string_type s =
17343                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
17344                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
17345 </pre>
17346            <p>and then insert the characters of s into out. <i>out</i>.</p>
17347 </blockquote>
17348
17349 <p>
17350 This means that the bool overload of <tt>do_put()</tt> will never be called,
17351 which contradicts the first paragraph. Perhaps the declaration
17352 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
17353 </p>
17354
17355 <p>
17356 Note also that there is no <b>Returns</b> clause for this function, which
17357 should probably be corrected, just as should the second occurrence
17358 of <i>"out."</i> in the text.
17359 </p>
17360
17361 <p>
17362 I think the least invasive change to fix it would be something like
17363 the following:
17364 </p>
17365
17366
17367 <p><b>Proposed resolution:</b></p>
17368 <p>In 22.4.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
17369   the <tt>bool</tt> overload.</p>
17370
17371 <p>
17372 In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes
17373 </p>
17374
17375 <blockquote><p>
17376      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
17377      of the member function.
17378 </p></blockquote>
17379
17380 <blockquote><p>
17381     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
17382     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
17383     do_put (..., bool))</tt>
17384     like so:
17385 </p></blockquote>
17386
17387 <blockquote><p>
17388     23   <b>Returns</b>: If <tt>(str.flags() &amp;
17389          ios_base::boolalpha) == 0</tt> then
17390          <tt>do_put (out, str, fill, (long)val)</tt>
17391          Otherwise the function obtains a string <tt>s</tt> as if by</p>
17392 <pre>             string_type s =
17393                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
17394                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
17395 </pre>
17396          <p>and then inserts each character <tt>c</tt> of s into out via
17397            <tt>*out++ = c</tt>
17398          and returns <tt>out</tt>.</p>
17399 </blockquote>
17400
17401
17402
17403 <p><b>Rationale:</b></p><p>
17404 This fixes a couple of obvious typos, and also fixes what appears to
17405 be a requirement of gratuitous inefficiency.
17406 </p>
17407
17408
17409
17410
17411 <hr>
17412 <h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
17413 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17414  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
17415 <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>
17416 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17417 <p><b>Discussion:</b></p>
17418 <p>
17419 22.1.1, p7 (copied below) allows iostream formatters and extractors
17420 to make assumptions about the values returned from facet members.
17421 However, such assumptions are apparently not guaranteed to hold
17422 in other cases (e.g., when the facet members are being called directly
17423 rather than as a result of iostream calls, or between successive
17424 calls to the same iostream functions with no interevening calls to
17425 <tt>imbue()</tt>, or even when the facet member functions are called
17426 from other member functions of other facets). This restriction
17427 prevents locale from being implemented efficiently.
17428 </p>
17429
17430
17431 <p><b>Proposed resolution:</b></p>
17432 <p>Change the first sentence in 22.1.1, p7 from</p>
17433 <blockquote><p>
17434     In successive calls to a locale facet member function during
17435     a call to an iostream inserter or extractor or a streambuf member
17436     function, the returned result shall be identical. [Note: This
17437     implies that such results may safely be reused without calling
17438     the locale facet member function again, and that member functions
17439     of iostream classes cannot safely call <tt>imbue()</tt>
17440     themselves, except as specified elsewhere. --end note]
17441 </p></blockquote>
17442
17443 <p>to</p>
17444
17445 <blockquote><p>
17446     In successive calls to a locale facet member function on a facet
17447     object installed in the same locale, the returned result shall be
17448     identical. ...
17449 </p></blockquote>
17450
17451
17452
17453 <p><b>Rationale:</b></p>
17454 <p>This change is reasonable becuase it clarifies the intent of this
17455   part of the standard.</p>
17456
17457
17458
17459
17460
17461 <hr>
17462 <h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
17463 <p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17464  <b>Submitter:</b> Andrew Demkin <b>Opened:</b> 2002-04-26 <b>Last modified:</b> 2010-10-29</p>
17465 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
17466 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17467 <p><b>Discussion:</b></p>
17468 <p>
17469 The definition of bind1st() (D.11 [depr.lib.binders]) can result in
17470 the construction of an unsafe binding between incompatible pointer
17471 types. For example, given a function whose first parameter type is
17472 'pointer to T', it's possible without error to bind an argument of
17473 type 'pointer to U' when U does not derive from T:
17474 </p>
17475 <pre>   foo(T*, int);
17476
17477    struct T {};
17478    struct U {};
17479
17480    U u;
17481
17482    int* p;
17483    int* q;
17484
17485    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
17486 </pre>
17487
17488 <p>
17489 The definition of bind1st() includes a functional-style conversion to
17490 map its argument to the expected argument type of the bound function
17491 (see below):
17492 </p>
17493 <pre>  typename Operation::first_argument_type(x)
17494 </pre>
17495
17496 <p>
17497 A functional-style conversion (D.11 [depr.lib.binders]) is defined to be
17498 semantically equivalent to an explicit cast expression (D.11 [depr.lib.binders]), which may (according to 5.4, paragraph 5) be interpreted
17499 as a reinterpret_cast, thus masking the error.
17500 </p>
17501
17502 <p>The problem and proposed change also apply to D.11 [depr.lib.binders].</p>
17503
17504
17505 <p><b>Proposed resolution:</b></p>
17506 <p>Add this sentence to the end of D.11 [depr.lib.binders]/1:
17507   "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
17508   favor of <tt>std::tr1::bind</tt>."</p>
17509
17510 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
17511   the standard, "std::tr1::bind" should be changed to "std::bind". (2)
17512   20.5.6 should probably be moved to Annex D.</p>
17513
17514
17515 <p><b>Rationale:</b></p>
17516 <p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
17517   superior solution.  It solves this problem and others.</p>
17518
17519
17520
17521
17522
17523 <hr>
17524 <h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
17525 <p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17526  <b>Submitter:</b> Walter Brown and Marc Paterno <b>Opened:</b> 2002-05-20 <b>Last modified:</b> 2010-10-29</p>
17527 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
17528 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17529 <p><b>Discussion:</b></p>
17530 <p>
17531 The destructor of ios_base::failure should have an empty throw
17532 specification, because the destructor of its base class, exception, is
17533 declared in this way.
17534 </p>
17535
17536
17537 <p><b>Proposed resolution:</b></p>
17538 <p>Change the destructor to</p>
17539 <pre>  virtual ~failure() throw();
17540 </pre>
17541
17542
17543 <p><b>Rationale:</b></p>
17544 <p>Fixes an obvious glitch.  This is almost editorial.</p>
17545
17546
17547
17548
17549
17550 <hr>
17551 <h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
17552 <p><b>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17553  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2010-10-29</p>
17554 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
17555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17556 <p><b>Discussion:</b></p>
17557 <p>
17558 27.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
17559 clause for seekoff.
17560 </p>
17561
17562
17563 <p><b>Proposed resolution:</b></p>
17564 <p>
17565 Make this paragraph, the Effects clause for setbuf, consistent in wording
17566 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
17567 to indicate the purpose of setbuf:
17568 </p>
17569
17570 <p>Original text:</p>
17571
17572 <blockquote><p>
17573 1 Effects: Performs an operation that is defined separately for each
17574 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
17575 </p></blockquote>
17576
17577 <p>Proposed text:</p>
17578
17579 <blockquote><p>
17580 1 Effects: Influences stream buffering in a way that is defined separately
17581 for each class derived from basic_streambuf in this clause
17582 (27.7.1.3, 27.8.1.4).
17583 </p></blockquote>
17584
17585
17586
17587 <p><b>Rationale:</b></p>
17588 <p>The LWG doesn't believe there is any normative difference between
17589   the existing wording and what's in the proposed resolution, but the
17590   change may make the intent clearer.</p>
17591
17592
17593
17594
17595
17596 <hr>
17597 <h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
17598 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17599  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2010-10-29</p>
17600 <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>
17601 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17602 <p><b>Discussion:</b></p>
17603 <p>
17604 Some stream and streambuf member functions are declared non-const,
17605 even thought they appear only to report information rather than to
17606 change an object's logical state.  They should be declared const.  See
17607 document N1360 for details and rationale.
17608 </p>
17609
17610 <p>The list of member functions under discussion: <tt>in_avail</tt>,
17611 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
17612
17613 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
17614
17615
17616
17617 <p><b>Proposed resolution:</b></p>
17618 <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>
17619 <p>Replace</p>
17620 <pre>  bool is_open();
17621 </pre>
17622 <p>with</p>
17623 <pre>  bool is_open() const;
17624 </pre>
17625
17626
17627 <p><b>Rationale:</b></p>
17628 <p>Of the changes proposed in N1360, the only one that is safe is
17629 changing the filestreams' is_open to const.  The LWG believed that
17630 this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
17631 member function, after all,is already const.</p>
17632
17633 <p>The other proposed changes are less safe, because some streambuf
17634 functions that appear merely to report a value do actually perform
17635 mutating operations.  It's not even clear that they should be
17636 considered "logically const", because streambuf has two interfaces, a
17637 public one and a protected one.  These functions may, and often do,
17638 change the state as exposed by the protected interface, even if the
17639 state exposed by the public interface is unchanged.</p>
17640
17641 <p>Note that implementers can make this change in a binary compatible
17642 way by providing both overloads; this would be a conforming extension.</p>
17643
17644
17645
17646
17647
17648
17649 <hr>
17650 <h3><a name="369"></a>369. io stream objects and static ctors</h3>
17651 <p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17652  <b>Submitter:</b> Ruslan Abdikeev <b>Opened:</b> 2002-07-08 <b>Last modified:</b> 2010-10-29</p>
17653 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
17654 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17655 <p><b>Discussion:</b></p>
17656 <p>
17657 Is it safe to use standard iostream objects from constructors of
17658 static objects?  Are standard iostream objects constructed and are
17659 their associations established at that time?
17660 </p>
17661
17662 <p>Surpisingly enough, Standard does NOT require that.</p>
17663
17664 <p>
17665 27.3/2 [lib.iostream.objects] guarantees that standard iostream
17666 objects are constructed and their associations are established before
17667 the body of main() begins execution.  It also refers to ios_base::Init
17668 class as the panacea for constructors of static objects.
17669 </p>
17670
17671 <p>
17672 However, there's nothing in 27.3 [lib.iostream.objects],
17673 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
17674 that would require implementations to allow access to standard
17675 iostream objects from constructors of static objects.
17676 </p>
17677
17678 <p>Details:</p>
17679
17680 <p>Core text refers to some magic object ios_base::Init, which will
17681 be discussed below:</p>
17682
17683 <blockquote><p>
17684     "The [standard iostream] objects are constructed, and their
17685     associations are established at some time prior to or during
17686     first time an object of class basic_ios&lt;charT,traits&gt;::Init
17687     is constructed, and in any case before the body of main
17688     begins execution." (27.3/2 [lib.iostream.objects])
17689 </p></blockquote>
17690
17691 <p>
17692 The first <i>non-normative</i> footnote encourages implementations
17693 to initialize standard iostream objects earlier than required.
17694 </p>
17695
17696 <p>However, the second <i>non-normative</i> footnote makes an explicit
17697 and unsupported claim:</p>
17698
17699 <blockquote><p>
17700   "Constructors and destructors for static objects can access these
17701   [standard iostream] objects to read input from stdin or write output
17702   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
17703 </p></blockquote>
17704
17705 <p>
17706 The only bit of magic is related to that ios_base::Init class.  AFAIK,
17707 the rationale behind ios_base::Init was to bring an instance of this
17708 class to each translation unit which #included &lt;iostream&gt; or
17709 related header.  Such an inclusion would support the claim of footnote
17710 quoted above, because in order to use some standard iostream object it
17711 is necessary to #include &lt;iostream&gt;.
17712 </p>
17713
17714 <p>
17715 However, while Standard explicitly describes ios_base::Init as
17716 an appropriate class for doing the trick, I failed to found a
17717 mention of an _instance_ of ios_base::Init in Standard.
17718 </p>
17719
17720
17721 <p><b>Proposed resolution:</b></p>
17722
17723 <p>Add to 27.4 [iostream.objects], p2, immediately before the last sentence
17724 of the paragraph, the following two sentences:</p>
17725
17726 <blockquote><p>
17727 If a translation unit includes &lt;iostream&gt;, or explicitly
17728 constructs an ios_base::Init object, these stream objects shall
17729 be constructed before dynamic initialization of non-local
17730 objects defined later in that translation unit, and these stream
17731 objects shall be destroyed after the destruction of dynamically
17732 initialized non-local objects defined later in that translation unit.
17733 </p></blockquote>
17734
17735 <p><i>[Lillehammer: Matt provided wording.]</i></p>
17736
17737 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
17738
17739
17740
17741 <p><b>Rationale:</b></p>
17742 <p>
17743 The original proposed resolution unconditionally required
17744 implementations to define an ios_base::Init object of some
17745 implementation-defined name in the header &lt;iostream&gt;. That's an
17746 overspecification. First, defining the object may be unnecessary
17747 and even detrimental to performance if an implementation can
17748 guarantee that the 8 standard iostream objects will be initialized
17749 before any other user-defined object in a program. Second, there
17750 is no need to require implementations to document the name of the
17751 object.</p>
17752
17753 <p>
17754 The new proposed resolution gives users guidance on what they need to
17755 do to ensure that stream objects are constructed during startup.</p>
17756
17757
17758
17759
17760
17761 <hr>
17762 <h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
17763 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17764  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-07-15 <b>Last modified:</b> 2010-10-29</p>
17765 <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>
17766 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17767 <p><b>Discussion:</b></p>
17768 <p>Defect report for description of basic_istream::get (section 27.7.1.3 [istream.unformatted]), paragraph 15. The description for the get function
17769 with the following signature:</p>
17770
17771 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
17772   sb);
17773 </pre>
17774
17775 <p>is incorrect. It reads</p>
17776
17777 <blockquote><p>
17778   Effects: Calls get(s,n,widen('\n'))
17779 </p></blockquote>
17780
17781 <p>which I believe should be:</p>
17782
17783 <blockquote><p>
17784   Effects: Calls get(sb,widen('\n'))
17785 </p></blockquote>
17786
17787
17788 <p><b>Proposed resolution:</b></p>
17789 <p>Change the <b>Effects</b> paragraph to:</p>
17790 <blockquote><p>
17791   Effects: Calls get(sb,this-&gt;widen('\n'))
17792 </p></blockquote>
17793
17794 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen' 
17795       with 'this-&gt;widen'.]</i></p>
17796
17797
17798
17799
17800 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
17801
17802
17803
17804
17805 <hr>
17806 <h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
17807 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17808  <b>Submitter:</b> Frank Compagner <b>Opened:</b> 2002-07-20 <b>Last modified:</b> 2010-10-29</p>
17809 <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>
17810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17811 <p><b>Discussion:</b></p>
17812 <p>
17813 The requirements for multiset and multimap containers (23.1
17814 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
17815 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
17816 the stability of the required (mutating) member functions. It appears
17817 the standard allows these functions to reorder equivalent elements of
17818 the container at will, yet the pervasive red-black tree implementation
17819 appears to provide stable behaviour.
17820 </p>
17821
17822 <p>This is of most concern when considering the behaviour of erase().
17823 A stability requirement would guarantee the correct working of the
17824 following 'idiom' that removes elements based on a certain predicate
17825 function.
17826 </p>
17827
17828 <pre>  multimap&lt;int, int&gt; m;
17829   multimap&lt;int, int&gt;::iterator i = m.begin();
17830   while (i != m.end()) {
17831       if (pred(i))
17832           m.erase (i++);
17833       else
17834           ++i;
17835   }
17836 </pre>
17837
17838 <p>
17839 Although clause 23.1.2/8 guarantees that i remains a valid iterator
17840 througout this loop, absence of the stability requirement could
17841 potentially result in elements being skipped. This would make
17842 this code incorrect, and, furthermore, means that there is no way
17843 of erasing these elements without iterating first over the entire
17844 container, and second over the elements to be erased. This would
17845 be unfortunate, and have a negative impact on both performance and
17846 code simplicity.
17847 </p>
17848
17849 <p>
17850 If the stability requirement is intended, it should be made explicit
17851 (probably through an extra paragraph in clause 23.1.2).
17852 </p>
17853 <p>
17854 If it turns out stability cannot be guaranteed, i'd argue that a
17855 remark or footnote is called for (also somewhere in clause 23.1.2) to
17856 warn against relying on stable behaviour (as demonstrated by the code
17857 above).  If most implementations will display stable behaviour, any
17858 problems emerging on an implementation without stable behaviour will
17859 be hard to track down by users. This would also make the need for an
17860 erase_if() member function that much greater.
17861 </p>
17862
17863 <p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
17864
17865
17866
17867 <p><b>Proposed resolution:</b></p>
17868
17869 <p>Add the following to the end of 23.2.4 [associative.reqmts] paragraph 4: 
17870 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
17871   are <i>stable</i>: they preserve the relative ordering of equivalent
17872   elements.</p> 
17873
17874 <p><i>[Lillehammer: Matt provided wording]</i></p>
17875
17876 <p><i>[Joe Gottman points out that the provided wording does not address
17877 multimap and multiset.  N1780 also addresses this issue and suggests
17878 wording.]</i></p>
17879
17880
17881 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
17882
17883
17884
17885
17886 <p><b>Rationale:</b></p>
17887 <p>The LWG agrees that this guarantee is necessary for common user
17888   idioms to work, and that all existing implementations provide this
17889   property.  Note that this resolution guarantees stability for
17890   multimap and multiset, not for all associative containers in
17891   general.</p>
17892
17893
17894
17895
17896
17897
17898 <hr>
17899 <h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
17900 <p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts], 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17901  <b>Submitter:</b> Keith Baker <b>Opened:</b> 2002-07-23 <b>Last modified:</b> 2010-10-29</p>
17902 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
17903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17904 <p><b>Discussion:</b></p>
17905
17906 <p>
17907 In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts]
17908 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
17909 exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function
17910 exceptions() found in 27.5.4 [ios] be used instead?
17911 </p>
17912
17913
17914
17915 <p><b>Proposed resolution:</b></p>
17916 <p>
17917 In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change
17918 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
17919 </p>
17920
17921
17922 <p><b>Rationale:</b></p>
17923 <p>Fixes an obvious typo.</p>
17924
17925
17926
17927
17928
17929 <hr>
17930 <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
17931 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17932  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2010-10-29</p>
17933 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
17934 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17935 <p><b>Discussion:</b></p>
17936 <p>
17937 In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
17938 14 all contain references to "basic_ios::" which should be
17939 "ios_base::".
17940 </p>
17941
17942
17943 <p><b>Proposed resolution:</b></p>
17944 <p>
17945 Change all references to "basic_ios" in Table 90, Table 91, and
17946 paragraph 14 to "ios_base".
17947 </p>
17948
17949
17950 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
17951
17952
17953
17954
17955 <hr>
17956 <h3><a name="376"></a>376. basic_streambuf semantics</h3>
17957 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17958  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2010-10-29</p>
17959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
17960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17961 <p><b>Discussion:</b></p>
17962 <p>
17963 In Section 27.8.1.4 [stringbuf.virtuals], Table 90, the implication is that
17964 the four conditions should be mutually exclusive, but they are not.
17965 The first two cases, as written, are subcases of the third.</p>
17966
17967 <p>
17968 As written, it is unclear what should be the result if cases 1 and 2
17969 are both true, but case 3 is false.
17970 </p>
17971
17972
17973
17974 <p><b>Proposed resolution:</b></p>
17975
17976 <p>Rewrite these conditions as:</p>
17977 <blockquote>
17978 <p>
17979   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
17980 </p>
17981
17982 <p>
17983   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
17984 </p>
17985
17986 <p>
17987   (which &amp; (ios_base::in|ios_base::out)) == 
17988 (ios_base::in|ios_base::out)
17989    and way == either ios_base::beg or ios_base::end
17990 </p>
17991
17992 <p>Otherwise</p>
17993 </blockquote>
17994
17995
17996
17997 <p><b>Rationale:</b></p>
17998 <p>It's clear what we wanted to say, we just failed to say it.  This
17999   fixes it.</p>
18000
18001
18002
18003
18004
18005 <hr>
18006 <h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
18007 <p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18008  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
18009 <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>
18010 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18011 <p><b>Discussion:</b></p>
18012 <p>
18013 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
18014 </p>
18015 <pre>  charT do_widen (char c) const;
18016
18017   -11- Effects: Applies the simplest reasonable transformation from
18018        a char value or sequence of char values to the corresponding
18019        charT value or values. The only characters for which unique
18020        transformations are required are those in the basic source
18021        character set (2.2). For any named ctype category with a
18022        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
18023        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
18024 </pre>
18025 <p>
18026 Shouldn't the last sentence instead read
18027 </p>
18028 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
18029        and valid ctype_base::mask value M
18030        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
18031 </pre>
18032 <p>
18033 I.e., if the narrow character c is not a member of a class of
18034 characters then neither is the widened form of c. (To paraphrase
18035 footnote 224.)
18036 </p>
18037
18038
18039 <p><b>Proposed resolution:</b></p>
18040 <p>
18041 Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the
18042 following text:
18043 </p>
18044 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
18045        and valid ctype_base::mask value M,
18046        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
18047 </pre>
18048
18049 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
18050
18051
18052
18053
18054 <p><b>Rationale:</b></p>
18055 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
18056
18057
18058
18059
18060
18061 <hr>
18062 <h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
18063 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18064  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
18065 <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>
18066 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18067 <p><b>Discussion:</b></p>
18068 <p>
18069 Tables 53 and 54 in 22.4.1.5 [locale.codecvt.byname] are both titled "convert
18070 result values," when surely "do_in/do_out result values" must have
18071 been intended for Table 53 and "do_unshift result values" for Table
18072 54.
18073 </p>
18074 <p>
18075 Table 54, row 3 says that the meaning of partial is "more characters
18076 needed to be supplied to complete termination." The function is not
18077 supplied any characters, it is given a buffer which it fills with
18078 characters or, more precisely, destination elements (i.e., an escape
18079 sequence). So partial means that space for more than (to_limit - to)
18080 destination elements was needed to terminate a sequence given the
18081 value of state.
18082 </p>
18083
18084
18085 <p><b>Proposed resolution:</b></p>
18086 <p>
18087 Change the title of Table 53 to "do_in/do_out result values" and
18088 the title of Table 54 to "do_unshift result values."
18089 </p>
18090 <p>
18091 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
18092 heading Meaning, to "space for more than (to_limit - to) destination
18093 elements was needed to terminate a sequence given the value of state."
18094 </p>
18095
18096
18097
18098
18099 <hr>
18100 <h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
18101 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18102  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
18103 <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>
18104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18105 <p><b>Discussion:</b></p>
18106 <p>
18107 All but one codecvt member functions that take a state_type argument
18108 list as one of their preconditions that the state_type argument have
18109 a valid value. However, according to 22.2.1.5.2, p6,
18110 codecvt::do_unshift() is the only codecvt member that is supposed to
18111 return error if the state_type object is invalid.
18112 </p>
18113
18114 <p>
18115 It seems to me that the treatment of state_type by all codecvt member
18116 functions should be the same and the current requirements should be
18117 changed. Since the detection of invalid state_type values may be
18118 difficult in general or computationally expensive in some specific
18119 cases, I propose the following:
18120 </p>
18121
18122
18123 <p><b>Proposed resolution:</b></p>
18124 <p>
18125 Add a new paragraph before 22.2.1.5.2, p5, and after the function
18126 declaration below
18127 </p>
18128 <pre>    result do_unshift(stateT&amp; state,
18129     externT* to, externT* to_limit, externT*&amp; to_next) const;
18130 </pre>
18131 <p>
18132 as follows:
18133 </p>
18134 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
18135     if at the beginning of a sequence, or else equal to the result of
18136     converting the preceding characters in the sequence.
18137 </pre>
18138 <p>
18139 and change the text in Table 54, row 4, the <b>error</b> row, under
18140 the heading Meaning, from
18141 </p>
18142 <pre>    state has invalid value
18143 </pre>
18144 <p>
18145 to
18146 </p>
18147 <pre>    an unspecified error has occurred
18148 </pre>
18149
18150
18151 <p><b>Rationale:</b></p>
18152 <p>The intent is that implementations should not be required to detect
18153 invalid state values; such a requirement appears nowhere else.  An
18154 invalid state value is a precondition violation, <i>i.e.</i> undefined
18155 behavior.  Implementations that do choose to detect invalid state
18156 values, or that choose to detect any other kind of error, may return
18157 <b>error</b> as an indication.</p>
18158
18159
18160
18161
18162
18163 <hr>
18164 <h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
18165 <p><b>Section:</b> 24.2.6 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18166  <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Opened:</b> 2002-10-17 <b>Last modified:</b> 2010-10-29</p>
18167 <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>
18168 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18169 <p><b>Discussion:</b></p>
18170 <p>
18171 Following a discussion on the boost list regarding end iterators and
18172 the possibility of performing operator--() on them, it seems to me
18173 that there is a typo in the standard.  This typo has nothing to do
18174 with that discussion.
18175 </p>
18176
18177 <p>
18178 I have checked this newsgroup, as well as attempted a search of the
18179 Active/Defect/Closed Issues List on the site for the words "s is
18180 derefer" so I believe this has not been proposed before.  Furthermore,
18181 the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> on section
18182 24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> is not related to this issue.
18183 </p>
18184
18185 <p>
18186 The standard makes the following assertion on bidirectional iterators,
18187 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
18188 </p>
18189
18190 <pre>                         operational  assertion/note
18191 expression  return type   semantics    pre/post-condition
18192
18193 --r          X&amp;                        pre: there exists s such
18194                                        that r == ++s.
18195                                        post: s is dereferenceable.
18196                                        --(++r) == r.
18197                                        --r == --s implies r == s.
18198                                        &amp;r == &amp;--r.
18199 </pre>
18200
18201 <p>
18202 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
18203 </p>
18204
18205 <p>
18206 In particular, "s is dereferenceable" seems to be in error.  It seems
18207 that the intention was to say "r is dereferenceable".
18208 </p>
18209
18210 <p>
18211 If it were to say "r is dereferenceable" it would
18212 make perfect sense.  Since s must be dereferenceable prior to
18213 operator++, then the natural result of operator-- (to undo operator++)
18214 would be to make r dereferenceable.  Furthermore, without other
18215 assertions, and basing only on precondition and postconditions, we
18216 could not otherwise know this.  So it is also interesting information.
18217 </p>
18218
18219
18220
18221 <p><b>Proposed resolution:</b></p>
18222 <p>
18223 Change the guarantee to "postcondition: r is dereferenceable."
18224 </p>
18225
18226
18227 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
18228
18229
18230
18231
18232 <hr>
18233 <h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
18234 <p><b>Section:</b> 25.4.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18235  <b>Submitter:</b> Hans Bos <b>Opened:</b> 2002-10-18 <b>Last modified:</b> 2010-10-29</p>
18236 <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>
18237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18238 <p><b>Discussion:</b></p>
18239 <p>
18240 Section 25.4.3.3 [equal.range]
18241 states that at most 2 * log(last - first) + 1
18242 comparisons are allowed for equal_range.
18243 </p>
18244
18245 <p>It is not possible to implement equal_range with these constraints.</p>
18246
18247 <p>In a range of one element as in:</p>
18248 <pre>    int x = 1;
18249     equal_range(&amp;x, &amp;x + 1, 1)
18250 </pre>
18251
18252 <p>it is easy to see that at least 2 comparison operations are needed.</p>
18253
18254 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
18255
18256 <p>I have checked a few libraries and they all use the same (nonconforming)
18257 algorithm for equal_range that has a complexity of</p>
18258 <pre>     2* log(distance(first, last)) + 2.
18259 </pre>
18260 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
18261
18262 <p>
18263 It is easy to see that 2 * log(distance) + 2 comparisons are enough
18264 since equal range can be implemented with lower_bound and upper_bound
18265 (both log(distance) + 1).
18266 </p>
18267
18268 <p>
18269 I think it is better to require something like 2log(distance) + O(1)  (or
18270 even logarithmic as multiset::equal_range).
18271 Then an implementation has more room to optimize for certain cases (e.g.
18272 have log(distance) characteristics when at most match is found in the range
18273 but 2log(distance) + 4 for the worst case).
18274 </p>
18275
18276
18277
18278 <p><b>Proposed resolution:</b></p>
18279 <p>In 25.4.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
18280 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
18281
18282 <p>In 25.4.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
18283 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
18284
18285 <p>In 25.4.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
18286 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
18287
18288 <p><i>[Matt provided wording]</i></p>
18289
18290
18291
18292 <p><b>Rationale:</b></p>
18293 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
18294   decided that threw away too much valuable information.  The fact
18295   that lower_bound is twice as fast as equal_range is important.
18296   However, it's better to allow an arbitrary additive constant than to
18297   specify an exact count.  An exact count would have to
18298   involve <tt>floor</tt> or <tt>ceil</tt>.  It would be too easy to
18299   get this wrong, and don't provide any substantial value for users.</p>
18300
18301
18302
18303
18304 <hr>
18305 <h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
18306 <p><b>Section:</b> 24.5.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18307  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2010-10-29</p>
18308 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18309 <p><b>Discussion:</b></p>
18310 <p>In 24.5.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt> 
18311 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
18312 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
18313 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
18314
18315 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
18316   necessarily have a return type
18317   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
18318   return type is merely required to be convertible
18319   to <tt>Iterator</tt>'s value type.  The return type specified for
18320   reverse_iterator's operator[] would thus appear to be impossible.</p>
18321
18322 <p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, the type of
18323   <tt>a[n]</tt> will continue to be required (for random access
18324   iterators) to be convertible to the value type, and also <tt>a[n] =
18325   t</tt> will be a valid expression.  Implementations of
18326   <tt>reverse_iterator</tt> will likely need to return a proxy from
18327   <tt>operator[]</tt> to meet these requirements. As mentioned in the
18328   comment from Dave Abrahams, the simplest way to specify that
18329   <tt>reverse_iterator</tt> meet this requirement to just mandate
18330   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
18331
18332
18333
18334 <p><b>Proposed resolution:</b></p>
18335
18336 <p>In 24.5.1.2 [reverse.iter.requirements] change:</p>
18337
18338 <blockquote>
18339 <pre>reference operator[](difference_type n) const;
18340 </pre>
18341 </blockquote>
18342
18343 <p>to:</p>
18344
18345 <blockquote>
18346 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.2.7 [random.access.iterators]
18347 </pre>
18348 </blockquote>
18349
18350
18351
18352
18353 <p><i>[
18354 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
18355     that the return type of reverse_iterator's operator[] is
18356     unspecified, allowing the random access iterator requirements to
18357     impose an appropriate return type.  If we accept 299's proposed
18358     resolution (and I think we should), the return type will be
18359     readable and writable, which is about as good as we can do.
18360 ]</i></p>
18361
18362
18363
18364
18365
18366
18367 <hr>
18368 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
18369 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18370  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2010-10-29</p>
18371 <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>
18372 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18373 <p><b>Discussion:</b></p>
18374 <p>
18375 The absence of explicit description of std::complex&lt;T&gt; layout
18376 makes it imposible to reuse existing software developed in traditional
18377 languages like Fortran or C with unambigous and commonly accepted
18378 layout assumptions.  There ought to be a way for practitioners to
18379 predict with confidence the layout of std::complex&lt;T&gt; whenever T
18380 is a numerical datatype.  The absence of ways to access individual
18381 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
18382 severe pessimizations. For example, the only way to change,
18383 independently, the real and imaginary parts is to write something like
18384 </p>
18385
18386 <pre>complex&lt;T&gt; z;
18387 // ...
18388 // set the real part to r
18389 z = complex&lt;T&gt;(r, z.imag());
18390 // ...
18391 // set the imaginary part to i
18392 z = complex&lt;T&gt;(z.real(), i);
18393 </pre>
18394
18395 <p>
18396 At this point, it seems appropriate to recall that a complex number
18397 is, in effect, just a pair of numbers with no particular invariant to
18398 maintain.  Existing practice in numerical computations has it that a
18399 complex number datatype is usually represented by Cartesian
18400 coordinates. Therefore the over-encapsulation put in the specification
18401 of std::complex&lt;&gt; is not justified.
18402 </p>
18403
18404
18405
18406 <p><b>Proposed resolution:</b></p>
18407 <p>Add the following requirements to 26.4 [complex.numbers] as 26.3/4:</p>
18408 <blockquote>
18409 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
18410
18411 <ul>
18412 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
18413 is well-formed; and</li>
18414 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
18415 real part of z; and</li>
18416 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
18417 imaginary part of z.</li>
18418 </ul>
18419
18420 <p>
18421 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
18422 and the expression a[i] is well-defined for an integer expression
18423 i then:
18424 </p>
18425
18426 <ul>
18427 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
18428 part of a[i]; and</li>
18429 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
18430 imaginary part of a[i].</li>
18431 </ul>
18432 </blockquote>
18433
18434 <p>
18435 In 26.4.2 [complex] and 26.4.3 [complex.special] add the following member functions
18436 (changing <tt>T</tt> to concrete types as appropriate for the specializations).
18437 </p>
18438
18439 <blockquote><pre>void real(T);
18440 void imag(T);
18441 </pre></blockquote>
18442
18443 <p>
18444 Add to 26.4.4 [complex.members]
18445 </p>
18446
18447 <blockquote>
18448 <pre>T real() const;
18449 </pre>
18450 <blockquote>
18451 <i>Returns:</i> the value of the real component
18452 </blockquote>
18453 <pre>void real(T val);
18454 </pre>
18455 <blockquote>
18456 Assigns val to the real component.
18457 </blockquote>
18458 <pre>T imag() const;
18459 </pre>
18460 <blockquote>
18461 <i>Returns:</i> the value of the imaginary component
18462 </blockquote>
18463 <pre>void imag(T val);
18464 </pre>
18465 <blockquote>
18466 Assigns val to the imaginary component.
18467 </blockquote>
18468 </blockquote>
18469
18470 <p><i>[Kona: The layout guarantee is absolutely necessary for C
18471   compatibility.  However, there was disagreement about the other part
18472   of this proposal: retrieving elements of the complex number as
18473   lvalues.  An alternative: continue to have real() and imag() return
18474   rvalues, but add set_real() and set_imag().  Straw poll: return
18475   lvalues - 2, add setter functions - 5.  Related issue: do we want
18476   reinterpret_cast as the interface for converting a complex to an
18477   array of two reals, or do we want to provide a more explicit way of
18478   doing it?  Howard will try to resolve this issue for the next
18479   meeting.]</i></p>
18480
18481
18482 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
18483
18484
18485 <p><i>[
18486 Bellevue:
18487 ]</i></p>
18488
18489
18490 <blockquote>
18491 Second half of proposed wording replaced and moved to Ready.
18492 </blockquote>
18493
18494 <p><i>[
18495 Pre-Sophia Antipolis, Howard adds:
18496 ]</i></p>
18497
18498
18499 <blockquote>
18500 Added the members to 26.4.3 [complex.special] and changed from Ready to Review.
18501 </blockquote>
18502
18503 <p><i>[
18504 Post-Sophia Antipolis:
18505 ]</i></p>
18506
18507
18508 <blockquote>
18509 Moved from WP back to Ready so that the "and 26.4.3 [complex.special]" in the proposed
18510 resolution can be officially applied.
18511 </blockquote>
18512
18513
18514
18515 <p><b>Rationale:</b></p>
18516 <p>The LWG believes that C99 compatibility would be enough
18517 justification for this change even without other considerations.  All
18518 existing implementations already have the layout proposed here.</p>
18519
18520
18521
18522
18523
18524 <hr>
18525 <h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
18526 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18527  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2010-10-29</p>
18528 <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>
18529 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18530 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
18531 <p><b>Discussion:</b></p>
18532 <p>Consider the following program:</p>
18533 <pre>    #include &lt;iostream&gt;
18534     #include &lt;ostream&gt;
18535     #include &lt;vector&gt;
18536     #include &lt;valarray&gt;
18537     #include &lt;algorithm&gt;
18538     #include &lt;iterator&gt;
18539     template&lt;typename Array&gt;
18540     void print(const Array&amp; a)
18541     {
18542     using namespace std;
18543     typedef typename Array::value_type T;
18544     copy(&amp;a[0], &amp;a[0] + a.size(),
18545     ostream_iterator&lt;T&gt;(std::cout, " "));
18546     }
18547     template&lt;typename T, unsigned N&gt;
18548     unsigned size(T(&amp;)[N]) { return N; }
18549     int main()
18550     {
18551     double array[] = { 0.89, 9.3, 7, 6.23 };
18552     std::vector&lt;double&gt; v(array, array + size(array));
18553     std::valarray&lt;double&gt; w(array, size(array));
18554     print(v); // #1
18555     std::cout &lt;&lt; std::endl;
18556     print(w); // #2
18557     std::cout &lt;&lt; std::endl;
18558     }
18559 </pre>
18560
18561 <p>While the call numbered #1 succeeds, the call numbered #2 fails
18562 because the const version of the member function
18563 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
18564 const-reference. That seems to be so for no apparent reason, no
18565 benefit. Not only does that defeats users' expectation but it also
18566 does hinder existing software (written either in C or Fortran)
18567 integration within programs written in C++.  There is no reason why
18568 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
18569 should not return a const T&amp;.</p>
18570
18571
18572 <p><b>Proposed resolution:</b></p>
18573 <p>In the class synopsis in 26.6.2 [template.valarray], and in
18574 26.6.2.3 [valarray.access] just above paragraph 1, change</p>
18575 <pre>  T operator[](size_t const);
18576 </pre>
18577 <p>to</p>
18578 <pre>  const T&amp; operator[](size_t const);
18579 </pre>
18580
18581 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
18582   wehre it belongs.]</i></p>
18583
18584
18585
18586
18587 <p><b>Rationale:</b></p>
18588 <p>Return by value seems to serve no purpose.  Valaray was explicitly
18589 designed to have a specified layout so that it could easily be
18590 integrated with libraries in other languages, and return by value
18591 defeats that purpose.  It is believed that this change will have no
18592 impact on allowable optimizations.</p>
18593
18594
18595
18596
18597
18598 <hr>
18599 <h3><a name="391"></a>391. non-member functions specified as const</h3>
18600 <p><b>Section:</b> 22.3.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18601  <b>Submitter:</b> James Kanze <b>Opened:</b> 2002-12-10 <b>Last modified:</b> 2010-10-29</p>
18602 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18603 <p><b>Discussion:</b></p>
18604 <p>
18605 The specifications of toupper and tolower both specify the functions as
18606 const, althought they are not member functions, and are not specified as
18607 const in the header file synopsis in section 22.3 [locales].
18608 </p>
18609
18610
18611 <p><b>Proposed resolution:</b></p>
18612 <p>In 22.3.3.2 [conversions], remove <tt>const</tt> from the function
18613   declarations of std::toupper and std::tolower</p>
18614
18615
18616 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
18617
18618
18619
18620
18621 <hr>
18622 <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
18623 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18624  <b>Submitter:</b> James Kanze <b>Opened:</b> 2003-01-03 <b>Last modified:</b> 2010-10-29</p>
18625 <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>
18626 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18627 <p><b>Discussion:</b></p>
18628 <p>
18629 In 26.8 [c.math], the C++ standard refers to the C standard for the
18630 definition of rand(); in the C standard, it is written that "The
18631 implementation shall behave as if no library function calls the rand
18632 function."
18633 </p>
18634
18635 <p>
18636 In 25.3.12 [alg.random.shuffle], there is no specification as to
18637 how the two parameter version of the function generates its random
18638 value.  I believe that all current implementations in fact call rand()
18639 (in contradiction with the requirement avove); if an implementation does
18640 not call rand(), there is the question of how whatever random generator
18641 it does use is seeded.  Something is missing.
18642 </p>
18643
18644
18645
18646 <p><b>Proposed resolution:</b></p>
18647 <p>
18648 In [lib.c.math], add a paragraph specifying that the C definition of
18649 rand shal be modified to say that "Unless otherwise specified, the
18650 implementation shall behave as if no library function calls the rand
18651 function."
18652 </p>
18653
18654 <p>
18655 In [lib.alg.random.shuffle], add a sentence to the effect that "In
18656 the two argument form of the function, the underlying source of
18657 random numbers is implementation defined. [Note: in particular, an
18658 implementation is permitted to use <tt>rand</tt>.]
18659 </p>
18660
18661
18662 <p><b>Rationale:</b></p>
18663 <p>The original proposed resolution proposed requiring the
18664   two-argument from of <tt>random_shuffle</tt> to
18665   use <tt>rand</tt>. We don't want to do that, because some existing
18666   implementations already use something else: gcc
18667   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
18668   problem if the number of elements in the sequence is greater than
18669   RAND_MAX.</p> 
18670
18671
18672
18673
18674
18675 <hr>
18676 <h3><a name="396"></a>396. what are characters zero and one</h3>
18677 <p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18678  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2010-10-29</p>
18679 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
18680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18681 <p><b>Discussion:</b></p>
18682     <p>
18683 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
18684 having the value of 0 or 1 but there is no definition of what
18685 that means for charT other than char and wchar_t. And even for
18686 those two types, the values 0 and 1 are not actually what is
18687 intended -- the values '0' and '1' are. This, along with the
18688 converse problem in the description of to_string() in 23.3.5.2,
18689 p33, looks like a defect remotely related to DR 303.
18690     </p>
18691     <p>
18692 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
18693     </p>
18694     <pre>23.3.5.1:
18695   -6-  An element of the constructed string has value zero if the
18696        corresponding character in str, beginning at position pos,
18697        is 0. Otherwise, the element has the value one.
18698     </pre>
18699     <pre>23.3.5.2:
18700   -33-  Effects: Constructs a string object of the appropriate
18701         type and initializes it to a string of length N characters.
18702         Each character is determined by the value of its
18703         corresponding bit position in *this. Character position N
18704         ?- 1 corresponds to bit position zero. Subsequent decreasing
18705         character positions correspond to increasing bit positions.
18706         Bit value zero becomes the character 0, bit value one becomes
18707         the character 1.
18708     </pre>
18709     <p>
18710 Also note the typo in 23.3.5.1, p6: the object under construction
18711 is a bitset, not a string.
18712     </p>
18713
18714 <p><i>[
18715 Sophia Antipolis:
18716 ]</i></p>
18717
18718
18719 <blockquote>
18720 <p>
18721 We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
18722 another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>) previously resolved at this meeting.
18723 </p>
18724 <p>
18725 Disposition: move to ready.
18726 </p>
18727 <p>
18728 We request that Howard submit a separate issue regarding the three to_string overloads.
18729 </p>
18730 </blockquote>
18731
18732   
18733
18734 <p><b>Proposed resolution:</b></p>
18735 <p>Change the constructor's function declaration immediately before 
18736 20.5.1 [bitset.cons] p3 to:</p>
18737 <pre>    template &lt;class charT, class traits, class Allocator&gt;
18738     explicit
18739     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
18740            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
18741            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
18742              basic_string&lt;charT, traits, Allocator&gt;::npos,
18743            charT zero = charT('0'), charT one = charT('1'))
18744 </pre>
18745 <p>Change the first two sentences of 20.5.1 [bitset.cons] p6 to: "An
18746 element of the constructed string has value 0 if the corresponding
18747 character in <i>str</i>, beginning at position <i>pos</i>,
18748 is <i>zero</i>. Otherwise, the element has the value 1.</p>
18749
18750 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
18751     "The function then throws invalid_argument if any of the rlen
18752     characters in str beginning at position pos is other than <i>zero</i>
18753     or <i>one</i>. The function uses traits::eq() to compare the character
18754     values."
18755 </p>
18756
18757 <p>Change the declaration of the <tt>to_string</tt> member function
18758   immediately before 20.5.2 [bitset.members] p33 to:</p>
18759 <pre>    template &lt;class charT, class traits, class Allocator&gt;
18760     basic_string&lt;charT, traits, Allocator&gt; 
18761     to_string(charT zero = charT('0'), charT one = charT('1')) const;
18762 </pre>
18763 <p>Change the last sentence of 20.5.2 [bitset.members] p33 to: "Bit
18764   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
18765   character <tt><i>one</i></tt>.</p>
18766 <p>Change 20.5.4 [bitset.operators] p8 to:</p>
18767 <p><b>Returns</b>:</p> 
18768 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
18769       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
18770       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
18771 </pre>
18772
18773
18774 <p><b>Rationale:</b></p>
18775 <p>There is a real problem here: we need the character values of '0'
18776   and '1', and we have no way to get them since strings don't have
18777   imbued locales. In principle the "right" solution would be to
18778   provide an extra object, either a ctype facet or a full locale,
18779   which would be used to widen '0' and '1'. However, there was some
18780   discomfort about using such a heavyweight mechanism.  The proposed
18781   resolution allows those users who care about this issue to get it
18782   right.</p>
18783 <p>We fix the inserter to use the new arguments.  Note that we already
18784   fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
18785
18786
18787
18788 <p><i>[
18789 post Bellevue:
18790 ]</i></p>
18791
18792
18793 <blockquote>
18794 We are happy with the resolution as proposed, and we move this to Ready.
18795 </blockquote>
18796
18797 <p><i>[
18798 Howard adds:
18799 ]</i></p>
18800
18801
18802 <blockquote>
18803 The proposed wording neglects the 3 newer to_string overloads.
18804 </blockquote>
18805
18806
18807
18808
18809 <hr>
18810 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
18811 <p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18812  <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
18813 <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>
18814 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18815 <p><b>Discussion:</b></p>
18816 <p>
18817 20.9.5.1 [allocator.members] allocator members, contains
18818 the following 3 lines:
18819 </p>
18820
18821 <pre>  12 Returns: new((void *) p) T( val)
18822      void destroy(pointer p);
18823   13 Returns: ((T*) p)-&gt;~T()
18824 </pre>
18825
18826 <p>
18827 The type cast "(T*) p" in the last line is redundant cause
18828 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
18829 </p>
18830
18831
18832 <p><b>Proposed resolution:</b></p>
18833 <p>
18834 Replace "((T*) p)" with "p".
18835 </p>
18836
18837
18838 <p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
18839
18840
18841
18842
18843 <hr>
18844 <h3><a name="401"></a>401.  incorrect type casts in table 32 in lib.allocator.requirements</h3>
18845 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18846  <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
18847 <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>
18848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18849 <p><b>Discussion:</b></p>
18850 <p>
18851 I think that in par2 of  [default.con.req] the last two
18852 lines of table 32 contain two incorrect type casts. The lines are ...
18853 </p>
18854
18855 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
18856   a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
18857 </pre>
18858
18859 <p>
18860 .... with the prerequisits coming from the preceding two paragraphs, especially
18861 from table 31:
18862 </p>
18863
18864 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
18865   alloc&lt;T&gt;::pointer    p     ;// random access iterator
18866                               // (may be different from T*)
18867   alloc&lt;T&gt;::reference  r = *p;// T&amp;
18868   T const&amp;             t     ;
18869 </pre>
18870
18871 <p>
18872 For that two type casts ("(void*)p" and "(T*)p") to be well-formed
18873 this would require then conversions to T* and void* for all
18874 alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
18875 requirements for alloc&lt;T&gt;::pointer, additionally to the only
18876 current requirement (being a random access iterator).
18877 </p>
18878
18879
18880 <p><b>Proposed resolution:</b></p>
18881
18882 <p>
18883 Accept proposed wording from
18884 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
18885 </p>
18886
18887 <p>
18888 Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
18889 "p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
18890 in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
18891 </p>
18892
18893 <p><i>[Kona: The LWG thinks this is somewhere on the border between
18894   Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
18895   object at the location <i>p</i>.  It's reading too much into the
18896   description to think that literally calling <tt>new</tt> is
18897   required.  Tweaking this description is low priority until we can do
18898   a thorough review of allocators, and, in particular, allocators with
18899   non-default pointer types.]</i></p>
18900
18901
18902 <p><i>[
18903 Batavia:  Proposed resolution changed to less code and more description.
18904 ]</i></p>
18905
18906
18907 <p><i>[
18908 post Oxford:  This would be rendered NAD Editorial by acceptance of
18909 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
18910 ]</i></p>
18911
18912
18913 <p><i>[
18914 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
18915 was subsequently split out into a separate paper N2436 for the purposes of voting.
18916 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
18917 issue to Ready status to be voted into the WP at Kona.
18918 ]</i></p>
18919
18920
18921
18922
18923
18924
18925
18926 <hr>
18927 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
18928 <p><b>Section:</b> 20.2.5 [allocator.requirements], 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18929  <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
18930 <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>
18931 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18932 <p><b>Discussion:</b></p>
18933 <p>
18934 This applies to the new expression that is contained in both par12 of
18935 20.9.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
18936 I think this new expression is wrong, involving unintended side
18937 effects.
18938 </p>
18939
18940
18941 <p>20.9.5.1 [allocator.members]  contains the following 3 lines:</p>
18942
18943 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
18944      void construct(pointer p, const_reference val);
18945   12 Returns: new((void *) p) T( val)
18946 </pre>
18947
18948
18949 <p> [default.con.req] in table 32 has the following line:</p>
18950 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
18951 </pre>
18952
18953 <p>
18954 .... with the prerequisits coming from the preceding two paragraphs,
18955 especially from table 31:
18956 </p>
18957
18958 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
18959   alloc&lt;T&gt;::pointer    p     ;// random access iterator
18960                               // (may be different from T*)
18961   alloc&lt;T&gt;::reference  r = *p;// T&amp;
18962   T const&amp;             t     ;
18963 </pre>
18964
18965 <p>
18966 Cause of using "new" but not "::new", any existing "T::operator new"
18967 function will hide the global placement new function. When there is no
18968 "T::operator new" with adequate signature,
18969 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
18970 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
18971 would be adding placement new and delete functions with adequate
18972 signature and semantic to class T, but class T might come from another
18973 party. Maybe even worse is the case when T has placement new and
18974 delete functions with adequate signature but with "unknown" semantic:
18975 I dont like to speculate about it, but whoever implements
18976 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
18977 probably must think about it.
18978 </p>
18979
18980
18981 <p><b>Proposed resolution:</b></p>
18982 <p>
18983 Replace "new" with "::new" in both cases.
18984 </p>
18985
18986
18987
18988
18989
18990
18991
18992 <hr>
18993 <h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
18994 <p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18995  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2003-03-25 <b>Last modified:</b> 2010-10-29</p>
18996 <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>
18997 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18998 <p><b>Discussion:</b></p>
18999
19000 <p>
19001 std::basic_string, 21.4 [basic.string] paragraph 2 says that
19002 basic_string "conforms to the requirements of a Sequence, as specified
19003 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
19004 include any prohibition on swap members throwing exceptions.
19005 </p>
19006
19007 <p>
19008 Section 23.2 [container.requirements] paragraph 10 does limit conditions under
19009 which exceptions may be thrown, but applies only to "all container
19010 types defined in this clause" and so excludes basic_string::swap
19011 because it is defined elsewhere.
19012 </p>
19013
19014 <p>
19015 Eric Niebler points out that 21.4 [basic.string] paragraph 5 explicitly
19016 permits basic_string::swap to invalidates iterators, which is
19017 disallowed by 23.2 [container.requirements] paragraph 10. Thus the standard would
19018 be contradictory if it were read or extended to read as having
19019 basic_string meet 23.2 [container.requirements] paragraph 10 requirements.
19020 </p>
19021
19022 <p>
19023 Yet several LWG members have expressed the belief that the original
19024 intent was that basic_string::swap should not throw exceptions as
19025 specified by 23.2 [container.requirements] paragraph 10, and that the standard is
19026 unclear on this issue. The complexity of basic_string::swap is
19027 specified as "constant time", indicating the intent was to avoid
19028 copying (which could cause a bad_alloc or other exception). An
19029 important use of swap is to ensure that exceptions are not thrown in
19030 exception-safe code.
19031 </p>
19032
19033 <p>
19034 Note: There remains long standing concern over whether or not it is
19035 possible to reasonably meet the 23.2 [container.requirements] paragraph 10 swap
19036 requirements when allocators are unequal. The specification of
19037 basic_string::swap exception requirements is in no way intended to
19038 address, prejudice, or otherwise impact that concern.
19039 </p>
19040
19041
19042
19043
19044
19045
19046
19047 <p><b>Proposed resolution:</b></p>
19048 <p>
19049 In 21.4.6.8 [string::swap], add a throws clause:
19050 </p>
19051
19052 <p>
19053 Throws: Shall not throw exceptions.
19054 </p>
19055
19056
19057
19058
19059
19060 <hr>
19061 <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
19062 <p><b>Section:</b> 17.6.3.6 [replacement.functions], 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19063  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-04-24 <b>Last modified:</b> 2010-10-29</p>
19064 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19065 <p><b>Discussion:</b></p>
19066 <p>
19067 The eight basic dynamic memory allocation functions (single-object
19068 and array versions of ::operator new and ::operator delete, in the
19069 ordinary and nothrow forms) are replaceable.  A C++ program may
19070 provide an alternative definition for any of them, which will be used
19071 in preference to the implementation's definition.  
19072 </p>
19073
19074 <p>
19075 Three different parts of the standard mention requirements on
19076 replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single]
19077 and 18.6.1.2 [new.delete.array], and 3.7.3 [basic.stc.auto].
19078 </p>
19079
19080 <p>None of these three places say whether a replacement function may
19081   be declared inline.  18.6.1.1 [new.delete.single] paragraph 2 specifies a
19082   signature for the replacement function, but that's not enough:
19083   the <tt>inline</tt> specifier is not part of a function's signature.
19084   One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
19085   requires that "an inline function shall be defined in every
19086   translation unit in which it is used," but this may not be quite
19087   specific enough either.  We should either explicitly allow or
19088   explicitly forbid inline replacement memory allocation
19089   functions.</p>
19090
19091
19092 <p><b>Proposed resolution:</b></p>
19093 <p>
19094 Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3:
19095 "The program's definitions shall not be specified as <tt>inline</tt>.
19096 No diagnostic is required."
19097 </p>
19098
19099 <p><i>[Kona: added "no diagnostic is required"]</i></p>
19100
19101
19102
19103
19104 <p><b>Rationale:</b></p>
19105 <p>
19106 The fact that <tt>inline</tt> isn't mentioned appears to have been
19107 nothing more than an oversight.  Existing implementations do not
19108 permit inline functions as replacement memory allocation functions.
19109 Providing this functionality would be difficult in some cases, and is
19110 believed to be of limited value.
19111 </p>
19112
19113
19114
19115
19116
19117 <hr>
19118 <h3><a name="405"></a>405. qsort and POD</h3>
19119 <p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19120  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2003-04-08 <b>Last modified:</b> 2010-10-29</p>
19121 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
19122 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19123 <p><b>Discussion:</b></p>
19124 <p>
19125 Section 25.5 [alg.c.library] describes bsearch and qsort, from the C
19126 standard library. Paragraph 4 does not list any restrictions on qsort,
19127 but it should limit the base parameter to point to POD.  Presumably,
19128 qsort sorts the array by copying bytes, which requires POD.
19129 </p>
19130
19131
19132 <p><b>Proposed resolution:</b></p>
19133 <p>
19134 In 25.5 [alg.c.library] paragraph 4, just after the declarations and
19135 before the nonnormative note, add these words: "both of which have the
19136 same behavior as the original declaration.  The behavior is undefined
19137 unless the objects in the array pointed to by <i>base</i> are of POD
19138 type."
19139 </p>
19140
19141 <p><i>[Something along these lines is clearly necessary.  Matt
19142   provided wording.]</i></p>
19143
19144
19145
19146
19147
19148
19149 <hr>
19150 <h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
19151 <p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19152  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-04-27 <b>Last modified:</b> 2010-10-29</p>
19153 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
19154 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19155 <p><b>Discussion:</b></p>
19156 <p>
19157 There is a possible defect in the standard: the standard text was
19158 never intended to prevent arbitrary ForwardIterators, whose operations
19159 may throw exceptions, from being passed, and it also wasn't intended
19160 to require a temporary buffer in the case where ForwardIterators were
19161 passed (and I think most implementations don't use one).  As is, the
19162 standard appears to impose requirements that aren't met by any
19163 existing implementation.
19164 </p>
19165
19166
19167 <p><b>Proposed resolution:</b></p>
19168 <p>Replace 23.4.1.4 [vector.modifiers] paragraph 1 with:</p>
19169 <blockquote><p>
19170   1- Notes: Causes reallocation if the new size is greater than the
19171   old capacity. If no reallocation happens, all the iterators and
19172   references before the insertion point remain valid. If an exception
19173   is thrown other than by the copy constructor or assignment operator
19174   of T or by any InputIterator operation there are no effects.
19175 </p></blockquote>
19176
19177 <p><i>[We probably need to say something similar for deque.]</i></p>
19178
19179
19180
19181
19182
19183
19184
19185 <hr>
19186 <h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
19187 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19188  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2010-10-29</p>
19189 <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>
19190 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19191 <p><b>Discussion:</b></p>
19192 <p>
19193 Clause X [iterator.concepts], paragraph 5, says that the only expression
19194 that is defined for a singular iterator is "an assignment of a
19195 non-singular value to an iterator that holds a singular value".  This 
19196 means that destroying a singular iterator (e.g. letting an automatic
19197 variable go out of scope) is technically undefined behavior.  This
19198 seems overly strict, and probably unintentional.
19199 </p>
19200
19201
19202 <p><b>Proposed resolution:</b></p>
19203 <p>
19204 Change the sentence in question to "... the only exceptions are
19205 destroying an iterator that holds a singular value, or the assignment
19206 of a non-singular value to an iterator that holds a singular value."
19207 </p>
19208
19209
19210
19211
19212
19213 <hr>
19214 <h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
19215 <p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19216  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2010-10-29</p>
19217 <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>
19218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19219 <p><b>Discussion:</b></p>
19220 <p>
19221 A strict reading of 27.9.1 [fstreams] shows that opening or
19222 closing a basic_[io]fstream does not affect the error bits.  This
19223 means, for example, that if you read through a file up to EOF, and
19224 then close the stream and reopen it at the beginning of the file,
19225 the EOF bit in the stream's error state is still set.  This is
19226 counterintuitive.
19227 </p>
19228 <p>
19229 The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
19230 and put in a footnote to clarify that the strict reading was indeed
19231 correct.  We did that because we believed the standard was
19232 unambiguous and consistent, and that we should not make architectural
19233 changes in a TC.  Now that we're working on a new revision of the
19234 language, those considerations no longer apply.
19235 </p>
19236
19237
19238 <p><b>Proposed resolution:</b></p>
19239
19240 <p>Change 27.9.1.9 [ifstream.members], para. 3 from:</p>
19241
19242 <blockquote><p>
19243 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)].
19244 </p></blockquote>
19245
19246 <p>to:</p>
19247
19248 <blockquote><p>
19249 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
19250 </p></blockquote>
19251
19252 <p>Change 27.9.1.13 [ofstream.members], para. 3 from:</p>
19253
19254 <blockquote><p>
19255 Calls rdbuf()-&gt;open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)).
19256 </p></blockquote>
19257
19258 <p>to:</p>
19259
19260 <blockquote><p>
19261 Calls rdbuf()-&gt;open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
19262 </p></blockquote>
19263
19264 <p>Change 27.9.1.17 [fstream.members], para. 3 from:</p>
19265
19266 <blockquote><p>
19267 Calls rdbuf()-&gt;open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) )
19268 </p></blockquote>
19269
19270 <p>to:</p>
19271
19272 <blockquote><p>
19273 Calls rdbuf()-&gt;open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) ), else calls clear().
19274 </p></blockquote>
19275
19276
19277
19278 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
19279 provided wording.  He suggests having open, not close, clear the error
19280 flags.]</i></p>
19281
19282
19283 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
19284   old one didn't make sense because it proposed to fix this at the
19285   level of basic_filebuf, which doesn't have access to the stream's
19286   error state.  Howard's proposed resolution fixes this at the level
19287   of the three fstream class template instead.]</i></p>
19288
19289
19290
19291
19292
19293
19294
19295
19296 <hr>
19297 <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
19298 <p><b>Section:</b> 23.3.4.1 [list.cons], 23.3.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19299  <b>Submitter:</b> Hans Bos <b>Opened:</b> 2003-06-07 <b>Last modified:</b> 2010-10-29</p>
19300 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
19301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19302 <p><b>Discussion:</b></p>
19303 <p>
19304 Sections 23.3.4.1 [list.cons] and 23.3.4.3 [list.modifiers] list
19305 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
19306 stack.  Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator&lt; (23.3.4.1 [list.cons]
19307 par3) are defined.
19308 </p>
19309
19310
19311 <p><b>Proposed resolution:</b></p>
19312
19313 <p>Add the following new paragraphs after 23.3.4.1 [list.cons]
19314   paragraph 3:</p>
19315
19316 <blockquote>
19317
19318 <pre>  operator!=
19319 </pre>
19320 <p>Returns: <tt>x.c != y.c</tt></p>
19321
19322 <pre>  operator&gt;
19323 </pre>
19324 <p>Returns: <tt>x.c &gt; y.c</tt></p>
19325
19326 <pre>  operator&lt;=
19327 </pre>
19328 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
19329
19330 <pre>  operator&gt;=
19331 </pre>
19332 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
19333
19334 </blockquote>
19335
19336 <p>Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:</p>
19337
19338 <blockquote>
19339
19340 <pre>  operator==
19341 </pre>
19342 <p>Returns: <tt>x.c == y.c</tt></p>
19343
19344 <pre>  operator&lt;
19345 </pre>
19346 <p>Returns: <tt>x.c &lt; y.c</tt></p>
19347
19348 <pre>  operator!=
19349 </pre>
19350 <p>Returns: <tt>x.c != y.c</tt></p>
19351
19352 <pre>  operator&gt;
19353 </pre>
19354 <p>Returns: <tt>x.c &gt; y.c</tt></p>
19355
19356 <pre>  operator&lt;=
19357 </pre>
19358 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
19359
19360 <pre>  operator&gt;=
19361 </pre>
19362 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
19363
19364 </blockquote>
19365
19366
19367 <p><i>[Kona: Matt provided wording.]</i></p>
19368
19369
19370
19371
19372 <p><b>Rationale:</b></p>
19373 <p>There isn't any real doubt about what these operators are
19374 supposed to do, but we ought to spell it out.</p>
19375
19376
19377
19378
19379
19380 <hr>
19381 <h3><a name="411"></a>411. Wrong names of set member functions</h3>
19382 <p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19383  <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2003-07-09 <b>Last modified:</b> 2010-10-29</p>
19384 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
19385 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19386 <p><b>Discussion:</b></p>
19387 <p>
19388 25.4.5 [alg.set.operations] paragraph 1 reads:
19389 "The semantics of the set operations are generalized to multisets in a 
19390 standard way by defining union() to contain the maximum number of 
19391 occurrences of every element, intersection() to contain the minimum, and 
19392 so on."
19393 </p>
19394
19395 <p>
19396 This is wrong.  The name of the functions are set_union() and
19397 set_intersection(), not union() and intersection().
19398 </p>
19399
19400
19401 <p><b>Proposed resolution:</b></p>
19402 <p>Change that sentence to use the correct names.</p>
19403
19404
19405
19406
19407
19408 <hr>
19409 <h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
19410 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19411  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-07-10 <b>Last modified:</b> 2010-10-29</p>
19412 <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>
19413 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19414 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
19415 <p><b>Discussion:</b></p>
19416 <p>
19417 The Effects clause in 27.5.4.3 [iostate.flags] paragraph 5 says that the
19418 function only throws if the respective bits are already set prior to
19419 the function call. That's obviously not the intent. The typo ought to
19420 be corrected and the text reworded as: "If (<i>state</i> &amp;
19421 exceptions()) == 0, returns. ..."
19422 </p>
19423
19424
19425 <p><b>Proposed resolution:</b></p>
19426 <p>
19427 In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
19428 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
19429 &amp; exceptions()) == 0".
19430 </p>
19431
19432 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
19433   really do mean rdstate(); the ambiguity is that the wording in the
19434   standard doesn't make it clear whether we mean rdstate() before
19435   setting the new state, or rdsate() after setting it.  We intend the
19436   latter, of course. Post-Kona: Martin provided wording.]</i></p>
19437
19438
19439
19440
19441
19442
19443
19444 <hr>
19445 <h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
19446 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19447  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2003-07-13 <b>Last modified:</b> 2010-10-29</p>
19448 <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>
19449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19450 <p><b>Discussion:</b></p>
19451 <p>
19452 The second sentence of the proposed resolution says:
19453 </p>
19454
19455 <p>
19456 "If it inserted no characters because it caught an exception thrown
19457 while extracting characters from sb and ..."
19458 </p>
19459
19460 <p>
19461 However, we are not extracting from sb, but extracting from the
19462 basic_istream (*this) and inserting into sb. I can't really tell if
19463 "extracting" or "sb" is a typo.
19464 </p>
19465
19466 <p><i>[
19467 Sydney: Definitely a real issue. We are, indeed, extracting characters
19468 from an istream and not from sb. The problem was there in the FDIS and
19469 wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
19470 to have *this instead of sb. We're talking about the exception flag
19471 state of a basic_istream object, and there's only one basic_istream
19472 object in this discussion, so that would be a consistent
19473 interpretation.  (But we need to be careful: the exception policy of
19474 this member function must be consistent with that of other
19475 extractors.)  PJP will provide wording.
19476 ]</i></p>
19477
19478
19479
19480
19481 <p><b>Proposed resolution:</b></p>
19482 <p>Change the sentence from:</p>
19483
19484 <blockquote><p>
19485 If it inserted no characters because it caught an exception thrown
19486 while extracting characters from sb and failbit is on in exceptions(),
19487 then the caught exception is rethrown.
19488 </p></blockquote>
19489
19490 <p>to:</p>
19491
19492 <blockquote><p>
19493 If it inserted no characters because it caught an exception thrown
19494 while extracting characters from *this and failbit is on in exceptions(),
19495 then the caught exception is rethrown.
19496 </p></blockquote>
19497
19498
19499
19500
19501
19502 <hr>
19503 <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
19504 <p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19505  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-08-19 <b>Last modified:</b> 2010-10-29</p>
19506 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
19507 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19508 <p><b>Discussion:</b></p>
19509 <p>
19510 Consider the following code fragment:
19511 </p>
19512 <blockquote>
19513 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
19514 std::vector&lt;int&gt; v(A, A+8);
19515
19516 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
19517 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
19518 v.erase(i1);
19519 </pre>
19520 </blockquote>
19521
19522 <p>
19523 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
19524 both, or neither?
19525 </p>
19526
19527 <p>
19528 On all existing implementations that I know of, the status of i1 and
19529 i2 is the same: both of them will be iterators that point to some
19530 elements of the vector (albeit not the same elements they did
19531 before).  You won't get a crash if you use them.  Depending on 
19532 exactly what you mean by "invalidate", you might say that neither one
19533 has been invalidated because they still point to <i>something</i>,
19534 or you might say that both have been invalidated because in both
19535 cases the elements they point to have been changed out from under the
19536 iterator.
19537 </p>
19538
19539 <p>
19540 The standard doesn't say either of those things.  It says that erase
19541 invalidates all iterators and references "after the point of the
19542 erase".  This doesn't include i1, since it's at the point of the
19543 erase instead of after it.  I can't think of any sensible definition
19544 of invalidation by which one can say that i2 is invalidated but i1
19545 isn't.
19546 </p>
19547
19548 <p>
19549 (This issue is important if you try to reason about iterator validity
19550 based only on the guarantees in the standard, rather than reasoning
19551 from typical implementation techniques.  Strict debugging modes,
19552 which some programmers find useful, do not use typical implementation
19553 techniques.)
19554 </p>
19555
19556
19557 <p><b>Proposed resolution:</b></p>
19558 <p>
19559 In 23.4.1.4 [vector.modifiers] paragraph 3, change "Invalidates all the
19560 iterators and references after the point of the erase" to
19561 "Invalidates iterators and references at or after the point of the
19562 erase". 
19563 </p>
19564
19565
19566 <p><b>Rationale:</b></p>
19567 <p>I believe this was essentially a typographical error, and that it
19568   was taken for granted that erasing an element invalidates iterators
19569   that point to it.  The effects clause in question treats iterators
19570   and references in parallel, and it would seem counterintuitive to
19571   say that a reference to an erased value remains valid.</p>
19572
19573
19574
19575
19576
19577 <hr>
19578 <h3><a name="415"></a>415. behavior of std::ws</h3>
19579 <p><b>Section:</b> 27.7.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19580  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19582 <p><b>Discussion:</b></p>
19583 <p>
19584 According to 27.6.1.4, the ws() manipulator is not required to construct
19585 the sentry object. The manipulator is also not a member function so the
19586 text in 27.6.1, p1 through 4 that describes the exception policy for
19587 istream member functions does not apply. That seems inconsistent with
19588 the rest of extractors and all the other input functions (i.e., ws will
19589 not cause a tied stream to be flushed before extraction, it doesn't check
19590 the stream's exceptions or catch exceptions thrown during input, and it
19591 doesn't affect the stream's gcount).
19592 </p>
19593
19594
19595 <p><b>Proposed resolution:</b></p>
19596 <p>
19597 Add to 27.7.1.4 [istream.manip], immediately before the first sentence
19598 of paragraph 1, the following text:
19599 </p>
19600
19601     <blockquote><p>
19602     Behaves as an unformatted input function (as described in
19603     27.6.1.3, paragraph 1), except that it does not count the number
19604     of characters extracted and does not affect the value returned by
19605     subsequent calls to is.gcount(). After constructing a sentry
19606     object...  
19607     </p></blockquote>
19608
19609 <p><i>[Post-Kona: Martin provided wording]</i></p>
19610
19611
19612
19613
19614
19615
19616 <hr>
19617 <h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
19618 <p><b>Section:</b> 18.3.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19619  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19620 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19621 <p><b>Discussion:</b></p>
19622         <p>
19623
19624 Given two overloads of the function foo(), one taking an argument of type
19625 int and the other taking a long, which one will the call foo(LONG_MAX)
19626 resolve to? The expected answer should be foo(long), but whether that
19627 is true depends on the #defintion of the LONG_MAX macro, specifically
19628 its type. This issue is about the fact that the type of these macros
19629 is not actually required to be the same as the the type each respective
19630 limit.
19631 <br>
19632
19633 Section 18.2.2 of the C++ Standard does not specify the exact types of
19634 the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
19635 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
19636 <br>
19637
19638 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
19639 these constants] shall be replaced by constant expressions suitable for use
19640 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
19641 the following shall be replaced by expressions that have the same type as
19642 would an expression that is an object of the corresponding type converted
19643 according to the integer promotions."
19644 <br>
19645
19646 The "corresponding type converted according to the integer promotions" for
19647 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
19648 converted to the first of the following set of types that can represent it:
19649 int, long int, long long int. So on an implementation where (sizeof(long)
19650 == sizeof(int)) this type is actually int, while on an implementation where
19651 (sizeof(long) &gt; sizeof(int)) holds this type will be long.
19652 <br>
19653
19654 This is not an issue in C since the type of the macro cannot be detected
19655 by any conforming C program, but it presents a portability problem in C++
19656 where the actual type is easily detectable by overload resolution.
19657
19658         </p>
19659 <p><i>[Kona: the LWG does not believe this is a defect.  The C macro
19660   definitions are what they are; we've got a better
19661   mechanism, <tt>std::numeric_limits</tt>, that is specified more
19662   precisely than the C limit macros.  At most we should add a
19663   nonnormative note recommending that users who care about the exact
19664   types of limit quantities should use &lt;limits&gt; instead of
19665   &lt;climits&gt;.]</i></p>
19666
19667
19668     
19669
19670 <p><b>Proposed resolution:</b></p>
19671
19672 <p>
19673 Change 18.3.2 [c.limits], paragraph 2:
19674 </p>
19675
19676 <blockquote><p>
19677 -2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
19678 <ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
19679 to match the type to which they refer.<i>--end note</i>]</ins>
19680 </p></blockquote>
19681
19682
19683
19684
19685
19686 <hr>
19687 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
19688 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19689  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19690 <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>
19691 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19692 <p><b>Discussion:</b></p>
19693         <p>
19694
19695 27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
19696 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
19697 true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
19698 says that a formatted input function endeavors to obtain the requested input
19699 if the sentry's operator bool() returns true.
19700
19701 Given these requirements, no formatted extractor should ever set failbit if
19702 the initial stream rdstate() == eofbit. That is contrary to the behavior of
19703 all implementations I tested. The program below prints out
19704
19705 eof = 1, fail = 0
19706 eof = 1, fail = 1
19707
19708 on all of them.
19709         </p>
19710 <pre>
19711 #include &lt;sstream&gt;
19712 #include &lt;cstdio&gt;
19713
19714 int main()
19715 {
19716     std::istringstream strm ("1");
19717
19718     int i = 0;
19719
19720     strm &gt;&gt; i;
19721
19722     std::printf ("eof = %d, fail = %d\n",
19723                  !!strm.eof (), !!strm.fail ());
19724
19725     strm &gt;&gt; i;
19726
19727     std::printf ("eof = %d, fail = %d\n",
19728                  !!strm.eof (), !!strm.fail ());
19729 }
19730
19731 </pre>
19732         <p>
19733 <br>
19734
19735 Comments from Jerry Schwarz (c++std-lib-11373):
19736 <br>
19737
19738 Jerry Schwarz wrote:
19739 <br>
19740
19741 I don't know where (if anywhere) it says it in the standard, but the
19742 formatted extractors are supposed to set failbit if they don't extract
19743 any characters. If they didn't then simple loops like
19744 <br>
19745
19746 while (cin &gt;&gt; x);
19747 <br>
19748
19749 would loop forever.
19750 <br>
19751
19752 Further comments from Martin Sebor:
19753 <br>
19754
19755 The question is which part of the extraction should prevent this from happening
19756 by setting failbit when eofbit is already set. It could either be the sentry
19757 object or the extractor. It seems that most implementations have chosen to
19758 set failbit in the sentry [...] so that's the text that will need to be
19759 corrected. 
19760
19761         </p>
19762 <p>
19763 Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>.  If the sentry
19764 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
19765 you can never seek away from the end of stream.
19766 </p>
19767 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
19768   then set <i>ok</i> to false.  We believe that the sentry's
19769   constructor should always set failbit when <i>ok</i> is false, and
19770   we also think the standard already says that.  Possibly it could be
19771   clearer.</p> 
19772
19773
19774 <p><i>[
19775 2009-07 Frankfurt
19776 ]</i></p>
19777
19778
19779 <blockquote>
19780 Moved to Ready.
19781 </blockquote>
19782
19783
19784
19785 <p><b>Proposed resolution:</b></p>
19786 <p>
19787 Change 27.7.1.1.3 [istream::sentry], p2 to:
19788 </p>
19789
19790 <blockquote>
19791 <pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
19792 <p>
19793 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
19794 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>. 
19795 Otherwise</ins> prepares for formatted or unformatted input. ...
19796 </p>
19797 </blockquote>
19798
19799
19800
19801
19802
19803
19804 <hr>
19805 <h3><a name="420"></a>420. is std::FILE a complete type?</h3>
19806 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19807  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19808 <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>
19809 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19810 <p><b>Discussion:</b></p>
19811 <p>
19812 7.19.1, p2, of C99 requires that the FILE type only be declared in
19813 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
19814 struct is mentioned anywhere for obvious reasons.
19815 </p>
19816
19817 <p>
19818 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
19819 it really the intent that FILE be a complete type or is an implementation
19820 allowed to just declare it without providing a full definition?
19821 </p>
19822
19823
19824 <p><b>Proposed resolution:</b></p>
19825 <p>In the first sentence of 27.9.1 [fstreams] paragraph 2, change
19826   "defined" to "declared".</p>
19827
19828
19829 <p><b>Rationale:</b></p>
19830 <p>We don't want to impose any restrictions beyond what the C standard
19831   already says. We don't want to make anything implementation defined,
19832   because that imposes new requirements in implementations.</p>
19833
19834
19835
19836
19837
19838 <hr>
19839 <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
19840 <p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19841  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <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#reserved.names">issues</a> in [reserved.names].</p>
19843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19844 <p><b>Discussion:</b></p>
19845 <p>
19846 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
19847 explicitly specialize members of standard templates on user-defined types.
19848 The answer to the question might have an impact where library requirements
19849 are given using the "as if" rule. I.e., if programs are allowed to specialize
19850 member functions they will be able to detect an implementation's strict
19851 conformance to Effects clauses that describe the behavior of the function
19852 in terms of the other member function (the one explicitly specialized by
19853 the program) by relying on the "as if" rule.
19854 </p>
19855
19856
19857 <p><b>Proposed resolution:</b></p>
19858
19859 <p>
19860   Add the following sentence to 17.6.3.3 [reserved.names], p1:
19861 </p>
19862
19863 <blockquote><p>
19864 It is undefined for a C++ program to add declarations or definitions to
19865 namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
19866 program may add template specializations for any standard library template to
19867 namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
19868 template results in undefined behavior unless the declaration depends on a
19869 user-defined type of external linkage and unless the specialization meets the
19870 standard library requirements for the original template.<sup>168)</sup>
19871 <ins>A program has undefined behavior if it declares</ins>
19872 </p>
19873 <ul>
19874 <li><ins>an explicit specialization of any member function of a standard
19875             library class template, or</ins></li>
19876 <li><ins>an explicit specialization of any member function template of a
19877             standard library class or class template, or</ins></li>
19878 <li><ins>an explicit or partial specialization of any member class
19879             template of a standard library class or class template.</ins></li>
19880 </ul>
19881 <p>
19882 A program may explicitly instantiate any templates in the standard library only
19883 if the declaration depends on the name of a user-defined type of external
19884 linkage and the instantiation meets the standard library requirements for the
19885 original template.
19886 </p></blockquote>
19887
19888 <p><i>[Kona: straw poll was 6-1 that user programs should not be
19889   allowed to specialize individual member functions of standard
19890   library class templates, and that doing so invokes undefined
19891   behavior. Post-Kona: Martin provided wording.]</i></p>
19892
19893
19894 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
19895 to specialize individual member functions unless they specialize the
19896 whole class, but we're not sure these words say what we want them to;
19897 they could be read as prohibiting the specialization of any standard
19898 library class templates. We need to consult with CWG to make sure we
19899 use the right wording.]</i></p>
19900
19901
19902
19903
19904
19905
19906 <hr>
19907 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
19908 <p><b>Section:</b> 20.9.7 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19909  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19910 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19911 <p><b>Discussion:</b></p>
19912 <p>
19913 The standard is not clear about the requirements on the value returned from
19914 a call to get_temporary_buffer(0). In particular, it fails to specify whether
19915 the call should return a distinct pointer each time it is called (like
19916 operator new), or whether the value is unspecified (as if returned by
19917 malloc). The standard also fails to mention what the required behavior
19918 is when the argument is less than 0.
19919 </p>
19920
19921
19922 <p><b>Proposed resolution:</b></p>
19923 <p>Change 20.7.3 [meta.help] paragraph 2 from "...or a pair of 0
19924 values if no storage can be obtained" to "...or a pair of 0 values if
19925 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
19926 <p><i>[Kona: Matt provided wording]</i></p>
19927
19928
19929
19930
19931
19932 <hr>
19933 <h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
19934 <p><b>Section:</b> 25.2.13 [alg.search], 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19935  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
19936 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
19937 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19938 <p><b>Discussion:</b></p>
19939 <p>
19940 The complexity requirements for these function templates are incorrect
19941 (or don't even make sense) for negative n:</p>
19942
19943 <p>25.1.9, p7 (search_n):
19944 <br>
19945 Complexity: At most (last1 - first1) * count applications
19946 of the corresponding predicate.</p>
19947
19948 <p>25.2.5, p3 (fill_n):
19949 <br>
19950 Complexity: Exactly last - first (or n) assignments.</p>
19951
19952 <p>25.2.6, p3 (generate_n):
19953 <br>
19954 Complexity: Exactly last - first (or n) assignments.</p>
19955
19956 <p>
19957 In addition, the Requirements or the Effects clauses for the latter two
19958 templates don't say anything about the behavior when n is negative.
19959 </p>
19960
19961
19962 <p><b>Proposed resolution:</b></p>
19963 <p>Change 25.1.9, p7 to</p>
19964
19965 <blockquote><p>
19966 Complexity: At most (last1 - first1) * count applications
19967 of the corresponding predicate if count is positive,
19968 or 0 otherwise.
19969 </p></blockquote>
19970
19971 <p>Change 25.2.5, p2 to</p>
19972 <blockquote><p>
19973 Effects: Assigns value through all the iterators in the range [first,
19974 last), or [first, first + n) if n is positive, none otherwise.
19975 </p></blockquote>
19976
19977 <p>Change 25.2.5, p3 to:</p>
19978 <blockquote><p>
19979 Complexity: Exactly last - first (or n if n is positive,
19980 or 0 otherwise) assignments.
19981 </p></blockquote>
19982
19983 <p>
19984 Change 25.2.6, p1 
19985 to (notice the correction for the misspelled "through"):
19986 </p>
19987 <blockquote><p>
19988 Effects: Invokes the function object genand assigns the return
19989 value of gen through all the iterators in the range [first, last),
19990 or [first, first + n) if n is positive, or [first, first)
19991 otherwise.
19992 </p></blockquote>
19993
19994 <p>Change 25.2.6, p3 to:</p>
19995 <blockquote><p>
19996 Complexity: Exactly last - first (or n if n is positive,
19997 or 0 otherwise) assignments.
19998 </p></blockquote>
19999
20000
20001 <p><b>Rationale:</b></p>
20002 <p>Informally, we want to say that whenever we see a negative number
20003   we treat it the same as if it were zero.  We believe the above
20004   changes do that (although they may not be the minimal way of saying
20005   so).  The LWG considered and rejected the alternative of saying that
20006   negative numbers are undefined behavior.</p>
20007
20008
20009
20010
20011
20012 <hr>
20013 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
20014 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20015  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
20016 <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>
20017 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20018 <p><b>Discussion:</b></p>
20019 <p>
20020 The requirements specified in Stage 2 and reiterated in the rationale
20021 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
20022 do_get() compares characters on the stream against the widened elements
20023 of "012...abc...ABCX+-"
20024 </p>
20025
20026 <p>
20027 An implementation is required to allow programs to instantiate the num_get
20028 template on any charT that satisfies the requirements on a user-defined
20029 character type. These requirements do not include the ability of the
20030 character type to be equality comparable (the char_traits template must
20031 be used to perform tests for equality). Hence, the num_get template cannot
20032 be implemented to support any arbitrary character type. The num_get template
20033 must either make the assumption that the character type is equality-comparable
20034 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
20035 the comparisons (some other popular implementations do that). This diversity
20036 of approaches makes it difficult to write portable programs that attempt to
20037 instantiate the num_get template on user-defined types.
20038 </p>
20039
20040 <p><i>[Kona: the heart of the problem is that we're theoretically
20041   supposed to use traits classes for all fundamental character
20042   operations like assignment and comparison, but facets don't have
20043   traits parameters.  This is a fundamental design flaw and it
20044   appears all over the place, not just in this one place.  It's not
20045   clear what the correct solution is, but a thorough review of facets
20046   and traits is in order.  The LWG considered and rejected the
20047   possibility of changing numeric facets to use narrowing instead of
20048   widening.  This may be a good idea for other reasons (see issue
20049   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>), but it doesn't solve the problem raised by this
20050   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
20051   still has no idea which traits class the user wants to use for 
20052   the comparison, because only streams, not facets, are passed traits
20053   classes.   The standard does not require that two different
20054   traits classes with the same <tt>char_type</tt> must necessarily 
20055   have the same behavior.]</i></p>
20056
20057
20058 <p>Informally, one possibility: require that some of the basic
20059 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
20060 and <tt>assign</tt>, must behave the same way for all traits classes
20061 with the same <tt>char_type</tt>.  If we accept that limitation on
20062 traits classes, then the facet could reasonably be required to
20063 use <tt>char_traits&lt;charT&gt;</tt>.</p>
20064
20065 <p><i>[
20066 2009-07 Frankfurt
20067 ]</i></p>
20068
20069
20070 <blockquote>
20071 <p>
20072 There was general agreement that the standard only needs to specify the
20073 behavior when the character type is char or wchar_t.
20074 </p>
20075 <p>
20076 Beman: we don't need to worry about C++1x because there is a non-zero
20077 possibility that we would have a replacement facility for iostreams that
20078 would solve these problems.
20079 </p>
20080 <p>
20081 We need to change the following sentence in [locale.category], paragraph
20082 6 to specify that C is char and wchar_t:
20083 </p>
20084 <p>
20085 "A template formal parameter with name C represents the set of all
20086 possible specializations on a parameter that satisfies the requirements
20087 for a character on which any member of the iostream components can be
20088 instantiated."
20089 </p>
20090 <p>
20091 We also need to specify in 27 that the basic character operations, such
20092 as eq, lt, and assign use std::char_traits.
20093 </p>
20094 <p>
20095 Daniel volunteered to provide wording.
20096 </p>
20097 </blockquote>
20098
20099 <p><i>[
20100 2009-09-19 Daniel provided wording.
20101 ]</i></p>
20102
20103
20104 <p><i>[
20105 2009-10 Santa Cruz:
20106 ]</i></p>
20107
20108
20109 <blockquote>
20110 Leave as Open. Alisdair and/or Tom will provide wording based on discussions.
20111 We want to clearly state that streams and locales work just on <tt>char</tt>
20112 and <tt>wchar_t</tt> (except where otherwise specified).
20113 </blockquote>
20114
20115 <p><i>[
20116 2010-02-06 Tom updated the proposed wording.
20117 ]</i></p>
20118
20119
20120 <blockquote>
20121 <p><i>[
20122 The original proposed wording is preserved here:
20123 ]</i></p>
20124
20125
20126 <blockquote class="note">
20127 <ol>
20128 <li>
20129 <p>
20130 Change 22.3.1.1.1 [locale.category]/6:
20131 </p>
20132
20133 <blockquote>
20134 [..] A template formal parameter with name <tt>C</tt> represents the set of all possible
20135 specializations on a <ins><tt>char</tt> or <tt>wchar_t</tt></ins> parameter<del> that satisfies
20136 the requirements for a character on which any of the iostream components
20137 can be instantiated</del>. [..]
20138 </blockquote>
20139 </li>
20140
20141 <li>
20142 <p>
20143 Add the following sentence to the end of 22.4.2 [category.numeric]/2:
20144 </p>
20145
20146 <blockquote>
20147 [..] These specializations refer to [..], and also for the <tt>ctype&lt;&gt;</tt> facet to
20148 perform character classification. <ins>Implementations are encouraged
20149 but not required to use the <tt>char_traits&lt;charT&gt;</tt> functions for all
20150 comparisons and assignments of characters of type <tt>charT</tt> that do
20151 not belong to the set of required specializations.</ins>
20152 </blockquote>
20153 </li>
20154
20155 <li>
20156 <p>
20157 Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
20158 </p>
20159
20160 <blockquote>
20161 <p>
20162 Stage 2: If <tt>in==end</tt> then stage 2 terminates. Otherwise a <tt>charT</tt> is taken
20163 from <tt>in</tt> and local variables are initialized as if by
20164 </p>
20165
20166 <blockquote><pre>char_type ct = *in;
20167 <ins>using tr = char_traits&lt;char_type&gt;;
20168 const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct);</ins>
20169 char c = src[<del>find(atoms, atoms + sizeof(src) - 1, ct) - atoms</del>
20170              <ins>pos ? pos - atoms : sizeof(src) - 1</ins>];
20171 if (<ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).decimal_point()<ins>)</ins>)
20172     c = '.';
20173 bool discard =
20174     <ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).thousands_sep()<ins>)</ins>
20175     &amp;&amp; use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().length() != 0;
20176 </pre></blockquote>
20177
20178 <p>
20179 where the values <tt>src</tt> and <tt>atoms</tt> are defined as if by: [..]
20180 </p>
20181 </blockquote>
20182
20183 <p>
20184 [Remark of the author: I considered to replace the initialization
20185 "<tt>char_type ct = *in;</tt>"
20186 by the sequence "<tt>char_type ct; tr::assign(ct, *in);</tt>", but decided
20187 against it, because
20188 it is a copy-initialization context, not an assignment]
20189 </p>
20190 </li>
20191
20192 <li>
20193 <p>
20194 Add the following sentence to the end of 22.4.5 [category.time]/1:
20195 </p>
20196
20197 <blockquote>
20198 [..] Their members use [..] , to determine formatting details.
20199 <ins>Implementations are encouraged but not required to use the
20200 <tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
20201 of characters of type <tt>charT</tt> that do
20202 not belong to the set of required specializations.</ins>
20203 </blockquote>
20204 </li>
20205
20206 <li>
20207 <p>
20208 Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
20209 </p>
20210
20211 <ul>
20212 <li>
20213 <del>The next element of <tt>fmt</tt> is equal to <tt>'%'</tt></del> <ins>For the next element <tt>c</tt>
20214 of <tt>fmt char_traits&lt;char_type&gt;::eq(c, use_facet&lt;ctype&lt;char_type&gt;&gt;(f.getloc()).widen('%')) == true</tt></ins>,
20215 [..]
20216 </li>
20217 </ul>
20218 </li>
20219
20220 <li>
20221 <p>
20222 Add the following sentence to the end of 22.4.6 [category.monetary]/2:
20223 </p>
20224
20225 <blockquote>
20226 Their members use [..] to determine formatting details.
20227 <ins>Implementations are encouraged but not required to use the
20228 <tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
20229 of characters of type <tt>charT</tt> that do
20230 not belong to the set of required specializations.</ins>
20231 </blockquote>
20232 </li>
20233
20234 <li>
20235 <p>
20236 Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
20237 </p>
20238
20239 <blockquote>
20240 <p>
20241 [..] The value <tt>units</tt> is produced as if by:
20242 </p>
20243
20244 <blockquote><pre>for (int i = 0; i &lt; n; ++i)
20245   buf2[i] = src[<ins>char_traits&lt;charT&gt;::</ins>find(atoms, <del>atoms+</del>sizeof(src), buf1[i]) - atoms];
20246 buf2[n] = 0;
20247 sscanf(buf2, "%Lf", &amp;units);
20248 </pre></blockquote>
20249 </blockquote>
20250 </li>
20251
20252 <li>
20253 <p>
20254 Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
20255 </p>
20256
20257 <blockquote>
20258 [..] for character buffers <tt>buf1</tt> and <tt>buf2</tt>. If <ins>for</ins> the first
20259 character <ins><tt>c</tt></ins>
20260 in <tt>digits</tt> or <tt>buf2</tt> <del>is equal to
20261 <tt>ct.widen('-')</tt></del><ins><tt>char_traits&lt;charT&gt;::eq(c,
20262 ct.widen('-')) == true</tt></ins>, [..]
20263 </blockquote>
20264 </li>
20265
20266 <li>
20267 <p>
20268 Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
20269 </p>
20270
20271 <blockquote>
20272 <p>
20273 As in the case of the inserters, these extractors depend on the locale's
20274 <tt>num_get&lt;&gt;</tt> (22.4.2.1) object to perform parsing the input stream
20275 data.<ins><sup>(footnote)</sup></ins> [..]
20276 </p>
20277
20278 <p>
20279 <ins>
20280 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20281 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20282 results.
20283 </ins>
20284 </p>
20285 </blockquote>
20286 </li>
20287
20288 <li>
20289 <p>
20290 Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
20291 </p>
20292
20293 <blockquote>
20294 <p>
20295 <i>Effects:</i> The classes <tt>num_get&lt;&gt;</tt> and
20296 <tt>num_put&lt;&gt;</tt> handle locale-dependent numeric formatting and
20297 parsing. These inserter functions use the imbued locale value to perform
20298 numeric formatting.<ins><sup>(footnote)</sup></ins> [..]
20299 </p>
20300
20301 <p>
20302 <ins>
20303 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20304 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20305 results.
20306 </ins>
20307 </p>
20308 </blockquote>
20309 </li>
20310
20311 <li>
20312 <p>
20313 Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
20314 </p>
20315
20316 <blockquote>
20317 <p>
20318 <i>Returns:</i> An object of unspecified type such that if in is an object of type
20319 <tt>basic_istream&lt;charT, traits&gt;</tt> then the expression <tt>in &gt;&gt; get_money(mon, intl)</tt>
20320 behaves as if it called <tt>f(in, mon, intl)</tt>, where the function <tt>f</tt> is defined
20321 as:<ins><sup>(footnote)</sup></ins> [..]
20322 </p>
20323
20324 <p>
20325 <ins>
20326 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20327 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20328 results.
20329 </ins>
20330 </p>
20331 </blockquote>
20332 </li>
20333
20334 <li>
20335 <p>
20336 Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
20337 </p>
20338
20339 <blockquote>
20340 <p>
20341 <i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an object of type
20342 <tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt; put_money(mon, intl)</tt>
20343 behaves as a formatted input function that calls <tt>f(out, mon, intl)</tt>, where the
20344 function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
20345 </p>
20346
20347 <p>
20348 <ins>
20349 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20350 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20351 results.
20352 </ins>
20353 </p>
20354 </blockquote>
20355 </li>
20356
20357 <li>
20358 <p>
20359 13) Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
20360 </p>
20361
20362 <blockquote>
20363 <p>
20364 <i>Returns:</i> An object of unspecified type such that if <tt>in</tt> is an
20365 object of type b<tt>asic_istream&lt;charT, traits&gt;</tt> then the expression
20366 <tt>in &gt;&gt;get_time(tmb, fmt)</tt> behaves as if it called <tt>f(in, tmb, fmt)</tt>,
20367 where the function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
20368 </p>
20369
20370 <p>
20371 <ins>
20372 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20373 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20374 results.
20375 </ins>
20376 </p>
20377 </blockquote>
20378 </li>
20379
20380 <li>
20381 <p>
20382 Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
20383 </p>
20384
20385 <blockquote>
20386 <p>
20387 Returns: An object of unspecified type such that if <tt>out</tt> is an object of type
20388 <tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt;put_time(tmb, fmt)</tt>
20389 behaves as if it called <tt>f(out, tmb, fmt)</tt>, where the function <tt>f</tt> is defined
20390 as:<ins><sup>(footnote)</sup></ins> [..]
20391 </p>
20392
20393 <p>
20394 <ins>
20395 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20396 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20397 results.
20398 </ins>
20399 </p>
20400 </blockquote>
20401 </li>
20402 </ol>
20403
20404 </blockquote>
20405 </blockquote>
20406
20407 <p><i>[
20408 2010 Pittsburgh:
20409 ]</i></p>
20410
20411
20412 <blockquote>
20413 <p>
20414 Moved to Ready with only two of the bullets.  The original wording is preserved
20415 here:
20416 </p>
20417
20418 <blockquote class="note">
20419 <ol>
20420 <li>
20421 <p>
20422 Change 22.3.1.1.1 [locale.category]/6:
20423 </p>
20424
20425 <blockquote>
20426 [..] A template formal parameter with name <tt>C</tt> represents 
20427 the set 
20428 <del>of all possible specializations on a</del> 
20429 <ins>of types containing <tt>char</tt>, <tt>wchar_t</tt>,
20430 and any other implementation-defined character type
20431 </ins>
20432 <del> parameter</del>
20433 that satisfies
20434 the requirements for a character on which any of the iostream components
20435 can be instantiated. [..]
20436 </blockquote>
20437 </li>
20438
20439 <li>
20440 <p>
20441 Add the following sentence to the end of 22.4.2 [category.numeric]/2:
20442 </p>
20443
20444 <blockquote>
20445 [..] These specializations refer to [..], and also for the <tt>ctype&lt;&gt;</tt> facet to
20446 perform character classification. <ins>[<i>Note:</i> Implementations are encouraged
20447 but not required to use the <tt>char_traits&lt;charT&gt;</tt> functions for all
20448 comparisons and assignments of characters of type <tt>charT</tt> that do
20449 not belong to the set of required specializations - <i>end note</i>].</ins>
20450 </blockquote>
20451 </li>
20452
20453 <li>
20454 <p>
20455 Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
20456 </p>
20457
20458 <blockquote>
20459 <p>
20460 Stage 2: If <tt>in==end</tt> then stage 2 terminates. Otherwise a <tt>charT</tt> is taken
20461 from <tt>in</tt> and local variables are initialized as if by
20462 </p>
20463
20464 <blockquote><pre>char_type ct = *in;
20465 <ins>using tr = char_traits&lt;char_type&gt;;
20466 const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct);</ins>
20467 char c = src[<del>find(atoms, atoms + sizeof(src) - 1, ct) - atoms</del>
20468              <ins>pos ? pos - atoms : sizeof(src) - 1</ins>];
20469 if (<ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).decimal_point()<ins>)</ins>)
20470     c = '.';
20471 bool discard =
20472     <ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).thousands_sep()<ins>)</ins>
20473     &amp;&amp; use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().length() != 0;
20474 </pre></blockquote>
20475
20476 <p>
20477 where the values <tt>src</tt> and <tt>atoms</tt> are defined as if by: [..]
20478 </p>
20479 </blockquote>
20480
20481 <p>
20482 [Remark of the author: I considered to replace the initialization
20483 "<tt>char_type ct = *in;</tt>"
20484 by the sequence "<tt>char_type ct; tr::assign(ct, *in);</tt>", but decided
20485 against it, because
20486 it is a copy-initialization context, not an assignment]
20487 </p>
20488 </li>
20489
20490 <li>
20491 <p>
20492 Add the following sentence to the end of 22.4.5 [category.time]/1:
20493 </p>
20494
20495 <blockquote>
20496 [..] Their members use [..] , to determine formatting details.
20497 <ins>[<i>Note:</i> Implementations are encouraged but not required to use the
20498 <tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
20499 of characters of type <tt>charT</tt> that do
20500 not belong to the set of required specializations - <i>end note</i>].</ins>
20501 </blockquote>
20502 </li>
20503
20504 <li>
20505 <p>
20506 Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
20507 </p>
20508
20509 <ul>
20510 <li>
20511 <del>The next element of <tt>fmt</tt> is equal to <tt>'%'</tt></del> <ins>For the next element <tt>c</tt>
20512 of <tt>fmt char_traits&lt;char_type&gt;::eq(c, use_facet&lt;ctype&lt;char_type&gt;&gt;(f.getloc()).widen('%')) == true</tt></ins>,
20513 [..]
20514 </li>
20515 </ul>
20516 </li>
20517
20518 <li>
20519 <p>
20520 Add the following sentence to the end of 22.4.6 [category.monetary]/2:
20521 </p>
20522
20523 <blockquote>
20524 Their members use [..] to determine formatting details.
20525 <ins>[<i>Note:</i> Implementations are encouraged but not required to use the
20526 <tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
20527 of characters of type <tt>charT</tt> that do
20528 not belong to the set of required specializations - <i>end note</i>].</ins>
20529 </blockquote>
20530 </li>
20531
20532 <li>
20533 <p>
20534 Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
20535 </p>
20536
20537 <blockquote>
20538 <p>
20539 [..] The value <tt>units</tt> is produced as if by:
20540 </p>
20541
20542 <blockquote><pre>for (int i = 0; i &lt; n; ++i)
20543   buf2[i] = src[<ins>char_traits&lt;charT&gt;::</ins>find(atoms, <del>atoms+</del>sizeof(src), buf1[i]) - atoms];
20544 buf2[n] = 0;
20545 sscanf(buf2, "%Lf", &amp;units);
20546 </pre></blockquote>
20547 </blockquote>
20548 </li>
20549
20550 <li>
20551 <p>
20552 Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
20553 </p>
20554
20555 <blockquote>
20556 [..] for character buffers <tt>buf1</tt> and <tt>buf2</tt>. If <ins>for</ins> the first
20557 character <ins><tt>c</tt></ins>
20558 in <tt>digits</tt> or <tt>buf2</tt> <del>is equal to
20559 <tt>ct.widen('-')</tt></del><ins><tt>char_traits&lt;charT&gt;::eq(c,
20560 ct.widen('-')) == true</tt></ins>, [..]
20561 </blockquote>
20562 </li>
20563
20564 <li>
20565 <p>
20566 Add a new paragraph after the 
20567 first paragraph of 27.2.2 [iostreams.limits.pos]/1:
20568 </p>
20569 <blockquote>
20570 In the classes of clause 27,
20571 a template formal parameter with name <tt>charT</tt> represents 
20572 one of
20573 the set of types
20574 containing <tt>char</tt>, <tt>wchar_t</tt>,
20575 and any other implementation-defined character type
20576 that satisfies
20577 the requirements for a character on which any of the iostream components
20578 can be instantiated.
20579 </blockquote>
20580 </li>
20581
20582 <li>
20583 <p>
20584 Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
20585 </p>
20586
20587 <blockquote>
20588 <p>
20589 As in the case of the inserters, these extractors depend on the locale's
20590 <tt>num_get&lt;&gt;</tt> (22.4.2.1) object to perform parsing the input stream
20591 data.<ins><sup>(footnote)</sup></ins> [..]
20592 </p>
20593
20594 <p>
20595 <ins>
20596 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20597 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20598 results.
20599 </ins>
20600 </p>
20601 </blockquote>
20602 </li>
20603
20604 <li>
20605 <p>
20606 Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
20607 </p>
20608
20609 <blockquote>
20610 <p>
20611 <i>Effects:</i> The classes <tt>num_get&lt;&gt;</tt> and
20612 <tt>num_put&lt;&gt;</tt> handle locale-dependent numeric formatting and
20613 parsing. These inserter functions use the imbued locale value to perform
20614 numeric formatting.<ins><sup>(footnote)</sup></ins> [..]
20615 </p>
20616
20617 <p>
20618 <ins>
20619 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20620 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20621 results.
20622 </ins>
20623 </p>
20624 </blockquote>
20625 </li>
20626
20627
20628 <li>
20629 <p>
20630 Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
20631 </p>
20632
20633 <blockquote>
20634 <p>
20635 <i>Returns:</i> An object of unspecified type such that if in is an object of type
20636 <tt>basic_istream&lt;charT, traits&gt;</tt> then the expression <tt>in &gt;&gt; get_money(mon, intl)</tt>
20637 behaves as if it called <tt>f(in, mon, intl)</tt>, where the function <tt>f</tt> is defined
20638 as:<ins><sup>(footnote)</sup></ins> [..]
20639 </p>
20640
20641 <p>
20642 <ins>
20643 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20644 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20645 results.
20646 </ins>
20647 </p>
20648 </blockquote>
20649 </li>
20650
20651 <li>
20652 <p>
20653 Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
20654 </p>
20655
20656 <blockquote>
20657 <p>
20658 <i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an object of type
20659 <tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt; put_money(mon, intl)</tt>
20660 behaves as a formatted input function that calls <tt>f(out, mon, intl)</tt>, where the
20661 function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
20662 </p>
20663
20664 <p>
20665 <ins>
20666 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20667 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20668 results.
20669 </ins>
20670 </p>
20671 </blockquote>
20672 </li>
20673
20674 <li>
20675 <p>
20676 Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
20677 </p>
20678
20679 <blockquote>
20680 <p>
20681 <i>Returns:</i> An object of unspecified type such that if <tt>in</tt> is an
20682 object of type b<tt>asic_istream&lt;charT, traits&gt;</tt> then the expression
20683 <tt>in &gt;&gt;get_time(tmb, fmt)</tt> behaves as if it called <tt>f(in, tmb, fmt)</tt>,
20684 where the function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
20685 </p>
20686
20687 <p>
20688 <ins>
20689 <sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
20690 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20691 results.
20692 </ins>
20693 </p>
20694 </blockquote>
20695 </li>
20696
20697 <li>
20698 <p>
20699 Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
20700 </p>
20701
20702 <blockquote>
20703 <p>
20704 Returns: An object of unspecified type such that if <tt>out</tt> is an object of type
20705 <tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt;put_time(tmb, fmt)</tt>
20706 behaves as if it called <tt>f(out, tmb, fmt)</tt>, where the function <tt>f</tt> is defined
20707 as:<ins><sup>(footnote)</sup></ins> [..]
20708 </p>
20709
20710 <p>
20711 <ins>
20712 <sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
20713 <tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
20714 results.
20715 </ins>
20716 </p>
20717 </blockquote>
20718 </li>
20719 </ol>
20720 </blockquote>
20721 </blockquote>
20722
20723
20724
20725 <p><b>Proposed resolution:</b></p>
20726 <ol>
20727 <li>
20728 <p>
20729 Change 22.3.1.1.1 [locale.category]/6:
20730 </p>
20731
20732 <blockquote>
20733 [..] A template formal parameter with name <tt>C</tt> represents 
20734 the set 
20735 <del>of all possible specializations on a</del> 
20736 <ins>of types containing <tt>char</tt>, <tt>wchar_t</tt>,
20737 and any other implementation-defined character type
20738 </ins>
20739 <del> parameter</del>
20740 that satisfies
20741 the requirements for a character on which any of the iostream components
20742 can be instantiated. [..]
20743 </blockquote>
20744 </li>
20745
20746 <li>
20747 <p>
20748 Add a new paragraph after the 
20749 first paragraph of 27.2.2 [iostreams.limits.pos]/1:
20750 </p>
20751 <blockquote>
20752 In the classes of clause 27,
20753 a template formal parameter with name <tt>charT</tt> represents 
20754 one of
20755 the set of types
20756 containing <tt>char</tt>, <tt>wchar_t</tt>,
20757 and any other implementation-defined character type
20758 that satisfies
20759 the requirements for a character on which any of the iostream components
20760 can be instantiated.
20761 </blockquote>
20762 </li>
20763
20764 </ol>
20765
20766
20767
20768
20769 <hr>
20770 <h3><a name="428"></a>428. string::erase(iterator) validity</h3>
20771 <p><b>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
20772  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
20773 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
20774 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20775 <p><b>Discussion:</b></p>
20776 <p>
20777 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
20778 that q must be a valid dereferenceable iterator into the sequence a.
20779 </p>
20780
20781 <p>
20782 However, 21.3.5.5, p5 describing string::erase(p) only requires that
20783 p be a valid iterator.
20784 </p>
20785
20786 <p>
20787 This may be interepreted as a relaxation of the general requirement,
20788 which is most likely not the intent.
20789 </p>
20790
20791
20792 <p><b>Proposed resolution:</b></p>
20793 <p>Remove 21.4.6.5 [string::erase] paragraph 5.</p>
20794
20795
20796 <p><b>Rationale:</b></p>
20797 <p>The LWG considered two options: changing the string requirements to
20798   match the general container requirements, or just removing the
20799   erroneous string requirements altogether.  The LWG chose the latter
20800   option, on the grounds that duplicating text always risks the
20801   possibility that it might be duplicated incorrectly.</p>
20802
20803
20804
20805
20806
20807 <hr>
20808 <h3><a name="430"></a>430. valarray subset operations</h3>
20809 <p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20810  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
20811 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20812 <p><b>Discussion:</b></p>
20813 <p>
20814 The standard fails to specify the behavior of valarray::operator[](slice)
20815 and other valarray subset operations when they are passed an "invalid"
20816 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
20817 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
20818 object (e.g., slice (2, 1, 1) for a valarray of size 1).
20819 </p>
20820 <p><i>[Kona: the LWG believes that invalid slices should invoke
20821   undefined behavior.  Valarrays are supposed to be designed for high
20822   performance, so we don't want to require specific checking.  We
20823   need wording to express this decision.]</i></p>
20824
20825
20826 <p><i>[
20827 Bellevue:
20828 ]</i></p>
20829
20830
20831 <blockquote>
20832 Please note that the standard also fails to specify the behavior of
20833 slice_array and gslice_array in the valid case. Bill Plauger will
20834 endeavor to provide revised wording for slice_array and gslice_array.
20835 </blockquote>
20836
20837 <p><i>[
20838 post-Bellevue:  Bill provided wording.
20839 ]</i></p>
20840
20841
20842 <p><i>[
20843 2009-07 Frankfurt
20844 ]</i></p>
20845
20846
20847 <blockquote>
20848 <p>
20849 Move to Ready.
20850 </p>
20851 </blockquote>
20852
20853 <p><i>[
20854 2009-11-04 Pete opens:
20855 ]</i></p>
20856
20857
20858 <blockquote>
20859 The resolution to LWG issue 430 has not been applied --- there have been
20860 changes to the underlying text, and the resolution needs to be reworked.
20861 </blockquote>
20862
20863 <p><i>[
20864 2010-03-09 Matt updated wording.
20865 ]</i></p>
20866
20867
20868 <p><i>[
20869 2010 Pittsburgh: Moved to Ready for Pittsburgh.
20870 ]</i></p>
20871
20872
20873
20874
20875 <p><b>Proposed resolution:</b></p>
20876 <p>
20877 Replace 26.6.2.4 [valarray.sub], with the following:
20878 </p>
20879
20880 <blockquote>
20881 <p>
20882 The member operator is overloaded to provide several ways to select
20883 sequences of elements from among those controlled by <tt>*this</tt>.
20884 Each of these operations returns a subset of the array.  The
20885 const-qualified versions return this subset as a new <tt>valarray</tt>. The
20886 non-const versions return a class template object which has reference
20887 semantics to the original array, working in conjunction with various
20888 overloads of <tt>operator=</tt> (and other assigning operators) to allow
20889 selective replacement (slicing) of the controlled sequence. In each case
20890 the selected element(s) must exist.
20891 </p>
20892
20893 <pre>valarray&lt;T&gt; operator[](slice slicearr) const; 
20894 </pre>
20895
20896 <blockquote>
20897 <p>
20898 This function returns an object of class <tt>valarray&lt;T&gt;</tt>
20899 containing those elements of the controlled sequence designated by
20900 <tt>slicearr</tt>. [<i>Example:</i>
20901 </p>
20902
20903 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
20904 valarray&lt;char&gt; v1("ABCDE", 5); 
20905 v0[slice(2, 5, 3)] = v1; 
20906 // v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
20907 </pre></blockquote>
20908 <p>
20909 <i>end example</i>]
20910 </p>
20911 </blockquote>
20912  
20913 <pre>valarray&lt;T&gt; operator[](slice slicearr); 
20914 </pre>
20915
20916 <blockquote>
20917 <p>
20918 This function selects those elements of the controlled sequence
20919 designated by <tt>slicearr</tt>.  [<i>Example</i>:
20920 </p>
20921
20922 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
20923 valarray&lt;char&gt; v1("ABCDE", 5); 
20924 v0[slice(2, 5, 3)] = v1; 
20925 // v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
20926 </pre></blockquote>
20927 <p>
20928 <i>end example</i>]
20929 </p>
20930 </blockquote>
20931  
20932 <pre>valarray&lt;T&gt; operator[](const gslice&amp; gslicearr) const; 
20933 </pre>
20934
20935 <blockquote>
20936 <p>
20937 This function returns an object of class <tt>valarray&lt;T&gt;</tt>
20938 containing those elements of the controlled sequence designated by
20939 <tt>gslicearr</tt>. [<i>Example:</i>
20940 </p>
20941
20942 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
20943 const size_t lv[] = {2, 3}; 
20944 const size_t dv[] = {7, 2}; 
20945 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2); 
20946 // v0[gslice(3, len, str)] returns 
20947 // valarray&lt;char&gt;("dfhkmo", 6)
20948 </pre></blockquote>
20949 <p>
20950 <i>end example</i>]
20951 </p>
20952 </blockquote>
20953  
20954 <pre>gslice_array&lt;T&gt; operator[](const gslice&amp; gslicearr); 
20955 </pre>
20956
20957 <blockquote>
20958 <p>
20959 This function selects those elements of the controlled sequence
20960 designated by <tt>gslicearr</tt>.  [<i>Example:</i>
20961 </p>
20962
20963 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
20964 valarray&lt;char&gt; v1("ABCDEF", 6); 
20965 const size_t lv[] = {2, 3}; 
20966 const size_t dv[] = {7, 2}; 
20967 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2); 
20968 v0[gslice(3, len, str)] = v1; 
20969 // v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
20970 </pre></blockquote>
20971 <p>
20972 <i>end example</i>]
20973 </p>
20974 </blockquote>
20975  
20976 <pre>valarray&lt;T&gt; operator[](const valarray&lt;bool&gt;&amp; boolarr) const; 
20977 </pre>
20978
20979 <blockquote>
20980 <p>
20981 This function returns an object of class <tt>valarray&lt;T&gt;</tt>
20982 containing those elements of the controlled sequence designated by
20983 <tt>boolarr</tt>. [<i>Example:</i>
20984 </p>
20985
20986 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
20987 const bool vb[] = {false, false, true, true, false, true}; 
20988 // v0[valarray&lt;bool&gt;(vb, 6)] returns 
20989 // valarray&lt;char&gt;("cdf", 3)
20990 </pre></blockquote>
20991 <p>
20992 <i>end example</i>] 
20993 </p>
20994 </blockquote>
20995  
20996 <pre>mask_array&lt;T&gt; operator[](const valarray&lt;bool&gt;&amp; boolarr); 
20997 </pre>
20998
20999 <blockquote>
21000 <p>
21001 This function selects those elements of the controlled sequence
21002 designated by <tt>boolarr</tt>. [<i>Example:</i>
21003 </p>
21004
21005 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
21006 valarray&lt;char&gt; v1("ABC", 3); 
21007 const bool vb[] = {false, false, true, true, false, true}; 
21008 v0[valarray&lt;bool&gt;(vb, 6)] = v1; 
21009 // v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
21010 </pre></blockquote>
21011 <p>
21012 <i>end example</i>]
21013 </p>
21014 </blockquote>
21015  
21016 <pre>valarray&lt;T&gt; operator[](const valarray&lt;size_t&gt;&amp; indarr) const; 
21017 </pre>
21018
21019 <blockquote>
21020 <p>
21021 This function returns an object of class <tt>valarray&lt;T&gt;</tt>
21022 containing those elements of the controlled sequence designated by
21023 <tt>indarr</tt>. [<i>Example:</i>
21024 </p>
21025
21026 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
21027 const size_t vi[] = {7, 5, 2, 3, 8}; 
21028 // v0[valarray&lt;size_t&gt;(vi, 5)] returns 
21029 // valarray&lt;char&gt;("hfcdi", 5)
21030 </pre></blockquote>
21031 <p>
21032 <i>end example</i>] 
21033 </p>
21034 </blockquote>
21035  
21036 <pre>indirect_array&lt;T&gt; operator[](const valarray&lt;size_t&gt;&amp; indarr);
21037 </pre>
21038
21039 <blockquote>
21040 <p>
21041 This function selects those elements of the controlled sequence
21042 designated by <tt>indarr</tt>. [<i>Example:</i>
21043 </p>
21044
21045 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
21046 valarray&lt;char&gt; v1("ABCDE", 5); 
21047 const size_t vi[] = {7, 5, 2, 3, 8}; 
21048 v0[valarray&lt;size_t&gt;(vi, 5)] = v1; 
21049 // v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
21050 </pre></blockquote>
21051 <p>
21052 <i>end example</i>]
21053 </p>
21054 </blockquote>
21055
21056 </blockquote>
21057
21058
21059
21060
21061
21062 <hr>
21063 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
21064 <p><b>Section:</b> 20.2.5 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
21065  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20 <b>Last modified:</b> 2010-11-20</p>
21066 <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>
21067 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
21068 <p><b>Discussion:</b></p>
21069 <p>Clause 20.2.5 [allocator.requirements] paragraph 4 says that implementations
21070   are permitted to supply containers that are unable to cope with
21071   allocator instances and that container implementations may assume
21072   that all instances of an allocator type compare equal.  We gave
21073   implementers this latitude as a temporary hack, and eventually we
21074   want to get rid of it.  What happens when we're dealing with
21075   allocators that <i>don't</i> compare equal?
21076 </p>
21077
21078 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
21079   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
21080   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
21081   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
21082
21083 <p>1. This operation is illegal.  Perhaps we could say that an
21084   implementation is required to check and to throw an exception, or
21085   perhaps we could say it's undefined behavior.</p>
21086 <p>2. The operation performs a slow swap (i.e. using three
21087   invocations of <tt>operator=</tt>, leaving each allocator with its
21088   original container.  This would be an O(N) operation.</p>
21089 <p>3. The operation swaps both the vectors' contents and their
21090   allocators.  This would be an O(1) operation. That is:</p>
21091   <blockquote>
21092   <pre>    my_alloc a1(...);
21093     my_alloc a2(...);
21094     assert(a1 != a2);
21095
21096     vector&lt;int, my_alloc&gt; v1(a1);
21097     vector&lt;int, my_alloc&gt; v2(a2);
21098     assert(a1 == v1.get_allocator());
21099     assert(a2 == v2.get_allocator());
21100
21101     v1.swap(v2);
21102     assert(a1 == v2.get_allocator());
21103     assert(a2 == v1.get_allocator());
21104   </pre>
21105   </blockquote>
21106
21107 <p><i>[Kona: This is part of a general problem.  We need a paper
21108   saying how to deal with unequal allocators in general.]</i></p>
21109
21110
21111 <p><i>[pre-Sydney: Howard argues for option 3 in
21112 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
21113 ]</i></p>
21114
21115
21116 <p><i>[
21117 2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
21118 and move assignment operators.  For containers, these members transfer resources (i.e.
21119 the allocated memory) just like swap.
21120 ]</i></p>
21121
21122
21123 <p><i>[
21124 Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
21125 requirement using concepts.  If the allocator supports Swappable, then container's swap will
21126 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
21127 ]</i></p>
21128
21129
21130 <p><i>[
21131 2009-04-28 Pablo adds:
21132 ]</i></p>
21133
21134 <blockquote>
21135 Fixed in
21136 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
21137 I argued for marking this Tentatively-Ready right after Bellevue,
21138 but there was a concern that
21139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
21140 would break in the presence of the RVO. (That breakage had nothing to do with
21141 swap, but never-the-less). I addressed that breakage in in
21142 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
21143 (Summit) by means of a non-normative reference:
21144
21145 <blockquote>
21146 [<i>Note:</i> in situations where the copy constructor for a container is elided,
21147 this function is not called. The behavior in these cases is as if
21148 <tt>select_on_container_copy_construction</tt> returned <tt>x</tt> \97 <i>end note</i>]
21149 </blockquote>
21150
21151 </blockquote>
21152
21153 <p><i>[
21154 2009-10 Santa Cruz:
21155 ]</i></p>
21156
21157
21158 <blockquote>
21159 <del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
21160 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
21161 </blockquote>
21162
21163
21164
21165 <p><b>Proposed resolution:</b></p>
21166
21167
21168
21169
21170
21171 <hr>
21172 <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
21173 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21174  <b>Submitter:</b> Christian W Brock <b>Opened:</b> 2003-09-24 <b>Last modified:</b> 2010-10-29</p>
21175 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
21176 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21177 <p><b>Discussion:</b></p>
21178 <p>27.7.1.3 par 8 says:</p>
21179 <blockquote><p>
21180 Notes: The function can make a write position available only if
21181     ( mode &amp; ios_base::out) != 0. To make a write position
21182     available, the function reallocates (or initially allocates) an
21183     array object with a sufficient number of elements to hold the
21184     current array object (if any), plus one additional write position.
21185     If ( mode &amp; ios_base::in) != 0, the function alters the read end
21186     pointer egptr() to point just past the new write position (as
21187     does the write end pointer epptr()).
21188 </p></blockquote>
21189
21190 <p>
21191 The sentences "plus one additional write position." and especially
21192     "(as does the write end pointer epptr())" COULD by interpreted
21193     (and is interpreted by at least my library vendor) as:
21194 </p>
21195
21196 <blockquote><p>
21197     post-condition: epptr() == pptr()+1
21198 </p></blockquote>
21199
21200 <p>
21201 This WOULD force sputc() to call the virtual overflow() each time.
21202 </p>
21203
21204 <p>The proposed change also affects Defect Report 169.</p>
21205
21206
21207
21208 <p><b>Proposed resolution:</b></p>
21209 <p>27.7.1.1/2 Change:</p>
21210
21211 <blockquote><p>
21212 2- Notes: The function allocates no array object.
21213 </p></blockquote>
21214
21215 <p>
21216 to:
21217 </p>
21218
21219 <blockquote><p>
21220 2- Postcondition: str() == "".
21221 </p></blockquote>
21222
21223 <p>
21224 27.7.1.1/3 Change:
21225 </p>
21226
21227 <blockquote>
21228 <p>
21229 -3- Effects: Constructs an object of class basic_stringbuf,
21230 initializing the base class with basic_streambuf()
21231 (lib.streambuf.cons), and initializing mode with which . Then copies
21232 the content of str into the basic_stringbuf underlying character
21233 sequence and initializes the input and output sequences according to
21234 which. If which &amp; ios_base::out is true, initializes the output
21235 sequence with the underlying sequence. If which &amp; ios_base::in is
21236 true, initializes the input sequence with the underlying sequence.
21237 </p>
21238 </blockquote>
21239
21240 <p>to:</p>
21241
21242 <blockquote>
21243 <p>
21244 -3- Effects: Constructs an object of class basic_stringbuf,
21245 initializing the base class with basic_streambuf()
21246 (lib.streambuf.cons), and initializing mode with which. Then copies
21247 the content of str into the basic_stringbuf underlying character
21248 sequence. If which &amp; ios_base::out is true, initializes the output
21249 sequence such that pbase() points to the first underlying character,
21250 epptr() points one past the last underlying character, and if (which &amp;
21251 ios_base::ate) is true, pptr() is set equal to
21252 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
21253 is true, initializes the input sequence such that eback() and gptr()
21254 point to the first underlying character and egptr() points one past
21255 the last underlying character.
21256 </p>
21257 </blockquote>
21258
21259 <p>27.7.1.2/1 Change:</p>
21260
21261 <blockquote>
21262 <p>
21263 -1- Returns: A basic_string object whose content is equal to the
21264 basic_stringbuf underlying character sequence. If the buffer is only
21265 created in input mode, the underlying character sequence is equal to
21266 the input sequence; otherwise, it is equal to the output sequence. In
21267 case of an empty underlying character sequence, the function returns
21268 basic_string&lt;charT,traits,Allocator&gt;().
21269 </p>
21270 </blockquote>
21271
21272 <p>to:</p>
21273
21274 <blockquote>
21275 <p>
21276 -1- Returns: A basic_string object whose content is equal to the
21277 basic_stringbuf underlying character sequence. If the basic_stringbuf
21278 was created only in input mode, the resultant basic_string contains
21279 the character sequence in the range [eback(), egptr()).  If the
21280 basic_stringbuf was created with (which &amp; ios_base::out) being true
21281 then the resultant basic_string contains the character sequence in the
21282 range [pbase(), high_mark) where high_mark represents the position one
21283 past the highest initialized character in the buffer.  Characters can
21284 be initialized either through writing to the stream, or by
21285 constructing the basic_stringbuf with a basic_string, or by calling
21286 the str(basic_string) member function.  In the case of calling the
21287 str(basic_string) member function, all characters initialized prior to
21288 the call are now considered uninitialized (except for those
21289 characters re-initialized by the new basic_string).  Otherwise the
21290 basic_stringbuf has been created in neither input nor output mode and
21291 a zero length basic_string is returned.
21292 </p>
21293 </blockquote>
21294
21295 <p>
21296 27.7.1.2/2 Change:
21297 </p>
21298
21299 <blockquote>
21300 <p>
21301 -2- Effects: If the basic_stringbuf's underlying character sequence is
21302 not empty, deallocates it. Then copies the content of s into the
21303 basic_stringbuf underlying character sequence and initializes the
21304 input and output sequences according to the mode stored when creating
21305 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
21306 initializes the output sequence with the underlying sequence. If
21307 (mode&amp;ios_base::in) is true, then initializes the input sequence with
21308 the underlying sequence.
21309 </p>
21310 </blockquote>
21311
21312 <p>to:</p>
21313
21314 <blockquote>
21315 <p>
21316 -2- Effects: Copies the content of s into the basic_stringbuf
21317 underlying character sequence. If mode &amp; ios_base::out is true,
21318 initializes the output sequence such that pbase() points to the first
21319 underlying character, epptr() points one past the last underlying
21320 character, and if (mode &amp; ios_base::ate) is true,
21321 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
21322 mode &amp; ios_base::in is true, initializes the input sequence such that
21323 eback() and gptr() point to the first underlying character and egptr()
21324 points one past the last underlying character.
21325 </p>
21326 </blockquote>
21327
21328 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
21329
21330 <p>27.7.1.3/1 Change:</p>
21331
21332 <blockquote>
21333 <p>
21334 1- Returns: If the input sequence has a read position available,
21335 returns traits::to_int_type(*gptr()).  Otherwise, returns
21336 traits::eof().
21337 </p>
21338 </blockquote>
21339
21340 <p>to:</p>
21341
21342 <blockquote>
21343 <p>
21344 1- Returns: If the input sequence has a read position available,
21345 returns traits::to_int_type(*gptr()).  Otherwise, returns
21346 traits::eof().  Any character in the underlying buffer which has been
21347 initialized is considered to be part of the input sequence.
21348 </p>
21349 </blockquote>
21350
21351 <p>27.7.1.3/9 Change:</p>
21352
21353 <blockquote>
21354 <p>
21355 -9- Notes: The function can make a write position available only if (
21356 mode &amp; ios_base::out) != 0. To make a write position available, the
21357 function reallocates (or initially allocates) an array object with a
21358 sufficient number of elements to hold the current array object (if
21359 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
21360 0, the function alters the read end pointer egptr() to point just past
21361 the new write position (as does the write end pointer epptr()).
21362 </p>
21363 </blockquote>
21364
21365 <p>to:</p>
21366
21367 <blockquote>
21368 <p>
21369 -9- The function can make a write position available only if ( mode &amp;
21370 ios_base::out) != 0. To make a write position available, the function
21371 reallocates (or initially allocates) an array object with a sufficient
21372 number of elements to hold the current array object (if any), plus one
21373 additional write position. If ( mode &amp; ios_base::in) != 0, the
21374 function alters the read end pointer egptr() to point just past the
21375 new write position.
21376 </p>
21377 </blockquote>
21378
21379 <p>27.7.1.3/12 Change:</p>
21380
21381 <blockquote>
21382 <p>
21383 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
21384 positioning operation fails. Otherwise, the function assigns xbeg +
21385 newoff + off to the next pointer xnext .
21386 </p>
21387 </blockquote>
21388
21389 <p>to:</p>
21390
21391 <blockquote>
21392 <p>
21393 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
21394 uninitialized character (as defined in 27.8.1.3 [stringbuf.members]
21395 paragraph 1), the positioning operation fails. Otherwise, the function
21396 assigns xbeg + newoff + off to the next pointer xnext .
21397 </p>
21398 </blockquote>
21399
21400 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
21401   something along these lines was a good idea, but the original
21402   proposed resolution didn't say enough about the effect of various
21403   member functions on the underlying character sequences.]</i></p>
21404
21405
21406
21407
21408 <p><b>Rationale:</b></p>
21409 <p>The current basic_stringbuf description is over-constrained in such
21410 a way as to prohibit vendors from making this the high-performance
21411 in-memory stream it was meant to be.  The fundamental problem is that
21412 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
21413 observable from a derived client, and the current description
21414 restricts the range [pbase(), epptr()) from being grown geometrically.
21415 This change allows, but does not require, geometric growth of this
21416 range.</p>
21417
21418 <p>Backwards compatibility issues: These changes will break code that
21419 derives from basic_stringbuf, observes epptr(), and depends upon
21420 [pbase(), epptr()) growing by one character on each call to overflow()
21421 (i.e. test suites).  Otherwise there are no backwards compatibility
21422 issues.</p>
21423
21424 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
21425 binding, would be over specification.  The recommended change focuses
21426 on the important observable fact.</p>
21427
21428 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
21429 what must happen in terms of the sequences.  The terms "input
21430 sequence" and "output sequence" are not well defined.  2.  It
21431 introduces a common extension: open with app or ate mode.  I concur
21432 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
21433
21434 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
21435 resultant basic_string is not dependent upon epptr(), and thus
21436 implementors are free to grow the underlying buffer geometrically
21437 during overflow() *and* place epptr() at the end of that buffer.</p>
21438
21439 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
21440
21441 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
21442 the initially specified string are available for reading in an i/o
21443 basic_streambuf.</p>
21444
21445 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
21446 trailing parenthetical comment concerning epptr().</p>
21447
21448 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
21449 longer allowable since [pbase(), epptr()) may now contain
21450 uninitialized characters.  Positioning is only allowable over the
21451 initialized range.</p>
21452
21453
21454
21455
21456
21457 <hr>
21458 <h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
21459 <p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21460  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
21461 <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>
21462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21463 <p><b>Discussion:</b></p>
21464 <p>
21465 It has been pointed out a number of times that the bitset to_string() member
21466 function template is tedious to use since callers must explicitly specify the
21467 entire template argument list (3 arguments). At least two implementations
21468 provide a number of overloads of this template to make it easier to use.
21469 </p>
21470
21471
21472
21473 <p><b>Proposed resolution:</b></p>
21474 <p>In order to allow callers to specify no template arguments at all, just the
21475 first one (charT), or the first 2 (charT and traits), in addition to all
21476 three template arguments, add the following three overloads to both the
21477 interface (declarations only) of the class template bitset as well as to
21478 section 23.3.5.2, immediately after p34, the Returns clause of the existing
21479 to_string() member function template:</p>
21480
21481 <pre>    template &lt;class charT, class traits&gt;
21482     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
21483     to_string () const;
21484
21485     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
21486
21487     template &lt;class charT&gt;
21488     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
21489     to_string () const;
21490
21491     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
21492
21493     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
21494     to_string () const;
21495
21496     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
21497 </pre>
21498
21499 <p><i>[Kona: the LWG agrees that this is an improvement over the
21500   status quo.  Dietmar thought about an alternative using a proxy
21501   object but now believes that the proposed resolution above is the
21502   right choice.
21503 ]</i></p>
21504
21505
21506
21507
21508
21509
21510
21511
21512 <hr>
21513 <h3><a name="435"></a>435. bug in DR 25</h3>
21514 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21515  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
21516 <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>
21517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21518 <p><b>Discussion:</b></p>
21519
21520 <p>
21521 It has been pointed out that the proposed resolution in DR 25 may not be
21522 quite up to snuff: <br>
21523 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
21524 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
21525 </p>
21526
21527 <p>
21528 It looks like Petur is right. The complete corrected text is copied below.
21529 I think we may have have been confused by the reference to 22.2.2.2.2 and
21530 the subsequent description of `n' which actually talks about the second
21531 argument to sputn(), not about the number of fill characters to pad with.
21532 </p>
21533
21534 <p>
21535 So the question is: was the original text correct? If the intent was to
21536 follow classic iostreams then it most likely wasn't, since setting width()
21537 to less than the length of the string doesn't truncate it on output. This
21538 is also the behavior of most implementations (except for SGI's standard
21539 iostreams where the operator does truncate).
21540 </p>
21541
21542
21543
21544 <p><b>Proposed resolution:</b></p>
21545 <p>Change the text in 21.3.7.9, p4 from</p>
21546     <blockquote><p>
21547     If bool(k) is true, inserts characters as if by calling
21548     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
21549     of lib.facet.num.put.virtuals, where n is the larger of os.width()
21550     and str.size(); 
21551     </p></blockquote>
21552 <p>to</p>
21553     <blockquote><p>
21554     If bool(k) is true, determines padding as described in
21555     lib.facet.num.put.virtuals, and then inserts the resulting
21556     sequence of characters <tt>seq</tt> as if by calling
21557     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
21558     <tt>os.width()</tt> and <tt>str.size()</tt>;
21559      </p></blockquote>
21560
21561 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
21562   proposed resolution, is quite what we want.  We want to say that
21563   the string will be output, padded to os.width() if necessary.  We
21564   don't want to duplicate the padding rules in clause 22, because
21565   they're complicated, but we need to be careful because they weren't
21566   quite written with quite this case in mind.  We need to say what
21567   the character sequence is, and then defer to clause 22.  Post-Kona:
21568   Benjamin provided wording.]</i></p>
21569
21570
21571
21572
21573
21574
21575
21576 <hr>
21577 <h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
21578 <p><b>Section:</b> 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21579  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
21580 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21581 <p><b>Discussion:</b></p>
21582 <p>
21583 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
21584 and the locale template ctor? And if so, does it designate the same Facet as
21585 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
21586 Different implementations behave differently: some fail to compile, others
21587 accept such types but behave inconsistently.
21588 </p>
21589
21590
21591 <p><b>Proposed resolution:</b></p>
21592 <p>Change 22.1.1.1.2, p1 to read:</p>
21593
21594 <p>Template parameters in this clause which are required to be facets
21595 are those named Facet in declarations. A program that passes a type
21596 that is not a facet, or a type that refers to volatile-qualified
21597 facet, as an (explicit or deduced) template parameter to a locale
21598 function expecting a facet, is ill-formed.  A const-qualified facet is
21599 a valid template argument to any locale function that expects a Facet
21600 template parameter.</p>
21601
21602 <p><i>[Kona: changed the last sentence from a footnote to normative
21603 text.]</i></p>
21604
21605
21606
21607
21608
21609
21610 <hr>
21611 <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
21612 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21613  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2003-10-20 <b>Last modified:</b> 2010-10-29</p>
21614 <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>
21615 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21616 <p><b>Discussion:</b></p>
21617
21618 <p>Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
21619 noticed with statements like:</p>
21620 <pre>vector&lt;int&gt; v(10, 1);
21621 </pre>
21622
21623 <p>The intent of the above statement was to construct with:</p>
21624 <pre>vector(size_type, const value_type&amp;);
21625 </pre>
21626
21627 <p>but early implementations failed to compile as they bound to:</p>
21628 <pre>template &lt;class InputIterator&gt;
21629 vector(InputIterator f, InputIterator l);
21630 </pre>
21631 <p>instead.</p>
21632
21633 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
21634 member template constructor will have the same effect as:</p>
21635 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
21636 </pre>
21637 <p>(and similarly for the other member template functions of sequences).</p>
21638
21639 <p>There is also a note that describes one implementation technique:</p>
21640 <blockquote><p>
21641    One way that sequence implementors can satisfy this requirement is to
21642    specialize the member template for every integral type.
21643 </p></blockquote>
21644
21645 <p>This might look something like:</p>
21646 <blockquote>
21647 <pre>template &lt;class T&gt;
21648 struct vector
21649 {
21650      typedef unsigned size_type;
21651
21652      explicit vector(size_type) {}
21653      vector(size_type, const T&amp;) {}
21654
21655      template &lt;class I&gt;
21656      vector(I, I);
21657
21658      // ...
21659 };
21660
21661 template &lt;class T&gt;
21662 template &lt;class I&gt;
21663 vector&lt;T&gt;::vector(I, I) { ... }
21664
21665 template &lt;&gt;
21666 template &lt;&gt;
21667 vector&lt;int&gt;::vector(int, int) { ... }
21668
21669 template &lt;&gt;
21670 template &lt;&gt;
21671 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
21672
21673 //  ...
21674 </pre>
21675 </blockquote>
21676
21677 <p>Label this solution 'A'.</p>
21678
21679 <p>The standard also says:</p>
21680 <blockquote><p>
21681  Less cumbersome implementation techniques also exist.
21682 </p></blockquote>
21683 <p>
21684 A popular technique is to not specialize as above, but instead catch
21685 every call with the member template, detect the type of InputIterator,
21686 and then redirect to the correct logic.  Something like:
21687 </p>
21688 <blockquote>
21689 <pre>template &lt;class T&gt;
21690 template &lt;class I&gt;
21691 vector&lt;T&gt;::vector(I f, I l)
21692 {
21693      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
21694 }
21695
21696 template &lt;class T&gt;
21697 template &lt;class I&gt;
21698 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
21699 {
21700     // construct with iterators
21701 }
21702
21703 template &lt;class T&gt;
21704 template &lt;class I&gt;
21705 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
21706 {
21707     size_type sz = static_cast&lt;size_type&gt;(f);
21708     value_type v = static_cast&lt;value_type&gt;(l);
21709     // construct with sz,v
21710 }
21711 </pre>
21712 </blockquote>
21713
21714 <p>Label this solution 'B'.</p>
21715
21716 <p>Both of these solutions solve the case the standard specifically
21717 mentions:</p>
21718 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
21719 </pre>
21720
21721 <p>
21722 However, (and here is the problem), the two solutions have different
21723 behavior in some cases where the value_type of the sequence is not an
21724 integral type.  For example consider:
21725 </p>
21726 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
21727      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
21728 </pre></blockquote>
21729 <p>
21730 The second line of this snippet is likely an error.  Solution A catches
21731 the error and refuses to compile.  The reason is that there is no
21732 specialization of the member template constructor that looks like:
21733 </p>
21734 <pre>template &lt;&gt;
21735 template &lt;&gt;
21736 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
21737 </pre>
21738
21739 <p>
21740 So the expression binds to the unspecialized member template
21741 constructor, and then fails (compile time) because char is not an
21742 InputIterator.
21743 </p>
21744
21745 <p>
21746 Solution B compiles the above example though.  'a' is casted to an
21747 unsigned integral type and used to size the outer vector.  'b' is
21748 static casted to the inner vector using it's explicit constructor:
21749 </p>
21750
21751 <pre>explicit vector(size_type n);
21752 </pre>
21753
21754 <p>
21755 and so you end up with a static_cast&lt;size_type&gt;('a') by
21756 static_cast&lt;size_type&gt;('b') matrix.
21757 </p>
21758
21759 <p>
21760 It is certainly possible that this is what the coder intended.  But the
21761 explicit qualifier on the inner vector has been thwarted at any rate.
21762 </p>
21763
21764 <p>
21765 The standard is not clear whether the expression:
21766 </p>
21767
21768 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
21769 </pre>
21770
21771 <p>
21772 (and similar expressions) are:
21773 </p>
21774
21775 <ol>
21776 <li>  undefined behavior.</li>
21777 <li>  illegal and must be rejected.</li>
21778 <li>  legal and must be accepted.</li>
21779 </ol>
21780
21781 <p>My preference is listed in the order presented.</p>
21782
21783 <p>There are still other techniques for implementing the requirements of
21784 paragraphs 9-11, namely the "restricted template technique" (e.g.
21785 enable_if).  This technique is the most compact and easy way of coding
21786 the requirements, and has the behavior of #2 (rejects the above
21787 expression).
21788 </p>
21789
21790 <p>
21791 Choosing 1 would allow all implementation techniques I'm aware of.
21792 Choosing 2 would allow only solution 'A' and the enable_if technique.
21793 Choosing 3 would allow only solution 'B'.
21794 </p>
21795
21796 <p>
21797 Possible wording for a future standard if we wanted to actively reject
21798 the expression above would be to change "static_cast" in paragraphs
21799 9-11 to "implicit_cast" where that is defined by:
21800 </p>
21801
21802 <blockquote>
21803 <pre>template &lt;class T, class U&gt;
21804 inline
21805 T implicit_cast(const U&amp; u)
21806 {
21807      return u;
21808 }
21809 </pre>
21810 </blockquote>
21811
21812
21813
21814 <p><b>Proposed resolution:</b></p>
21815
21816 <p>Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
21817
21818 <p>For every sequence defined in this clause and in clause lib.strings:</p>
21819
21820 <ul>
21821   <li>
21822     <p>If the constructor</p>
21823        <pre>       template &lt;class InputIterator&gt;
21824        X(InputIterator f, InputIterator l,
21825          const allocator_type&amp; a = allocator_type())
21826        </pre>
21827     <p>is called with a type InputIterator that does not qualify as
21828     an input iterator, then the constructor will behave as if the
21829     overloaded constructor:</p>
21830        <pre>       X(size_type, const value_type&amp; = value_type(),
21831          const allocator_type&amp; = allocator_type())
21832        </pre>
21833     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
21834   </li>
21835
21836   <li>
21837     <p>If the member functions of the forms:</p>
21838        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
21839        rt fx1(iterator p, InputIterator f, InputIterator l);
21840
21841        template &lt;class InputIterator&gt;          //  such as  append(), assign()
21842        rt fx2(InputIterator f, InputIterator l);
21843
21844        template &lt;class InputIterator&gt;          //  such as  replace()
21845        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
21846        </pre>
21847     <p>are called with a type InputIterator that does not qualify as
21848     an input iterator, then these functions will behave as if the
21849     overloaded member functions:</p>
21850        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
21851
21852        rt fx2(size_type, const value_type&amp;);
21853
21854        rt fx3(iterator, iterator, size_type, const value_type&amp;);
21855        </pre>
21856     <p>were called instead, with the same arguments.</p>
21857   </li>
21858 </ul>
21859
21860 <p>In the previous paragraph the alternative binding will fail if f 
21861 is not implicitly convertible to X::size_type or if l is not implicitly 
21862 convertible to X::value_type.</p>
21863
21864 <p>
21865 The extent to which an implementation determines that a type cannot be
21866 an input iterator is unspecified, except that as a minimum integral
21867 types shall not qualify as input iterators.
21868 </p>
21869
21870
21871
21872 <p><i>[
21873 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
21874 to be accepted, and also agreed that this is surprising behavior.  The
21875 LWG considered several options, including something like
21876 implicit_cast, which doesn't appear to be quite what we want.  We
21877 considered Howards three options: allow acceptance or rejection,
21878 require rejection as a compile time error, and require acceptance.  By
21879 straw poll (1-6-1), we chose to require a compile time error.
21880 Post-Kona: Howard provided wording.
21881 ]</i></p>
21882
21883
21884 <p><i>[
21885 Sydney: The LWG agreed with this general direction, but there was some
21886 discomfort with the wording in the original proposed resolution.
21887 Howard submitted new wording, and we will review this again in
21888 Redmond.
21889 ]</i></p>
21890
21891
21892 <p><i>[Redmond: one very small change in wording: the first argument
21893   is cast to size_t.  This fixes the problem of something like
21894   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not 
21895   implicitly convertible to the value type.]</i></p>
21896
21897
21898
21899
21900 <p><b>Rationale:</b></p>
21901 <p>The proposed resolution fixes:</p>
21902
21903 <pre>  vector&lt;int&gt; v(10, 1);
21904 </pre>
21905
21906 <p>
21907 since as integral types 10 and 1 must be disqualified as input
21908 iterators and therefore the (size,value) constructor is called (as
21909 if).</p>
21910
21911 <p>The proposed resolution breaks:</p>
21912
21913 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
21914 </pre>
21915
21916 <p>
21917 because the integral type 1 is not *implicitly* convertible to
21918 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
21919
21920 <p>
21921 The proposed resolution leaves the behavior of the following code
21922 unspecified.
21923 </p>
21924
21925 <pre>  struct A
21926   {
21927     operator int () const {return 10;}
21928   };
21929
21930   struct B
21931   {
21932     B(A) {}
21933   };
21934
21935   vector&lt;B&gt; v(A(), A());
21936 </pre>
21937
21938 <p>
21939 The implementation may or may not detect that A is not an input
21940 iterator and employee the (size,value) constructor.  Note though that
21941 in the above example if the B(A) constructor is qualified explicit,
21942 then the implementation must reject the constructor as A is no longer
21943 implicitly convertible to B.
21944 </p>
21945
21946
21947
21948
21949
21950 <hr>
21951 <h3><a name="441"></a>441. Is fpos::state const?</h3>
21952 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21953  <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-17 <b>Last modified:</b> 2010-10-29</p>
21954 <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>
21955 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21956 <p><b>Discussion:</b></p>
21957 <p>
21958 In section 27.5.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
21959 non const, but in section 27.5.3 [fpos] it is declared const.
21960 </p>
21961
21962
21963 <p><b>Proposed resolution:</b></p>
21964 <p>
21965 In section 27.5.3.1 [fpos.members], change the declaration of 
21966 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
21967 </p>
21968
21969
21970
21971
21972
21973 <hr>
21974 <h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
21975 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21976  <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-18 <b>Last modified:</b> 2010-10-29</p>
21977 <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>
21978 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21979 <p><b>Discussion:</b></p>
21980 <p>
21981 In section 27.7.2.4 [ostream::sentry] paragraph 4, in description part
21982 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
21983 as non const, but in section 27.6.2.3, in synopsis it is declared
21984 const.
21985 </p>
21986
21987
21988 <p><b>Proposed resolution:</b></p>
21989 <p>
21990 In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration
21991 of <tt>sentry::operator bool()</tt> to const.
21992 </p>
21993
21994
21995
21996
21997
21998 <hr>
21999 <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
22000 <p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22001  <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2010-10-29</p>
22002 <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>
22003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22004 <p><b>Discussion:</b></p>
22005 <p>
22006 In section 27.9.1.4 [filebuf.members] par6, in effects description of
22007 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
22008 should be overflow(traits::eof()).
22009 </p>
22010
22011
22012 <p><b>Proposed resolution:</b></p>
22013 <p>
22014 Change overflow(EOF) to overflow(traits::eof()).
22015 </p>
22016
22017
22018
22019
22020
22021 <hr>
22022 <h3><a name="444"></a>444. Bad use of casts in fstream</h3>
22023 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22024  <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2010-10-29</p>
22025 <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>
22026 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22027 <p><b>Discussion:</b></p>
22028 <p>
22029 27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1, 27.9.1.17 [fstream.members] p1 seems have same problem as exposed in LWG issue
22030 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
22031 </p>
22032
22033
22034 <p><b>Proposed resolution:</b></p>
22035
22036 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
22037  constness. The other two places are stylistic: we could change the
22038  C-style casts to const_cast. Post-Sydney: Howard provided wording.
22039 ]</i></p>
22040
22041
22042 <p>Change 27.8.1.7/1 from:</p>
22043 <blockquote><p>
22044   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
22045 </p></blockquote>
22046
22047 <p>to:</p>
22048 <blockquote><p>
22049   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
22050 </p></blockquote>
22051
22052 <p>Change 27.8.1.10/1 from:</p>
22053 <blockquote><p>
22054   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
22055 </p></blockquote>
22056
22057 <p>to:</p>
22058 <blockquote><p>
22059   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
22060 </p></blockquote>
22061
22062 <p>Change 27.8.1.13/1 from:</p>
22063 <blockquote><p>
22064   Returns: &amp;sb.
22065 </p></blockquote>
22066
22067 <p>to:</p>
22068 <blockquote><p>
22069   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
22070 </p></blockquote>
22071
22072
22073
22074
22075
22076
22077
22078
22079 <hr>
22080 <h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
22081 <p><b>Section:</b> 24.4.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22082  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-12-09 <b>Last modified:</b> 2010-10-29</p>
22083 <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>
22084 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22085 <p><b>Discussion:</b></p>
22086 <p>
22087 The standard places no restrictions at all on the reference type
22088 of input, output, or forward iterators (for forward iterators it
22089 only specifies that *x must be value_type&amp; and doesn't mention
22090 the reference type).  Bidirectional iterators' reference type is
22091 restricted only by implication, since the base iterator's
22092 reference type is used as the return type of reverse_iterator's
22093 operator*, which must be T&amp; in order to be a conforming forward
22094 iterator.
22095 </p>
22096
22097 <p>
22098 Here's what I think we ought to be able to expect from an input
22099 or forward iterator's reference type R, where a is an iterator
22100 and V is its value_type
22101 </p>
22102
22103 <ul>
22104   <li>
22105       *a is convertible to R
22106   </li>
22107
22108   <li>
22109       R is convertible to V
22110   </li>
22111
22112   <li>
22113       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
22114       static_cast&lt;V&gt;(*a) 
22115   </li>
22116 </ul>
22117
22118 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
22119   <pre>      { R r = *a; r = x; } is equivalent to *a = x;
22120   </pre>
22121
22122 <p>
22123 I think these requirements capture existing container iterators
22124 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
22125 its reference type would have to be changed to a constant
22126 reference.
22127 </p>
22128
22129
22130 <p>
22131 (Jeremy Siek) During the discussion in Sydney, it was felt that a
22132 simpler long term solution for this was needed. The solution proposed
22133 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
22134 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
22135 iterators in the Standard Library already meet this requirement. Some
22136 iterators are output iterators, and do not need to meet the
22137 requirement, and others are only specified through the general
22138 iterator requirements (which will change with this resolution). The
22139 sole case where there is an explicit definition of the reference type
22140 that will need to change is <tt>istreambuf_iterator</tt> which returns
22141 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
22142 <tt>charT&amp;</tt>. We propose changing the reference type of
22143 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
22144 </p>
22145
22146 <p>The other option for resolving the issue with <tt>pointer</tt>,
22147   mentioned in the note below, is to remove <tt>pointer</tt>
22148   altogether. I prefer placing requirements on <tt>pointer</tt> to
22149   removing it for two reasons. First, <tt>pointer</tt> will become
22150   useful for implementing iterator adaptors and in particular,
22151   <tt>reverse_iterator</tt> will become more well defined. Second,
22152   removing <tt>pointer</tt> is a rather drastic and publicly-visible
22153   action to take.</p>
22154
22155 <p>The proposed resolution technically enlarges the requirements for
22156 iterators, which means there are existing iterators (such as
22157 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
22158 iterators) that will no longer meet the requirements. Will this break
22159 existing code? The scenario in which it would is if an algorithm
22160 implementation (say in the Standard Library) is changed to rely on
22161 <tt>iterator_traits::reference</tt>, and then is used with one of the
22162 iterators that do not have an appropriately defined
22163 <tt>iterator_traits::reference</tt>.
22164 </p>
22165
22166
22167 <p>The proposed resolution makes one other subtle change. Previously,
22168 it was required that output iterators have a <tt>difference_type</tt>
22169 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
22170 iterator could not be an output iterator. This is clearly a mistake,
22171 so I've changed the wording to say that those types may be
22172 <tt>void</tt>.
22173 </p>
22174
22175
22176
22177 <p><b>Proposed resolution:</b></p>
22178
22179 <p>In 24.4.1 [iterator.traits], after:</p>
22180
22181 <blockquote><p>
22182 be defined as the iterator's difference type, value type and iterator
22183 category, respectively.
22184 </p></blockquote>
22185
22186 <p>add</p>
22187
22188 <blockquote><p>
22189 In addition, the types</p>
22190 <pre>iterator_traits&lt;Iterator&gt;::reference
22191 iterator_traits&lt;Iterator&gt;::pointer
22192 </pre>
22193 <p>must be defined as the iterator's reference and pointer types, that
22194 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
22195 respectively.</p>
22196 </blockquote>
22197
22198 <p>In 24.4.1 [iterator.traits], change:</p>
22199
22200 <blockquote><p>
22201 In the case of an output iterator, the types</p>
22202 <pre>iterator_traits&lt;Iterator&gt;::difference_type
22203 iterator_traits&lt;Iterator&gt;::value_type
22204 </pre>
22205 <p>are both defined as <tt>void</tt>.</p>
22206 </blockquote>
22207
22208 <p>to:</p>
22209 <blockquote><p>
22210 In the case of an output iterator, the types</p>
22211 <pre>iterator_traits&lt;Iterator&gt;::difference_type
22212 iterator_traits&lt;Iterator&gt;::value_type
22213 iterator_traits&lt;Iterator&gt;::reference
22214 iterator_traits&lt;Iterator&gt;::pointer
22215 </pre>
22216 <p>may be defined as <tt>void</tt>.</p>
22217 </blockquote>
22218
22219 <p>In 24.6.3 [istreambuf.iterator], change:</p>
22220 <blockquote>
22221 <pre>typename traits::off_type, charT*, charT&amp;&gt;
22222 </pre>
22223 </blockquote>
22224 <p>to:</p>
22225 <blockquote>
22226 <pre>typename traits::off_type, charT*, charT&gt;
22227 </pre>
22228 </blockquote>
22229
22230 <p><i>[
22231 Redmond: there was concern in Sydney that this might not be the only place
22232 where things were underspecified and needed to be changed.  Jeremy
22233 reviewed iterators in the standard and confirmed that nothing else
22234 needed to be changed.
22235 ]</i></p>
22236
22237
22238
22239
22240
22241
22242
22243
22244
22245 <hr>
22246 <h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
22247 <p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22248  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-01-07 <b>Last modified:</b> 2010-10-29</p>
22249 <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>
22250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22251 <p><b>Discussion:</b></p>
22252 <p>
22253 Table 76, the random access iterator requirement table, says that the
22254 return type of a[n] must be "convertible to T".  When an iterator's
22255 value_type T is an abstract class, nothing is convertible to T.
22256 Surely this isn't an intended restriction?
22257 </p>
22258
22259
22260 <p><b>Proposed resolution:</b></p>
22261 <p>
22262 Change the return type to "convertible to T const&amp;".
22263 </p>
22264
22265
22266
22267
22268
22269 <hr>
22270 <h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
22271 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22272  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2004-01-15 <b>Last modified:</b> 2010-10-29</p>
22273 <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>
22274 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22275 <p><b>Discussion:</b></p>
22276 <p>Original text:</p>
22277 <blockquote><p>
22278 The macro offsetof accepts a restricted set of type arguments in this
22279 International Standard. type shall be a POD structure or a POD union
22280 (clause 9). The result of applying the offsetof macro to a field that
22281 is a static data member or a function member is undefined."
22282 </p></blockquote>
22283
22284 <p>Revised text:</p>
22285 <blockquote><p>
22286 "If type is not a POD structure or a POD union the results are undefined."
22287 </p></blockquote>
22288
22289 <p>
22290 Looks to me like the revised text should have replaced only the second
22291 sentence. It doesn't make sense standing alone.
22292 </p>
22293
22294
22295
22296 <p><b>Proposed resolution:</b></p>
22297 <p>Change 18.1, paragraph 5, to:</p>
22298
22299 <blockquote><p>
22300 The macro offsetof accepts a restricted set of type arguments in this
22301 International Standard.  If type is not a POD structure or a POD union
22302 the results are undefined.  The result of applying the offsetof macro
22303 to a field that is a static data member or a function member is
22304 undefined."
22305 </p></blockquote>
22306
22307
22308
22309
22310
22311 <hr>
22312 <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
22313 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22314  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
22315 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
22316 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22317 <p><b>Discussion:</b></p>
22318 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
22319                                     ios_base::openmode);
22320 </pre>
22321 <p>
22322 is obliged to fail if nothing has been inserted into the stream. This
22323 is unnecessary and undesirable. It should be permissible to seek to
22324 an effective offset of zero.</p>
22325
22326 <p><i>[
22327  Sydney: Agreed that this is an annoying problem: seeking to zero should be
22328  legal. Bill will provide wording.
22329 ]</i></p>
22330
22331
22332
22333
22334 <p><b>Proposed resolution:</b></p>
22335 <p>Change the sentence from:</p>
22336 <blockquote><p>
22337 For a sequence to be positioned, if its next pointer (either
22338 gptr() or pptr()) is a null pointer, the positioning operation
22339 fails.
22340 </p></blockquote>
22341
22342 <p>to:</p>
22343
22344 <blockquote><p>
22345 For a sequence to be positioned, if its next pointer (either
22346 gptr() or pptr()) is a null pointer and the new offset newoff
22347 is nonzero, the positioning operation fails.
22348 </p></blockquote>
22349
22350
22351
22352
22353
22354 <hr>
22355 <h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
22356 <p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22357  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
22358 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
22359 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22360 <p><b>Discussion:</b></p>
22361 <p>
22362 Both cerr::tie() and wcerr::tie() are obliged to be null at program
22363 startup. This is overspecification and overkill. It is both traditional
22364 and useful to tie cerr to cout, to ensure that standard output is drained
22365 whenever an error message is written. This behavior should at least be
22366 permitted if not required. Same for wcerr::tie().
22367 </p>
22368
22369
22370 <p><b>Proposed resolution:</b></p>
22371
22372 <p>Add to the description of cerr:</p>
22373 <blockquote><p>
22374 After the object cerr is initialized, cerr.tie() returns &amp;cout.
22375 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
22376 (lib.basic.ios.cons).
22377 </p></blockquote>
22378
22379 <p>Add to the description of wcerr:</p>
22380
22381 <blockquote><p>
22382 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
22383 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
22384 (lib.basic.ios.cons).
22385 </p></blockquote>
22386
22387 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
22388   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
22389   provide wording.]</i></p>
22390
22391
22392
22393
22394
22395
22396 <hr>
22397 <h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
22398 <p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22399  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
22400 <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>
22401 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22402 <p><b>Discussion:</b></p>
22403
22404 <p>The C++ Standard effectively requires that the traditional C headers
22405 (of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
22406 headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
22407 to require that:</p>
22408
22409 <ul>
22410  <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
22411
22412  <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
22413     (effectively by including &lt;cxxx&gt;), then imports it into the global
22414     namespace with an individual using declaration.</li>
22415 </ul>
22416
22417 <p>
22418 The rules were left in this form despited repeated and heated objections
22419 from several compiler vendors. The C headers are often beyond the direct
22420 control of C++ implementors. In some organizations, it's all they can do
22421 to get a few #ifdef __cplusplus tests added. Third-party library vendors
22422 can perhaps wrap the C headers. But neither of these approaches supports
22423 the drastic restructuring required by the C++ Standard. As a result, it is
22424 still widespread practice to ignore this conformance requirement, nearly
22425 seven years after the committee last debated this topic. Instead, what is
22426 often implemented is:
22427 </p>
22428
22429 <ul>
22430  <li> Including the header &lt;xxx.h&gt; declares a C name in the
22431  global namespace.</li> 
22432
22433  <li> Including the header &lt;cxxx&gt; declares a C name in the
22434  global namespace (effectively by including &lt;xxx.h&gt;), then
22435  imports it into namespace std with an individual using declaration.</li>
22436 </ul>
22437
22438 <p>
22439 The practical benefit for implementors with the second approach is that
22440 they can use existing C library headers, as they are pretty much obliged
22441 to do. The practical cost for programmers facing a mix of implementations
22442 is that they have to assume weaker rules:</p>
22443
22444 <ul>
22445   <li> If you want to assuredly declare a C name in the global
22446   namespace, include &lt;xxx.h&gt;. You may or may not also get the
22447   declaration in namespace std.</li>
22448
22449   <li> If you want to assuredly declare a C name in namespace std,
22450   include &lt;cxxx&gt;. You may or may not also get the declaration in
22451   the global namespace.</li>
22452 </ul>
22453
22454 <p>
22455 There also exists the <i>possibility</i> of subtle differences due to
22456 Koenig lookup, but there are so few non-builtin types defined in the C
22457 headers that I've yet to see an example of any real problems in this
22458 area.
22459 </p>
22460
22461 <p>
22462 It is worth observing that the rate at which programmers fall afoul of
22463 these differences has remained small, at least as measured by newsgroup
22464 postings and our own bug reports. (By an overwhelming margin, the
22465 commonest problem is still that programmers include &lt;string&gt; and can't
22466 understand why the typename string isn't defined -- this a decade after
22467 the committee invented namespace std, nominally for the benefit of all
22468 programmers.)
22469 </p>
22470
22471 <p>
22472 We should accept the fact that we made a serious mistake and rectify it,
22473 however belatedly, by explicitly allowing either of the two schemes for
22474 declaring C names in headers.
22475 </p>
22476
22477 <p><i>[Sydney: This issue has been debated many times, and will
22478   certainly have to be discussed in full committee before any action
22479   can be taken.  However, the preliminary sentiment of the LWG was in
22480   favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
22481   suggests that we might also want to undeprecate the
22482   C-style <tt>.h</tt> headers.]</i></p>
22483
22484
22485
22486
22487 <p><b>Proposed resolution:</b></p>
22488 <p>
22489 Add to 17.6.1.2 [headers], para. 4:
22490 </p>
22491
22492 <blockquote><p>
22493 Except as noted in clauses 18 through 27 and Annex D, the contents of each
22494 header <i>cname</i> shall be the same as that of the corresponding header
22495 <i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
22496 7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
22497 7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
22498 the declarations <del>and definitions</del> (except for names which are defined
22499 as macros in C) are within namespace scope (3.3.5) of the namespace std. 
22500 <ins>It is unspecified whether these names are first declared within the global
22501 namespace scope and are then injected into namespace std by explicit
22502 using-declarations (7.3.3 [namespace.udecl]).</ins>
22503 </p></blockquote>
22504
22505 <p>
22506 Change D.7 [depr.c.headers], para. 2-3:
22507 </p>
22508
22509 <blockquote>
22510 <p>
22511 -2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
22512 as if each name placed in the Standard library namespace by the corresponding
22513 <i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
22514 namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
22515 by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
22516 <ins>It is unspecified whether these names are first declared or defined within
22517 namespace scope (3.3.6 [basic.scope.namespace]) of the namespace
22518 <tt>std</tt> and are then injected into the global namespace scope by explicit
22519 using-declarations (7.3.3 [namespace.udecl]).</ins>
22520 </p>
22521 <p>
22522 -3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
22523 provides its declarations and definitions within the namespace <tt>std</tt>.
22524 <ins>It may also provide these names within the global namespace.</ins> The
22525 header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
22526 <ins>assuredly provides the same declarations and definitions within</ins> the
22527 global namespace, much as in the C Standard. <ins>It may also provide these
22528 names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
22529 </p>
22530 </blockquote>
22531
22532
22533
22534
22535
22536 <hr>
22537 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
22538 <p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22539  <b>Submitter:</b> Dag Henriksson <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
22540 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
22541 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22542 <p><b>Discussion:</b></p>
22543 <p>
22544 The constructor from unsigned long says it initializes "the first M
22545 bit positions to the corresponding bit values in val. M is the smaller
22546 of N and the value CHAR_BIT * sizeof(unsigned long)."
22547 </p>
22548
22549 <p>
22550 Object-representation vs. value-representation strikes again. CHAR_BIT *
22551 sizeof (unsigned long) does not give us the number of bits an unsigned long
22552 uses to hold the value. Thus, the first M bit position above is not
22553 guaranteed to have any corresponding bit values in val.
22554 </p>
22555
22556
22557 <p><b>Proposed resolution:</b></p>
22558 <p>In 20.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
22559   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
22560   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
22561   the value representation (section 3.9 [basic.types]) of <tt>unsigned
22562   long</tt>."
22563 </p>
22564
22565
22566
22567
22568
22569 <hr>
22570 <h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
22571 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22572  <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-04-01 <b>Last modified:</b> 2010-10-29</p>
22573 <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>
22574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22575 <p><b>Discussion:</b></p>
22576 <p>
22577 The second parameters of the non-default constructor and of the open
22578 member function for basic_fstream, named "mode", are optional
22579 according to the class declaration in 27.8.1.11 [lib.fstream].  The
22580 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
22581 27.8.1.13 lib.fstream.members] disagree with this, though the
22582 constructor declaration has the "explicit" function-specifier implying
22583 that it is intended to be callable with one argument.
22584 </p>
22585
22586
22587 <p><b>Proposed resolution:</b></p>
22588 <p>In 27.9.1.15 [fstream.cons], change</p>
22589 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode); 
22590 </pre>
22591 <p>to</p>
22592 <pre>  explicit basic_fstream(const char* s,
22593                          ios_base::openmode mode = ios_base::in|ios_base::out);
22594 </pre>
22595 <p>In 27.9.1.17 [fstream.members], change</p>
22596 <pre>  void open(const char*s, ios_base::openmode mode); 
22597 </pre>
22598 <p>to</p>
22599 <pre>  void open(const char*s,
22600             ios_base::openmode mode = ios_base::in|ios_base::out);
22601 </pre>
22602
22603
22604
22605
22606
22607 <hr>
22608 <h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
22609 <p><b>Section:</b> 22.4.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22610  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23 <b>Last modified:</b> 2010-10-29</p>
22611 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22612 <p><b>Discussion:</b></p>
22613 <p>
22614 Template time_get currently contains difficult, if not impossible,
22615 requirements for do_date_order, do_get_time, and do_get_date. All require
22616 the implementation to scan a field generated by the %x or %X conversion
22617 specifier in strftime. Yes, do_date_order can always return no_order, but
22618 that doesn't help the other functions. The problem is that %x can be
22619 nearly anything, and it can vary widely with locales. It's horribly
22620 onerous to have to parse "third sunday after Michaelmas in the year of
22621 our Lord two thousand and three," but that's what we currently ask of
22622 do_get_date. More practically, it leads some people to think that if
22623 %x produces 10.2.04, we should know to look for dots as separators. Still
22624 not easy.
22625 </p>
22626
22627 <p>
22628 Note that this is the <i>opposite</i> effect from the intent stated in the
22629 footnote earlier in this subclause:
22630 </p>
22631
22632 <blockquote><p>
22633 "In other words, user confirmation is required for reliable parsing of
22634 user-entered dates and times, but machine-generated formats can be
22635 parsed reliably. This allows parsers to be aggressive about interpreting
22636 user variations on standard formats."
22637 </p></blockquote>
22638
22639 <p>
22640 We should give both implementers and users an easier and more reliable
22641 alternative: provide a (short) list of alternative delimiters and say
22642 what the default date order is for no_order. For backward compatibility,
22643 and maximum latitude, we can permit an implementation to parse whatever
22644 %x or %X generates, but we shouldn't require it.
22645 </p>
22646
22647
22648 <p><b>Proposed resolution:</b></p>
22649
22650 <p><b>In the description:</b></p>
22651 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
22652         ios_base::iostate&amp; err, tm* t) const;
22653 </pre>
22654
22655 <p>
22656 2 Effects: Reads characters starting at suntil it has extracted those
22657 struct tm members, and remaining format characters, used by
22658 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
22659 encounters an error or end of sequence.
22660 </p>
22661
22662 <p><b>change:</b> 'X'</p>
22663
22664 <p><b>to:</b> "%H:%M:%S"</p>
22665
22666
22667 <p>Change</p>
22668 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
22669         ios_base::iostate&amp; err, tm* t) const;
22670
22671 4 Effects: Reads characters starting at s until it has extracted those
22672 struct tm members, and remaining format characters, used by
22673 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
22674 encounters an error.
22675 </pre>
22676
22677 <p>to</p>
22678 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
22679         ios_base::iostate&amp; err, tm* t) const;
22680 </pre>
22681
22682 <p>
22683 4 Effects: Reads characters starting at s until it has extracted those
22684 struct tm members, and remaining format characters, used by
22685 time_put&lt;&gt;::put to produce one of the following formats, or until it
22686 encounters an error. The format depends on the value returned by
22687 date_order() as follows:
22688 </p>
22689
22690 <pre>        date_order()  format
22691
22692         no_order      "%m/%d/%y"
22693         dmy           "%d/%m/%y"
22694         mdy           "%m/%d/%y"
22695         ymd           "%y/%m/%d"
22696         ydm           "%y/%d/%m"
22697 </pre>
22698 <p>
22699 An implementation may also accept additional implementation-defined formats.
22700 </p>
22701
22702 <p><i>[Redmond: agreed that this is a real problem.  The solution is
22703   probably to match C99's parsing rules.  Bill provided wording.
22704 ]</i></p>
22705
22706
22707
22708
22709
22710
22711
22712 <hr>
22713 <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
22714 <p><b>Section:</b> 23.4.1 [vector], 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22715  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2004-05-12 <b>Last modified:</b> 2010-10-29</p>
22716 <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>
22717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22718 <p><b>Discussion:</b></p>
22719
22720 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
22721 <ol>
22722 <li> add vector&lt;T&gt;::data() member (const and non-const version)
22723 semantics: if( empty() ) return 0; else return buffer_;</li>
22724 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
22725 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
22726 </ol>
22727
22728 <p>Rationale:</p>
22729
22730 <ul>
22731 <li>To obtain a pointer to the vector's buffer, one must use either operator[]() (which can give undefined  behavior for empty vectors) or at() (which will then throw if the vector is empty).  </li>
22732 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
22733 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
22734 <li>Neither when the map is const.</li>
22735 <li>when we want to make sure we don't add an element accidently</li>
22736 <li>when it should be considered an error if a key is not in the map</li>
22737 </ul>
22738
22739
22740
22741 <p><b>Proposed resolution:</b></p>
22742 <p>In 23.4.1 [vector], add the following to the <tt>vector</tt>
22743   synopsis after "element access" and before "modifiers":</p>
22744 <pre>  // <i>[lib.vector.data] data access</i>
22745   pointer       data();
22746   const_pointer data() const;
22747 </pre>
22748
22749 <p>Add a new subsection of 23.4.1 [vector]:</p>
22750 <blockquote>
22751 <p>23.2.4.x <tt>vector</tt> data access</p>
22752 <pre>   pointer       data();
22753    const_pointer data() const;
22754 </pre>
22755 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
22756    range.  For a non-empty vector, data() == &amp;front().</p>
22757 <p><b>Complexity:</b> Constant time.</p>
22758 <p><b>Throws:</b> Nothing.</p>
22759 </blockquote>
22760
22761 <p>In 23.6.1 [map], add the following to the <tt>map</tt>
22762 synopsis immediately after the line for operator[]:</p>
22763 <pre>  T&amp;       at(const key_type&amp; x);
22764   const T&amp; at(const key_type&amp; x) const;
22765 </pre>
22766
22767 <p>Add the following to 23.6.1.2 [map.access]:</p>
22768 <blockquote>
22769 <pre>  T&amp;       at(const key_type&amp; x);
22770   const T&amp; at(const key_type&amp; x) const;
22771 </pre>
22772
22773 <p><b>Returns:</b> A reference to the element whose key is equivalent
22774   to x, if such an element is present in the map.</p>
22775 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
22776
22777 </blockquote>
22778
22779
22780
22781 <p><b>Rationale:</b></p>
22782 <p>Neither of these additions provides any new functionality but the
22783   LWG agreed that they are convenient, especially for novices.  The
22784   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
22785   was chosen to match <tt>vector::at</tt>.</p>
22786
22787
22788
22789
22790
22791 <hr>
22792 <h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
22793 <p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22794  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2004-06-03 <b>Last modified:</b> 2010-10-29</p>
22795 <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>
22796 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22797 <p><b>Discussion:</b></p>
22798 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
22799 not_eq for !=.</p>
22800
22801 <p>Section 17.6.1.2 [headers] "Headers" says that except as noted in
22802 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
22803 as the C header &lt;name.h&gt;. In particular, table 12 lists
22804 &lt;ciso646&gt; as a C++ header.</p>
22805
22806 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
22807 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
22808 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
22809
22810 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
22811 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
22812 defined as macros in &lt;ciso646&gt;, but does not mention the contents
22813 of &lt;iso646.h&gt;.</p>
22814
22815 <p>I don't find any normative text to support C.2.2.2.</p>
22816
22817
22818
22819 <p><b>Proposed resolution:</b></p>
22820 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
22821   paragraph 6 (the one about functions must be functions):</p> 
22822
22823 <blockquote>
22824 <p>Identifiers that are keywords or operators in C++ shall not be defined
22825 as macros in C++ standard library headers. 
22826 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
22827 or &lt;ciso646&gt; has no effect. </p>
22828 </blockquote>
22829
22830 <p><i>[post-Redmond: Steve provided wording.]</i></p>
22831
22832
22833
22834
22835
22836
22837
22838 <hr>
22839 <h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
22840 <p><b>Section:</b> 21.2.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22841  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
22842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22843 <p><b>Discussion:</b></p>
22844
22845 <p>
22846 Table 37 describes the requirements on Traits::compare() in terms of
22847 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
22848 to yield the same result as operator&lt;(char, char).
22849 </p>
22850
22851 <p>
22852 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
22853 call memcmp() for efficiency. However, the C standard requires both
22854 memcmp() and strcmp() to interpret characters under comparison as
22855 unsigned, regardless of the signedness of char. As a result, all
22856 these char_traits implementations fail to meet the requirement
22857 imposed by Table 37 on compare() when char is signed.
22858 </p>
22859
22860
22861 <p>Read email thread starting with c++std-lib-13499 for more. </p>
22862
22863
22864 <p><b>Proposed resolution:</b></p>
22865
22866
22867 <p>Change 21.1.3.1, p6 from</p>
22868 <blockquote><p>
22869     The two-argument members assign, eq, and lt are defined identically
22870     to the built-in operators =, ==, and &lt; respectively.
22871 </p></blockquote>
22872 <p>to</p>
22873 <blockquote><p>
22874   The two-argument member assign is defined identically to
22875   the built-in operator =. The two
22876   argument members eq and lt are defined identically to
22877   the built-in operators == and &lt; for type unsigned char.
22878 </p></blockquote>
22879
22880 <p><i>[Redmond: The LWG agreed with this general direction, but we
22881   also need to change <tt>eq</tt> to be consistent with this change.
22882   Post-Redmond: Martin provided wording.]</i></p>
22883
22884
22885
22886
22887
22888
22889 <hr>
22890 <h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
22891 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22892  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
22893 <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>
22894 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22895 <p><b>Discussion:</b></p>
22896
22897 <p>The program below is required to compile but when run it typically
22898 produces unexpected results due to the user-defined conversion from
22899 std::cout or any object derived from basic_ios to void*.
22900 </p>
22901
22902 <pre>    #include &lt;cassert&gt;
22903     #include &lt;iostream&gt;
22904
22905     int main ()
22906     {
22907         assert (std::cin.tie () == std::cout);
22908         // calls std::cout.ios::operator void*()
22909     }
22910 </pre>
22911
22912
22913 <p><b>Proposed resolution:</b></p>
22914
22915 <p>
22916 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
22917 conversion operator to some unspecified type that is guaranteed not
22918 to be convertible to any other type except for bool (a pointer-to-member
22919 might be one such suitable type). In addition, make it clear that the
22920 pointer type need not be a pointer to a complete type and when non-null,
22921 the value need not be valid.
22922 </p>
22923
22924 <p>Specifically, change in [lib.ios] the signature of</p>
22925 <pre>    operator void*() const;
22926 </pre>
22927 <p>to</p>
22928 <pre>    operator unspecified-bool-type() const;
22929 </pre>
22930 <p>and change [lib.iostate.flags], p1 from</p>
22931 <pre>    operator void*() const;
22932 </pre>
22933 <p>to</p>
22934 <pre>operator unspecified-bool-type() const;
22935
22936      -1- Returns: if fail() then a value that will evaluate false in a
22937       boolean context; otherwise a value that will evaluate true in a
22938       boolean context. The value type returned shall not be
22939       convertible to int.
22940
22941      -2- [Note: This conversion can be used in contexts where a bool
22942       is expected (e.g., an if condition); however, implicit
22943       conversions (e.g., to int) that can occur with bool are not
22944       allowed, eliminating some sources of user error. One possible
22945       implementation choice for this type is pointer-to-member.  - end
22946       note]
22947 </pre>
22948
22949 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
22950
22951 <p><i>[Lillehammer: Doug provided revised wording for
22952   "unspecified-bool-type".]</i></p>
22953  
22954
22955
22956
22957
22958
22959
22960
22961 <hr>
22962 <h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
22963 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
22964  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
22965 <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>
22966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22967 <p><b>Discussion:</b></p>
22968
22969 <p>
22970 The overloads of relational operators for vector&lt;bool&gt; specified
22971 in [lib.vector.bool] are redundant (they are semantically identical
22972 to those provided for the vector primary template) and may even be
22973 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
22974 in c++std-lib-13647).
22975 </p>
22976
22977
22978
22979 <p><b>Proposed resolution:</b></p>
22980 <p>
22981 Remove all overloads of overloads of relational operators for
22982 vector&lt;bool&gt; from [lib.vector.bool].
22983 </p>
22984
22985
22986
22987
22988 <hr>
22989 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
22990 <p><b>Section:</b> 18.8.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22991  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
22992 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22993 <p><b>Discussion:</b></p>
22994
22995 <p>[lib.exception] specifies the following:</p>
22996 <pre>    exception (const exception&amp;) throw();
22997     exception&amp; operator= (const exception&amp;) throw();
22998
22999     -4- Effects: Copies an exception object.
23000     -5- Notes: The effects of calling what() after assignment
23001         are implementation-defined.
23002 </pre>
23003
23004 <p>
23005 First, does the Note only apply to the assignment operator? If so,
23006 what are the effects of calling what() on a copy of an object? Is
23007 the returned pointer supposed to point to an identical copy of
23008 the NTBS returned by what() called on the original object or not?
23009 </p>
23010
23011 <p>
23012 Second, is this Note intended to extend to all the derived classes
23013 in section 19? I.e., does the standard provide any guarantee for
23014 the effects of what() called on a copy of any of the derived class
23015 described in section 19?
23016 </p>
23017
23018 <p>
23019 Finally, if the answer to the first question is no, I believe it
23020 constitutes a defect since throwing an exception object typically
23021 implies invoking the copy ctor on the object. If the answer is yes,
23022 then I believe the standard ought to be clarified to spell out
23023 exactly what the effects are on the copy (i.e., after the copy
23024 ctor was called).
23025 </p>
23026
23027 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
23028   fuzzy too.]</i></p>
23029
23030
23031 <p><i>[
23032 Batavia: Howard provided wording.
23033 ]</i></p>
23034
23035
23036 <p><i>[
23037 Bellevue:
23038 ]</i></p>
23039
23040
23041 <blockquote>
23042 <p>
23043 Eric concerned this is unimplementable, due to nothrow guarantees.
23044 Suggested implementation would involve reference counting.
23045 </p>
23046 <p>
23047 Is the implied reference counting subtle enough to call out a note on
23048 implementation? Probably not.
23049 </p>
23050 <p>
23051 If reference counting required, could we tighten specification further
23052 to require same pointer value? Probably an overspecification, especially
23053 if exception classes defer evalutation of final string to calls to
23054 what().
23055 </p>
23056 <p>
23057 Remember issue moved open and not resolved at Batavia, but cannot
23058 remember who objected to canvas a disenting opinion - please speak up if
23059 you disagree while reading these minutes!
23060 </p>
23061 <p>
23062 Move to Ready as we are accepting words unmodified.
23063 </p>
23064 </blockquote>
23065
23066 <p><i>[
23067 Sophia Antipolis:
23068 ]</i></p>
23069
23070
23071 <blockquote>
23072 The issue was pulled from Ready.  It needs to make clear that only homogenous copying
23073 is intended to be supported, not coping from a derived to a base.
23074 </blockquote>
23075
23076 <p><i>[
23077 Batavia (2009-05):
23078 ]</i></p>
23079
23080 <blockquote>
23081 <p>
23082 Howard supplied the following replacement wording
23083 for paragraph 7 of the proposed resolution:
23084 </p>
23085 <blockquote>
23086 <ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
23087   as would be obtained by using <tt>static_cast</tt>
23088   to cast the rhs to the same types as the lhs
23089   and then calling <tt>what()</tt> on that possibly sliced object.</ins>
23090 </blockquote>
23091 <p>
23092 Pete asks what "the same NTBS" means.
23093 </p>
23094 </blockquote>
23095
23096 <p><i>[
23097 2009-07-30 Niels adds:
23098 ]</i></p>
23099
23100
23101 <blockquote>
23102 Further discussion in the thread starting with c++std-lib-24512.
23103 </blockquote>
23104
23105 <p><i>[
23106 2009-09-24 Niels provided updated wording:
23107 ]</i></p>
23108
23109
23110 <blockquote>
23111 <p>
23112 I think the resolution should at least guarantee
23113 that the result of <tt>what()</tt> is independent of whether the compiler does
23114 copy-elision. And for any class derived from <tt>std::excepion</tt> that has a
23115 constructor that allows specifying a <tt>what_arg</tt>, it should make sure that
23116 the text of a user-provided <tt>what_arg</tt> is preserved, when the object is
23117 copied. Note that all the implementations I've tested already appear to
23118 satisfy the proposed resolution, including MSVC 2008 SP1, Apache
23119 stdcxx-4.2.1, GCC 4.1.2, GCC 4.3.2, and CodeGear C++ 6.13.
23120 </p>
23121 <p>
23122 The proposed resolution was updated with help from Daniel Krügler;
23123 the update aims to clarify that the proposed postcondition only
23124 applies to homogeneous copying.
23125 </p>
23126 </blockquote>
23127
23128 <p><i>[
23129 2009-10 Santa Cruz:
23130 ]</i></p>
23131
23132
23133 <blockquote>
23134 Moved to Ready after inserting "publicly accessible" in two places.
23135 </blockquote>
23136
23137
23138
23139 <p><b>Proposed resolution:</b></p>
23140
23141 <p>
23142 Change 18.8.1 [exception] to:
23143 </p>
23144
23145 <blockquote>
23146 <p>
23147 -1- The class <tt>exception</tt> defines the base class for the types of
23148 objects thrown as exceptions by C++ standard library components, and
23149 certain expressions, to report errors detected during program execution.
23150 </p>
23151 <p><ins>
23152 Each standard library class <tt>T</tt> that derives from class
23153 <tt>exception</tt> shall have a publicly accessible copy constructor and a publicly accessible copy assignment
23154 operator that do not exit with an exception. These member functions
23155 shall preserve the following postcondition: If two objects <i>lhs</i>
23156 and <i>rhs</i> both have dynamic type <tt>T</tt>, and <i>lhs</i> is a
23157 copy of <i>rhs</i>, then <tt>strcmp(<i>lhs</i>.what(),
23158 <i>rhs</i>.what()) == 0</tt>.
23159 </ins></p>
23160 <p>
23161  ...
23162 </p>
23163
23164 <pre>exception(const exception&amp; <ins>rhs</ins>) throw();
23165 exception&amp; operator=(const exception&amp; <ins>rhs</ins>) throw();</pre>
23166
23167 <blockquote>
23168 <p>
23169 -4- <i>Effects:</i> Copies an exception object.
23170 </p>
23171 <p>
23172 <del> -5- <i>Remarks:</i> The effects of calling <tt>what()</tt> after assignment
23173 are implementation-defined.</del>
23174 </p>
23175 <p>
23176 <ins>-5- <i>Postcondition:</i>
23177         If <tt>*this</tt>
23178         and <i>rhs</i> both have dynamic type <tt>exception</tt>
23179         then <tt>strcmp(what(), <i>rhs</i>.what()) == 0</tt>.</ins>
23180 </p>
23181
23182 </blockquote>
23183
23184 </blockquote>
23185
23186
23187
23188
23189
23190 <hr>
23191 <h3><a name="473"></a>473. underspecified ctype calls</h3>
23192 <p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23193  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2010-10-29</p>
23194 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23195 <p><b>Discussion:</b></p>
23196 <p>
23197 Most ctype member functions come in two forms: one that operates
23198 on a single character at a time and another form that operates
23199 on a range of characters. Both forms are typically described by
23200 a single Effects and/or Returns clause.
23201 </p>
23202 <p>
23203 The Returns clause of each of the single-character non-virtual forms
23204 suggests that the function calls the corresponding single character
23205 virtual function, and that the array form calls the corresponding
23206 virtual array form. Neither of the two forms of each virtual member
23207 function is required to be implemented in terms of the other.
23208 </p>
23209 <p>
23210 There are three problems:
23211 </p>
23212 <p>
23213 1. One is that while the standard does suggest that each non-virtual
23214 member function calls the corresponding form of the virtual function,
23215 it doesn't actually explicitly require it.
23216 </p>
23217 <p>
23218 Implementations that cache results from some of the virtual member
23219 functions for some or all values of their arguments might want to
23220 call the array form from the non-array form the first time to fill
23221 the cache and avoid any or most subsequent virtual calls. Programs
23222 that rely on each form of the virtual function being called from
23223 the corresponding non-virtual function will see unexpected behavior
23224 when using such implementations.
23225 </p>
23226 <p>
23227 2. The second problem is that either form of each of the virtual
23228 functions can be overridden by a user-defined function in a derived
23229 class to return a value that is different from the one produced by
23230 the virtual function of the alternate form that has not been
23231 overriden.
23232 </p>
23233 <p>
23234 Thus, it might be possible for, say, ctype::widen(c) to return one
23235 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
23236 wc to another value. This is almost certainly not intended. Both
23237 forms of every function should be required to return the same result
23238 for the same character, otherwise the same program using an
23239 implementation that calls one form of the functions will behave
23240 differently than when using another implementation that calls the
23241 other form of the function "under the hood."
23242 </p>
23243 <p>
23244 3. The last problem is that the standard text fails to specify whether
23245 one form of any of the virtual functions is permitted to be implemented
23246 in terms of the other form or not, and if so, whether it is required
23247 or permitted to call the overridden virtual function or not.
23248 </p>
23249 <p>
23250 Thus, a program that overrides one of the virtual functions so that
23251 it calls the other form which then calls the base member might end
23252 up in an infinite loop if the called form of the base implementation
23253 of the function in turn calls the other form.
23254 </p>
23255 <p>
23256 Lillehammer: Part of this isn't a real problem. We already talk about
23257 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
23258 each other, so users don't know which ones to override to avoid avoid
23259 infinite loops.</p>
23260
23261 <p>This is a problem for all facet virtuals, not just ctype virtuals,
23262 so we probably want a blanket statement in clause 22 for all
23263 facets. The LWG is leaning toward a blanket prohibition, that a
23264 facet's virtuals may never call each other. We might want to do that
23265 in clause 27 too, for that matter. A review is necessary.  Bill will
23266 provide wording.</p>
23267
23268 <p><i>[
23269 2009-07 Frankfurt, Howard provided wording directed by consensus.
23270 ]</i></p>
23271
23272
23273 <p><i>[
23274 2009-10 Santa Cruz:
23275 ]</i></p>
23276
23277
23278 <blockquote>
23279 Move to Ready.
23280 </blockquote>
23281
23282
23283
23284 <p><b>Proposed resolution:</b></p>
23285 <p>
23286 Add paragraph 3 to 22.4 [locale.categories]:
23287 </p>
23288
23289 <blockquote><ins>
23290 -3- Within this clause it is unspecified if one virtual function calls another
23291 virtual function.
23292 </ins></blockquote>
23293
23294
23295
23296 <p><b>Rationale:</b></p>
23297 <p>
23298 We are explicitly not addressing bullet
23299 item #2, thus giving implementors more latitude. Users will have to
23300 override both virtual functions, not just one.
23301 </p>
23302
23303
23304
23305
23306 <hr>
23307 <h3><a name="474"></a>474. confusing Footnote 297</h3>
23308 <p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23309  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2010-10-29</p>
23310 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
23311 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23312 <p><b>Discussion:</b></p>
23313
23314 <p>
23315 I think Footnote 297 is confused. The paragraph it applies to seems
23316 quite clear in that widen() is only called if the object is not a char
23317 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
23318 value of widen(c) is otherwise.
23319 </p>
23320
23321
23322 <p><b>Proposed resolution:</b></p>
23323 <p>
23324 I propose to strike the Footnote.
23325 </p>
23326
23327
23328
23329
23330 <hr>
23331 <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
23332 <p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23333  <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Opened:</b> 2004-07-09 <b>Last modified:</b> 2010-10-29</p>
23334 <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>
23335 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23336 <p><b>Discussion:</b></p>
23337 <p>
23338 It is not clear whether the function object passed to for_each is allowed to
23339 modify the elements of the sequence being iterated over.
23340 </p>
23341
23342 <p>
23343 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
23344 Non-modifying sequence operations". 'Non-modifying sequence operation' is
23345 never defined.
23346 </p>
23347
23348 <p>
23349 25(5) says: "If an algorithm's Effects section says that a value pointed to
23350 by any iterator passed as an argument is modified, then that algorithm has
23351 an additional type requirement: The type of that argument shall satisfy the
23352 requirements of a mutable iterator (24.1)."
23353 </p>
23354
23355 <p>for_each's Effects section does not mention whether arguments can be
23356 modified:</p>
23357
23358 <blockquote><p>
23359   "Effects: Applies f to the result of dereferencing every iterator in the
23360    range [first, last), starting from first and proceeding to last - 1."
23361 </p></blockquote>
23362
23363 <p>
23364 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
23365 the sense that neither the algorithms themselves nor the function objects
23366 passed to the algorithms may modify the sequences or elements in any way.
23367 This DR affects only for_each.
23368 </p>
23369
23370 <p>
23371 We suspect that for_each's classification in "non-modifying sequence
23372 operations" means that the algorithm itself does not inherently modify the
23373 sequence or the elements in the sequence, but that the function object
23374 passed to it may modify the elements it operates on. 
23375 </p>
23376
23377 <p>
23378 The original STL document by Stepanov and Lee explicitly prohibited the
23379 function object from modifying its argument.
23380 The "obvious" implementation of for_each found in several standard library 
23381 implementations, however, does not impose this restriction.
23382 As a result, we suspect that the use of for_each with function objects that modify
23383 their arguments is wide-spread. 
23384 If the restriction was reinstated, all such code would become non-conforming.
23385 Further, none of the other algorithms in the Standard
23386 could serve the purpose of for_each (transform does not guarantee the order in
23387 which its function object is called). 
23388 </p>
23389
23390 <p>
23391 We suggest that the standard be clarified to explicitly allow the function object 
23392 passed to for_each modify its argument.</p>
23393
23394
23395
23396 <p><b>Proposed resolution:</b></p>
23397 <p>Add a nonnormative note to the Effects in 25.2.4 [alg.foreach]: If
23398 the type of 'first' satisfies the requirements of a mutable iterator,
23399 'f' may apply nonconstant functions through the dereferenced iterators
23400 passed to it.
23401 </p>
23402
23403
23404
23405 <p><b>Rationale:</b></p>
23406 <p>The LWG believes that nothing in the standard prohibits function
23407   objects that modify the sequence elements. The problem is that
23408   for_each is in a secion entitled "nonmutating algorithms", and the
23409   title may be confusing.  A nonnormative note should clarify that.</p>
23410
23411
23412
23413
23414
23415 <hr>
23416 <h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
23417 <p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23418  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11 <b>Last modified:</b> 2010-10-29</p>
23419 <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>
23420 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23421 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
23422 <p><b>Discussion:</b></p>
23423 <p>
23424 The Forward Iterator requirements table contains the following:
23425 </p>
23426 <pre> expression  return type         operational  precondition
23427                                   semantics
23428   ==========  ==================  ===========  ==========================
23429   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
23430               otherwise const U&amp;
23431
23432   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
23433 </pre>
23434
23435 <p>The second line may be unnecessary.  Paragraph 11 of
23436   [lib.iterator.requirements] says:
23437 </p>
23438
23439 <blockquote><p>
23440    In the following sections, a and b denote values of type const X, n
23441    denotes a value of the difference type Distance, u, tmp, and m
23442    denote identifiers, r denotes a value of X&amp;, t denotes a value of
23443    value type T, o denotes a value of some type that is writable to
23444    the output iterator.
23445 </p></blockquote>
23446
23447 <p>
23448 Because operators can be overloaded on an iterator's const-ness, the
23449 current requirements allow iterators to make many of the operations
23450 specified using the identifiers a and b invalid for non-const
23451 iterators.</p>
23452
23453 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
23454
23455
23456 <p><b>Proposed resolution:</b></p>
23457
23458 <p>Remove the "r-&gt;m" line from the Forward Iterator requirements
23459 table. Change</p>
23460 <blockquote><p>
23461     "const X"
23462 </p></blockquote>
23463
23464 <p> to </p>
23465
23466 <blockquote><p>
23467     "X or const X" 
23468 </p></blockquote>
23469
23470 <p>in paragraph 11 of [lib.iterator.requirements].</p>
23471
23472
23473
23474
23475 <p><b>Rationale:</b></p>
23476 <p>
23477 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
23478 </p>
23479
23480
23481
23482
23483
23484 <hr>
23485 <h3><a name="482"></a>482. Swapping pairs</h3>
23486 <p><b>Section:</b> 20.3.5 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
23487  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-09-14 <b>Last modified:</b> 2010-11-20</p>
23488 <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>
23489 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
23490 <p><b>Discussion:</b></p>
23491 <p>(Based on recent comp.std.c++ discussion)</p>
23492
23493 <p>Pair (and tuple) should specialize std::swap to work in terms of
23494 std::swap on their components.  For example, there's no obvious reason
23495 why swapping two objects of type pair&lt;vector&lt;int&gt;,
23496 list&lt;double&gt; &gt; should not take O(1).</p>
23497
23498 <p><i>[Lillehammer: We agree it should be swappable.  Howard will
23499   provide wording.]</i></p>
23500
23501
23502 <p><i>[
23503 Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
23504 missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
23505 ]</i></p>
23506
23507
23508
23509
23510 <p><b>Proposed resolution:</b></p>
23511 <p>
23512 Wording provided in
23513 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
23514 </p>
23515
23516 <p><b>Rationale:</b></p>
23517 <p>
23518 Recommend <del>NAD</del><ins>Resolved</ins>, fixed by 
23519 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
23520 </p>
23521
23522
23523
23524
23525
23526 <hr>
23527 <h3><a name="488"></a>488. rotate throws away useful information</h3>
23528 <p><b>Section:</b> 25.3.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23529  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2004-11-22 <b>Last modified:</b> 2010-10-29</p>
23530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23531 <p><b>Discussion:</b></p>
23532 <p>
23533 rotate takes 3 iterators:  first, middle and last which point into a
23534 sequence, and rearranges the sequence such that the subrange [middle,
23535 last) is now at the beginning of the sequence and the subrange [first,
23536 middle) follows.  The return type is void. 
23537 </p>
23538
23539 <p>
23540 In many use cases of rotate, the client needs to know where the
23541 subrange [first, middle) starts after the rotate is performed.  This
23542 might look like: 
23543 </p>
23544 <pre>  rotate(first, middle, last);
23545   Iterator i = advance(first, distance(middle, last));
23546 </pre>
23547
23548 <p>
23549 Unless the iterators are random access, the computation to find the
23550 start of the subrange [first, middle) has linear complexity.  However,
23551 it is not difficult for rotate to return this information with
23552 negligible additional computation expense.  So the client could code: 
23553 </p>
23554 <pre>  Iterator i = rotate(first, middle, last);
23555 </pre>
23556
23557 <p>
23558 and the resulting program becomes significantly more efficient.
23559 </p>
23560
23561 <p>
23562 While the backwards compatibility hit with this change is not zero, it
23563 is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
23564 a significant benefit to the change. 
23565 </p>
23566
23567
23568
23569 <p><b>Proposed resolution:</b></p>
23570 <p>In 25 [algorithms] p2, change:</p>
23571
23572 <blockquote><pre>  template&lt;class ForwardIterator&gt;
23573     <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
23574                 ForwardIterator last);
23575 </pre></blockquote>
23576
23577 <p>In 25.3.11 [alg.rotate], change:</p>
23578
23579 <blockquote><pre>  template&lt;class ForwardIterator&gt;
23580     <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
23581                 ForwardIterator last);
23582 </pre></blockquote>
23583
23584 <p>In 25.3.11 [alg.rotate] insert a new paragraph after p1:</p>
23585
23586 <blockquote>
23587 <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
23588 </blockquote>
23589
23590 <p><i>[
23591 The LWG agrees with this idea, but has one quibble: we want to make
23592 sure not to give the impression that the function "advance" is
23593 actually called, just that the nth iterator is returned.  (Calling
23594 advance is observable behavior, since users can specialize it for
23595 their own iterators.)  Howard will provide wording.
23596 ]</i></p>
23597
23598
23599 <p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
23600
23601
23602 <p><i>[
23603 Toronto: moved to Ready.
23604 ]</i></p>
23605
23606
23607
23608
23609
23610
23611
23612 <hr>
23613 <h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
23614 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23615  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-01-10 <b>Last modified:</b> 2010-10-29</p>
23616 <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>
23617 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23618 <p><b>Discussion:</b></p>
23619 <p>It appears that there are no requirements specified for many of the
23620 template parameters in clause 22. It looks like this issue has never
23621 come up, except perhaps for Facet.</p>
23622
23623 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
23624 either, which is the wording that allows requirements on template
23625 parameters to be identified by name.</p>
23626
23627 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
23628 changed to cover clause 22. A better change, which will cover us in
23629 the future, would be to say that it applies to all the library
23630 clauses. Then if a template gets added to any library clause we are
23631 covered.</p>
23632
23633 <p>charT, InputIterator, and other names with requirements defined
23634 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
23635 But there are a few template arguments names which I don't think have
23636 requirements given elsewhere:</p>
23637
23638 <ul>
23639 <li>internT and externT.  The fix is to add wording saying that internT
23640 and externT must meet the same requirements as template arguments
23641 named charT.</li>
23642
23643 <li>stateT.  I'm not sure about this one. There already is some wording,
23644 but it seems a bit vague.</li>
23645
23646 <li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
23647 rename "Intl" to "International". The name is important because other
23648 text identifies the requirements for the name International but not
23649 for Intl.</li>
23650 </ul>
23651
23652 <p><b>Proposed resolution:</b></p>
23653 <p>Change 17.5.2.1 [type.descriptions], paragraph 1, from:</p>
23654 <blockquote><p>
23655 The Requirements subclauses may describe names that are used to
23656 specify constraints on template arguments.153) These names are used in
23657 clauses 20, 23, 25, and 26 to describe the types that may be supplied
23658 as arguments by a C++ program when instantiating template components
23659 from the library. 
23660 </p></blockquote>
23661 <p>to:</p>
23662 <blockquote><p>
23663 The Requirements subclauses may describe names that are used to
23664 specify constraints on template arguments.153) These names are used in
23665 library clauses to describe the types that may be supplied as
23666 arguments by a C++ program when instantiating template components from
23667 the library.
23668 </p></blockquote>
23669
23670 <p>In the front matter of class 22, locales, add:</p>
23671 <blockquote><p>
23672 Template parameter types internT and externT shall meet the
23673 requirements of charT (described in 21 [strings]).
23674 </p></blockquote>
23675
23676
23677 <p><b>Rationale:</b></p>
23678 <p>
23679  Again, a blanket clause isn't blanket enough. Also, we've got a
23680  couple of names that we don't have blanket requirement statements
23681  for. The only issue is what to do about stateT. This wording is
23682  thin, but probably adequate.</p>
23683
23684
23685
23686
23687
23688 <hr>
23689 <h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
23690 <p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23691  <b>Submitter:</b> richard@ex-parrot.com <b>Opened:</b> 2005-02-10 <b>Last modified:</b> 2010-10-29</p>
23692 <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>
23693 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23694 <p><b>Discussion:</b></p>
23695 <p>
23696 In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.4.1 [vector],
23697 the non-template assign() function has the signature</p>
23698
23699 <pre>  void assign( size_type n, const T&amp; t );
23700 </pre>
23701
23702 <p>The type, T, is not defined in this context.</p>
23703
23704
23705 <p><b>Proposed resolution:</b></p>
23706 <p>Replace "T" with "value_type".</p>
23707
23708
23709
23710
23711
23712 <hr>
23713 <h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
23714 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23715  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02 <b>Last modified:</b> 2010-10-29</p>
23716 <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>
23717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23718 <p><b>Discussion:</b></p>
23719
23720 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
23721
23722 <blockquote>
23723 <p>static const bool traps;<br>
23724 -59- true if trapping is implemented for the type.204)
23725 <br>
23726 Footnote 204: Required by LIA-1.
23727 </p>
23728 </blockquote>
23729
23730 <p>It's not clear what is meant by "is implemented" here.</p>
23731
23732 <p>
23733 In the context of floating point numbers it seems reasonable to expect
23734 to be able to use traps to determine whether a program can "safely" use
23735 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
23736 without causing a trap (i.e., on UNIX without having to worry about
23737 getting a signal). When traps is true, I would expect any of the
23738 operations in section 7 of IEEE 754 to cause a trap (and my program
23739 to get a SIGFPE). So, for example, on Alpha, I would expect traps
23740 to be true by default (unless I compiled my program with the -ieee
23741 option), false by default on most other popular architectures,
23742 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
23743 traps to be explicitly enabled by the program.
23744 </p>
23745
23746 <p>
23747 Another possible interpretation of p59 is that traps should be true
23748 on any implementation that supports traps regardless of whether they
23749 are enabled by default or not. I don't think such an interpretation
23750 makes the traps member very useful, even though that is how traps is
23751 implemented on several platforms. It is also the only way to implement
23752 traps on platforms that allow programs to enable and disable trapping
23753 at runtime.
23754 </p>
23755
23756
23757 <p><b>Proposed resolution:</b></p>
23758 <p>Change p59 to read:</p>
23759 <blockquote><p>True if, at program startup, there exists a value of the type that
23760   would cause an arithmetic operation using that value to trap.</p></blockquote>
23761
23762
23763 <p><b>Rationale:</b></p>
23764 <p>
23765  Real issue, since trapping can be turned on and off. Unclear what a
23766  static query can say about a dynamic issue. The real advice we should
23767  give users is to use cfenv for these sorts of queries. But this new
23768  proposed resolution is at least consistent and slightly better than
23769  nothing.</p>
23770
23771
23772
23773
23774
23775 <hr>
23776 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
23777 <p><b>Section:</b> 25.3.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23778  <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04 <b>Last modified:</b> 2010-10-29</p>
23779 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23780 <p><b>Discussion:</b></p>
23781 <p>
23782 Problem:
23783 The iterator requirements for partition() and stable_partition() [25.2.12]
23784 are listed as BidirectionalIterator, however, there are efficient algorithms
23785 for these functions that only require ForwardIterator that have been known
23786 since before the standard existed. The SGI implementation includes these (see
23787 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
23788 and
23789 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
23790 </p>
23791
23792 <p><i>[
23793 2009-04-30 Alisdair adds:
23794 ]</i></p>
23795
23796
23797 <blockquote>
23798 <p>
23799 Now we have concepts this is easier to express!
23800 </p>
23801 <p>
23802 Proposed resolution:
23803 </p>
23804 <p>
23805 Add the following signature to:
23806 </p>
23807 <p>
23808 Header <tt>&lt;algorithm&gt;</tt> synopsis  [algorithms.syn]<br>
23809 p3 Partitions 25.3.13 [alg.partitions]
23810 </p>
23811 <blockquote><pre> template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred&gt;
23812    requires ShuffleIterator&lt;Iter&gt;
23813          &amp;&amp; CopyConstructible&lt;Pred&gt;
23814    Iter partition(Iter first, Iter last, Pred pred);
23815 </pre></blockquote>
23816
23817 <p>
23818 Update p3 Partitions 25.3.13 [alg.partitions]:
23819 </p>
23820
23821 <blockquote>
23822 <p>
23823 <i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
23824 applications of the predicate
23825 are done.</del>
23826 <ins>
23827 If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
23828 first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
23829 are done.
23830 </ins>
23831 </p>
23832 <p><ins>
23833 If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
23834 are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
23835 </ins></p>
23836 </blockquote>
23837
23838 <p>
23839 [Editorial note: I looked for existing precedent in how we might call out
23840 distinct overloads overloads from a set of constrained templates, but there
23841 is not much existing practice to lean on.   advance/distance were the only
23842 algorithms I could find, and that wording is no clearer.]
23843 </p>
23844
23845 </blockquote>
23846
23847 <p><i>[
23848 2009-07 Frankfurt
23849 ]</i></p>
23850
23851
23852 <blockquote>
23853 <p>
23854 Hinnant: if you want to partition your std::forward_list, you'll need
23855 partition() to accept ForwardIterators.
23856 </p>
23857 <p>
23858 No objection to Ready.
23859 </p>
23860 <p>
23861 Move to Ready.
23862 </p>
23863 </blockquote>
23864
23865
23866
23867 <p><b>Proposed resolution:</b></p>
23868 <p>
23869 Change 25.2.12 from </p>
23870 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt; 
23871 BidirectionalIterator partition(BidirectionalIterato r first, 
23872                                 BidirectionalIterator last, 
23873                                 Predicate pred); 
23874 </pre></blockquote>
23875 <p>to </p>
23876 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt; 
23877 ForwardIterator partition(ForwardIterator first, 
23878                           ForwardIterator last, 
23879                           Predicate pred); 
23880 </pre></blockquote>
23881 <p>Change the complexity from </p>
23882
23883 <blockquote><p>
23884 At most (last - first)/2 swaps are done. Exactly (last - first) 
23885 applications of the predicate are done. 
23886 </p></blockquote>
23887
23888 <p>to </p>
23889
23890 <blockquote><p>
23891 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 
23892 swaps are done; otherwise at most (last - first) swaps are done. Exactly 
23893 (last - first) applications of the predicate are done. 
23894 </p></blockquote>
23895
23896
23897
23898 <p><b>Rationale:</b></p>
23899 <p>
23900 Partition is a "foundation" algorithm useful in many contexts (like sorting
23901 as just one example) - my motivation for extending it to include forward
23902 iterators is foward_list - without this extension you can't partition an foward_list
23903 (without writing your own partition). Holes like this in the standard
23904 library weaken the argument for generic programming (ideally I'd be able
23905 to provide a library that would refine std::partition() to other concepts
23906 without fear of conflicting with other libraries doing the same - but
23907 that is a digression). I consider the fact that partition isn't defined
23908 to work for ForwardIterator a minor embarrassment.
23909 </p>
23910
23911 <p><i>[Mont Tremblant:  Moved to Open, request motivation and use cases by next meeting. Sean provided further rationale by post-meeting mailing.]</i></p>
23912
23913
23914
23915
23916
23917
23918
23919 <hr>
23920 <h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
23921 <p><b>Section:</b> 26.5.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23922  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
23923 <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>
23924 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23925 <p><b>Discussion:</b></p>
23926 <p>
23927 Table 17: Random distribution requirements
23928 </p>
23929 <p>
23930 Row 1 requires that each random distribution provide a nested type "input_type";
23931 this type denotes the type of the values that the distribution consumes.
23932 </p>
23933 <p>
23934 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
23935 provides a second typedef ("result_type") that denotes the type of the values the
23936 distribution produces when called.  
23937 </p>
23938
23939
23940 <p><b>Proposed resolution:</b></p>
23941 <p>
23942 It seems to me that this is also a requirement
23943 for all distributions and should therefore be  indicated as such via a new second
23944 row to this table 17:
23945 </p>
23946 <table border="1" cellpadding="5">
23947 <tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
23948 </tbody></table>
23949
23950 <p><i>[
23951 Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
23952 ]</i></p>
23953
23954
23955
23956
23957
23958
23959
23960 <hr>
23961 <h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
23962 <p><b>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23963  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
23964 <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>
23965 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23966 <p><b>Discussion:</b></p>
23967 <p>
23968 Paragraph 11 of [tr.rand.var] equires that the member template
23969 </p>
23970 <blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
23971 </pre></blockquote>
23972 <p>
23973 return
23974 </p>
23975 <blockquote><pre>distribution()(e, value)
23976 </pre></blockquote>
23977 <p>
23978 However, not all distributions have an operator() with a corresponding signature.
23979 </p>
23980
23981 <p><i>[
23982 Berlin:  As a working group we voted in favor of N1932 which makes this moot:
23983 variate_generator has been eliminated.  Then in full committee we voted to give
23984 this issue WP status (mistakenly).
23985 ]</i></p>
23986
23987
23988
23989
23990 <p><b>Proposed resolution:</b></p>
23991 <p>
23992 We therefore  recommend that we insert the following precondition before paragraph 11:
23993 </p>
23994 <blockquote><p>
23995 Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
23996 </p></blockquote>
23997
23998
23999
24000
24001
24002 <hr>
24003 <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
24004 <p><b>Section:</b> 26.5.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24005  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24006 <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>
24007 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24008 <p><b>Discussion:</b></p>
24009 <p>
24010 The fifth of these engines with predefined parameters, ranlux64_base_01,
24011 appears to have an unintentional error for which there is a simple correction.
24012 The two pre-defined  subtract_with_carry_01 engines are given as: 
24013 </p>
24014 <blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
24015 typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
24016 </pre></blockquote>
24017 <p>
24018 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
24019 random number generation proposal, but that the simple correction to
24020 </p>
24021 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
24022 </pre></blockquote>
24023 <p>
24024 does meet the intent of defining well-known good parameterizations.
24025 </p>
24026 <p>
24027 The ranlux64_base_01 engine as presented fails to meet the intent for
24028 predefined engines, stated in proposal N1398 (section E):
24029 </p>
24030 <blockquote><p>
24031 In order to make good random numbers available to a large number of library
24032 users, this proposal not only defines generic random-number engines, but also
24033 provides a number of predefined well-known good parameterizations for those.
24034 </p></blockquote>
24035 <p>
24036 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
24037 long period and so meets this criterion.  This property makes it suitable for
24038 use in the excellent discard_block  engines defined subsequently.  The proof
24039 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
24040 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
24041 as defined in [tr.rand.eng.sub1]).
24042 </p>
24043 <p>
24044 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
24045 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
24046 explicit factorization  would be a challenge).  In consequence, while it is
24047 certainly possible for some seeding states that this engine would have a very
24048 long period, it is not at all "well-known" that this is the case. The intent
24049 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
24050 use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
24051 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
24052 to deliver 48 random bits at a time rather than 24.
24053 </p>
24054
24055
24056 <p><b>Proposed resolution:</b></p>
24057 <p>
24058 To achieve this intended behavior, the correct template parameteriztion  would be:
24059 </p>
24060 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
24061 </pre></blockquote>
24062 <p>
24063 The sequence of mantissa bits delivered by this is isomorphic (treating each
24064 double as having the  bits of two floats) to that delivered by ranlux_base_01.
24065 </p>
24066 <p>
24067 <b>References:</b>
24068 </p>
24069 <ol>
24070 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
24071 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
24072 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
24073 </ol>
24074
24075 <p><i>[
24076 Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
24077 just above paragraph 5.
24078 ]</i></p>
24079
24080
24081
24082
24083
24084
24085
24086 <hr>
24087 <h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
24088 <p><b>Section:</b> 23.2.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24089  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24090 <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>
24091 <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>
24092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24093 <p><b>Discussion:</b></p>
24094 <p>
24095 Issue 371 deals with stability of multiset/multimap under insert and erase
24096 (i.e. do they preserve the relative order in ranges of equal elements).
24097 The same issue applies to unordered_multiset and unordered_multimap.
24098 </p>
24099 <p><i>[
24100 Moved to open (from review):  There is no resolution.
24101 ]</i></p>
24102
24103
24104 <p><i>[
24105 Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
24106 as to whether this conflicted with existing practice or not.  An additional
24107 concern was in specifying (partial) ordering for an unordered container.
24108 ]</i></p>
24109
24110
24111
24112
24113 <p><b>Proposed resolution:</b></p>
24114 <p>
24115 Wording for the proposed resolution is taken from the equivalent text for associative containers.
24116 </p>
24117
24118 <p>
24119 Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to:
24120 </p>
24121
24122 <blockquote><p>
24123 An unordered associative container supports <i>unique</i> keys if it may 
24124 contain at most one element for each key. Otherwise, it supports <i>equivalent 
24125 keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support 
24126 unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> 
24127 support equivalent keys. In containers that support equivalent keys, elements 
24128 with equivalent keys are adjacent to each other. <ins>For
24129 <tt>unordered_multiset</tt> 
24130 and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> 
24131 preserve the relative ordering of equivalent elements.</ins>
24132 </p></blockquote>
24133
24134 <p>
24135 Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to:
24136 </p>
24137
24138 <blockquote>
24139 <p>The elements of an unordered associative container are organized into <i>
24140 buckets</i>. Keys with the same hash code appear in the same bucket. The number 
24141 of buckets is automatically increased as elements are added to an unordered 
24142 associative container, so that the average number of elements per bucket is kept 
24143 below a bound. Rehashing invalidates iterators, changes ordering between 
24144 elements, and changes which buckets elements appear in, but does not invalidate 
24145 pointers or references to elements. <ins>For <tt>unordered_multiset</tt> 
24146 and <tt>unordered_multimap</tt>, rehashing 
24147 preserves the relative ordering of equivalent elements.</ins></p>
24148 </blockquote>
24149
24150
24151
24152
24153
24154
24155 <hr>
24156 <h3><a name="519"></a>519. Data() undocumented</h3>
24157 <p><b>Section:</b> 23.3.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24158  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24159 <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>
24160 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24161 <p><b>Discussion:</b></p>
24162 <p>
24163 <tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
24164 </p>
24165
24166
24167 <p><b>Proposed resolution:</b></p>
24168 <p>
24169 Add a new section, after 6.2.2.3:
24170 </p>
24171 <blockquote><pre>T*       data()
24172 const T* data() const;
24173 </pre></blockquote>
24174 <p>
24175 <b>Returns:</b> <tt>elems</tt>.
24176 </p>
24177 <p>
24178 Change 6.2.2.4/2 to:
24179 </p>
24180 <blockquote><p>
24181 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
24182 of <tt>data()</tt> is unspecified.
24183 </p></blockquote>
24184
24185
24186
24187
24188
24189 <hr>
24190 <h3><a name="520"></a>520. Result_of and pointers to data members</h3>
24191 <p><b>Section:</b> 20.8.10.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24192  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24194 <p><b>Discussion:</b></p>
24195 <p>
24196 In the original proposal for binders, the return type of bind() when
24197 called with a pointer to member data as it's callable object was
24198 defined to be mem_fn(ptr); when Peter Dimov and I  unified the
24199 descriptions of the TR1 function objects we hoisted the descriptions
24200 of return types into the INVOKE pseudo-function and into result_of.
24201 Unfortunately, we left pointer to member data out of result_of, so
24202 bind doesn't have any specified behavior when called with a pointer
24203 to  member data.
24204 </p>
24205
24206
24207 <p><b>Proposed resolution:</b></p>
24208 <p><i>[
24209 Pete and Peter will provide wording.
24210 ]</i></p>
24211
24212
24213 <p>
24214 In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
24215 </p>
24216 <ol start="3">
24217 <li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
24218 shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
24219 <tt>R</tt> otherwise.</li>
24220 </ol>
24221
24222 <p><i>[
24223 Peter provided wording.
24224 ]</i></p>
24225
24226
24227
24228
24229
24230
24231
24232 <hr>
24233 <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
24234 <p><b>Section:</b> 20.8.4 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24235  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24236 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
24237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24238 <p><b>Discussion:</b></p>
24239 <p>
24240 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
24241 derived from unary_function&lt;T, R&gt; if T is:
24242 </p>
24243 <blockquote><p>
24244 a pointer to member function type with cv-qualifier cv and no arguments;
24245 the type T1 is cv T* and R is the return type of the pointer to member function;
24246 </p></blockquote>
24247 <p>
24248 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
24249 function. It should be a pointer to the class that T is a pointer to member of.
24250 Like this:
24251 </p>
24252 <blockquote><p>
24253 a pointer to a member function R T0::f() cv (where cv represents the member
24254 function's cv-qualifiers); the type T1 is cv T0*
24255 </p></blockquote>
24256 <p>
24257 Similarly, bullet item 2 in 2.1.2/4 should be:
24258 </p>
24259 <blockquote><p>
24260 a pointer to a member function R T0::f(T2) cv (where cv represents the member
24261 function's cv-qualifiers); the type T1 is cv T0*
24262 </p></blockquote>
24263
24264
24265 <p><b>Proposed resolution:</b></p>
24266
24267 <p>
24268 Change bullet item 2 in 2.1.2/3:
24269 </p>
24270
24271 <blockquote>
24272 <ul>
24273 <li>
24274 a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
24275 the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return 
24276 type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
24277 (where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
24278 the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
24279 </li>
24280 </ul>
24281 </blockquote>
24282
24283 <p>
24284 Change bullet item 2 in 2.1.2/4:
24285 </p>
24286
24287 <blockquote>
24288 <ul>
24289 <li>
24290 a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
24291 of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and 
24292 <tt>R</tt> is the return type of the pointer to member function</del>
24293 <ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
24294 function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
24295 </li>
24296 </ul>
24297 </blockquote>
24298
24299
24300
24301
24302
24303
24304 <hr>
24305 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
24306 <p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24307  <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
24308 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
24309 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24310 <p><b>Discussion:</b></p>
24311 <p>
24312 Tuple doesn't define swap().  It should.
24313 </p>
24314 <p><i>[
24315 Berlin: Doug to provide wording.
24316 ]</i></p>
24317
24318 <p><i>[
24319 Batavia: Howard to provide wording.
24320 ]</i></p>
24321
24322 <p><i>[
24323 Toronto: Howard to provide wording (really this time).
24324 ]</i></p>
24325
24326
24327 <p><i>[
24328 Bellevue:  Alisdair provided wording.
24329 ]</i></p>
24330
24331
24332
24333
24334 <p><b>Proposed resolution:</b></p>
24335
24336 <p>
24337 Add these signatures to 20.4 [tuple]
24338 </p>
24339
24340 <blockquote><pre>template &lt;class... Types&gt;
24341   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
24342 template &lt;class... Types&gt;
24343   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
24344 template &lt;class... Types&gt;
24345   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
24346 </pre></blockquote>
24347
24348 <p>
24349 Add this signature to 20.4.2 [tuple.tuple]
24350 </p>
24351
24352 <blockquote><pre>void swap(tuple&amp;&amp;);
24353 </pre></blockquote>
24354
24355 <p>
24356 Add the following two sections to the end of the tuple clauses
24357 </p>
24358
24359 <blockquote>
24360 <p>
24361 20.3.1.7 tuple swap [tuple.swap]
24362 </p>
24363
24364 <pre>void swap(tuple&amp;&amp; rhs); 
24365 </pre>
24366
24367 <blockquote>
24368 <p>
24369 <i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
24370 </p>
24371 <p>
24372 <i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
24373 in <tt>rhs</tt>.
24374 </p>
24375 <p>
24376 <i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
24377 exception. 
24378 </p>
24379 </blockquote>
24380
24381 <p>
24382 20.3.1.8 tuple specialized algorithms [tuple.special]
24383 </p>
24384
24385 <pre>template &lt;class... Types&gt;
24386   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
24387 template &lt;class... Types&gt;
24388   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
24389 template &lt;class... Types&gt;
24390   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
24391 </pre>
24392
24393 <blockquote>
24394 <p>
24395 <i>Effects:</i> x.swap(y)
24396 </p>
24397 </blockquote>
24398 </blockquote>
24399
24400
24401
24402
24403
24404
24405 <hr>
24406 <h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
24407 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24408  <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <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#re">issues</a> in [re].</p>
24410 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24411 <p><b>Discussion:</b></p>
24412 <p>
24413 This defect is also being discussed on the Boost developers list. The 
24414 full discussion can be found here:
24415 http://lists.boost.org/boost/2005/07/29546.php
24416 </p>
24417 <p>
24418 -- Begin original message --
24419 </p>
24420 <p>
24421 Also, I may have found another issue, closely related to the one under
24422 discussion. It regards case-insensitive matching of named character
24423 classes. The regex_traits&lt;&gt; provides two functions for working with
24424 named char classes: lookup_classname and isctype. To match a char class
24425 such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
24426 bitmask. Later, you pass a char and the bitmask to isctype and get a
24427 bool yes/no answer.
24428 </p>
24429 <p>
24430 But how does case-insensitivity work in this scenario? Suppose we're
24431 doing a case-insensitive match on [[:lower:]]. It should behave as if it
24432 were [[:lower:][:upper:]], right? But there doesn't seem to be enough
24433 smarts in the regex_traits interface to do this.
24434 </p>
24435 <p>
24436 Imagine I write a traits class which recognizes [[:fubar:]], and the
24437 "fubar" char class happens to be case-sensitive. How is the regex engine
24438 to know that? And how should it do a case-insensitive match of a
24439 character against the [[:fubar:]] char class? John, can you confirm this
24440 is a legitimate problem?
24441 </p>
24442 <p>
24443 I see two options:
24444 </p>
24445 <p>
24446 1) Add a bool icase parameter to lookup_classname. Then,
24447 lookup_classname( "upper", true ) will know to return lower|upper
24448 instead of just upper.
24449 </p>
24450 <p>
24451 2) Add a isctype_nocase function
24452 </p>
24453 <p>
24454 I prefer (1) because the extra computation happens at the time the
24455 pattern is compiled rather than when it is executed.
24456 </p>
24457 <p>
24458 -- End original message --
24459 </p>
24460
24461 <p>
24462 For what it's worth, John has also expressed his preference for option 
24463 (1) above.
24464 </p>
24465
24466
24467 <p><b>Proposed resolution:</b></p>
24468 <p>
24469 Adopt the proposed resolution in
24470 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
24471 </p>
24472
24473
24474 <p><i>[
24475 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
24476 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24477 ]</i></p>
24478
24479
24480
24481
24482
24483 <hr>
24484 <h3><a name="525"></a>525. type traits definitions not clear</h3>
24485 <p><b>Section:</b> 20.7.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
24486  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2005-07-11 <b>Last modified:</b> 2010-11-19</p>
24487 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary">issues</a> in [meta.unary].</p>
24488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
24489 <p><b>Discussion:</b></p>
24490 <p>
24491 It is not completely clear how the primary type traits deal with
24492 cv-qualified types.  And several of the secondary type traits
24493 seem to be lacking a definition.
24494 </p>
24495
24496 <p><i>[
24497 Berlin:  Howard to provide wording.
24498 ]</i></p>
24499
24500
24501
24502 <p><b>Proposed resolution:</b></p>
24503 <p>
24504 Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
24505 A
24506 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
24507 provides more detail for motivation.
24508 </p>
24509
24510
24511 <p><b>Rationale:</b></p>
24512 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
24513 in the WP.
24514
24515
24516
24517
24518
24519 <hr>
24520 <h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
24521 <p><b>Section:</b> 20.8.10.1.2 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24522  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2005-10-01 <b>Last modified:</b> 2010-10-29</p>
24523 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
24524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24525 <p><b>Discussion:</b></p>
24526 <p>
24527 The original bind proposal gives the guarantee that tr1::bind(f, t1, ..., tN) does not throw when the copy constructors of f, t1, ..., tN don't.
24528 </p>
24529
24530 <p>
24531 This guarantee is not present in the final version of TR1.
24532 </p>
24533
24534 <p>
24535 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
24536 </p>
24537
24538 <p><i>[
24539 Berlin: not quite editorial, needs proposed wording.
24540 ]</i></p>
24541
24542 <p><i>[
24543 Batavia:  Doug to translate wording to variadic templates.
24544 ]</i></p>
24545
24546
24547 <p><i>[
24548 Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
24549 longer refer to anything.  Alan to provide improved wording.
24550 ]</i></p>
24551
24552
24553
24554 <p><i>[
24555 Pre-Bellevue:  Alisdair provided wording.
24556 ]</i></p>
24557
24558
24559 <p>
24560 TR1 proposed resolution:
24561 </p>
24562
24563 <blockquote>
24564 <p>
24565 In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
24566 </p>
24567 <blockquote><p>
24568 <i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
24569 throws an exception.
24570 </p></blockquote>
24571
24572 <p>
24573 Add a new paragraph after p4:
24574 </p>
24575 <blockquote><p>
24576 <i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
24577 throws an exception.
24578 </p></blockquote>
24579
24580 </blockquote>
24581
24582
24583
24584 <p><b>Proposed resolution:</b></p>
24585 <p>
24586 In 20.8.10.1.2 [func.bind.bind], add a new paragraph after p2:
24587 </p>
24588
24589 <blockquote>
24590 <i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
24591 in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
24592 </blockquote>
24593
24594 <p>
24595 In 20.8.10.1.2 [func.bind.bind], add a new paragraph after p4:
24596 </p>
24597
24598 <blockquote>
24599 <i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
24600 in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
24601 </blockquote>
24602
24603
24604
24605
24606
24607
24608 <hr>
24609 <h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
24610 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24611  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-11-15 <b>Last modified:</b> 2010-10-29</p>
24612 <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>
24613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24614 <p><b>Discussion:</b></p>
24615 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
24616    that the elements of a vector must be stored in contiguous memory.
24617    Should the same also apply to <tt>basic_string</tt>?</p>
24618
24619 <p>We almost require contiguity already. Clause 23.6.4 [multiset]
24620   defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
24621   is a similar guarantee if we access the string's elements via the
24622   iterator interface.</p>
24623
24624 <p>Given the existence of <tt>data()</tt>, and the definition of
24625   <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
24626   I don't believe it's possible to write a useful and standard-
24627   conforming <tt>basic_string</tt> that isn't contiguous. I'm not
24628   aware of any non-contiguous implementation. We should just require
24629   it.
24630 </p>
24631
24632
24633 <p><b>Proposed resolution:</b></p>
24634 <p>Add the following text to the end of 21.4 [basic.string],
24635 paragraph 2. </p>
24636
24637 <blockquote>
24638   <p>The characters in a string are stored contiguously, meaning that if
24639   <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
24640   it obeys the identity
24641   <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
24642   for all <tt>0 &lt;= n &lt; s.size()</tt>.
24643   </p>
24644 </blockquote>
24645
24646
24647 <p><b>Rationale:</b></p>
24648 <p>
24649 Not standardizing this existing practice does not give implementors more
24650 freedom.  We thought it might a decade ago.  But the vendors have spoken
24651 both with their implementations, and with their voice at the LWG
24652 meetings.  The implementations are going to be contiguous no matter what
24653 the standard says.  So the standard might as well give string clients
24654 more design choices.
24655 </p>
24656
24657
24658
24659
24660
24661 <hr>
24662 <h3><a name="531"></a>531. array forms of unformatted input functions</h3>
24663 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24664  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-23 <b>Last modified:</b> 2010-10-29</p>
24665 <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>
24666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24667 <p><b>Discussion:</b></p>
24668 <p>
24669 The array forms of unformatted input functions don't seem to have well-defined
24670 semantics for zero-element arrays in a couple of cases. The affected ones
24671 (<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
24672 terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
24673 never be true when <tt>(n == 0)</tt> holds to start with. See
24674 c++std-lib-16071.
24675 </p>
24676
24677
24678 <p><b>Proposed resolution:</b></p>
24679 <p>
24680 I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
24681 </p>
24682             <ul>
24683                 <li>
24684                     <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
24685                     are stored;
24686                 </li>
24687             </ul>
24688 <p>
24689 Change 27.6.1.3, p9:
24690 </p>
24691
24692 <blockquote><p>
24693 If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
24694 may throw <tt>ios_base::failure</tt> (27.4.4.3)).  In any case, <ins>if <tt>(n
24695 &gt; 0)</tt> is true</ins> it then stores a null character into the next
24696 successive location of the array.
24697 </p></blockquote>
24698
24699         <p>
24700
24701 and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
24702
24703         </p>
24704             <ul>
24705                 <li>
24706                     <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
24707                     are stored (in which case the function calls
24708                     <tt>setstate(failbit)</tt>).
24709                 </li>
24710             </ul>
24711
24712         <p>
24713
24714 In addition, to clarify that <tt>istream::getline()</tt> must not store the
24715 terminating NUL character unless the the array has non-zero size, Robert
24716 Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
24717
24718         </p>
24719             <blockquote><p>
24720
24721 In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
24722 (using charT()) into the next successive location of the array.
24723
24724             </p></blockquote>
24725
24726 <p><i>[
24727 post-Redmond:  Pete noticed that the current resolution for <tt>get</tt> requires
24728 writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
24729 ]</i></p>
24730
24731
24732
24733
24734
24735
24736
24737 <hr>
24738 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
24739 <p><b>Section:</b> 20.9.10.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24740  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-11-09 <b>Last modified:</b> 2010-10-29</p>
24741 <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>
24742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24743 <p><b>Discussion:</b></p>
24744 <p>
24745 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
24746 says:
24747 </p>
24748 <blockquote><p>
24749 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
24750 </p></blockquote>
24751 <p>
24752 but <tt>get_deleter</tt> is a free function!
24753 </p>
24754
24755
24756 <p><b>Proposed resolution:</b></p>
24757 <p>
24758 Therefore, I think should be:
24759 </p>
24760 <blockquote><p>
24761 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
24762 </p></blockquote>
24763
24764
24765
24766
24767
24768 <hr>
24769 <h3><a name="534"></a>534. Missing basic_string members</h3>
24770 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24771  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2005-11-16 <b>Last modified:</b> 2010-10-29</p>
24772 <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>
24773 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24774 <p><b>Discussion:</b></p>
24775 <p>
24776 OK, we all know std::basic_string is bloated and already has way too
24777 many members.  However, I propose it is missing 3 useful members that
24778 are often expected by users believing it is a close approximation of the
24779 container concept.  All 3 are listed in table 71 as 'optional'
24780 </p>
24781
24782 <p>
24783 i/  pop_back.
24784 </p>
24785
24786 <p>
24787 This is the one I feel most strongly about, as I only just discovered it
24788 was missing as we are switching to a more conforming standard library
24789 &lt;g&gt;
24790 </p>
24791
24792 <p>
24793 I find it particularly inconsistent to support push_back, but not
24794 pop_back.
24795 </p>
24796
24797 <p>
24798 ii/ back.
24799 </p>
24800
24801 <p>
24802 There are certainly cases where I want to examine the last character of
24803 a string before deciding to append, or to trim trailing path separators
24804 from directory names etc.  *rbegin() somehow feels inelegant.
24805 </p>
24806
24807 <p>
24808 iii/ front
24809 </p>
24810
24811 <p>
24812 This one I don't feel strongly about, but if I can get the first two,
24813 this one feels that it should be added as a 'me too' for consistency.
24814 </p>
24815
24816 <p>
24817 I believe this would be similarly useful to the data() member recently
24818 added to vector, or at() member added to the maps.
24819 </p>
24820
24821
24822 <p><b>Proposed resolution:</b></p>
24823 <p>
24824 Add the following members to definition of class template basic_string, 21.3p7
24825 </p>
24826 <blockquote><pre>void pop_back ()
24827
24828 const charT &amp; front() const
24829 charT &amp; front()
24830
24831 const charT &amp; back() const
24832 charT &amp; back()
24833 </pre></blockquote>
24834 <p>
24835 Add the following paragraphs to basic_string description
24836 </p>
24837
24838 <p>
24839 21.3.4p5
24840 </p>
24841 <blockquote>
24842 <pre>const charT &amp; front() const
24843 charT &amp; front()
24844 </pre>
24845 <p>
24846 <i>Precondition:</i> <tt>!empty()</tt>
24847 </p>
24848 <p>
24849 <i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
24850 </p>
24851 </blockquote>
24852
24853 <p>
24854 21.3.4p6
24855 </p>
24856 <blockquote>
24857 <pre>const charT &amp; back() const
24858 charT &amp; back()
24859 </pre>
24860 <p>
24861 <i>Precondition:</i> <tt>!empty()</tt>
24862 </p>
24863 <p>
24864 <i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
24865 </p>
24866 </blockquote>
24867
24868 <p>
24869 21.3.5.5p10
24870 </p>
24871 <blockquote>
24872 <pre>void pop_back ()
24873 </pre>
24874 <p>
24875 <i>Precondition:</i> <tt>!empty()</tt>
24876 </p>
24877 <p>
24878 <i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
24879 </p>
24880 </blockquote>
24881
24882 <p>
24883 Update Table 71: (optional sequence operations)
24884 Add basic_string to the list of containers for the following operations.
24885 </p>
24886 <blockquote><pre>a.front()
24887 a.back()
24888 a.push_back()
24889 a.pop_back()
24890 a[n]
24891 </pre></blockquote>
24892
24893 <p><i>[
24894 Berlin: Has support.  Alisdair provided wording.
24895 ]</i></p>
24896
24897
24898
24899
24900
24901
24902 <hr>
24903 <h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
24904 <p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24905  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-12-14 <b>Last modified:</b> 2010-10-29</p>
24906 <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>
24907 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24908 <p><b>Discussion:</b></p>
24909 <p>
24910 std::string::swap currently says for effects and postcondition:
24911 </p>
24912
24913 <blockquote>
24914 <p>
24915 <i>Effects:</i> Swaps the contents of the two strings.
24916 </p>
24917
24918 <p>
24919 <i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
24920 <tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
24921 </p>
24922 </blockquote>
24923
24924 <p>
24925 Specifying both Effects and Postcondition seems redundant, and the postcondition
24926 needs to be made stronger. Users would be unhappy if the characters were not in
24927 the same order after the swap.
24928 </p>
24929
24930
24931 <p><b>Proposed resolution:</b></p>
24932 <blockquote>
24933 <p>
24934 <del><i>Effects:</i> Swaps the contents of the two strings.</del>
24935 </p>
24936
24937 <p>
24938 <i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
24939 characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
24940 <tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
24941 <del>were</del> <ins>was</ins> in <tt>*this</tt>.
24942 </p>
24943 </blockquote>
24944
24945
24946
24947
24948
24949 <hr>
24950 <h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
24951 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24952  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-12 <b>Last modified:</b> 2010-10-29</p>
24953 <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>
24954 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24955 <p><b>Discussion:</b></p>
24956 <p>
24957 In the most recent working draft, I'm still seeing:
24958 </p>
24959
24960 <blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
24961 </pre></blockquote>
24962
24963 <p>
24964 and
24965 </p>
24966
24967 <blockquote><pre>seekp(pos_type&amp; pos)
24968
24969 seekp(off_type&amp; off, ios_base::seekdir dir)
24970 </pre></blockquote>
24971
24972 <p>
24973 that is, by reference off and pos arguments.
24974 </p>
24975
24976
24977 <p><b>Proposed resolution:</b></p>
24978 <p>
24979 After 27.6.1.3p42 change:
24980 </p>
24981
24982 <blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
24983 </pre></blockquote>
24984
24985 <p>
24986 After 27.6.2.4p1 change:
24987 </p>
24988
24989 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
24990 </pre></blockquote>
24991
24992 <p>
24993 After 27.6.2.4p3 change:
24994 </p>
24995
24996 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
24997 </pre></blockquote>
24998
24999
25000
25001
25002
25003 <hr>
25004 <h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
25005 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25006  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2010-10-29</p>
25007 <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>
25008 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25009 <p><b>Discussion:</b></p>
25010 <p>
25011 I believe I botched the resolution of
25012 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
25013 241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
25014 has WP status.
25015 </p>
25016
25017 <p>
25018 This talks about <tt>unique_copy</tt> requirements and currently reads:
25019 </p>
25020
25021 <blockquote><p>
25022 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
25023 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
25024 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
25025 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
25026 requirements of forward iterator then the value type of <tt>InputIterator</tt>
25027 must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
25028 </p></blockquote>
25029
25030 <p>
25031 The problem (which Paolo discovered) is that when the iterators are at their
25032 most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
25033 <tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
25034 <tt>CopyAssignable</tt> (for the most efficient implementation).  However this
25035 proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
25036 and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
25037 This latter requirement does not necessarily imply that you can:
25038 </p>
25039
25040 <blockquote><pre>*<i>first</i> = *<i>first</i>;
25041 </pre></blockquote>
25042
25043
25044 <p><b>Proposed resolution:</b></p>
25045 <blockquote><p>
25046 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
25047 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
25048 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
25049 shall
25050 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
25051 requirements of forward iterator then the <del>value type</del> 
25052 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
25053 must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
25054 Otherwise CopyConstructible is not required.
25055 </p></blockquote>
25056
25057
25058
25059
25060
25061 <hr>
25062 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
25063 <p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25064  <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2010-10-29</p>
25065 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25066 <p><b>Discussion:</b></p>
25067 <p>
25068 There are some problems in the definition of partial_sum and
25069 adjacent_difference in 26.4 [lib.numeric.ops]
25070 </p>
25071
25072 <p>
25073 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
25074 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
25075 specifies the effects clause as;
25076 </p>
25077
25078 <blockquote><p>
25079 Assigns to every element referred to by iterator <tt>i</tt> in the range
25080 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
25081 </p>
25082 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
25083 </pre></blockquote>
25084 </blockquote>
25085
25086 <p>
25087 And similarly for BinaryOperation. Using just this definition, it seems
25088 logical to expect that:
25089 </p>
25090
25091
25092 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
25093 int  o_array[4];
25094
25095 std::partial_sum(i_array, i_array+4, o_array);
25096 </pre></blockquote>
25097
25098 <p>
25099 Is equivalent to
25100 </p>
25101
25102 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
25103 </pre></blockquote>
25104
25105 <p>
25106 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
25107 <tt>int</tt>.
25108 </p>
25109
25110 <p>
25111 Yet all implementations I have tested produce 100, -56, 44, -112,
25112 because they are using an accumulator of the <tt>InputIterator</tt>'s
25113 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
25114 </p>
25115
25116 <p>
25117 The issue becomes more noticeable when the result of the expression <tt>*i +
25118 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
25119 <tt>value_type</tt>. In a contrived example:
25120 </p>
25121
25122 <blockquote><pre>enum not_int { x = 1, y = 2 };
25123 ...
25124 not_int e_array[4] = { x, x, y, y };
25125 std::partial_sum(e_array, e_array+4, o_array);
25126 </pre></blockquote>
25127
25128 <p>
25129 Is it the intent that the operations happen in the <tt>input type</tt>, or in
25130 the <tt>result type</tt>?
25131 </p>
25132
25133 <p>
25134 If the intent is that operations happen in the <tt>result type</tt>, something
25135 like this should be added to the "Requires" clause of 26.4.3/4
25136 [lib.partial.sum]:
25137 </p>
25138
25139 <blockquote><p>
25140 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
25141 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
25142 (23.1) types.
25143 </p></blockquote>
25144
25145 <p>
25146 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
25147 [lib.inner.product].)
25148 </p>
25149
25150 <p>
25151 The "auto initializer" feature proposed in
25152 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
25153 is not required to
25154 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
25155 obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
25156 </p>
25157
25158 <p>
25159 If the intent is that operations happen in the <tt>input type</tt>, then
25160 something like this should be added instead;
25161 </p>
25162
25163 <blockquote><p>
25164 The type of *first shall meet the requirements of
25165 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
25166 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
25167 convertible to this type.
25168 </p></blockquote>
25169
25170 <p>
25171 The 'widening' behaviour can then be obtained by writing a custom proxy
25172 iterator, which is somewhat involved.
25173 </p>
25174
25175 <p>
25176 In both cases, the semantics should probably be clarified.
25177 </p>
25178
25179 <p>
25180 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
25181 all implementations seem to perform operations in the 'result' type:
25182 </p>
25183
25184 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
25185 int o_array[4];
25186
25187 std::adjacent_difference(i_array, i_array+4, o_array);
25188 </pre></blockquote>
25189
25190 <p>
25191 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
25192 </p>
25193
25194 <p>
25195 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
25196 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
25197 [lib.numeric.ops] by adding the following to 26.4.4/2
25198 [lib.adjacent.difference]:
25199 </p>
25200
25201 <blockquote><p>
25202 The type of <tt>*first</tt> shall meet the requirements of
25203 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
25204 </p></blockquote>
25205 <p><i>[
25206 Berlin: Giving output iterator's value_types very controversial. Suggestion of
25207 adding signatures to allow user to specify "accumulator".
25208 ]</i></p>
25209
25210
25211 <p><i>[
25212 Bellevue:
25213 ]</i></p>
25214
25215
25216 <blockquote>
25217 The intent of the algorithms is to perform their calculations using the type of the input iterator.
25218 Proposed wording provided.
25219 </blockquote>
25220
25221 <p><i>[
25222 Sophia Antipolis:
25223 ]</i></p>
25224
25225
25226 <blockquote>
25227 We did not agree that the proposed resolution was correct. For example,
25228 when the arguments are types <tt>(float*, float*, double*)</tt>, the
25229 highest-quality solution would use double as the type of the
25230 accumulator. If the intent of the wording is to require that the type of
25231 the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
25232 should specify it.
25233 </blockquote>
25234
25235 <p><i>[
25236 2009-05-09 Alisdair adds:
25237 ]</i></p>
25238
25239
25240 <blockquote>
25241 <p>
25242 Now that we have the facility, the 'best' accumulator type could probably be
25243 deduced as:
25244 </p>
25245 <blockquote><pre>std::common_type&lt;InIter::value_type, OutIter::reference&gt;::type
25246 </pre></blockquote>
25247 <p>
25248 This type would then have additional requirements of constructability and
25249 incrementability/assignability.
25250 </p>
25251 <p>
25252 If this extracting an accumulator type from a pair/set of iterators (with
25253 additional requirements on that type) is a problem for multiple functions,
25254 it might be worth extracting into a SharedAccumulator concept or similar.
25255 </p>
25256 <p>
25257 I'll go no further in writing up wording now, until the group gives a
25258 clearer indication of preferred direction.
25259 </p>
25260 </blockquote>
25261
25262 <p><i>[
25263 2009-07 Frankfurt
25264 ]</i></p>
25265
25266
25267 <blockquote>
25268 The proposed resolution isn't quite right. For example, "the type of
25269 *first" should be changed to "iterator::value_type" or similar. Daniel
25270 volunteered to correct the wording.
25271 </blockquote>
25272
25273 <p><i>[
25274 2009-07-29 Daniel corrected wording.
25275 ]</i></p>
25276
25277
25278 <p><i>[
25279 2009-10 Santa Cruz:
25280 ]</i></p>
25281
25282
25283 <blockquote>
25284 Move to Ready.
25285 </blockquote>
25286
25287
25288
25289 <p><b>Proposed resolution:</b></p>
25290
25291
25292
25293 <ol>
25294 <li>
25295 <p>
25296 Change 26.7.3 [partial.sum]/1 as indicated:
25297 </p>
25298
25299 <blockquote>
25300 <p>
25301 <i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
25302 initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
25303 <tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order, <tt>acc</tt> is then
25304 modified by <tt>acc = acc + *i</tt> or <tt>acc = binary_op(acc, *i)</tt> and is assigned
25305 to <tt>*(result + (i - first))</tt>.</ins> <del>Assigns to every element referred to by
25306 iterator <tt>i</tt> in the range <tt>[result,result + (last - first))</tt> a value
25307 correspondingly
25308 equal to</del>
25309 </p>
25310
25311 <blockquote><pre><del>
25312 ((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
25313 </del></pre></blockquote>
25314
25315 <p><del>
25316 or
25317 </del></p>
25318
25319 <blockquote><pre><del>
25320 binary_op(binary_op(...,
25321    binary_op(*first, *(first + 1)),...), *(first + (i - result)))
25322 </del></pre></blockquote>
25323 </blockquote>
25324 </li>
25325
25326 <li>
25327 <p>
25328 Change 26.7.3 [partial.sum]/3 as indicated:
25329 </p>
25330
25331 <blockquote>
25332 <i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
25333 applications
25334 of <tt><del>binary_op</del></tt><ins>the binary operation</ins>.
25335 </blockquote>
25336 </li>
25337
25338 <li>
25339 <p>
25340 Change 26.7.3 [partial.sum]/4 as indicated:
25341 </p>
25342
25343 <blockquote>
25344 <i>Requires:</i> <ins><tt>VT</tt> shall be constructible from the type of <tt>*first</tt>, the result of
25345 <tt>acc + *i</tt> or <tt>binary_op(acc, *i)</tt> shall be implicitly convertible to <tt>VT</tt>, and
25346 the result of the expression <tt>acc</tt> shall be writable to the <tt>result</tt>
25347 output iterator.</ins> In the ranges <tt>[first,last]</tt> and
25348 <tt>[result,result + (last - first)]</tt> [..]
25349 </blockquote>
25350 </li>
25351
25352 <li>
25353 <p>
25354 Change 26.7.4 [adjacent.difference]/1 as indicated:
25355 </p>
25356
25357 <blockquote>
25358 <p>
25359 <i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
25360 initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
25361 <tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order,
25362 initializes a
25363 value <tt>val</tt> of type <tt>VT</tt> with <tt>*i</tt>, assigns the result of <tt>val - acc</tt> or
25364 <tt>binary_op(val, acc)</tt>
25365 to <tt>*(result + (i - first))</tt> and modifies <tt>acc = std::move(val)</tt>.</ins>
25366 <del>Assigns to every element referred to by iterator <tt>i</tt> in the range
25367 <tt>[result + 1,
25368 result + (last - first))</tt> a value correspondingly equal to</del>
25369 </p>
25370
25371 <blockquote><pre><del>
25372 *(first + (i - result)) - *(first + (i - result) - 1)
25373 </del></pre></blockquote>
25374
25375 <p><del>
25376 or
25377 </del></p>
25378
25379 <blockquote><pre><del>
25380 binary_op(*(first + (i - result)), *(first + (i - result) - 1)).
25381 </del></pre></blockquote>
25382
25383 <p><del>
25384 result gets the value of *first.</del>
25385 </p>
25386 </blockquote>
25387 </li>
25388
25389 <li>
25390 <p>
25391 Change 26.7.4 [adjacent.difference]/2 as indicated:
25392 </p>
25393
25394 <blockquote>
25395 <i>Requires:</i> <ins><tt>VT</tt> shall be <tt>MoveAssignable</tt> ([moveassignable])
25396 and shall be
25397 constructible from the type of <tt>*first</tt>. The result
25398 of the expression <tt>acc</tt> and the result of the expression <tt>val - acc</tt> or
25399 <tt>binary_op(val, acc)</tt>
25400 shall be writable to the <tt>result</tt> output iterator.</ins> In the ranges
25401 <tt>[first,last]</tt> [..]
25402 </blockquote>
25403 </li>
25404
25405 <li>
25406 <p>
25407 Change 26.7.4 [adjacent.difference]/5 as indicated:
25408 </p>
25409
25410 <blockquote>
25411 <i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
25412 applications
25413 of <del><tt>binary_op</tt></del><ins>the binary operation</ins>.
25414 </blockquote>
25415 </li>
25416 </ol>
25417
25418
25419
25420
25421
25422
25423
25424
25425 <hr>
25426 <h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
25427 <p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25428  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-15 <b>Last modified:</b> 2010-10-29</p>
25429 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
25430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25431 <p><b>Discussion:</b></p>
25432 <p>
25433 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
25434 that talks about the operator*() member function of shared_ptr:
25435 </p>
25436
25437 <blockquote><p>
25438   Notes: When T is void, attempting to instantiate this member function
25439   renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
25440   does not necessarily result in instantiating this member function.
25441   --end note]
25442 </p></blockquote>
25443
25444 <p>
25445 with the requirement in temp.inst, p1:
25446 </p>
25447
25448 <blockquote><p>
25449   The implicit instantiation of a class template specialization causes
25450   the implicit instantiation of the declarations, but not of the
25451   definitions...
25452 </p></blockquote>
25453
25454 <p>
25455 I assume that what the note is really trying to say is that
25456 "instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
25457 this member function." That is, that this function must not be
25458 declared a member of shared_ptr&lt;void&gt;. Is my interpretation
25459 correct?
25460 </p>
25461
25462
25463 <p><b>Proposed resolution:</b></p>
25464 <p>
25465 Change 2.2.3.5p6
25466 </p>
25467
25468 <blockquote><p>
25469 -6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
25470 this member function renders the program ill-formed. [<i>Note:</i>
25471 Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
25472 instantiating this member function. <i>--end note</i>]</del> <ins>it is
25473 unspecified whether this member function is declared or not, and if so, what its
25474 return type is, except that the declaration (although not necessarily the
25475 definition) of the function shall be well-formed.</ins>
25476 </p></blockquote>
25477
25478
25479
25480
25481
25482
25483 <hr>
25484 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
25485 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25486  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-16 <b>Last modified:</b> 2010-10-29</p>
25487 <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>
25488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25489 <p><b>Discussion:</b></p>
25490 <p>
25491 Is the void specialization of the template assignment operator taking
25492 a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
25493 </p>
25494 <p>
25495 I.e., is this snippet well-formed:
25496 </p>
25497 <blockquote><pre>shared_ptr&lt;void&gt; p;
25498 p.operator=&lt;void&gt;(p);
25499 </pre></blockquote>
25500
25501 <p>
25502 Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
25503 to void. I suspect it's because shared_ptr has two template assignment
25504 operators, one of which takes auto_ptr, and the auto_ptr template gets
25505 implicitly instantiated in the process of overload resolution.
25506 </p>
25507
25508 <p>
25509 The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
25510 operator*() as with the same operator in shared_ptr&lt;void&gt;.
25511 </p>
25512
25513 <p>
25514 PS Strangely enough, the EDG front end doesn't mind the code, even
25515 though in a small test case (below) I can reproduce the error with
25516 it as well.
25517 </p>
25518
25519 <blockquote><pre>template &lt;class T&gt;
25520 struct A { T&amp; operator*() { return *(T*)0; } };
25521
25522 template &lt;class T&gt;
25523 struct B {
25524     void operator= (const B&amp;) { }
25525     template &lt;class U&gt;
25526     void operator= (const B&lt;U&gt;&amp;) { }
25527     template &lt;class U&gt;
25528     void operator= (const A&lt;U&gt;&amp;) { }
25529 };
25530
25531 int main ()
25532 {
25533     B&lt;void&gt; b;
25534     b.operator=&lt;void&gt;(b);
25535 }
25536 </pre></blockquote>
25537
25538
25539 <p><b>Proposed resolution:</b></p>
25540 <p>
25541 In [lib.memory] change:
25542 </p>
25543 <blockquote><pre>template&lt;class X&gt; class auto_ptr;
25544 <ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
25545 </pre></blockquote>
25546
25547 <p>
25548 In [lib.auto.ptr]/2 add the following before the last closing brace:
25549 </p>
25550
25551 <blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
25552 {
25553 public:
25554     typedef void element_type;
25555 };
25556 </pre></blockquote>
25557
25558
25559
25560
25561
25562
25563 <hr>
25564 <h3><a name="542"></a>542. shared_ptr observers</h3>
25565 <p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25566  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-18 <b>Last modified:</b> 2010-10-29</p>
25567 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
25568 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25569 <p><b>Discussion:</b></p>
25570 <p>
25571 Peter Dimov wrote:
25572 To: C++ libraries mailing list
25573 Message c++std-lib-15614
25574 [...]
25575 The intent is for both use_count() and unique() to work in a threaded environment.
25576 They are intrinsically prone to race conditions, but they never return garbage.
25577 </p>
25578
25579 <p>
25580 This is a crucial piece of information that I really wish were
25581 captured in the text. Having this in a non-normative note would
25582 have made everything crystal clear to me and probably stopped
25583 me from ever starting this discussion :) Instead, the sentence
25584 in p12 "use only for debugging and testing purposes, not for
25585 production code" very strongly suggests that implementations
25586 can and even are encouraged to return garbage (when threads
25587 are involved) for performance reasons.
25588 </p>
25589 <p>
25590 How about adding an informative note along these lines:
25591 </p>
25592 <blockquote><p>
25593   Note: Implementations are encouraged to provide well-defined
25594   behavior for use_count() and unique() even in the presence of
25595   multiple threads.
25596 </p></blockquote>
25597 <p>
25598 I don't necessarily insist on the exact wording, just that we
25599 capture the intent.
25600 </p>
25601
25602
25603 <p><b>Proposed resolution:</b></p>
25604 <p>
25605 Change 20.9.10.2.5 [util.smartptr.shared.obs] p12:
25606 </p>
25607 <blockquote><p>
25608 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
25609 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
25610 </p></blockquote>
25611
25612 <p>
25613 Change 20.9.10.3.5 [util.smartptr.weak.obs] p3:
25614 </p>
25615 <blockquote><p>
25616 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
25617 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
25618 </p></blockquote>
25619
25620
25621
25622
25623
25624 <hr>
25625 <h3><a name="543"></a>543. valarray slice default constructor</h3>
25626 <p><b>Section:</b> 26.6.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25627  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2005-11-03 <b>Last modified:</b> 2010-10-29</p>
25628 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25629 <p><b>Discussion:</b></p>
25630 <p>
25631 If one explicitly constructs a slice or glice with the default
25632 constructor, does the standard require this slice to have any usable
25633 state?  It says "creates a slice which specifies no elements", which
25634 could be interpreted two ways:
25635 </p>
25636 <ol>
25637 <li>There are no elements to which the slice refers (i.e. undefined).</li>
25638 <li>The slice specifies an array with no elements in it (i.e. defined).</li>
25639 </ol>
25640 <p>
25641 Here is a bit of code to illustrate:
25642 </p>
25643 <blockquote><pre>#include &lt;iostream&gt;
25644 #include &lt;valarray&gt;
25645
25646 int main()
25647 {
25648     std::valarray&lt;int&gt; v(10);
25649     std::valarray&lt;int&gt; v2 = v[std::slice()];
25650     std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
25651 }
25652 </pre></blockquote>
25653
25654 <p>
25655 Is the behavior undefined?  Or should the output be:
25656 </p>
25657
25658 <blockquote><pre>v[slice()].size() = 0
25659 </pre></blockquote>
25660
25661 <p>
25662 There is a similar question and wording for gslice at 26.3.6.1p1.
25663 </p>
25664
25665
25666 <p><b>Proposed resolution:</b></p>
25667
25668 <p><i>[Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]</i></p>
25669
25670
25671 <p>
25672 Change 26.6.4.1 [cons.slice]:
25673 </p>
25674
25675 <blockquote><p>
25676 1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
25677 which specifies no elements.</del> <ins>The default constructor is equivalent to
25678 <tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
25679 the declaration of arrays of slices. The constructor with arguments for a slice
25680 takes a start, length, and stride parameter.
25681 </p></blockquote>
25682
25683 <p>
25684 Change 26.6.6.1 [gslice.cons]:
25685 </p>
25686
25687 <blockquote><p>
25688 1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
25689 elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
25690 valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
25691 with arguments builds a <tt>gslice</tt> based on a specification of start,
25692 lengths, and strides, as explained in the previous section.
25693 </p></blockquote>
25694
25695
25696
25697
25698
25699
25700 <hr>
25701 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
25702 <p><b>Section:</b> 20.9.10.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25703  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
25704 <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>
25705 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25706 <p><b>Discussion:</b></p>
25707 <p>
25708 The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
25709 any, is destroyed. In principle there are two possibilities: it is destroyed
25710 unconditionally whenever ~shared_ptr is executed (which, from an implementation
25711 standpoint, means that the deleter is copied whenever the shared_ptr is copied),
25712 or it is destroyed immediately after the owned pointer is destroyed (which, from
25713 an implementation standpoint, means that the deleter object is shared between
25714 instances). We should say which it is.
25715 </p>
25716
25717
25718 <p><b>Proposed resolution:</b></p>
25719 <p>
25720 Add after the first sentence of 20.9.10.2.11 [util.smartptr.getdeleter]/1:
25721 </p>
25722 <blockquote>
25723 <p>
25724 The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
25725 that owns <tt><i>d</i></tt>.
25726 </p>
25727 <p>
25728 [<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
25729 This can happen if the implementation doesn't destroy the deleter until all
25730 <tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
25731 </p>
25732 </blockquote>
25733
25734
25735
25736
25737
25738 <hr>
25739 <h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
25740 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25741  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-12 <b>Last modified:</b> 2010-10-29</p>
25742 <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>
25743 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25744 <p><b>Discussion:</b></p>
25745 <p>
25746 Assuming we adopt the
25747 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
25748 compatibility package from C99</a>  what should be the return type of the
25749 following signature be:
25750 </p>
25751 <blockquote><pre>?  pow(float, int);
25752 </pre></blockquote>
25753 <p>
25754 C++03 says that the return type should be <tt>float</tt>. 
25755 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
25756 TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
25757 clients into a situation where C++03 provides answers that are not as high
25758 quality as C90/C99/TR1.  For example:
25759 </p>
25760 <blockquote><pre>#include &lt;math.h&gt;
25761
25762 int main()
25763 {
25764     float x = 2080703.375F;
25765     double y = pow(x, 2);
25766 }
25767 </pre></blockquote>
25768 <p>
25769 Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
25770 </p>
25771
25772 <blockquote><pre>y = 4329326534736.390625
25773 </pre></blockquote>
25774
25775 <p>
25776 which is exactly right.  While C++98/C++03 demands:
25777 </p>
25778
25779 <blockquote><pre>y = 4329326510080.
25780 </pre></blockquote>
25781
25782 <p>
25783 which is only approximately right.
25784 </p>
25785
25786 <p>
25787 I recommend that C++0X adopt the mixed mode arithmetic already adopted by
25788 Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
25789 <tt>double</tt>.
25790 </p>
25791
25792 <p><i>[
25793 Kona (2007): Other functions that are affected by this issue include
25794 <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
25795 26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
25796 nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
25797 resolution appears above, rather than below, the heading "Proposed
25798 resolution")
25799 ]</i></p>
25800
25801
25802 <p><i>[
25803 </i></p><p><i>
25804 Howard, post Kona:
25805 </i></p><i>
25806 <blockquote>
25807 <p>
25808 Unfortunately I strongly disagree with a part of the resolution
25809 from Kona.  I am moving from New to Open instead of to Review because I do not believe
25810 we have consensus on the intent of the resolution.
25811 </p>
25812 <p>
25813 This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
25814 the second integral parameter in each of these signatures (from C99) is <b>not</b> a
25815 <i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
25816 intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
25817 </p>
25818 <p>
25819 For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
25820 <tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
25821 correct signature is:
25822 </p>
25823 <blockquote>
25824 <pre>float nexttoward(float, long double);
25825 </pre>
25826 </blockquote>
25827 <p>
25828 which is what both the C++0X working paper and C99 state (as far as I currently understand).
25829 </p>
25830 <p>
25831 This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
25832 route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
25833 The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
25834 </p>
25835 </blockquote>
25836 ]</i><p></p>
25837
25838
25839 <p><i>[
25840 Bellevue:
25841 ]</i></p>
25842
25843
25844 <blockquote>
25845 This signature was not picked up from C99. Instead, if one types
25846 pow(2.0f,2), the promotion rules will invoke "double pow(double,
25847 double)", which generally gives special treatment for integral
25848 exponents, preserving full accuracy of the result.  New proposed
25849 wording provided.
25850 </blockquote>
25851
25852
25853 <p><b>Proposed resolution:</b></p>
25854 <p>
25855 Change 26.8 [c.math] p10:
25856 </p>
25857
25858 <blockquote>
25859 <p>
25860 The added signatures are:
25861 </p>
25862 <blockquote><pre>...
25863 <del>float pow(float, int);</del>
25864 ...
25865 <del>double pow(double, int);</del>
25866 ...
25867 <del>long double pow(long double, int);</del>
25868 </pre></blockquote>
25869 </blockquote>
25870
25871
25872
25873
25874
25875
25876 <hr>
25877 <h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
25878 <p><b>Section:</b> X [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25879  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-23 <b>Last modified:</b> 2010-10-29</p>
25880 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25881 <p><b>Discussion:</b></p>
25882 <p>
25883 Previously xxx.h was parsable by C++.  But in the case of C99's &lt;complex.h&gt;
25884 it isn't.  Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
25885 </p>
25886
25887 <ul>
25888 <li>&lt;string&gt;   : C++ API in namespace std</li>
25889 <li>&lt;cstring&gt;  : C API in namespace std</li>
25890 <li>&lt;string.h&gt; : C API in global namespace</li>
25891 </ul>
25892
25893 <p>
25894 In the case of C's complex, the C API won't compile in C++.  So we have:
25895 </p>
25896
25897 <ul>
25898 <li>&lt;complex&gt;   : C++ API in namespace std</li>
25899 <li>&lt;ccomplex&gt;  : ?</li>
25900 <li>&lt;complex.h&gt; : ?</li>
25901 </ul>
25902
25903 <p>
25904 The ? can't refer to the C API.  TR1 currently says:
25905 </p>
25906
25907 <ul>
25908 <li>&lt;complex&gt;   : C++ API in namespace std</li>
25909 <li>&lt;ccomplex&gt;  : C++ API in namespace std</li>
25910 <li>&lt;complex.h&gt; : C++ API in global namespace</li>
25911 </ul>
25912
25913
25914
25915 <p><b>Proposed resolution:</b></p>
25916 <p>
25917 Change 26.3.11 [cmplxh]:
25918 </p>
25919
25920 <blockquote>
25921 <p>
25922 The header behaves as if it includes the header
25923 <tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
25924 declarations to declare in the global namespace all function and type names
25925 declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
25926 <ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
25927 into the global namespace as there is no C interface to promote. <i>--end
25928 note</i>]</ins>
25929 </p>
25930 </blockquote>
25931
25932
25933
25934
25935
25936
25937 <hr>
25938 <h3><a name="552"></a>552. random_shuffle and its generator</h3>
25939 <p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
25940  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-01-25 <b>Last modified:</b> 2010-10-29</p>
25941 <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>
25942 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25943 <p><b>Discussion:</b></p>
25944 <p>
25945 ...is specified to shuffle its range by calling swap but not how
25946 (or even that) it's supposed to use the RandomNumberGenerator
25947 argument passed to it.
25948 </p>
25949 <p>
25950 Shouldn't we require that the generator object actually be used
25951 by the algorithm to obtain a series of random numbers and specify
25952 how many times its operator() should be invoked by the algorithm?
25953 </p>
25954
25955 <p>
25956 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
25957 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
25958 for some further discussion.
25959 </p>
25960
25961
25962
25963 <p><b>Proposed resolution:</b></p>
25964 <p>
25965 Adopt the proposed resolution in
25966 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
25967 </p>
25968
25969
25970 <p><i>[
25971 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
25972 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25973 ]</i></p>
25974
25975
25976
25977
25978
25979 <hr>
25980 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
25981 <p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25982  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05 <b>Last modified:</b> 2010-10-29</p>
25983 <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>
25984 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25985 <p><b>Discussion:</b></p>
25986 <p>
25987 In 25, p8 we allow BinaryPredicates to return a type that's convertible
25988 to bool but need not actually be bool. That allows predicates to return
25989 things like proxies and requires that implementations be careful about
25990 what kinds of expressions they use the result of the predicate in (e.g.,
25991 the expression in if (!pred(a, b)) need not be well-formed since the
25992 negation operator may be inaccessible or return a type that's not
25993 convertible to bool).
25994 </p>
25995 <p>
25996 Here's the text for reference:
25997 </p>
25998 <blockquote><p>
25999   ...if an algorithm takes BinaryPredicate binary_pred as its argument
26000  and first1 and first2 as its iterator arguments, it should work
26001  correctly in the construct if (binary_pred(*first1, first2)){...}.
26002 </p></blockquote>
26003
26004 <p>
26005 In 25.3, p2 we require that the Compare function object return true
26006 of false, which would seem to preclude such proxies. The relevant text
26007 is here:
26008 </p>
26009 <blockquote><p>
26010   Compare is used as a function object which returns true if the first
26011   argument is less than the second, and false otherwise...
26012 </p></blockquote>
26013
26014 <p><i>[
26015 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
26016 destroyed.
26017 ]</i></p>
26018
26019
26020 <p><i>[
26021 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
26022 ]</i></p>
26023
26024
26025 <p><i>[
26026 2009-10 Santa Cruz:
26027 ]</i></p>
26028
26029
26030 <blockquote>
26031 Move to Review once wording received. Stefanus to send proposed wording.
26032 </blockquote>
26033
26034 <p><i>[
26035 2009-10 Santa Cruz:
26036 ]</i></p>
26037
26038
26039 <blockquote>
26040 Move to Review once wording received. Stefanus to send proposed wording.
26041 </blockquote>
26042
26043 <p><i>[
26044 2009-10-24 Stefanus supplied wording.
26045 ]</i></p>
26046
26047
26048 <blockquote>
26049 Move to Review once wording received. Stefanus to send proposed wording.
26050 Old proposed wording here:
26051 <blockquote>
26052 <p>
26053 I think we could fix this by rewording 25.3, p2 to read somthing like:
26054 </p>
26055 <blockquote><p>
26056 -2- <tt>Compare</tt> is <del>used as a function object which returns
26057 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
26058 return value of the function call operator applied to an object of type
26059 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
26060 if the first argument of the call</ins> is less than the second, and
26061 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
26062 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
26063 will not apply any non-constant function through the dereferenced iterator.
26064 </p></blockquote>
26065 </blockquote>
26066 </blockquote>
26067
26068 <p><i>[
26069 2010-01-17:
26070 ]</i></p>
26071
26072
26073 <blockquote>
26074 <p>
26075 Howard expresses concern that the current direction of the proposed
26076 wording outlaws expressions such as:
26077 </p>
26078
26079 <blockquote><pre>if (!comp(x, y))
26080 </pre></blockquote>
26081
26082 <p>
26083 Daniel provides wording which addresses that concern.
26084 </p>
26085
26086 <p>
26087 The previous wording is saved here:
26088 </p>
26089
26090 <blockquote>
26091
26092 <p>
26093 Change 25.4 [alg.sorting] p2:
26094 </p>
26095 <blockquote>
26096 <tt>Compare</tt> is used as a function object<ins>. The return value of
26097 the function call operator applied to an object of type Compare, when
26098 converted to type bool, yields true if the first argument of the
26099 call</ins> <del>which returns <tt>true</tt> if the first argument</del>
26100 is less than the second, and <tt>false</tt> otherwise. <tt>Compare
26101 comp</tt> is used throughout for algorithms assuming an ordering
26102 relation. It is assumed that <tt>comp</tt> will not apply any
26103 non-constant function through the dereferenced iterator.
26104 </blockquote>
26105
26106 </blockquote>
26107
26108 </blockquote>
26109
26110 <p><i>[
26111 2010-01-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
26112 ]</i></p>
26113
26114
26115
26116 <p><b>Proposed resolution:</b></p>
26117
26118 <ol>
26119 <li>
26120 <p>
26121 Change 25.1 [algorithms.general]/7+8 as indicated. <i>[This change is
26122 recommended to bring the return value requirements of <tt>BinaryPredicate</tt>
26123 and <tt>Compare</tt> in sync.]</i>
26124 </p>
26125
26126 <blockquote>
26127 <p>
26128 7 The <tt>Predicate</tt> parameter is used whenever an algorithm expects a
26129 function object that when applied to the result of dereferencing the
26130 corresponding iterator returns a value testable as <tt>true</tt>. In other
26131 words, if an algorithm takes <tt>Predicate pred</tt> as its argument and
26132 <tt>first</tt> as its iterator argument, it should work correctly in the
26133 construct <del>if <tt>(pred(*first)){...}</tt></del> <ins><tt>pred(*first)</tt>
26134 contextually converted to <tt>bool</tt> (4 [conv])</ins>. The
26135 function object <tt>pred</tt> shall not apply any nonconstant function through
26136 the dereferenced iterator. This function object may be a pointer to function, or
26137 an object of a type with an appropriate function call operator.
26138 </p>
26139
26140 <p>
26141 8 The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a
26142 function object that when applied to the result of dereferencing two
26143 corresponding iterators or to dereferencing an iterator and type <tt>T</tt> when
26144 <tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>.
26145 In other words, if an algorithm takes <tt>BinaryPredicate</tt>
26146 <tt>binary_pred</tt> as its argument and <tt>first1</tt> and <tt>first2</tt> as
26147 its iterator arguments, it should work correctly in the construct <del><tt>if
26148 (binary_pred(*first1, *first2)){...}</tt></del> <ins><tt>binary_pred(*first1,
26149 *first2)</tt> contextually converted to <tt>bool</tt> (4 [conv])</ins>. <tt>BinaryPredicate</tt> always takes the first iterator
26150 type as its first argument, that is, in those cases when <tt>T value</tt> is
26151 part of the signature, it should work correctly in the <del>context of <tt>if
26152 (binary_pred(*first1, value)){...}</tt></del> <ins>construct
26153 <tt>binary_pred(*first1, value)</tt> contextually converted to <tt>bool</tt>
26154 (4 [conv])</ins>. <tt>binary_pred</tt> shall not apply any
26155 non-constant function through the dereferenced iterators.
26156 </p>
26157 </blockquote>
26158 </li>
26159
26160 <li>
26161 <p>
26162 Change 25.4 [alg.sorting]/2 as indicated:
26163 </p>
26164
26165 <blockquote>
26166 2 <tt>Compare</tt> is <del>used as</del> a function object <ins>type (20.8 [function.objects]). The return value of the function call operation
26167 applied to an object of type <tt>Compare</tt>, when contextually converted to
26168 type <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the first
26169 argument of the call</ins><del> which returns <tt>true</tt> if the first
26170 argument</del> is less than the second, and <tt>false</tt> otherwise.
26171 <tt>Compare comp</tt> is used throughout for algorithms assuming an ordering
26172 relation. It is assumed that <tt>comp</tt> will not apply any non-constant
26173 function through the dereferenced iterator.
26174 </blockquote>
26175 </li>
26176
26177 </ol>
26178
26179
26180
26181
26182
26183
26184 <hr>
26185 <h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
26186 <p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26187  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-19 <b>Last modified:</b> 2010-10-29</p>
26188 <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>
26189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26190 <p><b>Discussion:</b></p>
26191         <p>
26192
26193 18.3.1 [limits], p2 requires implementations  to provide specializations of the
26194 <code>numeric_limits</code> template for  each scalar type. While this
26195 could be interepreted to include cv-qualified forms of such types such
26196 an  interepretation   is  not  reflected   in  the  synopsis   of  the
26197 <code>&lt;limits&gt;</code> header.
26198
26199         </p>
26200         <p>
26201
26202 The absence  of specializations of the template  on cv-qualified forms
26203 of  fundamental types  makes <code>numeric_limits</code>  difficult to
26204 use in generic  code where the constness (or volatility)  of a type is
26205 not  always  immediately  apparent.  In  such  contexts,  the  primary
26206 template  ends   up  being   instantiated  instead  of   the  provided
26207 specialization, typically yielding unexpected behavior.
26208
26209         </p>
26210         <p>
26211
26212 Require   that  specializations   of   <code>numeric_limits</code>  on
26213 cv-qualified fundamental types have the same semantics as those on the
26214 unqualifed forms of the same types.
26215
26216         </p>
26217
26218
26219 <p><b>Proposed resolution:</b></p>
26220         <p>
26221
26222 Add  to  the   synopsis  of  the  <code>&lt;limits&gt;</code>  header,
26223 immediately  below  the  declaration  of  the  primary  template,  the
26224 following:
26225 </p>
26226
26227 <pre>
26228 template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
26229 template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
26230 template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;
26231
26232 </pre>
26233
26234         <p>
26235
26236 Add  a new paragraph  to the  end of  18.3.1.1 [numeric.limits], with  the following
26237 text:
26238
26239         </p>
26240         <p>
26241
26242 -new-para- The  value of each member  of a <code>numeric_limits</code>
26243 specialization on a  cv-qualified T is equal to the  value of the same
26244 member of <code>numeric_limits&lt;T&gt;</code>.
26245
26246         </p>
26247
26248 <p><i>[
26249 Portland: Martin will clarify that user-defined types get cv-specializations
26250 automatically.
26251 ]</i></p>
26252
26253
26254
26255
26256
26257
26258
26259 <hr>
26260 <h3><a name="561"></a>561. inserter overly generic</h3>
26261 <p><b>Section:</b> 24.5.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26262  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-21 <b>Last modified:</b> 2010-10-29</p>
26263 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26264 <p><b>Discussion:</b></p>
26265 <p>
26266 The declaration of <tt>std::inserter</tt> is:
26267 </p>
26268
26269 <blockquote><pre>template &lt;class Container, class Iterator&gt;
26270 insert_iterator&lt;Container&gt;
26271 inserter(Container&amp; x, Iterator i);
26272 </pre></blockquote>
26273
26274 <p>
26275 The template parameter <tt>Iterator</tt> in this function is completely unrelated
26276 to the template parameter <tt>Container</tt> when it doesn't need to be.  This
26277 causes the code to be overly generic.  That is, any type at all can be deduced
26278 as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
26279 <tt>Container</tt>.  However, for every free (unconstrained) template parameter
26280 one has in a signature, the opportunity for a mistaken binding grows geometrically.
26281 </p>
26282
26283 <p>
26284 It would be much better if <tt>inserter</tt> had the following signature instead:
26285 </p>
26286
26287 <blockquote><pre>template &lt;class Container&gt;
26288 insert_iterator&lt;Container&gt;
26289 inserter(Container&amp; x, typename Container::iterator i);
26290 </pre></blockquote>
26291
26292 <p>
26293 Now there is only one free template parameter.  And the second argument to
26294 <tt>inserter</tt> must be implicitly convertible to the container's iterator,
26295 else the call will not be a viable overload (allowing other functions in the
26296 overload set to take precedence).  Furthermore, the first parameter must have a
26297 nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
26298 is not viable.  Contrast this with the current situation
26299 where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
26300 types need not be anything closely related to containers or iterators.
26301 </p>
26302
26303 <p>
26304 This can adversely impact well written code.  Consider:
26305 </p>
26306
26307 <blockquote><pre>#include &lt;iterator&gt;
26308 #include &lt;string&gt;
26309
26310 namespace my
26311 {
26312
26313 template &lt;class String&gt;
26314 struct my_type {};
26315
26316 struct my_container
26317 {
26318 template &lt;class String&gt;
26319 void push_back(const my_type&lt;String&gt;&amp;);
26320 };
26321
26322 template &lt;class String&gt;
26323 void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
26324
26325 }  // my
26326
26327 int main()
26328 {
26329     my::my_container c;
26330     my::my_type&lt;std::string&gt; m;
26331     inserter(m, c);
26332 }
26333 </pre></blockquote>
26334
26335 <p>
26336 Today this code fails because the call to <tt>inserter</tt> binds to
26337 <tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
26338 proposed change <tt>std::inserter</tt> will no longer be a viable function which
26339 leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
26340 works as the client intends.
26341 </p>
26342
26343 <p>
26344 To make matters a little more insidious, the above example works today if you
26345 simply change the first argument to an rvalue:
26346 </p>
26347
26348 <blockquote><pre>    inserter(my::my_type(), c);
26349 </pre></blockquote>
26350
26351 <p>
26352 It will also work if instantiated with some string type other than
26353 <tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
26354 <tt>&lt;iterator&gt;</tt> happens to not get included.
26355 </p>
26356
26357 <p>
26358 And it will fail again for such inocuous reaons as <tt>my_type</tt> or
26359 <tt>my_container</tt> privately deriving from any <tt>std</tt> type.
26360 </p>
26361
26362 <p>
26363 It seems unfortunate that such simple changes in the client's code can result
26364 in such radically differing behavior.
26365 </p>
26366
26367
26368
26369 <p><b>Proposed resolution:</b></p>
26370 <p>
26371 Change 24.2:
26372 </p>
26373
26374 <blockquote><p>
26375 <b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
26376 </p>
26377 <blockquote><pre>...
26378 template &lt;class Container<del>, class Iterator</del>&gt;
26379    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
26380 ...
26381 </pre></blockquote>
26382 </blockquote>
26383
26384 <p>
26385 Change 24.4.2.5:
26386 </p>
26387
26388 <blockquote><p>
26389 <b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
26390 <blockquote><pre>...
26391 template &lt;class Container<del>, class Iterator</del>&gt;
26392    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
26393 ...
26394 </pre></blockquote>
26395 </blockquote>
26396
26397 <p>
26398 Change 24.4.2.6.5:
26399 </p>
26400
26401 <blockquote>
26402 <p>
26403 <b>24.4.2.6.5</b> <tt>inserter</tt>
26404 </p>
26405 <pre>template &lt;class Container<del>, class Inserter</del>&gt;
26406    insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
26407 </pre>
26408 <blockquote><p>
26409 -1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
26410 </p></blockquote>
26411 </blockquote>
26412
26413
26414
26415 <p><i>[
26416 Kona (2007): This issue will probably be addressed as a part of the concepts overhaul of the library anyway, but the proposed resolution is correct in the absence of concepts. 
26417 Proposed Disposition: Ready
26418 ]</i></p>
26419
26420
26421
26422
26423
26424 <hr>
26425 <h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
26426 <p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26427  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
26428 <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>
26429 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26430 <p><b>Discussion:</b></p>
26431         <p>
26432
26433 For  better efficiency,  the requirement  on the  stringbuf  ctor that
26434 takes  a  string  argument  should  be  loosened  up  to  let  it  set
26435 <code>epptr()</code>  beyond  just   one  past  the  last  initialized
26436 character  just like  <code>overflow()</code> has  been changed  to be
26437 allowed  to  do   (see  issue  432).  That  way   the  first  call  to
26438 <code>sputc()</code> on  an object won't  necessarily cause a  call to
26439 <code>overflow</code>. The corresponding change  should be made to the
26440 string overload of the <code>str()</code> member function.
26441
26442         </p>
26443
26444
26445 <p><b>Proposed resolution:</b></p>
26446         <p>
26447
26448 Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
26449
26450         </p>
26451
26452 <blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
26453                ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
26454 </pre>
26455
26456 <p>
26457 -3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
26458 initializing the base class with <tt>basic_streambuf()</tt>
26459 (27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
26460 Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
26461 <i>str</i> into the <tt>basic_stringbuf</tt> underlying character
26462 sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
26463 output sequence such that <tt>pbase()</tt> points to the first underlying
26464 character, <tt>epptr()</tt> points one past the last underlying character, and
26465 <tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
26466 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
26467 <tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
26468 that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 
26469 character and <tt>egptr()</tt> points one past the last underlying character.</del>
26470 </p>
26471 </blockquote>
26472
26473         <p>
26474
26475 Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
26476 read:
26477
26478         </p>
26479 <blockquote>
26480 <p>
26481 -2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
26482 <tt>basic_stringbuf</tt> underlying character sequence <ins>and
26483 initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
26484 <del>If
26485 <tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
26486 sequence such that <tt>pbase()</tt> points to the first underlying character, 
26487 <tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
26488 is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
26489 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
26490 <tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence 
26491 such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
26492 character and <tt>egptr()</tt> points one past the last underlying character.</del>
26493 </p>
26494
26495         <p>
26496
26497 <ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
26498 <code>pbase()</code>  points  to the  first  underlying character  and
26499 <code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
26500 <code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
26501 + s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
26502 is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
26503 <code>eback()</code>  points to  the first  underlying  character, and
26504 <code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
26505 s.size())</code> hold.</ins>
26506
26507         </p>
26508 </blockquote>
26509
26510
26511 <p><i>[
26512 Kona (2007) Moved to Ready.
26513 ]</i></p>
26514
26515
26516
26517
26518
26519 <hr>
26520 <h3><a name="563"></a>563. stringbuf seeking from end</h3>
26521 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26522  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
26523 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
26524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26525 <p><b>Discussion:</b></p>
26526 <p>
26527 According to  Table 92  (unchanged by issue  432), when  <code>(way ==
26528 end)</code> the  <code>newoff</code> value in out mode  is computed as
26529 the difference between <code>epptr()</code> and <code>pbase()</code>.
26530 </p>
26531         <p>
26532
26533 This value  isn't meaningful unless the  value of <code>epptr()</code>
26534 can be  precisely controlled by a  program.  That used  to be possible
26535 until  we accepted the  resolution of  issue 432,  but since  then the
26536 requirements on <code>overflow()</code> have  been relaxed to allow it
26537 to  make  more than  1  write  position  available (i.e.,  by  setting
26538 <code>epptr()</code>     to     some     unspecified    value     past
26539 <code>pptr()</code>).      So    after     the    first     call    to
26540 <code>overflow()</code>  positioning the  output sequence  relative to
26541 end will have unspecified results.
26542
26543         </p>
26544         <p>
26545
26546 In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
26547 epptr())</code> need not hold, there are two different possible values
26548 for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
26549 <code>egptr() - eback()</code>.
26550
26551         </p>
26552
26553
26554 <p><b>Proposed resolution:</b></p>
26555         <p>
26556
26557 Change the <code>newoff</code>  column in the last row  of Table 94 to
26558 read:
26559
26560         </p>
26561 <blockquote><p>
26562
26563 the <del>end</del> <ins>high mark</ins> pointer minus the beginning 
26564 pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
26565
26566 </p></blockquote>
26567
26568
26569 <p><i>[
26570 Kona (2007) Moved to Ready.
26571 ]</i></p>
26572
26573
26574
26575
26576
26577 <hr>
26578 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
26579 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26580  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
26581 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
26582 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26583 <p><b>Discussion:</b></p>
26584 <p>
26585 The   effects  of  the   <code>seekpos()</code>  member   function  of
26586 <code>basic_stringbuf</code>  simply say  that the  function positions
26587 the  input and/or  output  sequences  but fail  to  spell out  exactly
26588 how. This is in contrast  to the detail in which <code>seekoff()</code>
26589 is described.
26590 </p>
26591
26592 <p><i>[
26593 2009-07 Frankfurt
26594 ]</i></p>
26595
26596
26597 <blockquote>
26598 Move to Ready.
26599 </blockquote>
26600
26601
26602
26603 <p><b>Proposed resolution:</b></p>
26604         <p>
26605
26606 Change 27.7.1.3, p13 to read:
26607
26608         </p>
26609 <blockquote>
26610 <p>
26611 -13- <i>Effects:</i> <ins>Equivalent to <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
26612 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
26613 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
26614 (as described below).</del>
26615 </p>
26616 <ul>
26617 <li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
26618 <li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
26619 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
26620 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
26621 has not been obtained by a previous successful call to one of the positioning
26622 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
26623 the effect is undefined.</del></li>
26624 </ul>
26625 </blockquote>
26626
26627
26628 <p><i>[
26629 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
26630 definition, so there is no ambiguity as to what it means. Proposed
26631 Disposition: NAD
26632 ]</i></p>
26633
26634
26635 <p><i>[
26636 Post-Kona Martin adds:
26637 I'm afraid I disagree
26638 with the Kona '07 rationale for marking it NAD. The only text
26639 that describes precisely what it means to position the input
26640 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
26641 clause is inadequate in comparison and the proposed resolution
26642 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
26643 ]</i></p>
26644
26645
26646
26647
26648
26649 <hr>
26650 <h3><a name="565"></a>565. xsputn inefficient</h3>
26651 <p><b>Section:</b> 27.6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26652  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
26653 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26654 <p><b>Discussion:</b></p>
26655         <p>
26656
26657 <tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
26658 "writing up to  <tt>n</tt> characters to the output  sequence as if by
26659 repeated calls to <tt>sputc(c)</tt>."
26660
26661         </p>
26662         <p>
26663
26664 Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
26665 <tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
26666 <tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
26667 suboptimal in  some interesting cases,  such as in unbuffered  mode or
26668 when the buffer is <tt>basic_stringbuf</tt>.
26669
26670         </p>
26671         <p>
26672
26673 Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
26674 required  and the  wording is  simply  meant to  describe the  general
26675 effect of appending to the end  of the sequence it would be worthwhile
26676 to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
26677 required to cause a call to <tt>overflow()</tt>.
26678
26679         </p>
26680
26681 <p><i>[
26682 2009-07 Frankfurt
26683 ]</i></p>
26684
26685
26686 <blockquote>
26687 Move to Ready.
26688 </blockquote>
26689
26690
26691
26692 <p><b>Proposed resolution:</b></p>
26693         <p>
26694
26695 Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
26696 27.5.2.4.5, p1 (N1804):
26697
26698         </p>
26699         <blockquote>    
26700             <p>
26701 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
26702 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
26703 written are obtained from successive elements of the array whose first element
26704 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
26705 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
26706 <tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
26707 <tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
26708 it achieves the same effects by other means.</ins>
26709             </p>
26710         </blockquote>    
26711         <p>
26712
26713 In addition,  I suggest to  add a footnote  to this function  with the
26714 same text as Footnote 292 to  make it extra clear that derived classes
26715 are permitted to override <tt>xsputn()</tt> for efficiency.
26716
26717         </p>
26718
26719
26720 <p><i>[
26721 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
26722 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
26723 has always been the intention of the committee. We believe that the
26724 proposed wording doesn't accomplish that. Proposed Disposition: Open
26725 ]</i></p>
26726
26727
26728
26729
26730
26731 <hr>
26732 <h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
26733 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26734  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
26735 <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>
26736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26737 <p><b>Discussion:</b></p>
26738         <p>
26739
26740 The array forms of unformatted input functions don't have well-defined
26741 semantics for zero-element  arrays in a couple of  cases. The affected
26742 ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
26743 terminate when <tt>(n - 1)</tt> characters are stored, which obviously
26744 can never be true when <tt>(n == 0)</tt> to start with.
26745
26746         </p>
26747
26748
26749 <p><b>Proposed resolution:</b></p>
26750         <p>
26751
26752 I  propose  the following  changes  (references  are  relative to  the
26753 Working Draft (document N1804).
26754
26755         </p>
26756         <p>
26757
26758 Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
26759
26760         </p>
26761         <blockquote>
26762             <p>
26763
26764 <ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
26765 characters are stored;
26766
26767             </p>
26768         </blockquote>
26769         <p>
26770
26771 Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
26772 3 as follows:
26773
26774         </p>
26775         <blockquote>
26776             <p>
26777
26778 <ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
26779 are     stored     (in    which     case     the    function     calls
26780 <tt>setstate(failbit)</tt>).
26781
26782             </p>
26783         </blockquote>
26784         <p>
26785
26786 Finally, change p21 as follows:
26787
26788         </p>
26789         <blockquote>
26790             <p>
26791
26792 In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
26793 stores  a null  character  (using charT())  into  the next  successive
26794 location of the array.
26795
26796             </p>
26797         </blockquote>
26798
26799
26800
26801
26802
26803 <hr>
26804 <h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
26805 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26806  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-25 <b>Last modified:</b> 2010-10-29</p>
26807 <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>
26808 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26809 <p><b>Discussion:</b></p>
26810         <p>
26811
26812 Issue  60 explicitly made  the extractor  and inserter  operators that
26813 take a  <tt>basic_streambuf*</tt> argument formatted  input and output
26814 functions,  respectively.  I  believe that's  wrong, certainly  in the
26815 case of  the extractor, since formatted functions  begin by extracting
26816 and  discarding  whitespace.  The  extractor  should  not discard  any
26817 characters.
26818
26819         </p>
26820
26821
26822 <p><b>Proposed resolution:</b></p>
26823         <p>
26824
26825 I propose to  change each operator to behave  as unformatted input and
26826 output function,  respectively. The changes below are  relative to the
26827 working draft document number N1804.
26828
26829         </p>
26830         <p>
26831
26832 Specifically, change 27.6.1.2.3, p14 as follows:
26833
26834         </p>
26835
26836             <blockquote>
26837         <p>
26838
26839 <i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
26840 (as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
26841 1</ins>).
26842
26843         </p>
26844             </blockquote>
26845         <p>
26846
26847 And change 27.6.2.5.3, p7 as follows:
26848
26849         </p>
26850
26851             <blockquote>
26852         <p>
26853
26854 <i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
26855 (as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
26856 1</ins>).
26857
26858         </p>
26859             </blockquote>
26860
26861
26862 <p><i>[
26863 Kona (2007): Proposed Disposition: Ready
26864 ]</i></p>
26865
26866
26867
26868
26869
26870 <hr>
26871 <h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
26872 <p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26873  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2006-04-18 <b>Last modified:</b> 2010-10-29</p>
26874 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
26875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26876 <p><b>Discussion:</b></p>
26877 <p>
26878 lib.iostream.objects requires that the standard stream objects are never
26879 destroyed, and it requires that they be destroyed.
26880 </p>
26881 <p>
26882 DR 369 adds words to say that we really mean for ios_base::Init objects to force
26883 construction of standard stream objects. It ends, though, with the phrase "these
26884 stream objects shall be destroyed after the destruction of dynamically ...".
26885 However, the rule for destruction is stated in the standard: "The objects are
26886 not destroyed during program execution."
26887 </p>
26888
26889
26890 <p><b>Proposed resolution:</b></p>
26891 <p>
26892 Change 27.4 [iostream.objects]/1:
26893 </p>
26894
26895 <blockquote>
26896 <p>
26897 -2- The objects are constructed and the associations are established at
26898 some time prior to or during the first time an object of class
26899 <tt>ios_base::Init</tt> is constructed, and in any case before the body of main
26900 begins execution.<sup>290)</sup> The objects are not destroyed during program
26901 execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
26902 constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
26903 constructed before dynamic initialization of non-local objects defined
26904 later in that translation unit<del>, and these stream objects shall be
26905 destroyed after the destruction of dynamically initialized non-local
26906 objects defined later in that translation unit</del>.
26907 </p>
26908 </blockquote>
26909
26910
26911 <p><i>[
26912 Kona (2007): From 27.4 [iostream.objects]/2, strike the words "...and these stream objects
26913 shall be destroyed after the destruction of dynamically initialized
26914 non-local objects defined later in that translation unit." Proposed
26915 Disposition: Review
26916 ]</i></p>
26917
26918
26919
26920
26921
26922 <hr>
26923 <h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
26924 <p><b>Section:</b> 20.9.10.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
26925  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-04-23 <b>Last modified:</b> 2010-10-29</p>
26926 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
26927 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26928 <p><b>Discussion:</b></p>
26929 <p>
26930 [tr.util.smartptr.shared.dest] says in its second bullet:
26931 </p>
26932
26933 <p>
26934 "If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
26935 decrements that instance's use count."
26936 </p>
26937
26938 <p>
26939 The problem with this formulation is that it presupposes the existence of an
26940 "use count" variable that can be decremented and that is part of the state of a
26941 shared_ptr instance (because of the "that instance's use count".)
26942 </p>
26943
26944 <p>
26945 This is contrary to the spirit of the rest of the specification that carefully
26946 avoids to require an use count variable. Instead, use_count() is specified to
26947 return a value, a number of instances.
26948 </p>
26949
26950 <p>
26951 In multithreaded code, the usual implicit assumption is that a shared variable
26952 should not be accessed by more than one thread without explicit synchronization,
26953 and by introducing the concept of an "use count" variable, the current wording
26954 implies that two shared_ptr instances that share ownership cannot be destroyed
26955 simultaneously.
26956 </p>
26957
26958 <p>
26959 In addition, if we allow the interpretation that an use count variable is part
26960 of shared_ptr's state, this would lead to other undesirable consequences WRT
26961 multiple threads. For example,
26962 </p>
26963
26964 <blockquote><pre>p1 = p2;
26965 </pre></blockquote>
26966
26967 <p>
26968 would now visibly modify the state of p2, a "write" operation, requiring a lock.
26969 </p>
26970
26971
26972 <p><b>Proposed resolution:</b></p>
26973 <p>
26974 Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
26975 </p>
26976
26977 <blockquote>
26978 <ul>
26979 <li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
26980 <tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
26981 <li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
26982 (<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
26983 </ul>
26984 </blockquote>
26985
26986 <p>
26987 Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
26988 </p>
26989
26990 <blockquote><p>
26991 [<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
26992 <tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
26993 with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
26994 after <tt>*this</tt> is destroyed. <i>--end note</i>]
26995 </p></blockquote>
26996
26997
26998
26999
27000
27001 <hr>
27002 <h3><a name="576"></a>576. find_first_of is overconstrained</h3>
27003 <p><b>Section:</b> 25.2.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27004  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2006-04-25 <b>Last modified:</b> 2010-10-29</p>
27005 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
27006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27007 <p><b>Discussion:</b></p>
27008 <p>
27009 In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
27010 find_first_of are specified to require Forward Iterators, as follows:
27011 </p>
27012
27013 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
27014   ForwardIterator1
27015   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
27016                         ForwardIterator2 first2, ForwardIterator2 last2);
27017 template&lt;class ForwardIterator1, class ForwardIterator2,
27018                   class BinaryPredicate&gt;
27019 ForwardIterator1
27020   find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
27021                          ForwardIterator2 first2, ForwardIterator2 last2,
27022                         BinaryPredicate pred);
27023 </pre></blockquote>
27024
27025 <p>
27026 However, ForwardIterator1 need not actually be a Forward Iterator; an Input
27027 Iterator suffices, because we do not need the multi-pass property of the Forward
27028 Iterator or a true reference.
27029 </p>
27030
27031
27032 <p><b>Proposed resolution:</b></p>
27033 <p>
27034 Change the declarations of <tt>find_first_of</tt> to:
27035 </p>
27036
27037 <blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
27038   <del>ForwardIterator1</del><ins>InputIterator1</ins>
27039   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
27040                         ForwardIterator2 first2, ForwardIterator2 last2);
27041 template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
27042                   class BinaryPredicate&gt;
27043 <del>ForwardIterator1</del><ins>InputIterator1</ins>
27044   find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
27045                          ForwardIterator2 first2, ForwardIterator2 last2,
27046                         BinaryPredicate pred);
27047 </pre></blockquote>
27048
27049
27050
27051
27052
27053
27054 <hr>
27055 <h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
27056 <p><b>Section:</b> 25.4.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27057  <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-05-03 <b>Last modified:</b> 2010-10-29</p>
27058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27059 <p><b>Discussion:</b></p>
27060 <p>
27061 ISO/IEC 14882:2003 says:
27062 </p>
27063
27064 <blockquote>
27065 <p>
27066 25.3.3.2 upper_bound
27067 </p>
27068 <p>
27069 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
27070 <tt>[<i>first</i>, <i>last</i>)</tt> such that
27071 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
27072 conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
27073 </p>
27074 </blockquote>
27075
27076 <p>
27077 From the description above, upper_bound cannot return last, since it's
27078 not in the interval [first, last). This seems to be a typo, because if
27079 value is greater than or equal to any other values in the range, or if
27080 the range is empty, returning last seems to be the intended behaviour.
27081 The corresponding interval for lower_bound is also [first, last].
27082 </p>
27083
27084
27085 <p><b>Proposed resolution:</b></p>
27086 <p>
27087 Change [lib.upper.bound]:
27088 </p>
27089
27090 <blockquote>
27091 <p>
27092 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
27093 <tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
27094 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
27095 conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
27096 </p>
27097 </blockquote>
27098
27099
27100
27101
27102
27103
27104 <hr>
27105 <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
27106 <p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27107  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-17 <b>Last modified:</b> 2010-10-29</p>
27108 <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>
27109 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27110 <p><b>Discussion:</b></p>
27111         <p>
27112
27113 The     description    of     the     allocator    member     function
27114 <code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
27115 either 0 or a  value previously returned from <code>allocate()</code>.
27116 Footnote 227 further suggests that  containers may pass the address of
27117 an adjacent element as this argument.
27118
27119         </p>
27120         <p>
27121
27122 I  believe  that  either  the  footnote  is  wrong  or  the  normative
27123 requirement that  the argument be  a value previously returned  from a
27124 call to  <code>allocate()</code> is wrong. The latter  is supported by
27125 the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
27126 Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
27127 <code>pointer</code>  type returned  by  <code>allocate()</code>, with
27128 the  two  types potentially  being  incompatible  and the  requirement
27129 impossible to satisfy.
27130
27131         </p>
27132         <p>
27133
27134 See also c++std-lib-14323 for some  more context on where this came up
27135 (again).
27136
27137         </p>
27138     
27139
27140     <p><b>Proposed resolution:</b></p>
27141         <p>
27142
27143 Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
27144 previously returned from <code>allocate()</code>. Specifically, change
27145 the paragraph as follows:
27146
27147         </p>
27148 <p>
27149 <del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
27150 <code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
27151 The value hint may be used by an implementation to help improve performance
27152 <sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
27153 implementation to help improve performance. -- <i>end note</i>]</ins>
27154 </p>
27155 <blockquote><p>
27156 <del>[Footnote: <sup>223)</sup>In a container member function, the address of an
27157 adjacent element is often a good choice to pass for this argument.</del>
27158 </p></blockquote>
27159     
27160
27161
27162
27163 <hr>
27164 <h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
27165 <p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27166  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2010-10-29</p>
27167 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
27168 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27169 <p><b>Discussion:</b></p>
27170         <p>
27171
27172 The resolution of issue 60 changed <code>basic_ostream::flush()</code>
27173 so as not  to require it to behave as  an unformatted output function.
27174 That has at least two in my opinion problematic consequences:
27175
27176         </p>
27177         <p>
27178
27179 First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
27180 unconditionally, without  regard to the  state of the stream.  I can't
27181 think of any reason why <code>flush()</code> should behave differently
27182 from the vast majority of stream functions in this respect.
27183
27184         </p>
27185         <p>
27186
27187 Second, <code>flush()</code> is not  required to catch exceptions from
27188 <code>pubsync()</code> or set  <code>badbit</code> in response to such
27189 events. That doesn't seem right either, as most other stream functions
27190 do so.
27191
27192         </p>
27193     
27194
27195     <p><b>Proposed resolution:</b></p>
27196         <p>
27197
27198 I  propose  to revert  the  resolution of  issue  60  with respect  to
27199 <code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
27200 as follows:
27201
27202         </p>
27203
27204 <p>
27205 Effects: <ins>Behaves as an  unformatted output function (as described
27206 in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
27207 pointer,  <ins>constructs a  sentry  object.  If  this object  returns
27208 <code>true</code> when converted to a  value of type bool the function
27209 </ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
27210 -1    calls    <code>setstate(badbit)</code>    (which    may    throw
27211 <code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
27212 sentry object returns <code>false</code>, does nothing.</ins><del>Does
27213 not  behave  as  an  unformatted  output  function  (as  described  in
27214 27.6.2.6, paragraph 1).</del>
27215 </p>
27216
27217     
27218
27219 <p><i>[
27220 Kona (2007): Proposed Disposition: Ready
27221 ]</i></p>
27222
27223
27224
27225
27226
27227 <hr>
27228 <h3><a name="586"></a>586. string inserter not a formatted function</h3>
27229 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27230  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2010-10-29</p>
27231 <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>
27232 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27233 <p><b>Discussion:</b></p>
27234         <p>
27235
27236 Section  and paragraph  numbers  in  this paper  are  relative to  the
27237 working draft document number N2009 from 4/21/2006.
27238
27239         </p>
27240
27241         <p>
27242
27243 The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
27244 required  to  behave  as  a   formatted  input  function,  as  is  the
27245 <code>std::getline()</code> overload for string described in p7.
27246
27247         </p>
27248         <p>
27249
27250 However, the <code>basic_string</code> inserter described in p5 of the
27251 same section has no such requirement. This has implications on how the
27252 operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
27253 (formatted  output functions are  required to  set <code>badbit</code>
27254 and swallow  the exception unless  <code>badbit</code> is also  set in
27255 <code>exceptions()</code>; the  string inserter doesn't  have any such
27256 requirement).
27257
27258         </p>
27259         <p>
27260
27261 I don't  see anything in the  spec for the string  inserter that would
27262 justify requiring  it to treat  exceptions differently from  all other
27263 similar operators. (If it did, I think it should be made this explicit
27264 by saying  that the  operator "does not  behave as a  formatted output
27265 function" as has been made customary by the adoption of the resolution
27266 of issue 60).
27267
27268         </p>
27269     
27270
27271     <p><b>Proposed resolution:</b></p>
27272         <p>
27273
27274 I propose to change the Effects clause in 21.3.7.9, p5, as follows:
27275
27276         </p>
27277             <blockquote>
27278         <p>
27279
27280 <i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
27281 were    constructed    by    typename    <code>basic_ostream&lt;charT,
27282 traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
27283 <code>true</code>, </del><ins>Behaves  as a formatted  output function
27284 (27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
27285 this  object returns <code>true</code>  when converted  to a  value of
27286 type   <code>bool</code>,   determines   padding   as   described   in
27287 22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
27288 <code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
27289 n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
27290 <code>os.width()</code>   and   <code>str.size()</code>;  then   calls
27291 <code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
27292 <code>os.setstate(ios_base::failbit)</code>.</del>
27293
27294         </p>
27295             </blockquote>
27296         <p>
27297
27298 This proposed  resilution assumes the  resolution of issue  394 (i.e.,
27299 that   all   formatted   output   functions  are   required   to   set
27300 <code>ios_base::badbit</code>  in response  to any  kind  of streambuf
27301 failure),   and   implicitly   assumes   that  a   return   value   of
27302 <code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
27303 indicates a failure.
27304
27305         </p>
27306     
27307
27308
27309
27310 <hr>
27311 <h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
27312 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27313  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-08-02 <b>Last modified:</b> 2010-10-29</p>
27314 <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>
27315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27316 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
27317 <p><b>Discussion:</b></p>
27318 <p>
27319 There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
27320 terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
27321 (requires InputIterator::value_type be the same type as the container's value_type).
27322 </p>
27323
27324
27325 <p><b>Proposed resolution:</b></p>
27326 <p>
27327 Change 23.1.1 p3:
27328 </p>
27329
27330 <blockquote><p>
27331 In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
27332 value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
27333 iterator requirements <ins>and refer to elements <ins>implicitly
27334 convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
27335 range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
27336 valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
27337 iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
27338 and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
27339 </p></blockquote>
27340
27341 <p>
27342 Change 23.1.2 p7:
27343 </p>
27344
27345 <blockquote><p>
27346 In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
27347 of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
27348 unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
27349 multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
27350 refer to elements <del>of</del> <ins>implicitly convertible to</ins>
27351 <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
27352 iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
27353 <tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
27354 value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
27355 and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
27356 </p></blockquote>
27357
27358
27359
27360 <p><b>Rationale:</b></p>
27361 <p>
27362 Concepts will probably come in and rewrite this section anyway.  But just in case it is
27363 easy to fix this up as a safety net and as a clear statement of intent.
27364 </p>
27365
27366
27367
27368
27369
27370 <hr>
27371 <h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
27372 <p><b>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27373  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2006-08-28 <b>Last modified:</b> 2010-10-29</p>
27374 <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>
27375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27376 <p><b>Discussion:</b></p>
27377 <p>
27378 Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
27379 &lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
27380 &lt;stdint.h&gt;, and were part of TR1.
27381 </p>
27382
27383 <p>
27384 Per 18.3.1/1, these headers define a number of macros and function macros. 
27385 While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
27386 footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
27387 header defines all ... macros the same as C99 subclause 7.18."
27388 </p>
27389
27390 <p>
27391 Therefore, if I wish to have the above-referenced macros and function macros
27392 defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
27393 does the C++ header define these macros/function macros unconditionally?
27394 </p>
27395
27396
27397 <p><b>Proposed resolution:</b></p>
27398 <p>
27399 To put this issue to rest for C++0X, I propose the following addition to 
27400 18.3.1/2 of the Working Paper N2009:
27401 </p>
27402
27403 <blockquote><p>
27404 [Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
27405 particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
27406 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
27407 </p></blockquote>
27408
27409
27410
27411
27412
27413 <hr>
27414 <h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
27415 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
27416  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-11-19</p>
27417 <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>
27418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
27419 <p><b>Discussion:</b></p>
27420
27421 <p>
27422 It seems undesirable to define the Swappable requirement in terms of
27423 CopyConstructible and Assignable requirements. And likewise, once the
27424 MoveConstructible and MoveAssignable requirements (N1860) have made it
27425 into the Working Draft, it seems undesirable to define the Swappable
27426 requirement in terms of those requirements. Instead, it appears
27427 preferable to have the Swappable requirement defined exclusively in
27428 terms of the existence of an appropriate swap function.
27429 </p>
27430
27431 <p>
27432 Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
27433 says:
27434 </p>
27435
27436 <blockquote><p>
27437 The Swappable requirement is met by satisfying one or more of the
27438 following conditions:</p>
27439 <ul>
27440 <li>
27441 T is Swappable if T satisfies the CopyConstructible requirements
27442 (20.1.3) and the Assignable requirements (23.1);
27443 </li>
27444 <li>
27445 T is Swappable if a namespace scope function named swap exists in the
27446 same namespace as the definition of T, such that the expression
27447 swap(t,u) is valid and has the semantics described in Table 33.
27448 </li>
27449 </ul>
27450 </blockquote>
27451
27452 <p>
27453 I can think of three disadvantages of this definition:
27454 </p>
27455
27456 <ol>
27457 <li>
27458 <p>
27459 If a client's type T satisfies the first condition (T is both
27460 CopyConstructible and Assignable), the client cannot stop T from
27461 satisfying the Swappable requirement without stopping T from
27462 satisfying the first condition.
27463 </p>
27464 <p>
27465 A client might want to stop T from satisfying the Swappable
27466 requirement, because swapping by means of copy construction and
27467 assignment might throw an exception, and she might find a throwing
27468 swap unacceptable for her type. On the other hand, she might not feel
27469 the need to fully implement her own swap function for this type. In
27470 this case she would want to be able to simply prevent algorithms that
27471 would swap objects of type T from being used, e.g., by declaring a
27472 swap function for T, and leaving this function purposely undefined.
27473 This would trigger a link error, if an attempt would be made to use
27474 such an algorithm for this type. For most standard library
27475 implementations, this practice would indeed have the effect of
27476 stopping T from satisfying the Swappable requirement.
27477 </p>
27478 </li>
27479 <li>
27480 <p>
27481 A client's type T that does not satisfy the first condition can not be
27482 made Swappable by providing a specialization of std::swap for T.
27483 </p>
27484 <p>
27485 While I'm aware about the fact that people have mixed feelings about
27486 providing a specialization of std::swap, it is well-defined to do so.
27487 It sounds rather counter-intuitive to say that T is not Swappable, if
27488 it has a valid and semantically correct specialization of std::swap.
27489 Also in practice, providing such a specialization will have the same
27490 effect as satisfying the Swappable requirement.
27491 </p>
27492 </li>
27493 <li>
27494 <p>
27495 For a client's type T that satisfies both conditions of the Swappable
27496 requirement, it is not specified which of the two conditions prevails.
27497 After reading section 20.1.4 [lib.swappable], one might wonder whether
27498 objects of T will be swapped by doing copy construction and
27499 assignments, or by calling the swap function of T.
27500 </p>
27501 <p>
27502 I'm aware that the intention of the Draft is to prefer calling the
27503 swap function of T over doing copy construction and assignments. Still
27504 in my opinion, it would be better to make this clear in the wording of
27505 the definition of Swappable. 
27506 </p>
27507 </li>
27508 </ol>
27509
27510 <p>
27511 I would like to have the Swappable requirement defined in such a way
27512 that the following code fragment will correctly swap two objects of a
27513 type T, if and only if T is Swappable:
27514 </p>
27515
27516 <pre>   using std::swap;
27517    swap(t, u);  // t and u are of type T.
27518 </pre>
27519
27520 <p>
27521 This is also the way Scott Meyers recommends calling a swap function,
27522 in Effective C++, Third Edition, item 25.
27523 </p>
27524
27525 <p>
27526 Most aspects of this issue have been dealt with in a discussion on
27527 comp.std.c++ about the Swappable requirement, from 13 September to 4
27528 October 2006, including valuable input by David Abrahams, Pete Becker,
27529 Greg Herlihy, Howard Hinnant and others.
27530 </p>
27531
27532 <p><i>[
27533 San Francisco:
27534 ]</i></p>
27535
27536
27537 <blockquote>
27538 Recommend NAD.  Solved by
27539 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>.
27540 </blockquote>
27541
27542 <p><i>[
27543 2009-07 Frankfurt
27544 ]</i></p>
27545
27546
27547 <blockquote>
27548 Moved to Open.  Waiting for non-concepts draft.
27549 </blockquote>
27550
27551 <p><i>[
27552 2009-11-08 Howard adds:
27553 ]</i></p>
27554
27555
27556 <blockquote>
27557 This issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>.
27558 </blockquote>
27559
27560 <p><i>[
27561 2010-02-03 Sean Hunt adds:
27562 ]</i></p>
27563
27564
27565 <blockquote>
27566 <p>
27567 While reading N3000, I independently came across Issue 594. Having seen that
27568 it's an issue under discussion, I think the proposed wording needs fixing to
27569 something more like "...function call swap(t,u) that includes std::swap in its
27570 overload set is valid...", because "...is valid within the namespace std..."
27571 does not allow other libraries to simply use the Swappable requirement by
27572 referring to the standard's definition, since they cannot actually perform any
27573 calls within std.
27574 </p>
27575
27576 <p>
27577 This wording I suggested would also make overloads visible in the same scope as
27578 the `using std::swap` valid for Swappable requirements; a more complex wording
27579 limiting the non-ADL overload set to std::swap might be required.
27580 </p>
27581 </blockquote>
27582
27583 <p><i>[
27584 2010 Pittsburgh:
27585 ]</i></p>
27586
27587
27588 <blockquote>
27589 Moved to NAD Editorial.  Rationale added.
27590 </blockquote>
27591
27592
27593
27594 <p><b>Rationale:</b></p>
27595 <p>
27596 Solved by N3048.
27597 </p>
27598
27599
27600 <p><b>Proposed resolution:</b></p>
27601 <p>
27602 Change section 20.1.4 [lib.swappable] as follows:
27603 </p>
27604 <blockquote><p>
27605 The Swappable requirement is met by satisfying
27606 <del>one or more of the following conditions:</del>
27607 <ins>the following condition:</ins></p>
27608 <ul>
27609
27610 <li>
27611 <del>T is Swappable if T satisfies the CopyConstructible requirements
27612 (20.1.3) and the Assignable requirements (23.1);</del>
27613 </li>
27614 <li>
27615 <del>
27616 T is Swappable if a namespace scope function named swap exists in the
27617 same namespace as the definition of T, such that the expression
27618 swap(t,u) is valid and has the semantics described in Table 33.
27619 </del>
27620 T is Swappable if an unqualified function call swap(t,u) is valid
27621 within the namespace std, and has the semantics described in Table 33.
27622 </li>
27623 </ul>
27624 </blockquote>
27625
27626
27627
27628
27629
27630 <hr>
27631 <h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
27632 <p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27633  <b>Submitter:</b> Stefan Große Pawig <b>Opened:</b> 2006-09-24 <b>Last modified:</b> 2010-10-29</p>
27634 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
27635 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27636 <p><b>Discussion:</b></p>
27637 <p>
27638 TR1 introduced, in the C compatibility chapter, the function
27639 fabs(complex&lt;T&gt;):
27640 </p>
27641 <blockquote><pre>----- SNIP -----
27642 8.1.1 Synopsis                                [tr.c99.cmplx.syn]
27643
27644   namespace std {
27645   namespace tr1 {
27646 [...]
27647   template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
27648   } // namespace tr1
27649   } // namespace std
27650
27651 [...]
27652
27653 8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
27654
27655 1 Effects: Behaves the same as C99 function cabs, defined in
27656   subclause 7.3.8.1.
27657 ----- SNIP -----
27658 </pre></blockquote>
27659
27660 <p>
27661 The current C++0X draft document (n2009.pdf) adopted this
27662 definition in chapter 26.3.1 (under the comment // 26.3.7 values)
27663 and 26.3.7/7.
27664 </p>
27665 <p>
27666 But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
27667 n1124), the referenced subclause reads
27668 </p>
27669
27670 <blockquote><pre>----- SNIP -----
27671 7.3.8.1 The cabs functions
27672
27673   Synopsis
27674
27675 1 #include &lt;complex.h&gt;
27676   double cabs(double complex z);
27677   float cabsf(float complex z);
27678   long double cabsl(long double z);
27679
27680   Description
27681
27682 2 The cabs functions compute the complex absolute value (also called
27683   norm, modulus, or magnitude) of z.
27684
27685   Returns
27686
27687 3 The cabs functions return the complex absolute value.
27688 ----- SNIP -----
27689 </pre></blockquote>
27690
27691 <p>
27692 Note that the return type of the cabs*() functions is not a complex
27693 type.  Thus, they are equivalent to the already well established
27694   template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
27695 (26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
27696 document n2009.pdf).
27697 </p>
27698 <p>
27699 So either the return value of fabs() is specified wrongly, or fabs()
27700 does not behave the same as C99's cabs*().
27701 </p>
27702
27703 <b>Possible Resolutions</b>
27704
27705 <p>
27706 This depends on the intention behind the introduction of fabs().
27707 </p>
27708 <p>
27709 If the intention was to provide a /complex/ valued function that
27710 calculates the magnitude of its argument, this should be
27711 explicitly specified.  In TR1, the categorization under "C
27712 compatibility" is definitely wrong, since C99 does not provide
27713 such a complex valued function.
27714 </p>
27715 <p>
27716 Also, it remains questionable if such a complex valued function
27717 is really needed, since complex&lt;T&gt; supports construction and
27718 assignment from real valued arguments.  There is no difference
27719 in observable behaviour between
27720 </p>
27721 <blockquote><pre>  complex&lt;double&gt; x, y;
27722   y = fabs(x);
27723   complex&lt;double&gt; z(fabs(x));
27724 </pre></blockquote>
27725 <p>
27726 and
27727 </p>
27728 <blockquote><pre>  complex&lt;double&gt; x, y;
27729   y = abs(x);
27730   complex&lt;double&gt; z(abs(x));
27731 </pre></blockquote>
27732 <p>
27733 If on the other hand the intention was to provide the intended
27734 functionality of C99, fabs() should be either declared deprecated
27735 or (for C++0X) removed from the standard, since the functionality
27736 is already provided by the corresponding overloads of abs().
27737 </p>
27738
27739 <p><i>[
27740 Bellevue:
27741 ]</i></p>
27742
27743
27744 <blockquote>
27745 Bill believes that abs() is a suitable overload. We should remove fabs().
27746 </blockquote>
27747
27748
27749 <p><b>Proposed resolution:</b></p>
27750
27751 <p>
27752 Change the synopsis in 26.4.1 [complex.syn]:
27753 </p>
27754
27755 <blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
27756 </pre></blockquote>
27757
27758 <p>
27759 Remove 26.4.7 [complex.value.ops], p7:
27760 </p>
27761
27762 <blockquote>
27763 <pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
27764 </pre>
27765 <blockquote>
27766 <p>
27767 <del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
27768 </p>
27769 </blockquote>
27770 </blockquote>
27771
27772
27773
27774 <p><i>[
27775 Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
27776 Proposed Disposition: Ready
27777 ]</i></p>
27778
27779
27780
27781
27782
27783 <hr>
27784 <h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
27785 <p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27786  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2006-09-26 <b>Last modified:</b> 2010-10-29</p>
27787 <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>
27788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27789 <p><b>Discussion:</b></p>
27790 <p>
27791 In testing 27.9.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
27792 </p>
27793 <blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
27794 </pre></blockquote>
27795 <p>
27796 and we expect the open to fail, because out|in|app is not listed in
27797 Table 92, and just before the table we see very specific words:
27798 </p>
27799 <blockquote><p>
27800   If mode is not some combination of flags shown in the table 
27801   then the open fails.
27802 </p></blockquote>
27803 <p>
27804 But the corresponding table in the C standard, 7.19.5.3, provides two
27805 modes "a+" and "a+b", to which the C++ modes out|in|app and
27806 out|in|app|binary would presumably apply.
27807 </p>
27808 <p>
27809 We would like to argue that the intent of Table 112 was to match the
27810 semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
27811 unintentional.  (Otherwise there would be valid and useful behaviors
27812 available in C file I/O which are unavailable using C++, for no
27813 valid functional reason.)
27814 </p>
27815 <p>
27816 We further request that the missing modes be explicitly restored to
27817 the WP, for inclusion in C++0x.
27818 </p>
27819
27820 <p><i>[
27821 Martin adds:
27822 ]</i></p>
27823
27824
27825 <p>
27826 ...besides "a+" and "a+b" the C++ table is also missing a row
27827 for a lone app bit which in at least two current implementation
27828 as well as in Classic Iostreams corresponds to the C stdio "a"
27829 mode and has been traditionally documented as implying ios::out.
27830 Which means the table should also have a row for in|app meaning
27831 the same thing as "a+" already proposed in the issue.
27832 </p>
27833
27834
27835 <p><b>Proposed resolution:</b></p>
27836 <p>
27837 Add to the table "File open modes" in 27.9.1.4 [filebuf.members]:
27838 </p>
27839
27840 <blockquote>
27841 <table border="1">
27842 <caption> File open modes</caption>
27843 <tbody><tr>
27844 <th colspan="5"><tt>ios_base</tt> Flag combination</th>
27845 <th><tt>stdio</tt> equivalent</th>
27846 </tr>
27847 <tr>
27848 <th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
27849 </tr>
27850
27851 <tr>
27852 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
27853 </tr>
27854 <tr>
27855 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
27856 </tr>
27857 <tr>
27858 <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
27859 </tr>
27860 <tr>
27861 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
27862 </tr>
27863 <tr>
27864 <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
27865 </tr>
27866 <tr>
27867 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
27868 </tr>
27869 <tr>
27870 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
27871 </tr>
27872 <tr>
27873 <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
27874 </tr>
27875 <tr>
27876 <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
27877 </tr>
27878
27879 <tr>
27880 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
27881 </tr>
27882 <tr>
27883 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
27884 </tr>
27885 <tr>
27886 <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
27887 </tr>
27888 <tr>
27889 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
27890 </tr>
27891 <tr>
27892 <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
27893 </tr>
27894 <tr>
27895 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
27896 </tr>
27897 <tr>
27898 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
27899 </tr><tr>
27900 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
27901 </tr>
27902 <tr>
27903 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
27904 </tr>
27905
27906
27907 </tbody></table>
27908 </blockquote>
27909
27910
27911
27912 <p><i>[
27913 Kona (2007) Added proposed wording and moved to Review.
27914 ]</i></p>
27915
27916
27917
27918
27919
27920 <hr>
27921 <h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
27922 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
27923  <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
27924 <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>
27925 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
27926 <p><b>Discussion:</b></p>
27927
27928 <p>
27929 In a private email, Daniel writes:
27930 </p>
27931 <blockquote>
27932 <p>
27933 I would like to 
27934 ask, what where the reason for the decision to 
27935 define the semantics of the integral conversion of the decimal types, namely
27936 </p>
27937 <pre>"operator long long() const;
27938
27939      Returns: Returns the result of the 
27940 conversion of *this to the type long long, as if 
27941 performed by the expression llrounddXX(*this)."
27942 </pre>
27943 <p>
27944 where XX stands for either 32, 64, or 128, 
27945 corresponding to the proper decimal type. The 
27946 exact meaning of llrounddXX is not given in that 
27947 paper, so I compared it to the corresponding 
27948 definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
27949 </p>
27950 <p>
27951 "The lround and llround functions round their 
27952 argument to the nearest integer value,
27953 rounding halfway cases away from zero, regardless 
27954 of the current rounding direction. [..]"
27955 </p>
27956 <p>
27957 Now considering the fact that integral conversion 
27958 of the usual floating-point types ("4.9 
27959 Floating-integral conversions") has truncation 
27960 semantic I wonder why this conversion behaviour 
27961 has not been transferred for the decimal types. 
27962 </p>
27963 </blockquote>
27964 <p>
27965 Robert comments:
27966 </p>
27967 <p>
27968 Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
27969 </p>
27970
27971
27972
27973 <p><b>Proposed resolution:</b></p>
27974 <p>
27975 Change the <b>Returns:</b> clause in 3.2.2.4 to:
27976 </p>
27977 <blockquote><p>
27978 <b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
27979 </p></blockquote>
27980 <p>
27981 Change the <b>Returns:</b> clause in 3.2.3.4 to:
27982 </p>
27983 <blockquote><p>
27984 <b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
27985 </p></blockquote>
27986 <p>
27987 Change the <b>Returns:</b> clause in 3.2.4.4 to:
27988 </p>
27989 <blockquote><p>
27990 <b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
27991 </p></blockquote>
27992
27993
27994
27995
27996
27997
27998 <hr>
27999 <h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
28000 <p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28001  <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28003 <p><b>Discussion:</b></p>
28004 <p>
28005 Daniel writes in a private email:
28006 </p>
28007
28008 <blockquote>
28009 <p>
28010 - 3.1 'Decimal type encodings' says in its note:
28011 </p>
28012 <pre>"this implies that 
28013 sizeof(std::decimal::decimal32) == 4, 
28014 sizeof(std::decimal::decimal64) == 8, and 
28015 sizeof(std::decimal::decimal128) == 16."
28016 </pre>
28017 <p>
28018 This is a wrong assertion, because the definition 
28019 of 'byte' in 1.7 'The C+ + memory model' of ISO 
28020 14882 (2nd edition) does not specify that a byte 
28021 must be necessarily 8 bits large, which would be 
28022 necessary to compare with the specified bit sizes 
28023 of the types decimal32, decimal64, and decimal128.
28024 </p>
28025 </blockquote>
28026
28027
28028 <p><b>Proposed resolution:</b></p>
28029 <p>
28030 Change 3.1 as follows:
28031 </p>
28032 <blockquote>
28033 <p>
28034 The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
28035 </p>
28036 <ul>
28037 <li>
28038 decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
28039 </li>
28040 <li>
28041 decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
28042
28043 </li>
28044 <li>
28045 decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
28046 </li>
28047 </ul>
28048 <p>
28049 <del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
28050 </p>
28051 </blockquote>
28052
28053
28054
28055
28056 <hr>
28057 <h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
28058 <p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28059  <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28060 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28061 <p><b>Discussion:</b></p>
28062 <p>
28063 Daniel writes:
28064 </p>
28065 <blockquote><p>
28066 - 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong 
28067 signatures to the wcstod32, wcstod64, and 
28068 wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
28069 </p></blockquote>
28070
28071
28072 <p><b>Proposed resolution:</b></p>
28073 <p>
28074 Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
28075 </p>
28076 <pre>       namespace std {
28077        namespace decimal {
28078          // 3.9.2 wcstod functions:
28079          decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
28080          decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
28081          decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
28082        }
28083        }
28084 </pre>
28085
28086
28087
28088
28089 <hr>
28090 <h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
28091 <p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28092  <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28094 <p><b>Discussion:</b></p>
28095 <p>
28096 Daniel writes in a private email:
28097 </p>
28098
28099 <blockquote>
28100 <p>
28101 - 3.3 'Additions to header &lt;limits&gt;' contains two 
28102 errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
28103 </p>
28104 <ol>
28105 <li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
28106 <li>The static member digits is assigned to 384,
28107 this should be 34 (Probably mixed up with the
28108 max. exponent for decimal::decimal64).</li>
28109 </ol>
28110 </blockquote>
28111
28112
28113 <p><b>Proposed resolution:</b></p>
28114 <p>
28115 In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
28116 </p>
28117 <pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
28118           public:
28119             static const bool is_specialized = true;
28120
28121             static decimal::decimal128 min() throw() { return DEC128_MIN; }
28122             static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
28123
28124             static const int digits       = <del>384</del> <ins>34</ins>;
28125             /* ... */
28126 </pre>
28127
28128
28129
28130
28131 <hr>
28132 <h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
28133 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28134  <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28135 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
28136 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28137 <p><b>Discussion:</b></p>
28138 <p>
28139 The document uses the term "generic floating types," but defines it nowhere.
28140 </p>
28141
28142
28143 <p><b>Proposed resolution:</b></p>
28144 <p>
28145 Change the first paragraph of "3 Decimal floating-point types" as follows:
28146 </p>
28147 <blockquote><p>
28148 This Technical Report introduces three decimal floating-point types, named
28149 decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
28150 subset of the set of values of type decimal64; the set of values of the type
28151 decimal64 is a subset of the set of values of the type decimal128. Support for
28152 decimal128 is optional.  <ins>These types supplement the Standard C++ types
28153 <code>float</code>, <code>double</code>, and <code>long double</code>, which are
28154 collectively described as the <i>basic floating types</i></ins>.
28155 </p></blockquote>
28156
28157
28158
28159
28160 <hr>
28161 <h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
28162 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28163  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28164 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
28165 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28166 <p><b>Discussion:</b></p>
28167 <p>In c++std-lib-17198, Martin writes:</p>
28168
28169 <blockquote><p>
28170 Each of the three classes proposed in the paper (decimal32, decimal64,
28171 and decimal128) explicitly declares and specifies the semantics of its
28172 copy constructor, copy assignment operator, and destructor. Since the
28173 semantics of all three functions are identical to the trivial versions
28174 implicitly generated by the compiler in the absence of any declarations
28175 it is safe to drop them from the spec. This change would make the
28176 proposed classes consistent with other similar classes already in the
28177 standard (e.g., std::complex).
28178 </p></blockquote>
28179
28180
28181 <p><b>Proposed resolution:</b></p>
28182 <p>
28183 Change "3.2.2 Class <code>decimal32</code>" as follows:
28184 </p>
28185 <pre>      namespace std {
28186       namespace decimal {
28187         class decimal32 {
28188           public:
28189             // 3.2.2.1 construct/copy/destroy:
28190             decimal32();
28191             <del>decimal32(const decimal32 &amp; d32);</del>
28192             <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
28193             <del>~decimal32();</del>
28194             /* ... */
28195 </pre>
28196 <p>
28197 Change "3.2.2.1 construct/copy/destroy" as follows:
28198 </p>
28199 <pre>        decimal32();
28200
28201     Effects: Constructs an object of type decimal32 with the value 0;
28202
28203         <del>decimal32(const decimal32 &amp; d32);</del>
28204         <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
28205
28206     <del>Effects: Copies an object of type decimal32.</del>
28207
28208         <del>~decimal32();</del>
28209
28210     <del>Effects: Destroys an object of type decimal32.</del>
28211
28212 </pre>
28213 <p>
28214 Change "3.2.3 Class <code>decimal64</code>" as follows:
28215 </p>
28216 <pre>      namespace std {
28217       namespace decimal {
28218         class decimal64 {
28219           public:
28220             // 3.2.3.1 construct/copy/destroy:
28221             decimal64();
28222             <del>decimal64(const decimal64 &amp; d64);</del>
28223             <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
28224             <del>~decimal64();</del>
28225             /* ... */
28226 </pre>
28227 <p>
28228 Change "3.2.3.1 construct/copy/destroy" as follows:
28229 </p>
28230 <pre>        decimal64();
28231
28232     Effects: Constructs an object of type decimal64 with the value 0;
28233
28234         <del>decimal64(const decimal64 &amp; d64);</del>
28235         <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
28236
28237     <del>Effects: Copies an object of type decimal64.</del>
28238
28239         <del>~decimal64();</del>
28240
28241     <del>Effects: Destroys an object of type decimal64.</del>
28242
28243 </pre>
28244 <p>
28245 Change "3.2.4 Class <code>decimal128</code>" as follows:
28246 </p>
28247 <pre>      namespace std {
28248       namespace decimal {
28249         class decimal128 {
28250           public:
28251             // 3.2.4.1 construct/copy/destroy:
28252             decimal128();
28253             <del>decimal128(const decimal128 &amp; d128);</del>
28254             <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
28255             <del>~decimal128();</del>
28256             /* ... */
28257 </pre>
28258 <p>
28259 Change "3.2.4.1 construct/copy/destroy" as follows:
28260 </p>
28261 <pre>        decimal128();
28262
28263     Effects: Constructs an object of type decimal128 with the value 0;
28264
28265         <del>decimal128(const decimal128 &amp; d128);</del>
28266         <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
28267
28268     <del>Effects: Copies an object of type decimal128.</del>
28269
28270         <del>~decimal128();</del>
28271
28272     <del>Effects: Destroys an object of type decimal128.</del>
28273
28274 </pre>
28275
28276
28277
28278
28279 <hr>
28280 <h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
28281 <p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28282  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
28283 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
28284 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28285 <p><b>Discussion:</b></p>
28286 <p>
28287 In c++std-lib-17197, Martin writes:
28288 </p>
28289 <blockquote><p>
28290 The extended_num_get and extended_num_put facets are designed
28291 to store a reference to a num_get or num_put facet which the
28292 extended facets delegate the parsing and formatting of types
28293 other than decimal. One form of the extended facet's ctor (the
28294 default ctor and the size_t overload) obtains the reference
28295 from the global C++ locale while the other form takes this
28296 reference as an argument.
28297 </p></blockquote>
28298 <blockquote><p>
28299 The problem with storing a reference to a facet in another
28300 object (as opposed to storing the locale object in which the
28301 facet is installed) is that doing so bypasses the reference
28302 counting mechanism designed to prevent a facet that is still
28303 being referenced (i.e., one that is still installed in some
28304 locale) from being destroyed when another locale that contains
28305 it is destroyed. Separating a facet reference from the locale
28306 it comes from van make it cumbersome (and in some cases might
28307 even make it impossible) for programs to prevent invalidating
28308 the reference. (The danger of this design is highlighted in
28309 the paper.)
28310 </p></blockquote>
28311 <blockquote><p>
28312 This problem could be easily avoided by having the extended
28313 facets store a copy of the locale from which they would extract
28314 the base facet either at construction time or when needed. To
28315 make it possible, the forms of ctors of the extended facets that
28316 take a reference to the base facet would need to be changed to
28317 take a locale argument instead.
28318 </p></blockquote>
28319
28320
28321 <p><b>Proposed resolution:</b></p>
28322 <p>
28323 1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
28324 </p>
28325 <pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
28326
28327             /* ... */
28328
28329             <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
28330             <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
28331 </pre>
28332 <p>
28333 2. Change the description of the above constructor in 3.10.2.1:
28334 </p>
28335 <pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
28336
28337 </pre>
28338 <blockquote>
28339 <p>
28340 <b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
28341 </p>
28342 <pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
28343                 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
28344                 { /* ... */ }
28345
28346 </pre>
28347 <p>
28348 <del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
28349 </p>
28350 </blockquote>
28351 <p>
28352 3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
28353 </p>
28354 <blockquote><p>
28355 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 
28356 </p></blockquote>
28357 <p>
28358 4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
28359 </p>
28360 <pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
28361
28362             /* ... */
28363
28364             <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
28365             <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
28366 </pre>
28367 <p>
28368 5. Change the description of the above constructor in 3.10.3.1:
28369 </p>
28370 <pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
28371 </pre>
28372 <blockquote>
28373 <p>
28374 <b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
28375 </p>
28376 <pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
28377                 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
28378                 { /* ... */ }
28379
28380 </pre>
28381 <p>
28382 <del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
28383 </p>
28384 </blockquote>
28385 <p>
28386 6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
28387 </p>
28388 <blockquote><p>
28389 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 
28390 </p></blockquote>
28391
28392 <p><i>[
28393 Redmond:  We would prefer to rename "extended" to "decimal".
28394 ]</i></p>
28395
28396
28397
28398
28399
28400
28401 <hr>
28402 <h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
28403 <p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
28404  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2006-10-17 <b>Last modified:</b> 2010-10-29</p>
28405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
28406 <p><b>Discussion:</b></p>
28407 <p>
28408 In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header.  The contents of that header have been moved into &lt;float.h&gt;.  For the sake of C compatibility, we should make corresponding changes.
28409 </p>
28410
28411
28412 <p><b>Proposed resolution:</b></p>
28413 <p>
28414 1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
28415 </p>
28416 <p>
28417 2. Change the text of subclause 3.4 as follows:
28418 </p>
28419 <blockquote>
28420 <p>
28421 <del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
28422 </p>
28423 <p>
28424 <del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
28425 </p>
28426 <p>
28427 <ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code> is described in [tr.c99.floath]. These headers are extended by this Technical Report to define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
28428 </p>
28429 </blockquote>
28430 <p>
28431 3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
28432 </p>
28433 <p>
28434 4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
28435 </p>
28436 <p>
28437 5. Change the contents of 3.4.2 as follows:
28438 </p>
28439 <pre>      <del>#include &lt;cdecfloat&gt;</del>
28440
28441       // <i>C-compatibility convenience typedefs:</i>
28442
28443       typedef std::decimal::decimal32  _Decimal32;
28444       typedef std::decimal::decimal64  _Decimal64;
28445       typedef std::decimal::decimal128 _Decimal128;
28446 </pre>
28447
28448
28449
28450
28451
28452 <hr>
28453 <h3><a name="607"></a>607. Concern about short seed vectors</h3>
28454 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28455  <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2010-10-29</p>
28456 <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>
28457 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28458 <p><b>Discussion:</b></p>
28459 <p>
28460 Short seed vectors of 32-bit quantities all result in different states. However
28461 this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
28462 these two seeds
28463 </p>
28464
28465 <blockquote><pre>unsigned short seed = {1, 2, 3};
28466 unsigned short seed = {1, 2, 3, 0};
28467 </pre></blockquote>
28468
28469 <p>
28470 both pack to
28471 </p>
28472
28473 <blockquote><pre>unsigned seed = {0x20001, 0x3};
28474 </pre></blockquote>
28475
28476 <p>
28477 yielding the same state.
28478 </p>
28479
28480 <p>
28481 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
28482 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
28483 for some further discussion.
28484 </p>
28485
28486
28487 <p><b>Proposed resolution:</b></p>
28488 <p>
28489 Adopt the proposed resolution in
28490 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
28491 </p>
28492
28493
28494 <p><i>[
28495 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
28496 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
28497 ]</i></p>
28498
28499
28500
28501
28502
28503 <hr>
28504 <h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
28505 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28506  <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2010-10-29</p>
28507 <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>
28508 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28509 <p><b>Discussion:</b></p>
28510 <p>
28511 In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
28512 treatment of signed quantities is unclear. Better to spell it out.
28513 </p>
28514
28515 <p>
28516 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
28517 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
28518 for some further discussion.
28519 </p>
28520
28521
28522 <p><b>Proposed resolution:</b></p>
28523 <p>
28524 Adopt the proposed resolution in
28525 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
28526 </p>
28527
28528
28529 <p><i>[
28530 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
28531 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
28532 ]</i></p>
28533
28534
28535
28536
28537
28538 <hr>
28539 <h3><a name="609"></a>609. missing static const</h3>
28540 <p><b>Section:</b> 26.5.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28541  <b>Submitter:</b> Walter E. Brown <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-10-29</p>
28542 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28543 <p><b>Discussion:</b></p>
28544 <p>
28545 In preparing N2111, an error on my part resulted in the omission of the
28546 following line from the template synopsis in the cited section:
28547 </p>
28548
28549 <blockquote><pre>static const size_t word_size = w;
28550 </pre></blockquote>
28551
28552 <p>
28553 (This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
28554 </p>
28555
28556
28557 <p><b>Proposed resolution:</b></p>
28558 <p>
28559 Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
28560 </p>
28561
28562 <blockquote><pre>// engine characteristics
28563 <ins>static const size_t word_size = w;</ins>
28564 </pre></blockquote>
28565
28566 <p>
28567 and accept my apologies for the oversight.
28568 </p>
28569
28570
28571
28572
28573
28574 <hr>
28575 <h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
28576 <p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28577  <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-10-29</p>
28578 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
28579 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28580 <p><b>Discussion:</b></p>
28581 <p>
28582 My suggestion is that implementers of both tr1::function and its 
28583 official C++0x successor be explicitly encouraged (but not required) to 
28584 optimize for the cases mentioned above, i.e., function pointers and 
28585 small function objects.  They could do this by using a small internal 
28586 buffer akin to the buffer used by implementations of the small string 
28587 optimization.  (That would make this the small functor optimization -- 
28588 SFO :-})  The form of this encouragement could be a note in the standard 
28589 akin to footnote 214 of the current standard.
28590 </p>
28591
28592 <p>
28593 Dave Abrahams notes:
28594 </p>
28595
28596 <p>
28597 "shall not throw exceptions" should really be "nothing," both to be more
28598 grammatical and to be consistent with existing wording in the standard.
28599 </p>
28600
28601 <p>
28602 Doug Gregor comments: I think this is a good idea. Currently, implementations of
28603 tr1::function are required to have non-throwing constructors and assignment
28604 operators when the target function object is a function pointer or a
28605 reference_wrapper. The common case, however, is for a tr1::function to store
28606 either an empty function object or a member pointer + an object pointer.
28607 </p>
28608 <p>
28609 The function implementation in the upcoming Boost 1.34.0 uses the
28610 "SFO", so that the function objects for typical bind expressions like
28611 </p>
28612 <blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
28613 </pre></blockquote>
28614
28615 <p>
28616 do not require heap allocation when stored in a boost::function. I
28617 believe Dinkumware's implementation also performs this optimization.
28618 </p>
28619
28620
28621
28622 <p><b>Proposed resolution:</b></p>
28623 <p>
28624 Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
28625 </p>
28626
28627 <blockquote>
28628 <p>
28629 <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
28630 pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
28631 may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
28632 the stored function object.
28633 </p>
28634 <p>
28635 <ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
28636 allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
28637 is an object holding only a pointer or reference to an object and a member
28638 function pointer (a "bound member function").</ins>
28639 </p>
28640 </blockquote>
28641
28642
28643
28644
28645
28646 <hr>
28647 <h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
28648 <p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28649  <b>Submitter:</b> Nicola Musatti <b>Opened:</b> 2006-11-13 <b>Last modified:</b> 2010-10-29</p>
28650 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
28651 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28652 <p><b>Discussion:</b></p>
28653 <p>
28654 In the latest available draft standard 
28655 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
28656 § 17.4.3.6 [res.on.functions] states:
28657 </p>
28658
28659 <blockquote>
28660 <p>
28661 -1- In certain cases (replacement functions, handler functions, operations on
28662 types used to instantiate standard library template components), the C++
28663 Standard Library depends on components supplied by a C++ program. If these
28664 components do not meet their requirements, the Standard places no requirements
28665 on the implementation.
28666 </p>
28667
28668 <p>
28669 -2- In particular, the effects are undefined in the following cases:
28670 </p>
28671 <p>
28672 [...]
28673 </p>
28674 <ul>
28675 <li>if an incomplete type (3.9) is used as a template argument when
28676 instantiating a template component. </li>
28677 </ul>
28678 </blockquote>
28679
28680 <p>
28681 This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
28682 states:
28683 </p>
28684
28685 <blockquote>
28686 <p>
28687 [...]
28688 </p>
28689
28690 <p>
28691 The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
28692 </p>
28693 </blockquote>
28694
28695
28696 <p><b>Proposed resolution:</b></p>
28697 <p>
28698 Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
28699 exceptions:
28700 </p>
28701
28702 <blockquote>
28703 <ul>
28704 <li>if an incomplete type (3.9) is used as a template argument when
28705 instantiating a template component<ins>, unless specifically allowed for the
28706 component</ins>. </li>
28707 </ul>
28708 </blockquote>
28709
28710
28711
28712
28713
28714
28715 <hr>
28716 <h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
28717 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28718  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2006-11-10 <b>Last modified:</b> 2010-10-29</p>
28719 <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>
28720 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28721 <p><b>Discussion:</b></p>
28722 <p>
28723 18.2.1.2 55 states that "A type is modulo if it is possible to add two
28724 positive numbers together and have a result that wraps around to a
28725 third number that is less".
28726 This seems insufficient for the following reasons:
28727 </p>
28728
28729 <ol>
28730 <li>Doesn't define what that value received is.</li>
28731 <li>Doesn't state the result is repeatable</li>
28732 <li> Doesn't require that doing addition, subtraction and other
28733 operations on all values is defined behaviour.</li>
28734 </ol>
28735
28736 <p><i>[
28737 Batavia: Related to
28738 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
28739 Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
28740 ]</i></p>
28741
28742
28743 <p><i>[
28744 Bellevue:  accept resolution, move to ready status.
28745 Does this mandate that is_modulo be true on platforms for which int
28746 happens to b modulo? A: the standard already seems to require that.
28747 ]</i></p>
28748
28749
28750
28751 <p><b>Proposed resolution:</b></p>
28752 <p>
28753 Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to:
28754 </p>
28755
28756 <blockquote><p>
28757 A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
28758 and have a result that wraps around to a third number that is less.</del>
28759 <ins>given any operation involving +,- or * on values of that type whose value
28760 would fall outside the range <tt>[min(), max()]</tt>, then the value returned
28761 differs from the true value by an integer multiple of <tt>(max() - min() +
28762 1)</tt>.</ins>
28763 </p></blockquote>
28764
28765
28766
28767
28768
28769
28770 <hr>
28771 <h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
28772 <p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28773  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-11-20 <b>Last modified:</b> 2010-10-29</p>
28774 <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>
28775 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28776 <p><b>Discussion:</b></p>
28777 <p>
28778 Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided 
28779 for all specializations."
28780 </p>
28781 <p>
28782 Then it goes on to show specializations for float and bool, where one member 
28783 is missing (max_digits10).
28784 </p>
28785
28786 <p>
28787 Maarten Kronenburg adds:
28788 </p>
28789
28790 <p>
28791 I agree, just adding the comment that the exact number of decimal digits
28792 is digits * ln(radix) / ln(10), where probably this real number is
28793 rounded downward for digits10, and rounded upward for max_digits10
28794 (when radix=10, then digits10=max_digits10).
28795 Why not add this exact definition also to the standard, so the user
28796 knows what these numbers exactly mean.
28797 </p>
28798
28799 <p>
28800 Howard adds:
28801 </p>
28802
28803 <p>
28804 For reference, here are the correct formulas from
28805 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
28806 </p>
28807
28808 <blockquote><pre>digits10 = floor((digits-1) * log10(2))
28809 max_digits10 = ceil((1 + digits) * log10(2))
28810 </pre></blockquote>
28811
28812 <p>
28813 We are also missing a statement regarding for what specializations this member has meaning.
28814 </p>
28815
28816
28817
28818 <p><b>Proposed resolution:</b></p>
28819 <p>
28820 Change and add after 18.3.1.2 [numeric.limits.members], p11:
28821 </p>
28822
28823 <blockquote>
28824 <pre>static const int max_digits10;</pre>
28825 <blockquote>
28826 <p>
28827 -11- Number of base 10 digits required to ensure that values which
28828 differ <del>by only one epsilon</del> are always differentiated.
28829 </p>
28830 <p><ins>
28831 -12- Meaningful for all floating point types.
28832 </ins></p>
28833 </blockquote>
28834 </blockquote>
28835
28836 <p>
28837 Change 18.3.1.5 [numeric.special], p2:
28838 </p>
28839
28840 <blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; { 
28841 public: 
28842   static const bool is_specialized = true; 
28843   ...
28844   static const int digits10 = 6;
28845   <ins>static const int max_digits10 = 9</ins>;
28846   ...
28847 </pre></blockquote>
28848
28849 <p>
28850 Change 18.3.1.5 [numeric.special], p3:
28851 </p>
28852
28853 <blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; { 
28854 public: 
28855   static const bool is_specialized = true; 
28856   ...
28857   static const int digits10 = 0;
28858   <ins>static const int max_digits10 = 0</ins>;
28859   ...
28860 </pre></blockquote>
28861
28862
28863
28864
28865
28866
28867
28868 <hr>
28869 <h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
28870 <p><b>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28871  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-16 <b>Last modified:</b> 2010-10-29</p>
28872 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
28873 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28874 <p><b>Discussion:</b></p>
28875 <p>
28876 Section 22.2.1.2 defines the ctype_byname class template. It contains the 
28877 line
28878 </p>
28879
28880 <blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
28881 </pre></blockquote>
28882
28883
28884
28885 <p><b>Proposed resolution:</b></p>
28886 <p>
28887 as this is a dependent type, it should obviously be
28888 </p>
28889
28890 <blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
28891 </pre></blockquote>
28892
28893
28894
28895
28896
28897 <hr>
28898 <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
28899 <p><b>Section:</b> 26.6.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28900  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-10 <b>Last modified:</b> 2010-10-29</p>
28901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28902 <p><b>Discussion:</b></p>
28903 <p>
28904 I would respectfully request an issue be opened with the intention to
28905 clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
28906 </p>
28907
28908
28909 <p><b>Proposed resolution:</b></p>
28910 <p>
28911 Change 26.6.2.7 [valarray.members], paragraph 10:
28912 </p>
28913
28914 <blockquote>
28915
28916 <pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
28917 </pre>
28918
28919 <blockquote>
28920 <p>
28921 This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
28922 length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
28923 <tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
28924 the leftmost element, a positive value of <i>n</i> shifts the elements
28925 circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
28926 element zero is taken as the leftmost element, a non-negative value of
28927 <i>n</i> shifts the elements circularly left <i>n</i> places and a
28928 negative value of <i>n</i> shifts the elements circularly right
28929 -<i>n</i> places.</ins>
28930 </p>
28931 </blockquote>
28932 </blockquote>
28933
28934
28935
28936 <p><b>Rationale:</b></p>
28937 <p>
28938 We do not believe that there is any real ambiguity about what happens
28939 when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
28940 expression causes more trouble that it solves. The expression is
28941 certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
28942 is implementation defined.
28943 </p>
28944
28945
28946 <p><i>[
28947 Kona (2007) Changed proposed wording, added rationale and set to Review.
28948 ]</i></p>
28949
28950
28951
28952
28953
28954 <hr>
28955 <h3><a name="619"></a>619. Longjmp wording problem</h3>
28956 <p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28957  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2007-01-12 <b>Last modified:</b> 2010-10-29</p>
28958 <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>
28959 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28960 <p><b>Discussion:</b></p>
28961 <p>
28962 The wording for <tt>longjmp</tt> is confusing.
28963 </p>
28964 <p>
28965 18.10 [support.runtime] -4- Other runtime support
28966 </p>
28967 <blockquote><p>
28968 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
28969 behavior in this International Standard.  If any automatic objects would
28970 be destroyed by a thrown exception transferring control to another
28971 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
28972 the throw point that transfers control to the same (destination) point has
28973 undefined behavior.
28974 </p></blockquote>
28975 <p>
28976 Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
28977 *at* the throw point that transfers control".
28978 </p>
28979 <p>
28980 Bill Gibbons thinks it should say something like "If any automatic objects
28981 would be destroyed by an exception thrown at the point of the longjmp and
28982 caught only at the point of the setjmp, the behavior is undefined."
28983 </p>
28984
28985
28986 <p><b>Proposed resolution:</b></p>
28987 <p>
28988 In general, accept Bill Gibbons' recommendation,
28989 but add "call" to indicate that the undefined behavior
28990 comes from the dynamic call, not from its presence in the code.
28991 In 18.10 [support.runtime] paragraph 4, change
28992 </p>
28993
28994 <blockquote><p>
28995 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
28996 restricted behavior in this International Standard.  <del>If any automatic
28997 objects would be destroyed by a thrown exception transferring control to another
28998 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
28999 that the throw point that transfers control to the same (destination) point has
29000 undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
29001 undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
29002 <tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
29003 </p></blockquote>
29004
29005
29006
29007
29008
29009 <hr>
29010 <h3><a name="620"></a>620. valid uses of empty valarrays</h3>
29011 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29012  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
29013 <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>
29014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29015 <p><b>Discussion:</b></p>
29016         <p>
29017
29018 The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
29019 suggests  that  it  is possible  to  increase  the  size of  an  empty
29020 <code>valarray</code>  object   by  calling  other   non-const  member
29021 functions of the class besides <code>resize()</code>. However, such an
29022 interpretation would  be contradicted by  the requirement on  the copy
29023 assignment  operator  (and  apparently   also  that  on  the  computed
29024 assignments)  that the  assigned arrays  be  the same  size.  See  the
29025 reflector discussion starting with c++std-lib-17871.
29026
29027         </p>
29028         <p>
29029
29030 In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
29031 language.
29032
29033         </p>
29034
29035
29036 <p><b>Proposed resolution:</b></p>
29037         <p>
29038
29039 Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.6.2.1 [valarray.cons]):
29040
29041         </p>
29042         <blockquote>
29043             <p>
29044
29045 <code>valarray();</code>
29046
29047             </p>
29048             <p>
29049
29050 <i>Effects</i>:      Constructs      an      object      of      class
29051 <code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
29052 length<del> until it is passed into a library function as a modifiable
29053 lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
29054
29055             </p>
29056             <p>
29057
29058 <ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
29059
29060             </p>
29061             <p>
29062
29063 <i>Footnote  280</i>:  This default  constructor  is essential,  since
29064 arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
29065 There  shall also  be  a way  to change  the  size of  an array  after
29066 initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
29067 useful.   The  length  of  an  empty  array  can  be  increased  after
29068 initialization  by  means</ins>  of the  <code>resize()</code>  member
29069 function.
29070
29071             </p>
29072         </blockquote>
29073
29074
29075
29076
29077
29078 <hr>
29079 <h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
29080 <p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29081  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
29082 <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>
29083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29084 <p><b>Discussion:</b></p>
29085         <p>
29086
29087 The computed and  "fill" assignment operators of <code>valarray</code>
29088 helper     array     class    templates     (<code>slice_array</code>,
29089 <code>gslice_array</code>,         <code>mask_array</code>,        and
29090 <code>indirect_array</code>) are const  member functions of each class
29091 template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
29092 since  they have reference  semantics and thus do  not affect
29093 the state of  the object on which they are  called.  However, the copy
29094 assignment  operators  of  these  class  templates,  which  also  have
29095 reference semantics,  are non-const.   The absence of  constness opens
29096 the door to speculation about whether they really are intended to have
29097 reference semantics (existing implementations vary widely).
29098
29099         </p>
29100
29101 <p>
29102 Pre-Kona, Martin adds:
29103 </p>
29104
29105 <p>
29106 I realized that adding the const qualifier to the
29107 functions as I suggested would break the const correctness of the
29108 classes. A few possible solutions come to mind:
29109 </p>
29110
29111 <ol>
29112 <li>Add the const qualifier to the return types of these functions.</li>
29113 <li>Change the return type of all the functions to void to match
29114 the signatures of all the other assignment operators these classes
29115 define.</li>
29116 <li>Prohibit the copy assignment of these classes by declaring the
29117 copy assignment operators private (as is done and documented by
29118 some implementations).</li>
29119 </ol>
29120
29121
29122
29123 <p><b>Proposed resolution:</b></p>
29124         <p>
29125
29126 Declare  the  copy  assignment  operators  of all  four  helper  array
29127 class templates const.
29128
29129         </p>
29130         <p>
29131
29132 Specifically,  make the following edits:
29133
29134         </p>
29135         <p>
29136
29137 Change     the    signature     in     26.6.5 [template.slice.array]    and
29138 26.6.5.1 [slice.arr.assign] as follows:
29139
29140         </p>
29141         <blockquote><pre>
29142 <code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
29143
29144         </pre></blockquote>
29145         <p>
29146
29147 Change     the     signature     in    26.6.7 [template.gslice.array]     and
29148 26.6.7.1 [gslice.array.assign] as follows:
29149
29150         </p>
29151         <blockquote><pre>
29152 <code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
29153
29154         </pre></blockquote>
29155         <p>
29156
29157 Change the  signature in 26.6.8 [template.mask.array]  and 26.6.8.1 [mask.array.assign] as
29158 follows:
29159
29160         </p>
29161         <blockquote><pre>
29162 <code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
29163
29164         </pre></blockquote>
29165         <p>
29166
29167 Change     the     signature     in    26.6.9 [template.indirect.array] and
29168 26.6.9.1 [indirect.array.assign] as follows:
29169
29170         </p>
29171         <blockquote><pre>
29172 <code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
29173
29174         </pre></blockquote>
29175
29176
29177 <p><i>[
29178 Kona (2007) Added const qualification to the return types and set to Ready.
29179 ]</i></p>
29180
29181
29182
29183
29184
29185 <hr>
29186 <h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
29187 <p><b>Section:</b> 27.9.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29188  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
29189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29190 <p><b>Discussion:</b></p>
29191         <p>
29192
29193 <code>basic_filebuf</code>  dtor is  specified to  have  the following
29194 straightforward effects:
29195
29196         </p>
29197         <blockquote><p>
29198
29199 <i>Effects</i>:       Destroys      an      object       of      class
29200 <code>basic_filebuf</code>. Calls <code>close()</code>.
29201
29202         </p></blockquote>
29203         <p>
29204
29205 <code>close()</code> does a lot of potentially complicated processing,
29206 including calling <code>overflow()</code> to write out the termination
29207 sequence  (to   bring  the  output  sequence  to   its  initial  shift
29208 state). Since  any of the  functions called during the  processing can
29209 throw an exception, what should the  effects of an exception be on the
29210 dtor? Should the  dtor catch and swallow it or  should it propagate it
29211 to the caller?  The text doesn't  seem to provide any guidance in this
29212 regard  other  than  the  general  restriction on  throwing  (but  not
29213 propagating)  exceptions  from   destructors  of  library  classes  in
29214 17.6.4.12 [res.on.exception.handling].
29215
29216         </p>
29217         <p>
29218
29219 Further,  the last thing  <code>close()</code> is  specified to  do is
29220 call <code>fclose()</code> to close the <code>FILE</code> pointer. The
29221 last sentence of the <i>Effects</i> clause reads:
29222
29223         </p>
29224         <blockquote><p>
29225
29226 ...   If    any   of    the   calls   to    <code>overflow</code>   or
29227 <code>std::fclose</code> fails then <code>close</code> fails.
29228
29229         </p></blockquote>
29230         <p>
29231
29232 This  suggests that  <code>close()</code>  might be  required to  call
29233 <code>fclose()</code>   if  and  only   if  none   of  the   calls  to
29234 <code>overflow()</code> fails, and avoid closing the <code>FILE</code>
29235 otherwise. This  way, if  <code>overflow()</code> failed to  flush out
29236 the data, the caller  would have  the opportunity to  try to  flush it
29237 again (perhaps  after trying  to deal with  whatever problem  may have
29238 caused the failure), rather than losing it outright.
29239
29240         </p>
29241         <p>
29242
29243 On the other hand,  the function's <i>Postcondition</i> specifies that
29244 <code>is_open() ==  false</code>, which  suggests that it  should call
29245 <code>fclose()</code>       unconditionally.       However,      since
29246 <i>Postcondition</i> clauses  are specified for many  functions in the
29247 standard,  including constructors  where they  obviously  cannot apply
29248 after an  exception, it's not clear  whether this <i>Postcondition</i>
29249 clause is intended to apply even after an exception.
29250
29251         </p>
29252         <p>
29253
29254 It  might  be worth  noting  that  the  traditional behavior  (Classic
29255 Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
29256 is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
29257 errors.
29258
29259         </p>
29260
29261 <p><i>[
29262 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a> for related issues.
29263 ]</i></p>
29264
29265
29266
29267
29268 <p><b>Proposed resolution:</b></p>
29269         <p>
29270
29271 After discussing this  on the reflector (see the  thread starting with
29272 c++std-lib-17650) we propose that <code>close()</code> be clarified to
29273 match the traditional behavior, that is to close the <code>FILE</code>
29274 unconditionally,  even after  errors or  exceptions.  In  addition, we
29275 propose the dtor description be amended so as to explicitly require it
29276 to catch and swallow any exceptions thrown by <code>close()</code>.
29277
29278         </p>
29279         <p>
29280
29281 Specifically,   we   propose   to   make  the   following   edits   in
29282 27.9.1.4 [filebuf.members]:
29283
29284         </p>
29285         <blockquote>
29286             <pre>
29287 <code>basic_filebuf&lt;charT,traits&gt;* close();</code>
29288
29289             </pre>
29290             <p>
29291
29292 <i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
29293 pointer.        If      a       put      area       exists,      calls
29294 <code>overflow(traits::eof())</code> to flush  characters. If the last
29295 virtual   member  function   called  on   <code>*this</code>  (between
29296 <code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
29297 and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
29298 <code>a_codecvt.unshift</code> (possibly several times) to determine a
29299 termination   sequence,    inserts   those   characters    and   calls
29300 <code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
29301 of whether  any of the preceding  calls fails or  throws an exception,
29302 the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
29303 <code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
29304 <ins>made    by   the    function</ins><del>to   <code>overflow</code>
29305 or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
29306 fails then <code>close</code> fails<ins>  by returning a null pointer.
29307 If one of these calls throws an exception, the exception is caught and
29308 rethrown after closing the file.</ins>
29309
29310             </p>
29311         </blockquote>
29312         <p>
29313
29314 And to make the following edits in 27.9.1.2 [filebuf.cons].
29315
29316         </p>
29317         <blockquote>
29318             <pre>
29319 <code>virtual ~basic_filebuf();</code>
29320
29321             </pre>
29322             <p>
29323
29324 <i>Effects</i>:       Destroys      an      object       of      class
29325 <code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
29326 <code>close()</code>.    <ins>If  an   exception  occurs   during  the
29327 destruction of the object, including the call to <code>close()</code>,
29328 the     exception    is     caught    but     not     rethrown    (see
29329 17.6.4.12 [res.on.exception.handling]).</ins>
29330
29331             </p>
29332         </blockquote>
29333
29334
29335
29336
29337
29338 <hr>
29339 <h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
29340 <p><b>Section:</b> 27.2.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29341  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
29342 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29343 <p><b>Discussion:</b></p>
29344         <p>
29345
29346 27.2.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
29347 clause 27 except  for <code>ios_base::imbue</code> causes any instance
29348 of                   <code>basic_ios::imbue</code>                  or
29349 <code>basic_streambuf::imbue</code> to be called."
29350
29351         </p>
29352         <p>
29353
29354 That      contradicts      the      <i>Effects</i>     clause      for
29355 <code>basic_streambuf::pubimbue()</code>  which requires  the function
29356 to do just that: call <code>basic_streambuf::imbue()</code>.
29357
29358         </p>
29359
29360
29361 <p><b>Proposed resolution:</b></p>
29362         <p>
29363
29364 To    fix   this,    rephrase    the   sentence    above   to    allow
29365 <code>pubimbue</code> to do what  it was designed to do. Specifically.
29366 change 27.2.1 [iostream.limits.imbue], p1 to read:
29367
29368         </p>
29369         <blockquote><p>
29370
29371 No     function    described     in    clause     27     except    for
29372 <code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
29373 causes    any    instance    of    <code>basic_ios::imbue</code>    or
29374 <code>basic_streambuf::imbue</code> to be called. ...
29375
29376         </p></blockquote>
29377
29378
29379
29380
29381
29382 <hr>
29383 <h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
29384 <p><b>Section:</b> 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29385  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
29386 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29387 <p><b>Discussion:</b></p>
29388         <p>
29389
29390 The behavior of the  <code>valarray</code> copy assignment operator is
29391 defined only when both sides have  the same number of elements and the
29392 spec is explicit about assignments of arrays of unequal lengths having
29393 undefined behavior.
29394
29395         </p>
29396         <p>
29397
29398 However, the generalized  subscripting assignment operators overloaded
29399 on <code>slice_array</code>  et al (26.6.2.2 [valarray.assign])  don't have any
29400 such restriction, leading  the reader to believe that  the behavior of
29401 these  overloads is  well defined  regardless  of the  lengths of  the
29402 arguments.
29403
29404         </p>
29405         <p>
29406
29407 For example,  based on  the reading  of the spec  the behavior  of the
29408 snippet below can be expected to be well-defined:
29409
29410         </p>
29411         <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
29412     const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
29413     std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }
29414
29415     b = a [from_0_to_3];
29416         </pre>
29417         <p>
29418
29419 In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
29420 <code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
29421 existing implementations vary.
29422
29423         </p>
29424
29425 <p>
29426 Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
29427 Proposal for Standard C++ Array Classes (see c++std-lib-704;
29428 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
29429 </p>
29430 <blockquote><p>
29431   ...if the size of the array on the right hand side of the equal
29432   sign differs from the size of the array on the left, a run time
29433   error occurs. How this error is handled is implementation
29434   dependent; for compilers which support it, throwing an exception
29435   would be reasonable.
29436 </p></blockquote>
29437
29438 <p>
29439 And see more history in
29440 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
29441 </p>
29442
29443         <p>
29444
29445 It has  been argued in  discussions on the committee's  reflector that
29446 the semantics of all <code>valarray</code> assignment operators should
29447 be permitted to be undefined unless  the  length  of the arrays  being
29448 assigned is the same as the length of the one being assigned from. See
29449 the thread starting at c++std-lib-17786.
29450
29451         </p>
29452         <p>
29453
29454 In order  to reflect  such views, the  standard must specify  that the
29455 size of the  array referred to by the argument  of the assignment must
29456 match the size of the array  under assignment, for example by adding a
29457 <i>Requires</i> clause to 26.6.2.2 [valarray.assign] as follows:
29458
29459         </p>
29460         <blockquote><p>
29461
29462 <i>Requires</i>: The length of the  array to which the argument refers
29463 equals <code>size()</code>.
29464
29465         </p></blockquote>
29466
29467         <p>
29468
29469 Note that it's  far from clear that such leeway  is necessary in order
29470 to implement <code>valarray</code> efficiently.
29471
29472         </p>
29473
29474
29475 <p><b>Proposed resolution:</b></p>
29476 <p>
29477 Insert new paragraph into 26.6.2.2 [valarray.assign]:
29478 </p>
29479
29480 <blockquote>
29481 <pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;); 
29482 valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;); 
29483 valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;); 
29484 valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
29485 </pre>
29486 <blockquote>
29487 <p><ins>
29488 <i>Requires</i>: The length of the  array to which the argument refers
29489 equals <code>size()</code>.
29490 </ins></p>
29491 <p>
29492 These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
29493 </p>
29494 </blockquote>
29495 </blockquote>
29496
29497
29498
29499
29500
29501 <hr>
29502 <h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
29503 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
29504  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-11-19</p>
29505 <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>
29506 <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>
29507 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
29508 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a></p>
29509 <p><b>Discussion:</b></p>
29510  <p>
29511
29512 Many member functions of <code>basic_string</code> are overloaded,
29513 with some of the overloads taking a <code>string</code> argument,
29514 others <code>value_type*</code>, others <code>size_type</code>, and
29515 others still <code>iterators</code>. Often, the requirements on one of
29516 the overloads are expressed in the form of <i>Effects</i>,
29517 <i>Throws</i>, and in the Working Paper
29518 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
29519 also <i>Remark</i> clauses, while those on the rest of the overloads
29520 via a reference to this overload and using a <i>Returns</i> clause.
29521 </p>
29522
29523 <p>
29524 The difference between the two forms of specification is that per
29525 17.5.1.4 [structure.specifications], p3, an <i>Effects</i> clause specifies
29526 <i>"actions performed by the functions,"</i> i.e., its observable
29527 effects, while a <i>Returns</i> clause is <i>"a description of the
29528 return value(s) of a function"</i> that does not impose any
29529 requirements on the function's observable effects.
29530 </p>
29531
29532 <p>
29533 Since only <i>Notes</i> are explicitly defined to be informative and
29534 all other paragraphs are explicitly defined to be normative, like
29535 <i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
29536 impose normative requirements.
29537 </p>
29538
29539 <p>
29540 So by this strict reading of the standard there are some member
29541 functions of <code>basic_string</code> that are required to throw an
29542 exception under some conditions or use specific traits members while
29543 many other otherwise equivalent overloads, while obliged to return the
29544 same values, aren't required to follow the exact same requirements
29545 with regards to the observable effects.
29546 </p>
29547
29548 <p>
29549 Here's an example of this problem that was precipitated by the change
29550 from informative Notes to normative <i>Remark</i>s (presumably made to
29551 address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>):
29552 </p>
29553
29554 <p>
29555 In the Working Paper, <code>find(string, size_type)</code> contains a
29556 <i>Remark</i> clause (which is just a <i>Note</i> in the current
29557 standard) requiring it to use <code>traits::eq()</code>.
29558 </p>
29559
29560 <p>
29561 <code>find(const charT *s, size_type pos)</code> is specified to
29562 return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
29563 and so it is not required to use <code>traits::eq()</code>. However,
29564 the Working Paper has replaced the original informative <i>Note</i>
29565 about the function using <code>traits::length()</code> with a
29566 normative requirement in the form of a <i>Remark</i>. Calling
29567 <code>traits::length()</code> may be suboptimal, for example when the
29568 argument is a very long array whose initial substring doesn't appear
29569 anywhere in <code>*this</code>.
29570 </p>
29571
29572 <p>
29573 Here's another similar example, one that existed even prior to the
29574 introduction of <i>Remark</i>s:
29575 </p>
29576
29577 <p>
29578 <code> insert(size_type pos, string, size_type, size_type)</code> is
29579 required to throw <code>out_of_range</code> if <code>pos &gt;
29580 size()</code>.
29581 </p>
29582
29583 <p>
29584 <code>insert(size_type pos, string str)</code> is specified to return
29585 <code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
29586 so its effects when <code>pos &gt; size()</code> are strictly speaking
29587 unspecified.
29588 </p><p>
29589
29590 </p>
29591 I believe a careful review of the current <i>Effects</i> and
29592 <i>Returns</i> clauses is needed in order to identify all such
29593 problematic cases. In addition, a review of the Working Paper should
29594 be done to make sure that the newly introduced normative <i>Remark</i>
29595 clauses do not impose any undesirable normative requirements in place
29596 of the original informative <i>Notes</i>.
29597 <p></p>
29598
29599 <p><i>[
29600 Batavia: Alan and Pete to work.
29601 ]</i></p>
29602
29603
29604 <p><i>[
29605 Bellevue: Marked as NAD Editorial.
29606 ]</i></p>
29607
29608
29609 <p><i>[
29610 Post-Sophia Antipolis:
29611 Martin indicates there is still work to be done on this issue.
29612 Reopened.
29613 ]</i></p>
29614
29615
29616 <p><i>[
29617 Batavia (2009-05):
29618 ]</i></p>
29619
29620 <blockquote>
29621 Tom proposes we say that, unless specified otherwise,
29622 it is always the caller's responsibility to verify that supplied arguments
29623 meet the called function's requirements.
29624 If further semantics are specified
29625 (e.g., that the function throws under certain conditions),
29626 then it is up to the implementer to check those conditions.
29627 Alan feels strongly that our current use of Requires in this context
29628 is confusing, especially now that <tt>requires</tt> is a new keyword.
29629 </blockquote>
29630
29631 <p><i>[
29632 2009-07 Frankfurt
29633 ]</i></p>
29634
29635
29636 <blockquote>
29637 Move to Tentatively NAD.
29638 </blockquote>
29639
29640 <p><i>[
29641 2009 Santa Cruz:
29642 ]</i></p>
29643
29644
29645 <blockquote>
29646 Move to Open.  Martin will work on proposed wording.
29647 </blockquote>
29648
29649 <p><i>[
29650 2010 Pittsburgh:
29651 ]</i></p>
29652
29653
29654 <blockquote>
29655 Moved to NAD Editorial, solved by revision to N3021.
29656 </blockquote>
29657
29658
29659
29660
29661 <p><b>Rationale:</b></p>
29662 <p>
29663 Solved by revision to N3021.
29664 </p>
29665
29666
29667 <p><b>Proposed resolution:</b></p>
29668 <p>
29669 </p>
29670
29671
29672
29673
29674
29675 <hr>
29676 <h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
29677 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29678  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-01-23 <b>Last modified:</b> 2010-10-29</p>
29679 <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>
29680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29681 <p><b>Discussion:</b></p>
29682 <p>
29683 Section 28.8 [re.regex] lists a constructor
29684 </p>
29685
29686 <blockquote><pre>template&lt;class InputIterator&gt;
29687 basic_regex(InputIterator first, InputIterator last,
29688                        flag_type f = regex_constants::ECMAScript);
29689 </pre></blockquote>
29690
29691 <p>
29692 However, in section 28.8.2 [re.regex.construct], this constructor takes a 
29693 pair of <tt>ForwardIterator</tt>.
29694 </p>
29695
29696
29697 <p><b>Proposed resolution:</b></p>
29698 <p>
29699 Change 28.8.2 [re.regex.construct]:
29700 </p>
29701
29702 <blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
29703   basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, 
29704               flag_type f = regex_constants::ECMAScript);
29705 </pre></blockquote>
29706
29707
29708
29709
29710
29711
29712 <hr>
29713 <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
29714 <p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29715  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2010-10-29</p>
29716 <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>
29717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29718 <p><b>Discussion:</b></p>
29719 <p>
29720 is there an issue opened for (0,3) as complex number with
29721 the French local?  With the English local, the above parses as an
29722 imaginery complex number.  With the French locale it parses as a
29723 real complex number.
29724 </p>
29725
29726 <p>
29727 Further notes/ideas from the lib-reflector, messages 17982-17984:
29728 </p>
29729
29730 <blockquote>
29731 <p>
29732 Add additional entries in num_punct to cover the complex separator (French would be ';').
29733 </p>
29734 <p>
29735 Insert a space before the comma, which should eliminate the ambiguity.
29736 </p>
29737 <p>
29738 Solve the problem for ordered sequences in general, perhaps with a
29739 dedicated facet.  Then complex should use that solution.
29740 </p>
29741 </blockquote>
29742
29743 <p><i>[
29744 Bellevue:
29745 ]</i></p>
29746
29747
29748 <blockquote>
29749 <p>
29750 After much discussion, we agreed on the following: Add a footnote:
29751 </p>
29752 <p>
29753 [In a locale in which comma is being used as a decimal point character,
29754 inserting "showbase" into the output stream forces all outputs to show
29755 an explicit decimal point character; then all inserted complex sequences
29756 will extract unambiguously.]
29757 </p>
29758 <p>
29759 And move this to READY status.
29760 </p>
29761 </blockquote>
29762
29763 <p><i>[
29764 Pre-Sophia Antipolis, Howard adds:
29765 ]</i></p>
29766
29767
29768 <blockquote>
29769 Changed "showbase" to "showpoint" and changed from Ready to Review.
29770 </blockquote>
29771
29772 <p><i>[
29773 Post-Sophia Antipolis:
29774 ]</i></p>
29775
29776
29777 <blockquote>
29778 <p>
29779 I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
29780 In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
29781 voted the footnote into the WP with "showbase".
29782 </p>
29783 <p>
29784 I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
29785 </p>
29786 </blockquote>
29787
29788
29789
29790 <p><b>Proposed resolution:</b></p>
29791 <p>
29792 Add a footnote to 26.4.6 [complex.ops] p16:
29793 </p>
29794
29795 <blockquote>
29796 [In a locale in which comma is being used as a decimal point character,
29797 inserting <tt>showpoint</tt> into the output stream forces all outputs to show
29798 an explicit decimal point character; then all inserted complex sequences
29799 will extract unambiguously.]
29800 </blockquote>
29801
29802
29803
29804
29805
29806 <hr>
29807 <h3><a name="630"></a>630. arrays of valarray</h3>
29808 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29809  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2010-10-29</p>
29810 <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>
29811 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29812 <p><b>Discussion:</b></p>
29813         <p>
29814
29815 Section 26.2 [numeric.requirements], p1     suggests     that     a
29816 <code>valarray</code>  specialization on  a  type <code>T</code>  that
29817 satisfies  the requirements enumerated  in the  paragraph is  itself a
29818 valid  type   on  which  <code>valarray</code>   may  be  instantiated
29819 (Footnote       269        makes       this       clear).        I.e.,
29820 <code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
29821 <code>T</code>   is   valid.    However,  since   implementations   of
29822 <code>valarray</code> are permitted to initialize storage allocated by
29823 the class by  invoking the default ctor of  <code>T</code> followed by
29824 the    copy    assignment    operator,   such    implementations    of
29825 <code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
29826 specializations of <code>valarray</code> whose assignment operator had
29827 undefined behavior when the size of its argument didn't match the size
29828 of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
29829 be  impossible  to resize  such  an array  of  arrays  by calling  the
29830 <code>resize()</code> member  function on it if the  function used the
29831 copy  assignment operator  after constructing  all elements  using the
29832 default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
29833 obtain default-initialized storage) as it's permitted to do.
29834
29835         </p>
29836         <p>
29837
29838 Stated      more     generally,      the      problem     is      that
29839 <code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
29840 required or  guaranteed to have well-defined semantics  for every type
29841 <code>T</code>     that      satisfies     all     requirements     in
29842 26.2 [numeric.requirements].
29843
29844         </p>
29845         <p>
29846
29847 I  believe  this  problem  was  introduced  by  the  adoption  of  the
29848 resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
29849 <i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
29850 operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
29851 as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
29852 (both  from 1993), had  well-defined semantics  for arrays  of unequal
29853 size (the  latter explicitly  only when <code>*this</code>  was empty;
29854 assignment of non empty arrays of unequal size was a runtime error).
29855
29856         </p>
29857         <p>
29858
29859 The  justification for  the  change given  in  N0857 was the "loss  of
29860 performance [deemed]  only significant  for very simple  operations on
29861 small arrays or for architectures with very few registers."
29862
29863         </p>
29864         <p>
29865
29866 Since tiny  arrays on a  limited subset of hardware  architectures are
29867 likely  to  be  an   exceedingly  rare  case  (despite  the  continued
29868 popularity of  x86) I  propose to revert  the resolution and  make the
29869 behavior    of   all   <code>valarray</code>    assignment   operators
29870 well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
29871 size).   I have implemented  this change  and measured  no significant
29872 degradation  in performance in  the common  case (non-empty  arrays of
29873 equal size).  I  have measured a 50% (and in  some cases even greater)
29874 speedup  in the  case of  assignments to  empty arrays  versus calling
29875 <code>resize()</code>  first followed  by  an invocation  of the  copy
29876 assignment operator.
29877
29878         </p>
29879
29880 <p><i>[
29881 Bellevue:
29882 ]</i></p>
29883
29884
29885 <blockquote>
29886 If no proposed wording by June meeting, this issue should be closed NAD.
29887 </blockquote>
29888
29889 <p><i>[
29890 2009-07 Frankfurt
29891 ]</i></p>
29892
29893
29894 <blockquote>
29895 <p>
29896 Move resolution 1 to Ready.
29897 </p>
29898 <p>
29899 Howard: second resolution has been commented out (made invisible).
29900 Can be brought back on demand.
29901 </p>
29902 </blockquote>
29903
29904
29905
29906 <p><b>Proposed resolution:</b></p>
29907         <p>
29908
29909 Change 26.6.2.2 [valarray.assign], p1 as follows:
29910
29911         </p>
29912         <blockquote>
29913             <p>
29914                 <code>
29915
29916 valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
29917
29918                 </code>
29919             </p>
29920             <p>
29921
29922 -1- Each element of the <code>*this</code> array is assigned the value
29923 of  the  corresponding  element   of  the  argument  array.   <del>The
29924 resulting behavior is undefined if </del><ins>When </ins>the length of
29925 the  argument  array  is  not   equal  to  the  length  of  the  *this
29926 array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
29927 arrays     the      same     length,     as      if     by     calling
29928 <code>resize(x.size())</code>, before performing the assignment.</ins>
29929
29930             </p>
29931         </blockquote>
29932         <p>
29933
29934 And  add a new  paragraph just  below paragraph  1 with  the following
29935 text:
29936
29937         </p>
29938         <blockquote>
29939             <p>
29940
29941 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
29942
29943             </p>
29944         </blockquote>
29945         <p>
29946
29947 Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
29948
29949         </p>
29950         <blockquote>
29951             <p>
29952
29953 <ins>-?- When the length,  <i><code>N</code></i> of the array referred
29954 to by the  argument is not equal to  the length of <code>*this</code>,
29955 the  operator resizes <code>*this</code>  to make  the two  arrays the
29956 same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
29957 performing the assignment.</ins>
29958
29959             </p>
29960         </blockquote>
29961
29962 <p><i>[
29963 pre-Sophia Antipolis, Martin adds the following compromise wording, but
29964 prefers the original proposed resolution:
29965 ]</i></p>
29966
29967
29968
29969
29970
29971
29972 <p><i>[
29973 Kona (2007): Gaby to propose wording for an alternative resolution in
29974 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
29975 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
29976 ]</i></p>
29977
29978
29979
29980
29981
29982 <hr>
29983 <h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
29984 <p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29985  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07 <b>Last modified:</b> 2010-10-29</p>
29986 <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>
29987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29988 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
29989 <p><b>Discussion:</b></p>
29990
29991 <p>
29992 20.9.5.1 [allocator.members] says:
29993 </p>
29994 <blockquote>
29995 <pre>pointer address(reference <i>x</i>) const;</pre>
29996 <blockquote>
29997 <p>
29998 -1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
29999 </p>
30000 </blockquote>
30001 </blockquote>
30002
30003 <p>
30004 20.9.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
30005 only defines the semantics of copy construction, but also restricts what an overloaded
30006 <tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
30007 and rvalue reference) to decouple these two requirements.  Indeed it is not evident
30008 that we should disallow overloading <tt>operator&amp;</tt> to return something other
30009 than the address of <tt>*this</tt>.
30010 </p>
30011
30012 <p>
30013 An example of when you want to overload <tt>operator&amp;</tt> to return something
30014 other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
30015 (or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
30016 such a proxy reference should logically yield a proxy pointer, which when dereferenced,
30017 yields a copy of the original proxy reference again.
30018 </p>
30019
30020 <p>
30021 On the other hand, some code truly needs the address of an object, and not a proxy
30022 (typically for determining the identity of an object compared to a reference object).
30023 <a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with 
30024 <a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
30025 It appears to me that this would be useful functionality for the default allocator.  Adopting
30026 this definition for <tt>allocator::address</tt> would free the standard of requiring
30027 anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>
30028 is expected to make use of <tt>allocator::address</tt> mandatory for containers.
30029 </p>
30030
30031
30032
30033 <p><b>Proposed resolution:</b></p>
30034 <p>
30035 Change 20.9.5.1 [allocator.members]:
30036 </p>
30037
30038 <blockquote>
30039 <pre>pointer address(reference <i>x</i>) const;</pre>
30040 <blockquote>
30041 <p>
30042 -1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
30043 even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
30044 </p>
30045 </blockquote>
30046
30047 <pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
30048 <blockquote>
30049 <p>
30050 -2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
30051 even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
30052 </p>
30053 </blockquote>
30054 </blockquote>
30055
30056 <p><i>[
30057 post Oxford:  This would be rendered NAD Editorial by acceptance of
30058 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
30059 ]</i></p>
30060
30061
30062 <p><i>[
30063 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
30064 was subsequently split out into a separate paper N2436 for the purposes of voting.
30065 The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
30066 issue to Ready status to be voted into the WP at Kona.
30067 ]</i></p>
30068
30069
30070
30071
30072
30073
30074
30075 <hr>
30076 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
30077 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
30078  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08 <b>Last modified:</b> 2010-11-20</p>
30079 <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>
30080 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
30081 <p><b>Discussion:</b></p>
30082 <p>
30083 The table of allocator requirements in 20.2.5 [allocator.requirements] describes
30084 <tt>allocator::address</tt> as:
30085 </p>
30086 <blockquote><pre>a.address(r)
30087 a.address(s)
30088 </pre></blockquote>
30089 <p>
30090 where <tt>r</tt> and <tt>s</tt> are described as:
30091 </p>
30092 <blockquote><p>
30093 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
30094 </p></blockquote>
30095
30096 <p>
30097 and <tt>p</tt> is 
30098 </p>
30099
30100 <blockquote><p>
30101 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
30102 where <tt>a1 == a</tt>
30103 </p></blockquote>
30104
30105 <p>
30106 This all implies that to get the address of some value of type <tt>T</tt> that
30107 value must have been allocated by this allocator or a copy of it.
30108 </p>
30109
30110 <p>
30111 However sometimes container code needs to compare the address of an external value of
30112 type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
30113 may want to compare the address of the external value <tt>t</tt> with that of a value
30114 stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
30115 want to make similar comparisons (to check for self-referencing calls).
30116 </p>
30117
30118 <p>
30119 Mandating that <tt>allocator::address</tt> can only be called for values which the
30120 allocator allocated seems overly restrictive.
30121 </p>
30122
30123 <p><i>[
30124 post San Francisco:
30125 ]</i></p>
30126
30127
30128 <blockquote>
30129 Pablo recommends NAD Editorial, solved by
30130 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
30131 </blockquote>
30132
30133 <p><i>[
30134 2009-04-28 Pablo adds:
30135 ]</i></p>
30136
30137
30138 <blockquote>
30139 Tentatively-ready NAD Editorial as fixed by
30140 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
30141 </blockquote>
30142
30143 <p><i>[
30144 2009-07 Frankfurt
30145 ]</i></p>
30146
30147
30148 <blockquote>
30149 Fixed by N2768.
30150 </blockquote>
30151
30152 <p><i>[
30153 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
30154 ]</i></p>
30155
30156
30157 <p><i>[
30158 2009-10 Santa Cruz:
30159 ]</i></p>
30160
30161
30162 <blockquote>
30163 <del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
30164 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
30165 </blockquote>
30166
30167
30168
30169 <p><b>Proposed resolution:</b></p>
30170 <p>
30171 Change 20.2.5 [allocator.requirements]:
30172 </p>
30173
30174 <blockquote>
30175 <p>
30176 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
30177 </p>
30178 <p>
30179 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
30180 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
30181 </p>
30182 </blockquote>
30183
30184 <p><i>[
30185 post Oxford:  This would be rendered NAD Editorial by acceptance of
30186 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
30187 ]</i></p>
30188
30189
30190 <p><i>[
30191 Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
30192 no resolution to this issue was recorded.  Moved to Open.
30193 ]</i></p>
30194
30195
30196
30197
30198
30199
30200
30201 <hr>
30202 <h3><a name="638"></a>638. deque end invalidation during erase</h3>
30203 <p><b>Section:</b> 23.3.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30204  <b>Submitter:</b> Steve LoBasso <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2010-10-29</p>
30205 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30206 <p><b>Discussion:</b></p>
30207 <p>
30208 The standard states at 23.3.2.3 [deque.modifiers]/4:
30209 </p>
30210 <blockquote><pre>deque erase(...)
30211 </pre>
30212  <p>
30213 <i>Effects:</i> ... An erase at either end of the deque invalidates only
30214 the iterators and the references to the erased elements.
30215 </p>
30216 </blockquote>
30217 <p>
30218 This does not state that iterators to end will be invalidated.
30219 It needs to be amended in such a way as to account for end invalidation.
30220 </p>
30221 <p>
30222 Something like:
30223 </p>
30224 <blockquote><p>
30225 Any time the last element is erased, iterators to end are invalidated.
30226 </p></blockquote>
30227
30228 <p>
30229 This would handle situations like:
30230 </p>
30231 <blockquote><pre>erase(begin(), end())
30232 erase(end() - 1)
30233 pop_back()
30234 resize(n, ...) where n &lt; size()
30235 pop_front() with size() == 1
30236
30237 </pre></blockquote>
30238
30239 <p><i>[
30240 Post Kona, Steve LoBasso notes:
30241 ]</i></p>
30242
30243
30244 <blockquote>
30245 My only issue with the proposed resolution is that it might not be clear
30246 that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
30247 iterators.
30248 </blockquote>
30249
30250
30251
30252 <p><b>Proposed resolution:</b></p>
30253 <p>
30254 Change 23.3.2.3 [deque.modifiers], p4:
30255 </p>
30256
30257 <blockquote>
30258 <pre>iterator erase(const_iterator position); 
30259 iterator erase(const_iterator first, const_iterator last);
30260 </pre>
30261
30262 <blockquote>
30263 <p>
30264 -4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
30265 invalidates all the iterators and references to elements of the
30266 <tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
30267 either end of the <tt>deque</tt> invalidates only the iterators and the
30268 references to the erased elements<ins>, except that erasing at the end
30269 also invalidates the past-the-end iterator</ins>.
30270 </p>
30271 </blockquote>
30272 </blockquote>
30273
30274
30275
30276 <p><i>[
30277 Kona (2007): Proposed wording added and moved to Review.
30278 ]</i></p>
30279
30280
30281 <p><i>[
30282 Bellevue:
30283 ]</i></p>
30284
30285
30286 <blockquote>
30287 Note that there is existing code that relies on iterators not being
30288 invalidated, but there are also existing implementations that do
30289 invalidate iterators. Thus, such code is not portable in any case. There
30290 is a pop_front() note, which should possibly be a separate issue. Mike
30291 Spertus to evaluate and, if need be, file an issue.
30292 </blockquote>
30293
30294
30295
30296
30297 <hr>
30298 <h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
30299 <p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30300  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2010-10-29</p>
30301 <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>
30302 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30303 <p><b>Discussion:</b></p>
30304 <p>
30305 The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic].
30306 Although the section starts with a listing of the inserters including
30307 the new ones:
30308 </p>
30309
30310 <blockquote><pre>operator&lt;&lt;(long long val );
30311 operator&lt;&lt;(unsigned long long val );
30312 </pre></blockquote>
30313
30314 <p>
30315 the text in paragraph 1, which describes the corresponding effects
30316 of the inserters, depending on the actual type of val, does not
30317 handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
30318 </p>
30319
30320 <p><i>[
30321 Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
30322 misses any reference to extended integral types supplied by the
30323 implementation - one of the additions by core a couple of working papers
30324 back.
30325 ]</i></p>
30326
30327
30328
30329
30330 <p><b>Proposed resolution:</b></p>
30331 <p>
30332 In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
30333 </p>
30334
30335 <blockquote>
30336 When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
30337 long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
30338 <tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
30339 occurs as if it performed the following code fragment:
30340 </blockquote>
30341
30342
30343
30344
30345
30346 <hr>
30347 <h3><a name="643"></a>643. Impossible "as if" clauses</h3>
30348 <p><b>Section:</b> 27.9.1.1 [filebuf], 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30349  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2010-10-29</p>
30350 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30351 <p><b>Discussion:</b></p>
30352 <p>
30353 The current standard 14882:2003(E) as well as N2134 have the
30354 following
30355 defects:
30356 </p>
30357
30358 <p>
30359 27.9.1.1 [filebuf]/5 says:
30360 </p>
30361
30362 <blockquote>
30363 <p>
30364 In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
30365 facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
30366 </p>
30367 <blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
30368   use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
30369 </pre></blockquote>
30370 </blockquote>
30371
30372 <p>
30373 <tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
30374 copyconstructible, so the codecvt construction should fail to compile.
30375 </p>
30376
30377 <p>
30378 A similar issue arises in 22.4.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
30379 </p>
30380
30381
30382 <p><b>Proposed resolution:</b></p>
30383 <p>
30384 In 27.9.1.1 [filebuf]/5 change the "as if" code
30385 </p>
30386
30387 <blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
30388   use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
30389 </pre></blockquote>
30390
30391 <p>
30392 In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
30393 </p>
30394
30395 <blockquote>
30396 <p>
30397 A local variable <tt><i>punct</i></tt> is initialized via
30398 </p>
30399 <blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
30400 </pre></blockquote>
30401 </blockquote>
30402
30403 <p>
30404 (Please note also the additional provided trailing semicolon)
30405 </p>
30406
30407
30408
30409
30410
30411
30412 <hr>
30413 <h3><a name="646"></a>646. const incorrect match_result members</h3>
30414 <p><b>Section:</b> 28.10.5 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30415  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2010-10-29</p>
30416 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30417 <p><b>Discussion:</b></p>
30418 <p>
30419 28.10.5 [re.results.form] (root and para 3) in N2134 defines the two function template
30420 members format as non-const functions, although they are declared
30421 as const in 28.10 [re.results]/3.
30422 </p>
30423
30424
30425 <p><b>Proposed resolution:</b></p>
30426 <p>
30427 Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
30428 in section 28.10.5 [re.results.form].
30429 </p>
30430
30431
30432
30433
30434
30435 <hr>
30436 <h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
30437 <p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30438  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
30439 <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>
30440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30441 <p><b>Discussion:</b></p>
30442 <p>
30443 Both the class definition of regex_token_iterator (28.12.2 [re.tokiter]/6) and the latter member specifications (28.12.2.2 [re.tokiter.comp]/1+2) declare both comparison operators as
30444 non-const functions. Furtheron, both dereference operators are
30445 unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
30446 as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
30447 </p>
30448
30449
30450 <p><b>Proposed resolution:</b></p>
30451 <p>
30452 1) In (28.12.2 [re.tokiter]/6) change the current declarations
30453 </p>
30454
30455 <blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
30456 bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
30457 const value_type&amp; operator*() <ins>const</ins>;
30458 const value_type* operator-&gt;() <ins>const</ins>;
30459 </pre></blockquote>
30460
30461 <p>
30462 2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
30463 </p>
30464
30465 <blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
30466 bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
30467 </pre></blockquote>
30468
30469 <p>
30470 3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
30471 </p>
30472
30473 <blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
30474 const value_type* operator-&gt;() <ins>const</ins>;
30475 </pre></blockquote>
30476
30477
30478 <p><i>[
30479 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
30480 is to adopt the proposed wording in this issue).
30481 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30482 ]</i></p>
30483
30484
30485
30486
30487
30488 <hr>
30489 <h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
30490 <p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30491  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
30492 <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>
30493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30494 <p><b>Discussion:</b></p>
30495 <p>
30496 The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
30497 the effects of the three non-default constructors of class
30498 template regex_token_iterator but is does not clarify which values
30499 are legal values for submatch/submatches. This becomes
30500 an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
30501 the notion of a "current match" by saying:
30502 </p>
30503
30504 <blockquote><p>
30505 The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
30506 == -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
30507 <tt>subs[N]</tt>.
30508 </p></blockquote>
30509
30510 <p>
30511 It's not clear to me, whether other negative values except -1
30512 are legal arguments or not - it seems they are not.
30513 </p>
30514
30515
30516 <p><b>Proposed resolution:</b></p>
30517 <p>
30518 Add the following precondition paragraph just before the current
30519 28.12.2.1 [re.tokiter.cnstr]/2:
30520 </p>
30521
30522 <blockquote><p>
30523 <i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
30524 </p></blockquote>
30525
30526
30527 <p><i>[
30528 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
30529 is to adopt the proposed wording in this issue).
30530 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30531 ]</i></p>
30532
30533
30534
30535
30536
30537 <hr>
30538 <h3><a name="652"></a>652. regex_iterator and const correctness</h3>
30539 <p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30540  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
30541 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30542 <p><b>Discussion:</b></p>
30543 <p>
30544 Both the class definition of regex_iterator (28.12.1 [re.regiter]/1) and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2) declare both comparison operators as
30545 non-const functions. Furtheron, both dereference operators are
30546 unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
30547 as well as in (28.12.1.3 [re.regiter.deref]/1+2).
30548 </p>
30549
30550
30551 <p><b>Proposed resolution:</b></p>
30552 <p>
30553 1) In (28.12.1 [re.regiter]/1) change the current declarations
30554 </p>
30555
30556 <blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
30557 bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
30558 const value_type&amp; operator*() <ins>const</ins>;
30559 const value_type* operator-&gt;() <ins>const</ins>;
30560 </pre></blockquote>
30561
30562 <p>
30563 2) In 28.12.1.3 [re.regiter.deref] change the following declarations
30564 </p>
30565
30566 <blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
30567 const value_type* operator-&gt;() <ins>const</ins>;
30568 </pre></blockquote>
30569
30570 <p>
30571 3) In 28.12.1.2 [re.regiter.comp] change the following declarations
30572 </p>
30573
30574 <blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
30575 bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
30576 </pre></blockquote>
30577
30578
30579 <p><i>[
30580 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
30581 is to adopt the proposed wording in this issue).
30582 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30583 ]</i></p>
30584
30585
30586
30587
30588
30589 <hr>
30590 <h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
30591 <p><b>Section:</b> 26.5.1.4 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30592  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
30593 <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>
30594 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30595 <p><b>Discussion:</b></p>
30596 <p>
30597 Table 98 and para 5 in 26.5.1.4 [rand.req.eng] specify
30598 the IO insertion and extraction semantic of random
30599 number engines. It can be shown, v.i., that the specification
30600 of the extractor cannot guarantee to fulfill the requirement
30601 from para 5:
30602 </p>
30603
30604 <blockquote><p>
30605 If a textual representation written via os &lt;&lt; x was
30606 subsequently read via is &gt;&gt; v, then x == v provided that
30607 there have been no intervening invocations of x or of v.
30608 </p></blockquote>
30609
30610 <p>
30611 The problem is, that the extraction process described in
30612 table 98 misses to specify that it will initially set the
30613 if.fmtflags to ios_base::dec, see table 104:
30614 </p>
30615
30616 <blockquote><p>
30617 dec: converts integer input or generates integer output
30618 in decimal base
30619 </p></blockquote>
30620
30621 <p>
30622 Proof: The following small program demonstrates the violation
30623 of requirements (exception safety not fulfilled):
30624 </p>
30625
30626 <blockquote><pre>#include &lt;cassert&gt;
30627 #include &lt;ostream&gt;
30628 #include &lt;iostream&gt;
30629 #include &lt;iomanip&gt;
30630 #include &lt;sstream&gt;
30631
30632 class RanNumEngine {
30633   int state;
30634 public:
30635   RanNumEngine() : state(42) {}
30636
30637   bool operator==(RanNumEngine other) const {
30638       return state == other.state;
30639   }
30640
30641   template &lt;typename Ch, typename Tr&gt;
30642   friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
30643     Ch old = os.fill(os.widen(' ')); // Sets space character
30644     std::ios_base::fmtflags f = os.flags();
30645     os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
30646     os.fill(old); // Undo
30647     os.flags(f);
30648     return os;
30649   }
30650
30651   template &lt;typename Ch, typename Tr&gt;
30652   friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
30653        // Uncomment only for the fix.
30654
30655     //std::ios_base::fmtflags f = is.flags();
30656     //is &gt;&gt; std::dec;
30657     is &gt;&gt; engine.state;
30658     //is.flags(f);
30659     return is;
30660   }
30661 };
30662
30663 int main() {
30664     std::stringstream s;
30665     s &lt;&lt; std::setfill('#'); // No problem
30666         s &lt;&lt; std::oct; // Yikes!
30667         // Here starts para 5 requirements:
30668     RanNumEngine x;
30669     s &lt;&lt; x;
30670     RanNumEngine v;
30671     s &gt;&gt; v;
30672     assert(x == v); // Fails: 42 == 34
30673 }
30674 </pre></blockquote>
30675
30676 <p>
30677 A second, minor issue seems to be, that the insertion
30678 description from table 98 unnecessarily requires the
30679 addition of ios_base::fixed (which only influences floating-point
30680 numbers). Its not entirely clear to me whether the proposed
30681 standard does require that the state of random number engines
30682 is stored in integral types or not, but I have the impression
30683 that this is the indent, see e.g. p. 3
30684 </p>
30685
30686 <blockquote><p>
30687 The specification of each random number engine defines the
30688 size of its state in multiples of the size of its result_type.
30689 </p></blockquote>
30690
30691 <p>
30692 If other types than integrals are supported, then I wonder why
30693 no requirements are specified for the precision of the stream.
30694 </p>
30695
30696 <p>
30697 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
30698 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
30699 for some further discussion.
30700 </p>
30701
30702
30703 <p><b>Proposed resolution:</b></p>
30704 <p>
30705 Adopt the proposed resolution in
30706 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
30707 </p>
30708
30709
30710 <p><i>[
30711 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
30712 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30713 ]</i></p>
30714
30715
30716
30717
30718
30719 <hr>
30720 <h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
30721 <p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30722  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
30723 <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>
30724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30725 <p><b>Discussion:</b></p>
30726 <p>
30727 In 26.5.2 [rand.synopsis] we have the declaration
30728 </p>
30729
30730 <blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
30731   size_t bits&gt;
30732 result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
30733 </pre></blockquote>
30734
30735 <p>
30736 Besides the "result_type" issue (already recognized by Bo Persson
30737 at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
30738 the template parameter order is not reasonably choosen: Obviously
30739 one always needs to specify all three parameters, although usually
30740 only two are required, namely the result type RealType and the
30741 wanted bits, because UniformRandomNumberGenerator can usually
30742 be deduced.
30743 </p>
30744
30745 <p>
30746 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
30747 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
30748 for some further discussion.
30749 </p>
30750
30751
30752 <p><b>Proposed resolution:</b></p>
30753 <p>
30754 Adopt the proposed resolution in
30755 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
30756 </p>
30757
30758
30759 <p><i>[
30760 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
30761 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30762 ]</i></p>
30763
30764
30765
30766
30767
30768 <hr>
30769 <h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
30770 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
30771  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-19 <b>Last modified:</b> 2010-11-19</p>
30772 <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>
30773 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
30774 <p><b>Discussion:</b></p>
30775 <p>
30776 The header <tt>&lt;functional&gt;</tt> synopsis in 20.8 [function.objects]
30777 contains the following two free comparison operator templates
30778 for the <tt>function</tt> class template
30779 </p>
30780
30781 <blockquote><pre>template&lt;class Function1, class Function2&gt;
30782 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
30783 template&lt;class Function1, class Function2&gt;
30784 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
30785 </pre></blockquote>
30786
30787 <p>
30788 which are nowhere described. I assume that they are relicts before the
30789 corresponding two private and undefined member templates in the function
30790 template (see 20.8.14.2 [func.wrap.func] and  [func.wrap.func.undef]) have been introduced. The original free
30791 function templates should be removed, because using an undefined entity
30792 would lead to an ODR violation of the user.
30793 </p>
30794
30795
30796 <p><b>Proposed resolution:</b></p>
30797 <p>
30798 Remove the above mentioned two function templates from
30799 the header <tt>&lt;functional&gt;</tt> synopsis (20.8 [function.objects])
30800 </p>
30801
30802 <blockquote><pre><del>template&lt;class Function1, class Function2&gt;
30803 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
30804 template&lt;class Function1, class Function2&gt;
30805 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
30806 </pre></blockquote>
30807
30808
30809
30810 <p><b>Rationale:</b></p>
30811 Fixed by
30812 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
30813 Standard Library Applications for Deleted Functions.
30814
30815
30816
30817
30818
30819 <hr>
30820 <h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
30821 <p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
30822  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25 <b>Last modified:</b> 2010-10-29</p>
30823 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
30824 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
30825 <p><b>Discussion:</b></p>
30826 <p>
30827 Greg Herlihy has clearly demonstrated that a user defined input
30828 iterator should have an operator-&gt;(), even if its
30829 value type is a built-in type (comp.std.c++, "Re: Should any iterator
30830 have an operator-&gt;() in C++0x?", March 2007).  And as Howard
30831 Hinnant remarked in the same thread that the input iterator
30832 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
30833 defect!
30834 </p>
30835 <p>
30836 Based on Greg's example, the following code demonstrates the issue:
30837 </p><pre> #include &lt;iostream&gt; 
30838  #include &lt;fstream&gt;
30839  #include &lt;streambuf&gt; 
30840
30841  typedef char C;
30842  int main ()
30843  {
30844    std::ifstream s("filename", std::ios::in);
30845    std::istreambuf_iterator&lt;char&gt; i(s);
30846
30847    (*i).~C();  // This is well-formed...
30848    i-&gt;~C();  // ... so this should be supported!
30849  }
30850 </pre>
30851 <p></p>
30852 <p>
30853 Of course, operator-&gt; is also needed when the value_type of
30854 istreambuf_iterator is a class.
30855 </p>
30856 <p>
30857 The operator-&gt; could be implemented in various ways.  For instance,
30858 by storing the current value inside the iterator, and returning its
30859 address.  Or by returning a proxy, like operator_arrow_proxy, from
30860 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
30861 </p>
30862 <p>
30863 I hope that the resolution of this issue will contribute to getting a
30864 clear and consistent definition of iterator concepts.
30865 </p>
30866
30867 <p><i>[
30868 Kona (2007): The proposed resolution is inconsistent because the return
30869 type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
30870 but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
30871 ]</i></p>
30872
30873
30874 <p><i>[
30875 Niels Dekker (mailed to Howard Hinnant):
30876 ]</i></p>
30877
30878 <blockquote>
30879 <p>
30880 The proposed resolution does
30881 not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
30882 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
30883 may in fact be a proxy.
30884 </p>
30885 <p>
30886 AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
30887 unspecified for some iterator categories") implies that for any iterator
30888 class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
30889 definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
30890 </p>
30891 <p>
30892 Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
30893 be removed from the resolution. I think it's up to the library
30894 implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
30895 longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
30896 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
30897 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
30898 </p>
30899 </blockquote>
30900
30901 <p><i>[
30902 2009-04-30 Alisdair adds:
30903 ]</i></p>
30904
30905
30906 <blockquote>
30907 Note that operator-&gt; is now a requirement in the <tt>InputIterator</tt> concept, so
30908 this issue cannot be ignored or existing valid programs will break when
30909 compiled with an 0x library.
30910 </blockquote>
30911
30912 <p><i>[
30913 2009-05-29 Alisdair adds:
30914 ]</i></p>
30915
30916
30917 <blockquote>
30918 <p>
30919 I agree with the observation that in principle the type 'pointer' may be a
30920 proxy, and the words highlighting this are redundant.
30921 </p>
30922 <p>
30923 However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
30924 by the derivation from <tt>std::iterator</tt>.  At a minimum, the 4th parameter of
30925 this base class template should become unspecified.  That permits the
30926 introduction of a proxy as a nested class in some further undocumented (not
30927 even exposition-only) base.
30928 </p>
30929 <p>
30930 It also permits the <tt>istream_iterator</tt> approach where the cached value is
30931 stored in the iterator itself, and the iterator serves as its own proxy for
30932 post-increment <tt>operator++</tt> - removing the need for the existing
30933 exposition-only nested class <tt>proxy</tt>.
30934 </p>
30935 <p>
30936 Note that the current <tt>proxy</tt> class also has exactly the right properties to
30937 serve as the pointer <tt>proxy</tt> too.  This is likely to be a common case where an
30938 <tt>InputIterator</tt> does not hold internal state but delegates to another class.
30939 </p>
30940 <p>
30941 Proposed Resolution:
30942 </p>
30943 <p>
30944 In addition to the current proposal:
30945 </p>
30946 <p>
30947 24.6.3 [istreambuf.iterator]
30948 </p>
30949 <blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
30950 class istreambuf_iterator
30951   : public iterator&lt;input_iterator_tag, charT,
30952                     typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
30953 </pre></blockquote>
30954 </blockquote>
30955
30956 <p><i>[
30957 2009-07 Frankfurt
30958 ]</i></p>
30959
30960
30961 <blockquote>
30962 <p>
30963 Move the additional part into the proposed resolution, and wrap the
30964 descriptive text in a Note.
30965 </p>
30966 <p><i>[Howard: done.]</i></p>
30967
30968 <p>
30969 Move to Ready.
30970 </p>
30971 </blockquote>
30972
30973
30974
30975 <p><b>Proposed resolution:</b></p>
30976 <p>
30977 Add to the synopsis in 24.6.3 [istreambuf.iterator]:
30978 </p>
30979
30980 <blockquote><pre>charT operator*() const;
30981 <ins>pointer operator-&gt;() const;</ins>
30982 istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
30983 </pre></blockquote>
30984
30985 <p>
30986 24.6.3 [istreambuf.iterator]
30987 </p>
30988
30989 <blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
30990 class istreambuf_iterator
30991   : public iterator&lt;input_iterator_tag, charT,
30992                     typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
30993 </pre></blockquote>
30994
30995 <p>
30996 Change 24.6.3 [istreambuf.iterator], p1:
30997 </p>
30998
30999 <blockquote><p>
31000 The class template <tt>istreambuf_iterator</tt> reads successive
31001 characters from the <tt>streambuf</tt> for which it was constructed.
31002 <tt>operator*</tt> provides access to the current input character, if
31003 any. <ins>[<i>Note:</i> <tt>operator-&gt;</tt> may return a proxy. \97
31004 <i>end note</i>]</ins> Each time
31005 <tt>operator++</tt> is evaluated, the iterator advances to the next
31006 input character. If the end of stream is reached
31007 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
31008 iterator becomes equal to the end of stream iterator value. The default
31009 constructor <tt>istreambuf_iterator()</tt> and the constructor
31010 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
31011 object suitable for use as an end-of-range.
31012 </p></blockquote>
31013
31014
31015
31016
31017
31018
31019
31020 <hr>
31021 <h3><a name="660"></a>660. Missing Bitwise Operations</h3>
31022 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31023  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-04-02 <b>Last modified:</b> 2010-10-29</p>
31024 <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>
31025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31026 <p><b>Discussion:</b></p>
31027 <p>Section 20.8 [function.objects] provides <span id="st" name="st" class="st">function</span>
31028 <span id="st" name="st" class="st">objects</span> for some unary and binary 
31029 operations, but others are missing. In a LWG reflector discussion, beginning 
31030 with c++std-lib-18078, pros and cons of adding some of the missing operations 
31031 were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
31032 Yes, I see the chicken and egg problems here, but it would be nice to see a 
31033 couple of genuine uses before making additions."</p>
31034 <p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
31035 already added these functions, either publicly or for internal use. For example, 
31036 Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we 
31037 need those <span id="st" name="st" class="st">function</span>
31038 <span id="st" name="st" class="st">objects</span> to represent various parallel 
31039 collective operations (reductions, prefix reductions, etc.) in the new Message 
31040 Passing Interface (MPI) library."</p>
31041 <p>Because the bitwise operators have the strongest use cases, the proposed 
31042 resolution is limited to them.</p>
31043
31044
31045 <p><b>Proposed resolution:</b></p>
31046 <p>To 20.8 [function.objects], Function objects, paragraph 2, add to the header 
31047 &lt;functional&gt; synopsis:</p>
31048 <blockquote>
31049   <pre>template &lt;class T&gt; struct bit_and;
31050 template &lt;class T&gt; struct bit_or;
31051 template &lt;class T&gt; struct bit_xor;</pre>
31052 </blockquote>
31053 <p>At a location in clause 20 to be determined by the Project Editor, add:</p>
31054 <blockquote>
31055   <p>The library provides basic function object classes for all of the bitwise 
31056   operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
31057   <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
31058   T operator()(const T&amp; x , const T&amp; y ) const;
31059 };</pre>
31060   <blockquote>
31061     <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
31062   </blockquote>
31063   <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
31064   T operator()(const T&amp; x , const T&amp; y ) const;
31065 };</pre>
31066   <blockquote>
31067     <p><code>operator()</code> returns <code>x | y</code> .</p>
31068   </blockquote>
31069   <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
31070   T operator()(const T&amp; x , const T&amp; y ) const;
31071 };</pre>
31072   <blockquote>
31073     <p><code>operator()</code> returns <code>x ^ y</code> .</p>
31074   </blockquote>
31075 </blockquote>
31076
31077
31078
31079
31080
31081 <hr>
31082 <h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
31083 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31084  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-04-01 <b>Last modified:</b> 2010-10-29</p>
31085 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
31086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31087 <p><b>Discussion:</b></p>
31088 <p>
31089 To the more drastic changes of 27.7.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
31090 the explicit description of the extraction of the types short and int in
31091 terms of as-if code fragments.
31092 </p>
31093
31094 <ol>
31095 <li>
31096 The corresponding as-if extractions in paragraph 2 and 3 will never
31097 result in a change of the operator&gt;&gt; argument val, because the
31098 contents of the local variable lval is in no case written into val.
31099 Furtheron both fragments need a currently missing parentheses in the
31100 beginning of the if-statement to be valid C++.
31101 </li>
31102 <li>
31103 I would like to ask whether the omission of a similar explicit
31104 extraction of unsigned short and unsigned int in terms of long -
31105 compared to their corresponding new insertions, as described in 27.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or an
31106 oversight.
31107 </li>
31108 </ol>
31109
31110
31111 <p><b>Proposed resolution:</b></p>
31112 <ol>
31113 <li>
31114 <p>
31115 In 27.7.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
31116 </p>
31117 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
31118 iostate err = 0;
31119 long lval;
31120 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
31121 if (err == 0) <ins>{</ins>
31122   <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
31123       err = ios_base::failbit;
31124   <ins>else
31125     val = static_cast&lt;short&gt;(lval);
31126 }</ins>
31127 setstate(err);
31128 </pre></blockquote>
31129
31130 <p>
31131 Similarily in 27.7.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
31132 </p>
31133
31134 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
31135 iostate err = 0;
31136 long lval;
31137 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
31138 if (err == 0) <ins>{</ins>
31139   <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
31140       err = ios_base::failbit;
31141   <ins>else
31142     val = static_cast&lt;int&gt;(lval);
31143 }</ins>
31144 setstate(err);
31145 </pre></blockquote>
31146 </li>
31147 <li>
31148 ---
31149 </li>
31150 </ol>
31151
31152
31153 <p><i>[
31154 Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
31155 is incorrectly italicized in the code fragments corresponding to
31156 <tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
31157 twice on the line with the <tt>static_cast</tt> in the proposed resolution --
31158 should be italicized. Also, in response to part two of the issue: this
31159 is deliberate.
31160 ]</i></p>
31161
31162
31163
31164
31165
31166 <hr>
31167 <h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
31168 <p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31169  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
31170 <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>
31171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31172 <p><b>Discussion:</b></p>
31173 <p>
31174 22.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
31175 </p>
31176
31177 <blockquote><p>
31178 <i>Effects:</i> Places characters starting at to that should be appended to
31179 terminate a sequence when the current <tt>stateT</tt> is given by
31180 <tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
31181 <i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
31182 pointer pointing one beyond the last element successfully stored.
31183 <em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
31184 </p></blockquote>
31185
31186 <p>
31187 The following objection has been raised:
31188 </p>
31189
31190 <blockquote><p>
31191 Since the C++ Standard permits a nontrivial conversion for the required
31192 instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
31193 <tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
31194 </p></blockquote>
31195
31196 <p>
31197 [Plum ref _222152Y50]
31198 </p>
31199
31200
31201 <p><b>Proposed resolution:</b></p>
31202 <p>
31203 Change 22.4.1.4.2 [locale.codecvt.virtuals], p7:
31204 </p>
31205
31206 <blockquote>
31207 <p>
31208 <i>Effects:</i> Places characters starting at <i>to</i> that should be
31209 appended to terminate a sequence when the current <tt>stateT</tt> is
31210 given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
31211 destination elements, and leaves the <i>to_next</i> pointer pointing one
31212 beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
31213 mbstate_t&gt;</tt> stores no characters.</del>
31214 </p>
31215 </blockquote>
31216
31217
31218
31219
31220
31221 <hr>
31222 <h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
31223 <p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31224  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
31225 <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>
31226 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31227 <p><b>Discussion:</b></p>
31228 <p>
31229 22.4.1.4.2 [locale.codecvt.virtuals], para 8 says:
31230 </p>
31231
31232 <blockquote><p>
31233 <tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
31234 </p></blockquote>
31235
31236 <p>
31237 The following objection has been raised:
31238 </p>
31239
31240 <blockquote><p>
31241 Despite what the C++ Standard 
31242 says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since 
31243 they can be nontrivial. At least one implementation does whatever the 
31244 C functions do.
31245 </p></blockquote>
31246
31247 <p>
31248 [Plum ref _222152Y62]
31249 </p>
31250
31251
31252 <p><b>Proposed resolution:</b></p>
31253 <p>
31254 Change 22.4.1.4.2 [locale.codecvt.virtuals], p8:
31255 </p>
31256
31257 <blockquote>
31258 <p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
31259 <p>...</p>
31260 <p>
31261 <del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
31262 </p>
31263 </blockquote>
31264
31265
31266
31267
31268
31269
31270 <hr>
31271 <h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
31272 <p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31273  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
31274 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
31275 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31276 <p><b>Discussion:</b></p>
31277 <p>
31278 22.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
31279 </p>
31280
31281 <blockquote><p>
31282 <sup>257)</sup> For international 
31283 specializations (second template parameter <tt>true</tt>) this is always four 
31284 characters long, usually three letters and a space.
31285 </p></blockquote>
31286
31287 <p>
31288 The following objection has been raised:
31289 </p>
31290
31291 <blockquote><p>
31292 The international currency 
31293 symbol is whatever the underlying locale says it is, not necessarily 
31294 four characters long.
31295 </p></blockquote>
31296
31297 <p>
31298 [Plum ref _222632Y41]
31299 </p>
31300
31301
31302 <p><b>Proposed resolution:</b></p>
31303 <p>
31304 Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]:
31305 </p>
31306
31307 <blockquote>
31308 <p>
31309 <sup>253)</sup> For international specializations (second template
31310 parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
31311 four characters long, usually three letters and a space.
31312 </p>
31313 </blockquote>
31314
31315
31316
31317
31318
31319 <hr>
31320 <h3><a name="671"></a>671. precision of hexfloat</h3>
31321 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
31322  <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20 <b>Last modified:</b> 2010-10-29</p>
31323 <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>
31324 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
31325 <p><b>Discussion:</b></p>
31326 <p>
31327 I am trying to understand how TR1 supports hex float (%a) output.
31328 </p>
31329 <p>
31330 As far as I can tell, it does so via the following:
31331 </p>
31332 <p>
31333 8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
31334 </p>
31335 <p>
31336 In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
31337 the line:
31338 floatfield == ios_base::scientific %E
31339 </p>
31340 <p>
31341 add the two lines:
31342 </p>
31343 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
31344 floatfield == ios_base::fixed | ios_base::scientific %A 2
31345 </pre></blockquote>
31346 <p>
31347 [Note: The additional requirements on print and scan functions, later
31348 in this clause, ensure that the print functions generate hexadecimal
31349 floating-point fields with a %a or %A conversion specifier, and that
31350 the scan functions match hexadecimal floating-point fields with a %g
31351 conversion specifier.  end note]
31352 </p>
31353 <p>
31354 Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
31355 </p>
31356 <p>
31357 For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
31358 if str.precision() &gt; 0, then str.precision() is specified in the
31359 conversion specification.
31360 </p>
31361 <p>
31362 This would seem to imply that when floatfield == fixed|scientific, the
31363 precision of the conversion specifier is to be taken from
31364 str.precision().  Is this really what's intended?  I sincerely hope
31365 that I'm either missing something or this is an oversight.  Please
31366 tell me that the committee did not intend to mandate that hex floats
31367 (and doubles) should by default be printed as if by %.6a.
31368 </p>
31369
31370 <p><i>[
31371 Howard: I think the fundamental issue we overlooked was that with %f,
31372 %e, %g, the default precision was always 6.  With %a the default
31373 precision is not 6, it is infinity.  So for the first time, we need to
31374 distinguish between the default value of precision, and the precision
31375 value 6.
31376 ]</i></p>
31377
31378
31379 <p><i>[
31380 2009-07 Frankfurt
31381 ]</i></p>
31382
31383
31384 <blockquote>
31385 <p>
31386 Leave this open for Robert and Daniel to work on.
31387 </p>
31388 <p>
31389 Straw poll: Disposition?
31390 </p>
31391 <ul>
31392 <li>Default is %.6a (i.e. NAD): 2</li>
31393 <li>Always %a (no precision): 6</li>
31394 <li>precision(-1) == %a: 3</li>
31395 </ul>
31396 <p>
31397 Daniel and Robert have direction to write up wording for the "always %a" solution.
31398 </p>
31399
31400 <p><i>[
31401 2009-07-15 Robert provided wording.
31402 ]</i></p>
31403
31404 </blockquote>
31405
31406 <p><i>[
31407 2009-10 Santa Cruz:
31408 ]</i></p>
31409
31410
31411 <blockquote>
31412 Move to Ready.
31413 </blockquote>
31414
31415
31416
31417 <p><b>Proposed resolution:</b></p>
31418 <p>
31419 Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end
31420 of Stage 1):
31421 </p>
31422
31423 <blockquote>
31424 For conversion from a floating-point type, <tt>str.precision()</tt> is specified
31425 <ins>as precision</ins> in the conversion specification
31426 <ins>if <tt>floatfield != (ios_base::fixed | ios_base::scientific)</tt>, else no
31427 precision is specified</ins>.
31428 </blockquote>
31429
31430
31431
31432 <p><i>[
31433 Kona (2007): Robert volunteers to propose wording.
31434 ]</i></p>
31435
31436
31437
31438
31439
31440 <hr>
31441 <h3><a name="672"></a>672. Swappable requirements need updating</h3>
31442 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31443  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2010-10-29</p>
31444 <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>
31445 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31446 <p><b>Discussion:</b></p>
31447 <p>
31448 The current <tt>Swappable</tt> is:
31449 </p>
31450
31451 <blockquote>
31452 <table border="1">
31453 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
31454 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
31455 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally 
31456 held by <tt>t</tt></td></tr>
31457 <tr><td colspan="3">
31458 <p>
31459 The Swappable requirement is met by satisfying one or more of the following conditions:
31460 </p>
31461 <ul>
31462 <li>
31463 <tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) 
31464 and the <tt>CopyAssignable</tt> requirements (Table 36);
31465 </li>
31466 <li>
31467 <tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same 
31468 namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid 
31469 and has the semantics described in this table.
31470 </li>
31471 </ul>
31472 </td></tr>
31473 </tbody></table>
31474 </blockquote>
31475
31476 <p>
31477 With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
31478 require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
31479 </p>
31480
31481 <p>
31482 Additionally we may want to support proxy references such that the following code is acceptable:
31483 </p>
31484
31485 <blockquote><pre>namespace Mine {
31486
31487 template &lt;class T&gt;
31488 struct proxy {...};
31489
31490 template &lt;class T&gt;
31491 struct proxied_iterator
31492 {
31493    typedef T value_type;
31494    typedef proxy&lt;T&gt; reference;
31495    reference operator*() const;
31496    ...
31497 };
31498
31499 struct A
31500 {
31501    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
31502    void swap(A&amp;);
31503    ...
31504 };
31505
31506 void swap(A&amp;, A&amp;);
31507 void swap(proxy&lt;A&gt;, A&amp;);
31508 void swap(A&amp;, proxy&lt;A&gt;);
31509 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
31510
31511 }  // Mine
31512
31513 ...
31514
31515 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
31516 Mine::A a;
31517 swap(*i1, a);
31518 </pre></blockquote>
31519
31520 <p>
31521 I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
31522 itself.  We do not need to anything in terms of implementation except not block their way with overly
31523 constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
31524 between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
31525 </p>
31526
31527
31528
31529 <p><b>Proposed resolution:</b></p>
31530
31531 <p>
31532 Change 20.2.1 [utility.arg.requirements]:
31533 </p>
31534
31535 <blockquote>
31536
31537 <p>
31538 -1- The template definitions in the C++ Standard Library refer to various
31539 named requirements whose details are set out in tables 31-38. In these
31540 tables, <tt>T</tt> is a type to be supplied by a C++ program
31541 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
31542 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
31543 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
31544 <tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
31545 rvalue of type <tt>T</tt>.
31546 </p>
31547
31548 <table border="1">
31549 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
31550 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
31551 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
31552 <td><tt>t</tt> has the value originally
31553 held by <tt>u</tt>, and
31554 <tt>u</tt> has the value originally held
31555 by <tt>t</tt></td></tr>
31556 <tr><td colspan="3">
31557 <p>
31558 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
31559 </p>
31560 <ul>
31561 <li>
31562 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
31563 <del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
31564 requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
31565 requirements (Table <del>36</del> <ins>35</ins>);
31566 </li>
31567 <li>
31568 <tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
31569 <tt>swap</tt> exists in the same namespace as the definition of
31570 <tt>T</tt>, such that the expression
31571 <tt>swap(t,u)</tt> is valid and has the
31572 semantics described in this table.
31573 </li>
31574 </ul>
31575 </td></tr>
31576 </tbody></table>
31577 </blockquote>
31578
31579
31580
31581 <p><i>[
31582 Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
31583 move semantics. The issue relating to the support of proxies is
31584 separable from the one relating to move semantics, and it's bigger than
31585 just swap. We'd like to address only the move semantics changes under
31586 this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>) to handle proxies. Also, there
31587 may be a third issue, in that the current definition of <tt>Swappable</tt> does
31588 not permit rvalues to be operands to a swap operation, and Howard's
31589 proposed resolution would allow the right-most operand to be an rvalue,
31590 but it would not allow the left-most operand to be an rvalue (some swap
31591 functions in the library have been overloaded to permit left operands to
31592 swap to be rvalues).
31593 ]</i></p>
31594
31595
31596
31597
31598
31599 <hr>
31600 <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
31601 <p><b>Section:</b> 20.9.9 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31602  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2010-10-29</p>
31603 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
31604 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31605 <p><b>Discussion:</b></p>
31606 <p>
31607 Since the publication of
31608 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
31609 there have been a few small but significant advances which should be included into
31610 <tt>unique_ptr</tt>.  There exists a
31611 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
31612 for all of these changes.
31613 </p>
31614
31615 <ul>
31616
31617 <li>
31618 <p>
31619 Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
31620 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
31621 even if it is never used.  For example see
31622 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
31623 happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
31624 type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
31625 <tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
31626 the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
31627 This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
31628 face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
31629 </p>
31630
31631 <p>
31632 This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
31633 which could be very useful to the client.
31634 </p>
31635
31636 </li>
31637
31638 <li>
31639 <p>
31640 Efforts have been made to better support containers and smart pointers in shared
31641 memory contexts.  One of the key hurdles in such support is not assuming that a
31642 pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
31643 for <tt>unique_ptr</tt> by having the deleter define the pointer type:
31644 <tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
31645 <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
31646 type (example implementation
31647 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
31648 This change has no run time overhead.  It has no interface overhead on
31649 authors of custom delter types.  It simply allows (but not requires)
31650 authors of custom deleter types to define a smart pointer for the
31651 storage type of <tt>unique_ptr</tt> if they find such functionality
31652 useful.  <tt>std::default_delete</tt> is an example of a deleter which
31653 defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
31654 and not including a <tt>pointer typedef</tt>.
31655 </p>
31656 </li>
31657
31658 <li>
31659 <p>
31660 When the deleter type is a function pointer then it is unsafe to construct
31661 a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
31662 This case is easy to check for with a <tt>static_assert</tt> assuring that the
31663 deleter is not a pointer type in those constructors which do not accept deleters.
31664 </p>
31665
31666 <blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
31667 </pre></blockquote>
31668
31669 </li>
31670
31671 </ul>
31672
31673 <p><i>[
31674 Kona (2007): We don't like the solution given to the first bullet in
31675 light of concepts. The second bullet solves the problem of supporting
31676 fancy pointers for one library component only. The full LWG needs to
31677 decide whether to solve the problem of supporting fancy pointers
31678 piecemeal, or whether a paper addressing the whole library is needed. We
31679 think that the third bullet is correct.
31680 ]</i></p>
31681
31682
31683 <p><i>[
31684 Post Kona: Howard adds example user code related to the first bullet:
31685 ]</i></p>
31686
31687
31688 <blockquote>
31689 <pre>void legacy_code(void*, std::size_t);
31690
31691 void foo(std::size_t N)
31692 {
31693     std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
31694     legacy_code(ptr.get(), N);
31695 }   // unique_ptr used for exception safety purposes
31696 </pre>
31697 </blockquote>
31698
31699 <p>
31700 I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
31701 to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
31702 want to disable (with concepts or by other means) are the two member functions:
31703 </p>
31704
31705 <blockquote><pre>T&amp; operator*() const;
31706 T* operator-&gt;() const;
31707 </pre></blockquote>
31708
31709
31710
31711 <p><b>Proposed resolution:</b></p>
31712
31713 <p><i>[
31714 I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
31715 the proposed resolutions below.
31716 ]</i></p>
31717
31718
31719 <ul>
31720 <li>
31721
31722 <p>
31723 Change 20.9.9.2 [unique.ptr.single]:
31724 </p>
31725
31726 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
31727    ...
31728    <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
31729    ...
31730 };
31731 </pre></blockquote>
31732
31733 <p>
31734 Change 20.9.9.2.4 [unique.ptr.single.observers]:
31735 </p>
31736
31737 <blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
31738 </pre></blockquote>
31739
31740 </li>
31741
31742 <li>
31743 <p>
31744 Change 20.9.9.2 [unique.ptr.single]:
31745 </p>
31746
31747 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
31748 public:
31749   <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
31750    ...
31751    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
31752    ...
31753    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
31754    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
31755    ...
31756    <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
31757    <del>T*</del> <ins>pointer</ins> get() const;
31758    ...
31759    <del>T*</del> <ins>pointer</ins> release();
31760    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
31761 };
31762 </pre></blockquote>
31763
31764 <p>
31765 <ins>
31766 -3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
31767 exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
31768 <tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
31769 <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
31770 The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
31771 and <tt>CopyAssignable</tt>.
31772 </ins>
31773 </p>
31774
31775 <p>
31776 Change 20.9.9.2.1 [unique.ptr.single.ctor]:
31777 </p>
31778
31779 <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
31780 ...
31781 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
31782 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
31783 ...
31784 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
31785 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
31786 ...
31787 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d); 
31788 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
31789 ...
31790 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d); 
31791 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
31792 ...
31793 </pre></blockquote>
31794
31795 <p>
31796 -23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
31797 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
31798 <del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
31799 reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
31800 (diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
31801 <del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
31802 <ins>pointer</ins>.
31803 </p>
31804
31805 <p>
31806 -25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
31807 the construction, modulo any required offset adjustments resulting from
31808 the cast from <del><tt>U*</tt></del>
31809 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
31810 <ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
31811 internally stored deleter which was constructed from
31812 <tt>u.get_deleter()</tt>.
31813 </p>
31814
31815 <p>
31816 Change 20.9.9.2.3 [unique.ptr.single.asgn]:
31817 </p>
31818
31819 <blockquote>
31820 <p>
31821 -8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
31822 <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
31823 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
31824 convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
31825 </p>
31826 </blockquote>
31827
31828 <p>
31829 Change 20.9.9.2.4 [unique.ptr.single.observers]:
31830 </p>
31831
31832 <blockquote>
31833 <pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
31834 ...
31835 <pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
31836 </blockquote>
31837
31838 <p>
31839 Change 20.9.9.2.5 [unique.ptr.single.modifiers]:
31840 </p>
31841
31842 <blockquote>
31843 <pre><del>T*</del> <ins>pointer</ins> release();</pre>
31844 ...
31845 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
31846 </blockquote>
31847
31848 <p>
31849 Change 20.9.9.3 [unique.ptr.runtime]:
31850 </p>
31851
31852 <blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
31853 public:
31854   <ins>typedef <i>implementation</i> pointer;</ins>
31855    ...
31856    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
31857    ...
31858    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
31859    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
31860    ...
31861    <del>T*</del> <ins>pointer</ins> get() const;
31862    ...
31863    <del>T*</del> <ins>pointer</ins> release();
31864    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
31865 };
31866 </pre></blockquote>
31867
31868 <p>
31869 Change 20.9.9.3.1 [unique.ptr.runtime.ctor]:
31870 </p>
31871
31872 <blockquote>
31873 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
31874 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
31875 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
31876 </pre>
31877
31878 <p>
31879 These constructors behave the same as in the primary template except
31880 that they do not accept pointer types which are convertible to
31881 <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
31882 implementation technique is to create private templated overloads of
31883 these members. <i>-- end note</i>]
31884 </p>
31885 </blockquote>
31886
31887 <p>
31888 Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]:
31889 </p>
31890
31891 <blockquote>
31892 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
31893 </pre>
31894
31895 <p>
31896 -1- <i>Requires:</i> Does not accept pointer types which are convertible
31897 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
31898 required). [<i>Note:</i> One implementation technique is to create a private
31899 templated overload. <i>-- end note</i>]
31900 </p>
31901 </blockquote>
31902
31903 </li>
31904
31905 <li>
31906
31907 <p>
31908 Change 20.9.9.2.1 [unique.ptr.single.ctor]:
31909 </p>
31910
31911 <blockquote>
31912 <pre>unique_ptr();</pre>
31913 <blockquote>
31914 <p>
31915 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
31916 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
31917 reference type <ins>or pointer type (diagnostic required)</ins>.
31918 </p>
31919 </blockquote>
31920 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
31921 <blockquote>
31922 <p>
31923 <i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
31924 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
31925 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
31926 required)</ins>.
31927 </p>
31928 </blockquote>
31929 </blockquote>
31930
31931 </li>
31932
31933 </ul>
31934
31935
31936
31937
31938
31939
31940 <hr>
31941 <h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
31942 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31943  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
31944 <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>
31945 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31946 <p><b>Discussion:</b></p>
31947 <p>
31948 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
31949 any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
31950 and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
31951 </p>
31952
31953
31954 <p><b>Proposed resolution:</b></p>
31955
31956 <p>
31957 Change 20.9.10.2 [util.smartptr.shared] as follows:
31958 </p>
31959
31960 <blockquote>
31961 <pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
31962 <ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
31963 template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
31964 ...
31965 template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
31966 <ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
31967 template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
31968 </blockquote>
31969
31970 <p>
31971 Change 20.9.10.2.1 [util.smartptr.shared.const] as follows:
31972 </p>
31973
31974 <blockquote>
31975 <pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
31976 </blockquote>
31977
31978 <p>
31979 Add to 20.9.10.2.1 [util.smartptr.shared.const]:
31980 </p>
31981
31982 <blockquote>
31983 <pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
31984 <blockquote>
31985
31986 <p><ins>
31987 <i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
31988           not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
31989           otherwise.
31990 </ins></p>
31991
31992 <p><ins>
31993 <i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
31994 </ins></p>
31995 </blockquote>
31996
31997 </blockquote>
31998
31999 <p>
32000 Change 20.9.10.2.3 [util.smartptr.shared.assign] as follows:
32001 </p>
32002
32003 <blockquote>
32004 <pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
32005 </blockquote>
32006
32007 <p>
32008 Add to 20.9.10.2.3 [util.smartptr.shared.assign]:
32009 </p>
32010
32011 <blockquote>
32012 <pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
32013
32014 <blockquote>
32015 <p><ins>
32016 -4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
32017 </ins></p>
32018 <p><ins>
32019 -5- <i>Returns:</i> <tt>*this</tt>.
32020 </ins></p>
32021 </blockquote>
32022
32023 </blockquote>
32024
32025
32026
32027 <p><i>[
32028 Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of
32029 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
32030 ]</i></p>
32031
32032
32033
32034
32035
32036 <hr>
32037 <h3><a name="675"></a>675. Move assignment of containers</h3>
32038 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32039  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
32040 <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>
32041 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32042 <p><b>Discussion:</b></p>
32043 <p>
32044 James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
32045 (just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
32046 the wrong semantics under move assignment when the source is not truly an rvalue, but a
32047 moved-from lvalue (destructors could run late).
32048 </p>
32049
32050 <blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
32051 <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
32052 ...
32053 v1 = v2;               // #1
32054 v1 = std::move(v2);    // #2
32055 </pre></blockquote>
32056
32057 <p>
32058 Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
32059 It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
32060 both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
32061 <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
32062 copy assignment or move assignment.
32063 </p>
32064
32065 <p>
32066 This implies that the semantics of move assignment of a generic container should be
32067 <tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
32068 effect would be to move assign each element.  In either case, the complexity of move
32069 assignment needs to be relaxed to <tt>O(v1.size())</tt>.
32070 </p>
32071
32072 <p>
32073 The performance hit of this change is not nearly as drastic as it sounds. 
32074 In practice, the target of a move assignment has always just been move constructed
32075 or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
32076 this common use case) we are still achieving O(1) complexity.
32077 </p>
32078
32079
32080
32081 <p><b>Proposed resolution:</b></p>
32082 <p>
32083 Change 23.2 [container.requirements]:
32084 </p>
32085
32086 <blockquote>
32087 <table border="1">
32088 <caption>Table 89: Container requirements</caption>
32089 <tbody><tr>
32090 <th>expression</th><th>return type</th><th>operational semantics</th>
32091 <th>assertion/note pre/post-condition</th><th>complexity</th>
32092 </tr>
32093 <tr>
32094 <td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
32095 <td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
32096 <td><tt>a</tt> shall be equal to the 
32097 value that <tt>rv</tt> had 
32098 before this construction
32099 </td>
32100 <td><del>(Note C)</del> <ins>linear</ins></td>
32101 </tr>
32102 </tbody></table>
32103
32104 <p>
32105 Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
32106 <tt>lexicographical_compare()</tt> are defined in clause 25. Those
32107 entries marked "(Note A)" should have constant complexity. Those entries
32108 marked "(Note B)" have constant complexity unless
32109 <tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
32110 <tt>true</tt>, in which case they have linear complexity.
32111 <del>Those entries
32112 marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
32113 rv.get_allocator()</tt> or if either
32114 <tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
32115 is <tt>true</tt> or
32116 <tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
32117 is <tt>true</tt> and linear complexity otherwise.</del>
32118 </p>
32119 </blockquote>
32120
32121
32122
32123 <p><i>[
32124 post Bellevue Howard adds:
32125 ]</i></p>
32126
32127
32128 <blockquote>
32129 <p>
32130 This issue was voted to WP in Bellevue, but accidently got stepped on by
32131 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
32132 which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
32133 the wording right.  The intent of this issue and N2525 are not in conflict.
32134 </p>
32135 </blockquote>
32136
32137 <p><i>[
32138 post Sophia Antipolis Howard updated proposed wording:
32139 ]</i></p>
32140
32141
32142
32143
32144
32145 <hr>
32146 <h3><a name="676"></a>676. Moving the unordered containers</h3>
32147 <p><b>Section:</b> 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
32148  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
32149 <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>
32150 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
32151 <p><b>Discussion:</b></p>
32152 <p>
32153 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
32154 resolution below adds move-support consistent with
32155 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
32156 and the current working draft.
32157 </p>
32158
32159 <p>
32160 The current proposed resolution simply lists the requirements for each function.
32161 These might better be hoisted into the requirements table for unordered associative containers.
32162 Futhermore a mild reorganization of the container requirements could well be in order.
32163 This defect report is purposefully ignoring these larger issues and just focusing
32164 on getting the unordered containers "moved".
32165 </p>
32166
32167 <p><i>[
32168 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
32169 ]</i></p>
32170
32171
32172 <p><i>[
32173 2009-10-17 Removed rvalue-swaps from wording.
32174 ]</i></p>
32175
32176
32177 <p><i>[
32178 2009-10 Santa Cruz:
32179 ]</i></p>
32180
32181
32182 <blockquote>
32183 Move to Review. Alisdair will review proposed wording.
32184 </blockquote>
32185
32186 <p><i>[
32187 2009-10-29 Daniel updates wording.
32188 ]</i></p>
32189
32190
32191 <p><i>[
32192 2010-01-26 Alisdair updates wording.
32193 ]</i></p>
32194
32195
32196 <p><i>[
32197 2010-02-10 Howard updates wording to reference the unordered container
32198 requirements table (modified by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>) as much as possible.
32199 ]</i></p>
32200
32201
32202 <p><i>[
32203 Voted to WP in Bellevue.
32204 ]</i></p>
32205
32206
32207 <p><i>[
32208 post Bellevue, Pete notes:
32209 ]</i></p>
32210
32211
32212 <blockquote>
32213 <p>
32214 Please remind people who are reviewing issues to check that the text
32215 modifications match the current draft. Issue 676, for example, adds two
32216 overloads for unordered_map::insert taking a hint. One takes a
32217 const_iterator and returns a const_iterator, and the other takes an
32218 iterator and returns an iterator. This was correct at the time the issue
32219 was written, but was changed in Toronto so there is only one hint
32220 overload, taking a const_iterator and returning an iterator.
32221 </p>
32222 <p>
32223 This issue is not ready. In addition to the relatively minor signature
32224 problem I mentioned earlier, it puts requirements in the wrong places.
32225 Instead of duplicating requirements throughout the template
32226 specifications, it should put them in the front matter that talks about
32227 requirements for unordered containers in general. This presentation
32228 problem is editorial, but I'm not willing to do the extensive rewrite
32229 that it requires. Please put it back into Open status.
32230 </p>
32231 </blockquote>
32232
32233 <p><i>[
32234 2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
32235 ]</i></p>
32236
32237
32238 <p><i>[
32239 2010-02-24 Pete moved to Open:
32240 ]</i></p>
32241
32242
32243 <blockquote>
32244 The descriptions of the semantics of the added <tt>insert</tt> functions belong
32245 in the requirements table. That's where the rest of the <tt>insert</tt>
32246 functions are.
32247 </blockquote>
32248
32249 <p><i>[
32250 2010 Pittsburgh:
32251 ]</i></p>
32252
32253
32254 <blockquote>
32255 Move issue 676 to Ready for Pittsburgh. Nico to send Howard an issue for
32256 the broader problem.
32257 </blockquote>
32258
32259
32260
32261 <p><b>Rationale:</b></p>
32262 <p><i>[
32263 San Francisco:
32264 ]</i></p>
32265
32266
32267 <blockquote>
32268 Solved by
32269 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
32270 </blockquote>
32271
32272 <p><i>[
32273 Rationale is obsolete.
32274 ]</i></p>
32275
32276
32277
32278
32279
32280 <p><b>Proposed resolution:</b></p>
32281
32282 <p><b><tt>unordered_map</tt></b></p>
32283
32284 <p>
32285 Change 23.7.1 [unord.map]:
32286 </p>
32287
32288 <blockquote><pre>class unordered_map
32289 {
32290     ...
32291     unordered_map(const unordered_map&amp;);
32292     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
32293     unordered_map(const Allocator&amp;);
32294     unordered_map(const unordered_map&amp;, const Allocator&amp;);
32295     unordered_map(unordered_map&amp;&amp;, const Allocator&amp;);
32296     ...
32297     unordered_map&amp; operator=(const unordered_map&amp;);
32298     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
32299     ...
32300     // modifiers
32301     ...
32302     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
32303     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
32304     iterator       insert(const_iterator hint, const value_type&amp; obj);
32305     <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
32306     ...
32307     mapped_type&amp; operator[](const key_type&amp; k);
32308     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
32309     ...
32310 };
32311
32312 </pre></blockquote>
32313
32314 <p>
32315 Add to 23.7.1.2 [unord.map.elem]:
32316 </p>
32317
32318 <blockquote>
32319
32320 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
32321
32322 <blockquote>
32323 <p>...</p>
32324 <p><ins>
32325 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
32326 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
32327 </ins></p>
32328
32329 <p><ins>
32330 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32331 </ins></p>
32332
32333 </blockquote>
32334
32335 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
32336
32337 <blockquote>
32338 <p><ins>
32339 <i>Requires:</i> <tt>key_type</tt> shall be <tt>MoveConstructible</tt> and
32340 <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
32341 </ins></p>
32342
32343 <p><ins>
32344 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
32345 element whose key is equivalent to <tt>k</tt> , inserts the value
32346 <tt>value_type(std::move(k), mapped_type())</tt>.
32347 </ins></p>
32348
32349 <p><ins>
32350 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
32351 (unique) element whose key is equivalent to <tt>k</tt>.
32352 </ins></p>
32353
32354 <p><ins>
32355 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32356 </ins></p>
32357
32358 </blockquote>
32359
32360 </blockquote>
32361
32362 <p>
32363 Add new section [unord.map.modifiers]:
32364 </p>
32365
32366 <blockquote>
32367 <pre><ins>template &lt;class P&gt;
32368   pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
32369 </pre>
32370
32371 <blockquote>
32372
32373 <p><ins>
32374 <i>Requires:</i> <tt>value_type</tt> is constructible from
32375 <tt>std::forward&lt;P&gt;(x)</tt>.
32376 </ins></p>
32377
32378 <p><ins>
32379 <i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
32380 if there is no element in the container with key equivalent to the key of
32381 <tt>value_type(x)</tt>.
32382 </ins></p>
32383
32384 <p><ins>
32385 <i>Returns:</i> The <tt>bool</tt> component of the returned
32386 <tt>pair</tt> indicates whether the insertion takes place, and the iterator
32387 component points to the element with key equivalent to the key of
32388 <tt>value_type(x)</tt>.
32389 </ins></p>
32390
32391 <p><ins>
32392 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32393 </ins></p>
32394
32395 <p><ins>
32396 <i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
32397 <tt>value_type</tt>, else this signature shall not participate in overload
32398 resolution.
32399 </ins></p>
32400
32401 </blockquote>
32402
32403
32404 <pre><ins>template &lt;class P&gt;
32405   iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
32406 </pre>
32407
32408 <blockquote>
32409
32410 <p><ins>
32411 <i>Requires:</i> <tt>value_type</tt> is constructible from
32412 <tt>std::forward&lt;P&gt;(x)</tt>.
32413 </ins></p>
32414
32415 <p><ins>
32416 <i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
32417 if there is no element in the container with key equivalent to the key of
32418 <tt>value_type(x)</tt>.  The iterator <tt>hint</tt> is a hint pointing to where
32419 the search should start. Implementations are permitted to ignore the hint.
32420 </ins></p>
32421
32422 <p><ins>
32423 <i>Returns:</i> An iterator pointing to the element with key equivalent to the
32424 key of <tt>value_type(x)</tt>.
32425 </ins></p>
32426
32427 <p><ins>
32428 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32429 </ins></p>
32430
32431 <p><ins>
32432 <i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
32433 <tt>value_type</tt>, else this signature shall not participate in overload
32434 resolution.
32435 </ins></p>
32436
32437 </blockquote>
32438
32439 </blockquote>
32440
32441 <p><b><tt>unordered_multimap</tt></b></p>
32442
32443 <p>
32444 Change 23.7.2 [unord.multimap]:
32445 </p>
32446
32447 <blockquote><pre>class unordered_multimap
32448 {
32449     ...
32450     unordered_multimap(const unordered_multimap&amp;);
32451     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
32452     unordered_multimap(const Allocator&amp;);
32453     unordered_multimap(const unordered_multimap&amp;, const Allocator&amp;);
32454     unordered_multimap(unordered_multimap&amp;&amp;, const Allocator&amp;);
32455     ...
32456     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
32457     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
32458     ...
32459     // modifiers
32460     ...
32461     iterator insert(const value_type&amp; obj); 
32462     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
32463     iterator       insert(const_iterator hint, const value_type&amp; obj);
32464     <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
32465     ...
32466 };
32467
32468 </pre></blockquote>
32469
32470 <p>
32471 Add new section [unord.multimap.modifiers]:
32472 </p>
32473
32474 <blockquote>
32475 <pre><ins>template &lt;class P&gt;
32476   iterator insert(P&amp;&amp; x);</ins>
32477 </pre>
32478
32479 <blockquote>
32480
32481 <p><ins>
32482 <i>Requires:</i> <tt>value_type</tt> is constructible from
32483 <tt>std::forward&lt;P&gt;(x)</tt>.
32484 </ins></p>
32485
32486 <p><ins>
32487 <i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt>.
32488 </ins></p>
32489
32490 <p><ins>
32491 <i>Returns:</i> An iterator pointing to the element with key equivalent to the
32492 key of <tt>value_type(x)</tt>.
32493 </ins></p>
32494
32495 <p><ins>
32496 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32497 </ins></p>
32498
32499 <p><ins>
32500 <i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
32501 <tt>value_type</tt>, else this signature shall not participate in overload
32502 resolution.
32503 </ins></p>
32504
32505 </blockquote>
32506
32507 <pre><ins>template &lt;class P&gt;
32508   iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
32509 </pre>
32510
32511 <blockquote>
32512
32513 <p><ins>
32514 <i>Requires:</i> <tt>value_type</tt> is constructible from
32515 <tt>std::forward&lt;P&gt;(x)</tt>.
32516 </ins></p>
32517
32518 <p><ins>
32519 <i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
32520 if there is no element in the container with key equivalent to the key of
32521 <tt>value_type(x)</tt>.  The iterator <tt>hint</tt> is a hint pointing to where
32522 the search should start. Implementations are permitted to ignore the hint.
32523 </ins></p>
32524
32525 <p><ins>
32526 <i>Returns:</i> An iterator pointing to the element with key equivalent to the
32527 key of <tt>value_type(x)</tt>.
32528 </ins></p>
32529
32530 <p><ins>
32531 <i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
32532 </ins></p>
32533
32534 <p><ins>
32535 <i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
32536 <tt>value_type</tt>, else this signature shall not participate in overload
32537 resolution.
32538 </ins></p>
32539
32540 </blockquote>
32541
32542 </blockquote>
32543
32544 <p><b><tt>unordered_set</tt></b></p>
32545
32546 <p>
32547 Change 23.7.3 [unord.set]:
32548 </p>
32549
32550 <blockquote><pre>class unordered_set
32551 {
32552     ...
32553     unordered_set(const unordered_set&amp;);
32554     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
32555     unordered_set(const Allocator&amp;);
32556     unordered_set(const unordered_set&amp;, const Allocator&amp;);
32557     unordered_set(unordered_set&amp;&amp;, const Allocator&amp;);
32558     ...
32559     unordered_set&amp; operator=(const unordered_set&amp;);
32560     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
32561     ...
32562     // modifiers 
32563     ...
32564     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
32565     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
32566     iterator       insert(const_iterator hint, const value_type&amp; obj);
32567     <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
32568     ...
32569 };
32570 </pre></blockquote>
32571
32572 <p><b><tt>unordered_multiset</tt></b></p>
32573
32574 <p>
32575 Change 23.7.4 [unord.multiset]:
32576 </p>
32577
32578 <blockquote><pre>class unordered_multiset
32579 {
32580     ...
32581     unordered_multiset(const unordered_multiset&amp;);
32582     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
32583     unordered_multiset(const Allocator&amp;);
32584     unordered_multiset(const unordered_multiset&amp;, const Allocator&amp;);
32585     unordered_multiset(unordered_multiset&amp;&amp;, const Allocator&amp;);
32586     ...
32587     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
32588     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
32589     ...
32590     // modifiers
32591     ...
32592     iterator insert(const value_type&amp; obj); 
32593     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
32594     iterator       insert(const_iterator hint, const value_type&amp; obj);
32595     <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
32596     ...
32597 };
32598
32599 </pre></blockquote>
32600
32601
32602
32603
32604
32605
32606 <hr>
32607 <h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
32608 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32609  <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2010-10-29</p>
32610 <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>
32611 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32612 <p><b>Discussion:</b></p>
32613 <p>
32614 <tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
32615 engines which ideally would yield "distant" states when given "close"
32616 seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
32617 Working Draft for C++,
32618 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
32619 (2007-05-08), has 3 weaknesses
32620 </p>
32621
32622 <ol>
32623 <li>
32624 <p> Collisions in state.  Because of the way the state is initialized,
32625     seeds of different lengths may result in the same state.  The
32626     current version of seed_seq has the following properties:</p>
32627 <ul>
32628 <li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
32629       distinct state.</li>
32630 </ul>
32631 <p>
32632     The proposed algorithm (below) has the considerably stronger
32633     properties:</p>
32634 <ul>
32635 <li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
32636       result in distinct states.
32637 </li>
32638 <li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
32639       distinct states.
32640 </li>
32641 </ul>
32642 </li>
32643 <li>
32644 <p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
32645     and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
32646     a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
32647     used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
32648     possible states.</p>
32649
32650 <p> The proposed algorithm uses a more complex recursion which results
32651     in much better mixing.</p>
32652 </li>
32653 <li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
32654     algorithm remedies this.
32655 </li>
32656 </ol>
32657 <p>
32658 The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
32659 initialization procedure for the Mersenne Twister by Makoto Matsumoto
32660 and Takuji Nishimura.  The weakness (2) given above was communicated to
32661 me by Matsumoto last year.
32662 </p>
32663 <p>
32664 The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
32665 a student of Matsumoto, and is given in the implementation of the
32666 SIMD-oriented Fast Mersenne Twister random number generator SFMT.
32667 <a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
32668 <a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
32669 </p>
32670 <p>
32671 See
32672 Mutsuo Saito,
32673 An Application of Finite Field: Design and Implementation of 128-bit
32674 Instruction-Based Fast Pseudorandom Number Generator,
32675 Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
32676 <a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
32677 </p>
32678 <p>
32679 One change has been made here, namely to treat the case of small <tt>n</tt>
32680 (setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
32681 </p>
32682 <p>
32683 Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
32684 in making this incompatible improvement to it.
32685 </p>
32686
32687 <p>
32688 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
32689 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
32690 for some further discussion.
32691 </p>
32692
32693
32694 <p><b>Proposed resolution:</b></p>
32695 <p>
32696 Adopt the proposed resolution in
32697 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
32698 </p>
32699
32700
32701 <p><i>[
32702 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
32703 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
32704 ]</i></p>
32705
32706
32707
32708
32709
32710 <hr>
32711 <h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
32712 <p><b>Section:</b> 26.5.1.4 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32713  <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2010-10-29</p>
32714 <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>
32715 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32716 <p><b>Discussion:</b></p>
32717 <p>
32718 Section 26.5.1.4 [rand.req.eng] Random number engine requirements:
32719 </p>
32720
32721 <p>
32722 This change follows naturally from the proposed change to
32723 <tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
32724 </p>
32725
32726 <p>
32727 In table 104 the description of <tt>X(q)</tt> contains a special treatment of
32728 the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
32729 </p>
32730
32731 <ol>
32732 <li>It replicates the functionality provided by <tt>X()</tt>.</li>
32733 <li>It leads to the possibility of a collision in the state provided
32734     by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
32735 <li>It is inconsistent with the description of the <tt>X(q)</tt> in
32736 paragraphs 26.5.3.1 [rand.eng.lcong] p5, 26.5.3.2 [rand.eng.mers] p8, and 26.5.3.3 [rand.eng.sub] p10 where
32737 there is no special treatment of <tt>q.size() == 0</tt>.</li>
32738 <li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
32739     allows for the case <tt>q.size() == 0</tt>.</li>
32740 </ol>
32741
32742 <p>
32743 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
32744 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
32745 for some further discussion.
32746 </p>
32747
32748
32749 <p><b>Proposed resolution:</b></p>
32750 <p>
32751 Adopt the proposed resolution in
32752 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
32753 </p>
32754
32755
32756 <p><i>[
32757 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
32758 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
32759 ]</i></p>
32760
32761
32762
32763
32764
32765 <hr>
32766 <h3><a name="679"></a>679. resize parameter by value</h3>
32767 <p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32768  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2010-10-29</p>
32769 <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>
32770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32771 <p><b>Discussion:</b></p>
32772 <p>
32773 The C++98 standard specifies that one member function alone of the containers
32774 passes its parameter (<tt>T</tt>) by value instead of by const reference:
32775 </p>
32776
32777 <blockquote><pre>void resize(size_type sz, T c = T());
32778 </pre></blockquote>
32779
32780 <p>
32781 This fact has been discussed / debated repeatedly over the years, the first time
32782 being even before C++98 was ratified.  The rationale for passing this parameter by
32783 value has been:
32784 </p>
32785
32786 <blockquote>
32787 <p>
32788 So that self referencing statements are guaranteed to work, for example:
32789 </p>
32790 <blockquote><pre>v.resize(v.size() + 1, v[0]);
32791 </pre></blockquote>
32792 </blockquote>
32793
32794 <p>
32795 However this rationale is not convincing as the signature for <tt>push_back</tt> is:
32796 </p>
32797
32798 <blockquote><pre>void push_back(const T&amp; x);
32799 </pre></blockquote>
32800
32801 <p>
32802 And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
32803 And <tt>push_back</tt> must also work in the self referencing case:
32804 </p>
32805
32806 <blockquote><pre>v.push_back(v[0]);  // must work
32807 </pre></blockquote>
32808
32809 <p>
32810 The problem with passing <tt>T</tt> by value is that it can be significantly more
32811 expensive than passing by reference.  The converse is also true, however when it is
32812 true it is usually far less dramatic (e.g. for scalar types).
32813 </p>
32814
32815 <p>
32816 Even with move semantics available, passing this parameter by value can be expensive.
32817 Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
32818 </p>
32819
32820 <blockquote><pre>std::vector&lt;int&gt; x(1000);
32821 std::vector&lt;std::vector&lt;int&gt;&gt; v;
32822 ...
32823 v.resize(v.size()+1, x);
32824 </pre></blockquote>
32825
32826 <p>
32827 In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
32828 <tt>resize</tt>.  And then internally, since the code can not know at compile
32829 time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
32830 usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
32831 within the <tt>vector</tt>.
32832 </p>
32833
32834 <p>
32835 With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
32836 only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
32837 copies that can be saved represents a significant savings.
32838 </p>
32839
32840 <p>
32841 If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
32842 as well.  The resize taking a reference parameter has been coded and shipped in the
32843 CodeWarrior library with no reports of problems which I am aware of.
32844 </p>
32845
32846
32847
32848 <p><b>Proposed resolution:</b></p>
32849 <p>
32850 Change 23.3.2 [deque], p2:
32851 </p>
32852
32853 <blockquote><pre>class deque {
32854    ...
32855    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32856 </pre></blockquote>
32857
32858 <p>
32859 Change 23.3.2.2 [deque.capacity], p3:
32860 </p>
32861
32862 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32863 </pre></blockquote>
32864
32865 <p>
32866 Change 23.3.4 [list], p2:
32867 </p>
32868
32869 <blockquote><pre>class list {
32870    ...
32871    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32872 </pre></blockquote>
32873
32874 <p>
32875 Change 23.3.4.2 [list.capacity], p3:
32876 </p>
32877
32878 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32879 </pre></blockquote>
32880
32881 <p>
32882 Change 23.4.1 [vector], p2:
32883 </p>
32884
32885 <blockquote><pre>class vector {
32886    ...
32887    void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32888 </pre></blockquote>
32889
32890 <p>
32891 Change 23.4.1.2 [vector.capacity], p11:
32892 </p>
32893
32894 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
32895 </pre></blockquote>
32896
32897
32898
32899
32900
32901
32902 <hr>
32903 <h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
32904 <p><b>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32905  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2010-10-29</p>
32906 <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>
32907 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32908 <p><b>Discussion:</b></p>
32909 <p>
32910 <tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
32911 does not consistently match the type which is returned in the description
32912 in 24.5.3.3.5 [move.iter.op.ref].
32913 </p>
32914
32915 <blockquote><pre>template &lt;class Iterator&gt;
32916 class move_iterator {
32917 public:
32918     ...
32919     typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
32920     ...
32921     pointer operator-&gt;() const {return current;}
32922     ...
32923 private: 
32924     Iterator current; // exposition only
32925 };
32926 </pre></blockquote>
32927
32928
32929 <p>
32930 There are two possible fixes.
32931 </p>
32932
32933 <ol>
32934 <li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
32935 <li><tt>typedef Iterator pointer;</tt></li>
32936 </ol>
32937
32938 <p>
32939 The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
32940 disadvantage of this is it may not work well with iterators which return a
32941 proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
32942 references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
32943 pointer.  That proxy pointer may or may not be the same type as the iterator's
32944 <tt>pointer</tt> type.
32945 </p>
32946
32947 <p>
32948 By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
32949 the language forwards calls to <tt>operator-&gt;</tt> automatically until it
32950 finds a non-class type, the second solution avoids the issue of an overloaded
32951 <tt>operator&amp;()</tt> entirely.
32952 </p>
32953
32954 <p><b>Proposed resolution:</b></p>
32955 <p>
32956 Change the synopsis in 24.5.3.1 [move.iterator]:
32957 </p>
32958
32959 <blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
32960 </pre></blockquote>
32961
32962
32963
32964
32965
32966
32967 <hr>
32968 <h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
32969 <p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32970  <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27 <b>Last modified:</b> 2010-10-29</p>
32971 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
32972 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32973 <p><b>Discussion:</b></p>
32974 <p>
32975 In 28.9.2 [re.submatch.op] of N2284, 
32976 operator functions numbered 31-42 seem impossible to compare. E.g.: 
32977 </p>
32978
32979 <blockquote>
32980 <pre>template &lt;class BiIter&gt;
32981    bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
32982                     const sub_match&lt;BiIter&gt;&amp; rhs);
32983 </pre>
32984 <blockquote>
32985 <p>
32986 -31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
32987 </p>
32988 </blockquote>
32989 </blockquote>
32990
32991 <p>
32992 When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
32993 <tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
32994 of <tt>std::basic_string&lt;char&gt;</tt>.  However, the behaviour of comparison between 
32995 these two types is not defined in 21.4.8 [string.nonmembers] of N2284.
32996  This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
32997 </p>
32998
32999
33000 <p><b>Proposed resolution:</b></p>
33001 <p>
33002 Adopt the proposed resolution in
33003 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
33004 </p>
33005
33006
33007 <p><i>[
33008 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
33009 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
33010 ]</i></p>
33011
33012
33013
33014
33015
33016 <hr>
33017 <h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
33018 <p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33019  <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-03 <b>Last modified:</b> 2010-10-29</p>
33020 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
33021 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33022 <p><b>Discussion:</b></p>
33023 <p>
33024 Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
33025 constructor: 
33026 </p>
33027 <blockquote><pre>template &lt;class InputIterator&gt;
33028      basic_regex(InputIterator first, InputIterator last, 
33029                  flag_type f = regex_constants::ECMAScript);
33030 </pre></blockquote>
33031
33032 <p>
33033 In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
33034 </p>
33035
33036 <blockquote><pre>template &lt;class ForwardIterator&gt;
33037      basic_regex(ForwardIterator first, ForwardIterator last, 
33038                  flag_type f = regex_constants::ECMAScript);
33039 </pre></blockquote>
33040
33041 <p>
33042 <tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
33043 </p>
33044
33045 <p><i>[
33046 John adds:
33047 ]</i></p>
33048
33049
33050 <blockquote>
33051 <p>
33052 I think either could be implemented?  Although an input iterator would 
33053 probably require an internal copy of the string being made.
33054 </p>
33055 <p>
33056 I have no strong feelings either way, although I think my original intent 
33057 was <tt>InputIterator</tt>. 
33058 </p>
33059 </blockquote>
33060
33061
33062 <p><b>Proposed resolution:</b></p>
33063 <p>
33064 Adopt the proposed resolution in
33065 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
33066 </p>
33067
33068
33069 <p><i>[
33070 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
33071 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
33072 ]</i></p>
33073
33074
33075
33076
33077
33078 <hr>
33079 <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
33080 <p><b>Section:</b> 24.5.1.3.19 [reverse.iter.opdiff], 24.5.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33081  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-06-10 <b>Last modified:</b> 2010-10-29</p>
33082 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33083 <p><b>Discussion:</b></p>
33084 <p>
33085 In C++03 the difference between two <tt>reverse_iterators</tt>
33086 </p>
33087 <blockquote><pre>ri1 - ri2
33088 </pre></blockquote>
33089 <p>
33090 is possible to compute only if both iterators have the same base 
33091 iterator. The result type is the <tt>difference_type</tt> of the base iterator. 
33092 </p>
33093 <p>
33094 In the current draft, the operator is defined as 24.5.1.3.19 [reverse.iter.opdiff] 
33095 </p>
33096 <blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
33097 typename reverse_iterator&lt;Iterator&gt;::difference_type 
33098    operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
33099                     const reverse_iterator&lt;Iterator2&gt;&amp; y);
33100 </pre></blockquote>
33101 <p>
33102 The return type is the same as the C++03 one, based on the no longer 
33103 present <tt>Iterator</tt> template parameter. 
33104 </p>
33105 <p>
33106 Besides being slightly invalid, should this operator work only when 
33107 <tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the 
33108 implementation choose one of them? Which one? 
33109 </p>
33110 <p>
33111 The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
33112 24.5.3.3.14 [move.iter.nonmember]. 
33113 </p>
33114
33115
33116 <p><b>Proposed resolution:</b></p>
33117 <p>
33118 Change the synopsis in 24.5.1.1 [reverse.iterator]:
33119 </p>
33120
33121 <blockquote>
33122 <pre>template &lt;class Iterator1, class Iterator2&gt; 
33123   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
33124     const reverse_iterator&lt;Iterator1&gt;&amp; x, 
33125     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
33126 </pre>
33127 </blockquote>
33128
33129 <p>
33130 Change 24.5.1.3.19 [reverse.iter.opdiff]:
33131 </p>
33132
33133 <blockquote>
33134 <pre>template &lt;class Iterator1, class Iterator2&gt; 
33135   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
33136     const reverse_iterator&lt;Iterator1&gt;&amp; x, 
33137     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
33138 </pre>
33139 <blockquote>
33140 <p>
33141 <i>Returns:</i> <tt>y.current - x.current</tt>.
33142 </p>
33143 </blockquote>
33144 </blockquote>
33145
33146
33147 <p>
33148 Change the synopsis in 24.5.3.1 [move.iterator]:
33149 </p>
33150
33151 <blockquote>
33152 <pre>template &lt;class Iterator1, class Iterator2&gt; 
33153   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
33154     const move_iterator&lt;Iterator1&gt;&amp; x, 
33155     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
33156 </pre>
33157 </blockquote>
33158
33159 <p>
33160 Change 24.5.3.3.14 [move.iter.nonmember]:
33161 </p>
33162
33163 <blockquote>
33164 <pre>template &lt;class Iterator1, class Iterator2&gt; 
33165   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
33166     const move_iterator&lt;Iterator1&gt;&amp; x, 
33167     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
33168 </pre>
33169 <blockquote>
33170 <p>
33171 <i>Returns:</i> <tt>x.base() - y.base()</tt>.
33172 </p>
33173 </blockquote>
33174 </blockquote>
33175
33176 <p><i>[
33177 Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
33178 goes in.
33179 ]</i></p>
33180
33181
33182
33183
33184
33185
33186
33187 <hr>
33188 <h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
33189 <p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const], 20.9.10.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33190  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
33191 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
33192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33193 <p><b>Discussion:</b></p>
33194 <p>
33195 Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
33196 rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
33197 code that works with raw pointers fails with <tt>shared_ptr</tt>:
33198 </p>
33199
33200 <blockquote><pre>void f( shared_ptr&lt;void&gt; );
33201 void f( shared_ptr&lt;int&gt; );
33202
33203 int main()
33204 {
33205   f( shared_ptr&lt;double&gt;() ); // ambiguous
33206 }
33207 </pre></blockquote>
33208
33209 <p>
33210 Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
33211 and the corresponding assignment operator to only participate in the
33212 overload resolution when the pointer types are compatible.
33213 </p>
33214
33215
33216 <p><b>Proposed resolution:</b></p>
33217 <p>
33218 In 20.9.10.2.1 [util.smartptr.shared.const], change:
33219 </p>
33220
33221 <blockquote><p>
33222 -14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
33223 second constructor shall not participate in the overload resolution
33224 unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
33225 to <tt>T*</tt>.
33226 </p></blockquote>
33227
33228 <p>
33229 In 20.9.10.3.1 [util.smartptr.weak.const], change:
33230 </p>
33231
33232 <blockquote>
33233 <pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
33234 <del>weak_ptr(weak_ptr const&amp; r);</del>
33235 <del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
33236 <ins>weak_ptr(weak_ptr const&amp; r);</ins>
33237 <ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
33238 <ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
33239 </pre>
33240 <blockquote><p>
33241 -4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
33242 third constructors<del>,</del> <ins>shall not participate in the
33243 overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
33244 <ins>is implicitly</ins> convertible to <tt>T*</tt>.
33245 </p></blockquote>
33246 </blockquote>
33247
33248
33249
33250
33251
33252
33253 <hr>
33254 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
33255 <p><b>Section:</b> 20.8.4.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
33256  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
33257 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
33258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
33259 <p><b>Discussion:</b></p>
33260 <p>
33261 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
33262 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
33263 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
33264 Now that we have a mechanism to detect an rvalue, we can fix them to
33265 disallow this source of undefined behavior.
33266 </p>
33267
33268 <p>
33269 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
33270 </p>
33271
33272 <p><i>[
33273 2009-05-09 Alisdair adds:
33274 ]</i></p>
33275
33276
33277 <blockquote>
33278 <p>
33279 Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not
33280 believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on
33281 deducing <tt>T</tt> to be an rvalue reference type)
33282 </p>
33283 <p>
33284 However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted
33285 overload.
33286 </p>
33287 </blockquote>
33288
33289 <p><i>[
33290 2009-05-10 Howard adds:
33291 ]</i></p>
33292
33293
33294 <blockquote>
33295 <p>
33296 Without:
33297 </p>
33298
33299 <blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
33300 </pre></blockquote>
33301 <p>
33302 I believe this program will compile:
33303 </p>
33304
33305 <blockquote><pre>#include &lt;functional&gt;
33306
33307 struct A {};
33308
33309 const A source() {return A();}
33310
33311 int main()
33312 {
33313    std::reference_wrapper&lt;const A&gt; r = std::ref(source());
33314 }
33315 </pre></blockquote>
33316 <p>
33317 I.e. in:
33318 </p>
33319 <blockquote><pre>template &lt;ObjectType T&gt; reference_wrapper&lt;T&gt; ref(T&amp; t);
33320 </pre></blockquote>
33321
33322 <p>
33323 this:
33324 </p>
33325
33326 <blockquote><pre>ref(source())
33327 </pre></blockquote>
33328 <p>
33329 deduces <tt>T</tt> as <tt>const A</tt>, and so:
33330 </p>
33331
33332 <blockquote><pre>ref(const A&amp; t)
33333 </pre></blockquote>
33334
33335 <p>
33336 will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler).
33337 </p>
33338 <p>
33339 Therefore I think we still need the ref-protection.  I respectfully disagree with Alisdair's
33340 comment and am in favor of the proposed wording as it stands.  Also, CWG 606
33341 (noted below) has now been "favorably" resolved.
33342 </p>
33343
33344 </blockquote>
33345
33346 <p><i>[
33347 Batavia (2009-05):
33348 ]</i></p>
33349
33350 <blockquote>
33351 We agree with the proposed resolution.
33352 Move to Tentatively Ready.
33353 </blockquote>
33354
33355
33356 <p><b>Proposed resolution:</b></p>
33357 <p>
33358 In 20.8 [function.objects], add the following two signatures to the synopsis:
33359 </p>
33360
33361 <blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
33362 template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
33363 </pre></blockquote>
33364
33365
33366
33367 <p><i>[
33368 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
33369 addresses the first part of the resolution but not the second.
33370 ]</i></p>
33371
33372
33373 <p><i>[
33374 Bellevue:  Doug noticed problems with the current wording.
33375 ]</i></p>
33376
33377
33378 <p><i>[
33379 post Bellevue:  Howard and Peter provided revised wording.
33380 ]</i></p>
33381
33382
33383 <p><i>[
33384 This resolution depends on a "favorable" resolution of CWG 606:  that is,
33385 the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
33386 ]</i></p>
33387
33388
33389
33390
33391
33392 <hr>
33393 <h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
33394 <p><b>Section:</b> 20.8.4.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33395  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
33396 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
33397 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33398 <p><b>Discussion:</b></p>
33399 <p>
33400 The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
33401 motivation behind this is the safety problem with respect to rvalues,
33402 which is addressed by the proposed resolution of the previous issue.
33403 Therefore we should consider relaxing the requirements on the
33404 constructor since requests for the implicit conversion keep resurfacing.
33405 </p>
33406 <p>
33407 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
33408 </p>
33409
33410
33411 <p><b>Proposed resolution:</b></p>
33412 <p>
33413 Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
33414 proposed resolution of the previous issue is accepted, remove the
33415 <tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
33416 </p>
33417
33418
33419
33420
33421
33422 <hr>
33423 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
33424 <p><b>Section:</b> 23.7 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33425  <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2007-06-14 <b>Last modified:</b> 2010-10-29</p>
33426 <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>
33427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33428 <p><b>Discussion:</b></p>
33429 <p>
33430 The last version of TR1 does not include the following member
33431 functions
33432 for unordered containers:
33433 </p>
33434
33435 <blockquote><pre>const_local_iterator cbegin(size_type n) const;
33436 const_local_iterator cend(size_type n) const;
33437 </pre></blockquote>
33438
33439 <p>
33440 which looks like an oversight to me. I've checked th TR1 issues lists
33441 and the latest working draft of the C++0x std (N2284) and haven't
33442 found any mention to these menfuns or to their absence.
33443 </p>
33444 <p>
33445 Is this really an oversight, or am I missing something?
33446 </p>
33447
33448
33449
33450 <p><b>Proposed resolution:</b></p>
33451 <p>
33452 Add the following two rows to table 93 (unordered associative container
33453 requirements) in section 23.2.5 [unord.req]:
33454 </p>
33455
33456 <blockquote>
33457 <table border="1">
33458 <caption>Unordered associative container requirements (in addition to container)</caption>
33459 <tbody><tr>
33460 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
33461 </tr>
33462 <tr>
33463 <td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td> 
33464 </tr>
33465 <tr>
33466 <td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td> 
33467 </tr>
33468 </tbody></table>
33469 </blockquote>
33470
33471 <p>
33472 Add to the synopsis in 23.7.1 [unord.map]:
33473 </p>
33474
33475 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
33476 const_local_iterator cend(size_type n) const;</ins>
33477 </pre></blockquote>
33478
33479 <p>
33480 Add to the synopsis in 23.7.2 [unord.multimap]:
33481 </p>
33482
33483 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
33484 const_local_iterator cend(size_type n) const;</ins>
33485 </pre></blockquote>
33486
33487 <p>
33488 Add to the synopsis in 23.7.3 [unord.set]:
33489 </p>
33490
33491 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
33492 const_local_iterator cend(size_type n) const;</ins>
33493 </pre></blockquote>
33494
33495 <p>
33496 Add to the synopsis in 23.7.4 [unord.multiset]:
33497 </p>
33498
33499 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
33500 const_local_iterator cend(size_type n) const;</ins>
33501 </pre></blockquote>
33502
33503
33504
33505
33506
33507
33508 <hr>
33509 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
33510 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33511  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
33512 <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>
33513 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33514 <p><b>Discussion:</b></p>
33515 <p>
33516 In a private email Bill Plauger notes:
33517 </p>
33518 <blockquote><p>
33519 I  believe that  the function  that  implements <code>get_money</code>
33520 [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
33521 should behave  as a  formatted input function,  and the  function that
33522 implements <code>put_money</code> should  behave as a formatted output
33523 function. This  has implications regarding the  skipping of whitespace
33524 and the handling of errors, among other things.
33525 </p>
33526 <p>
33527 The words  don't say that  right now and  I'm far from  convinced that
33528 such a change is editorial.
33529 </p></blockquote>
33530 <p>
33531 Martin's response:
33532 </p>
33533 <blockquote><p>
33534 I agree that the manipulators should handle exceptions the same way as
33535 formatted I/O functions do. The text in N2072 assumes so but the
33536 <i>Returns</i> clause explicitly omits exception handling for the sake
33537 of brevity. The spec should be clarified to that effect.
33538 </p>
33539 <p>
33540 As for dealing  with whitespace, I also agree it  would make sense for
33541 the extractors  and inserters involving the new  manipulators to treat
33542 it the same way as formatted I/O.
33543 </p></blockquote>
33544
33545
33546 <p><b>Proposed resolution:</b></p>
33547 <p>
33548 Add  a new  paragraph immediately  above  p4 of 27.7.4 [ext.manip] with  the
33549 following text:
33550 </p>
33551 <blockquote><p>
33552 <i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
33553 described below behaves as a formatted input function (as
33554 described in 27.7.1.2.1 [istream.formatted.reqmts]).
33555 </p></blockquote>
33556 <p>
33557 Also change p4 of 27.7.4 [ext.manip] as follows:
33558 </p>
33559 <blockquote><p>
33560 <i>Returns</i>: An object <code>s</code> of unspecified type such that
33561 if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
33562 traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
33563 that    calls    </ins><code>f(in, mon, intl)</code><del>    were
33564 called</del>. The function <code>f</code> can be defined as...
33565 </p></blockquote>
33566
33567
33568 <p><i>[
33569 post Bellevue:
33570 ]</i></p>
33571
33572
33573 <blockquote>
33574 We recommend moving immediately to Review. We've looked at the issue and
33575 have a consensus that the proposed resolution is correct, but want an
33576 iostream expert to sign off. Alisdair has taken the action item to putt
33577 this up on the reflector for possible movement by Howard to Tenatively
33578 Ready.
33579 </blockquote>
33580
33581
33582
33583
33584 <hr>
33585 <h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
33586 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33587  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
33588 <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>
33589 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33590 <p><b>Discussion:</b></p>
33591 <p>
33592 The  <code>bitset</code> class template  provides the  member function
33593 <code>any()</code> to determine whether an  object of the type has any
33594 bits  set, and  the member  function <code>none()</code>  to determine
33595 whether all of an object's  bits are clear. However, the template does
33596 not   provide  a   corresponding  function   to  discover   whether  a
33597 <code>bitset</code>  object  has  all  its  bits  set.   While  it  is
33598 possible,  even easy,  to  obtain this  information  by comparing  the
33599 result of <code>count()</code>  with the result of <code>size()</code>
33600 for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
33601 operation  is   less  efficient   than  a  member   function  designed
33602 specifically  for that purpose  could be.   (<code>count()</code> must
33603 count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
33604 while <code>all()</code> could stop counting as soon as it encountered
33605 the first word with a zero bit).
33606 </p>
33607
33608
33609 <p><b>Proposed resolution:</b></p>
33610 <p>
33611 Add  a declaration of the new  member function <code>all()</code> to the
33612 defintion of the <code>bitset</code> template in 20.5 [template.bitset], p1,
33613 right above the declaration of <code>any()</code> as shown below:
33614 </p>
33615
33616 <blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
33617 bool test(size_t pos) const;
33618 <ins>bool all() const;</ins>
33619 bool any() const;
33620 bool none() const;
33621 </pre></blockquote>
33622
33623 <p>
33624 Add a description of the new member function to the end of 20.5.2 [bitset.members] with the following text:
33625 </p>
33626 <blockquote><p>
33627 <code>bool all() const;</code>
33628 </p>
33629 <blockquote>
33630 <i>Returns</i>: <code>count() == size()</code>.
33631 </blockquote>
33632 </blockquote>
33633
33634 <p>
33635 In  addition,   change  the  description   of  <code>any()</code>  and
33636 <code>none()</code>   for  consistency   with   <code>all()</code>  as
33637 follows:
33638 </p>
33639 <blockquote><p>
33640 <code>bool any() const;</code>
33641 </p>
33642 <blockquote>
33643 <p>
33644 <i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
33645 is one</del><ins><code>count() != 0</code></ins>.
33646 </p>
33647 </blockquote>
33648 <p>
33649 <code>bool none() const;</code>
33650 </p>
33651 <blockquote>
33652 <p>
33653 <i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
33654 is one</del><ins><code>count() == 0</code></ins>.
33655 </p>
33656 </blockquote>
33657 </blockquote>
33658
33659
33660
33661
33662
33663 <hr>
33664 <h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
33665 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33666  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
33667 <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>
33668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33669 <p><b>Discussion:</b></p>
33670 <p>
33671 Objects of the  <code>bitset</code> class template specializations can
33672 be constructed from  and explicitly converted to values  of the widest
33673 C++ integer  type, <code>unsigned long</code>.   With the introduction
33674 of  <code>long long</code> into  the language  the template  should be
33675 enhanced to make it possible  to interoperate with values of this type
33676 as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
33677 a brief discussion in support of this change.
33678 </p>
33679
33680
33681 <p><b>Proposed resolution:</b></p>
33682 <p>
33683 For simplicity,  instead of  adding overloads for  <code>unsigned long
33684 long</code> and dealing with possible ambiguities in the spec, replace
33685 the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
33686 argument  with  one  taking  <code>unsigned long  long</code>  in  the
33687 definition  of the  template as  shown below.   (The  standard permits
33688 implementations  to add  overloads on  other integer  types  or employ
33689 template tricks to  achieve the same effect provided  they don't cause
33690 ambiguities or changes in behavior.)
33691 </p>
33692 <blockquote>
33693 <pre>// [bitset.cons] constructors:
33694 bitset();
33695 bitset(unsigned <ins>long</ins> long val);
33696 template&lt;class charT, class traits, class Allocator&gt;
33697 explicit bitset(
33698                 const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
33699                 typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
33700                 typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
33701                     basic_string&lt;charT,traits,Allocator&gt;::npos);
33702 </pre>
33703 </blockquote>
33704 <p>
33705 Make a corresponding change in 20.5.1 [bitset.cons], p2:
33706 </p>
33707 <blockquote>
33708 <p>
33709 <code>bitset(unsigned <ins>long</ins> long val);</code>
33710 </p>
33711 <blockquote>
33712 <i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
33713 initializing  the  first <code><i>M</i></code>  bit  positions to  the
33714 corresponding      bit     values      in     <code><i>val</i></code>.
33715 <code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
33716 number of bits in  the value representation (section [basic.types]) of
33717 <code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
33718 <i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
33719 positions are initialized to zero.
33720 </blockquote>
33721 </blockquote>
33722
33723 <p>
33724 Additionally, introduce a new member function <code>to_ullong()</code>
33725 to make  it possible to  convert <code>bitset</code> to values  of the
33726 new  type. Add  the following  declaration  to the  definition of  the
33727 template, immediate  after the declaration  of <code>to_ulong()</code>
33728 in 20.5 [template.bitset], p1, as shown below:
33729 </p>
33730 <blockquote>
33731 <pre>// element access:
33732 bool operator[](size_t pos) const; // for b[i];
33733 reference operator[](size_t pos); // for b[i];
33734 unsigned long to_ulong() const;
33735 <ins>unsigned long long to_ullong() const;</ins>
33736 template &lt;class charT, class traits, class Allocator&gt;
33737 basic_string&lt;charT, traits, Allocator&gt; to_string() const;
33738 </pre>
33739 </blockquote>
33740 <p>
33741 And add a description of  the new member function to 20.5.2 [bitset.members],
33742 below  the  description of  the  existing <code>to_ulong()</code>  (if
33743 possible), with the following text:
33744 </p>
33745 <blockquote>
33746 <p>
33747 <code>unsigned long long to_ullong() const;</code>
33748 </p>
33749 <blockquote>
33750 <i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
33751 <code><i>x</i></code> corresponding to  the bits in <code>*this</code>
33752 cannot be represented as type <code>unsigned long long</code>.
33753 </blockquote>
33754 <blockquote>
33755 <i>Returns:</i> <code><i>x</i></code>.
33756 </blockquote>
33757 </blockquote>
33758
33759
33760
33761
33762
33763 <hr>
33764 <h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
33765 <p><b>Section:</b> 22.4.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33766  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
33767 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33768 <p><b>Discussion:</b></p>
33769 <p>
33770 The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
33771 function    returns    a    pointer    to   an    array    of    const
33772 <code>ctype_base::mask</code>    objects    (enums)   that    contains
33773 <code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
33774 describes the properties of the character set in the "C" locale (i.e.,
33775 whether a  character at an index  given by its value  is alpha, digit,
33776 punct,   etc.),   and   is    typically   used   to   initialize   the
33777 <code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
33778 protected      <code>ctype&lt;char&gt;</code>      member     function
33779 <code>table()</code>    then    returns     the    same    value    as
33780 <code>classic_table()</code>).
33781 </p>
33782 <p>
33783 However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
33784 the   table)    is   a   public    static   const   member    of   the
33785 <code>ctype&lt;char&gt;</code>           specialization,           the
33786 <code>classic_table()</code> static member function is protected. That
33787 makes getting at the classic  data less than convenient (i.e., one has
33788 to create  a whole derived class just  to get at the  masks array). It
33789 makes  little sense  to expose  the size  of the  table in  the public
33790 interface while making the table itself protected, especially when the
33791 table is a constant object.
33792 </p>
33793 <p>
33794 The  same argument  can be  made for  the non-static  protected member
33795 function <code>table()</code>.
33796 </p>
33797
33798
33799 <p><b>Proposed resolution:</b></p>
33800 <p>
33801 Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
33802 <code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
33803 moving their declarations into the public section of the definition of
33804 specialization in 22.4.1.3 [facet.ctype.special] as shown below:
33805 </p>
33806 <blockquote>
33807 <pre>  static locale::id id;
33808   static const size_t table_size = IMPLEMENTATION_DEFINED;
33809 <del>protected:</del>
33810   const mask* table() const throw();
33811   static const mask* classic_table() throw();
33812 <ins>protected:</ins>
33813
33814 ~ctype(); // virtual
33815 virtual char do_toupper(char c) const;
33816 </pre>
33817 </blockquote>
33818
33819
33820
33821
33822
33823 <hr>
33824 <h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
33825 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
33826  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23 <b>Last modified:</b> 2010-10-29</p>
33827 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
33828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
33829 <p><b>Discussion:</b></p>
33830 <p>
33831 From message c++std-lib-17897:
33832 </p>
33833 <p>
33834 The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
33835 implementation of the two arithmetic extractors that don't have a
33836 corresponding <code>num_get</code> interface (i.e., the
33837 <code>short</code> and <code>int</code> overloads) is subtly buggy in
33838 how it deals with <code>EOF</code>, overflow, and other similar
33839 conditions (in addition to containing a few typos).
33840 </p>
33841 <p>
33842 One problem is that if <code>num_get::get()</code> reaches the EOF
33843 after reading in an otherwise valid value that exceeds the limits of
33844 the narrower type (but not <code>LONG_MIN</code> or
33845 <code>LONG_MAX</code>), it will set <code><i>err</i></code> to
33846 <code>eofbit</code>. Because of the if condition testing for
33847 <code>(<i>err</i> == 0)</code>, the extractor won't set
33848 <code>failbit</code> (and presumably, return a bogus value to the
33849 caller).
33850 </p>
33851 <p>
33852 Another problem with the code is that it never actually sets the
33853 argument to the extracted value. It can't happen after the call to
33854 <code>setstate()</code> since the function may throw, so we need to
33855 show when and how it's done (we can't just punt as say: "it happens
33856 afterwards"). However, it turns out that showing how it's done isn't
33857 quite so easy since the argument is normally left unchanged by the
33858 facet on error except when the error is due to a misplaced thousands
33859 separator, which causes <code>failbit</code> to be set but doesn't
33860 prevent the facet from storing the value.
33861 </p>
33862
33863 <p><i>[
33864 Batavia (2009-05):
33865 ]</i></p>
33866
33867 <blockquote>
33868 <p>
33869 We believe this part of the Standard has been recently adjusted
33870 and that this issue was addressed during that rewrite.
33871 </p>
33872 <p>
33873 Move to NAD.
33874 </p>
33875 </blockquote>
33876
33877 <p><i>[
33878 2009-05-28 Howard adds:
33879 ]</i></p>
33880
33881
33882 <blockquote>
33883 <p>
33884 I've moved this issue from Tentatively NAD to Open.
33885 </p>
33886
33887 <p>
33888 The current wording of
33889 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
33890 in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
33891 in parsing arithmetic types, the value is always set, but sometimes in addition
33892 to setting <tt>failbit</tt>.
33893 </p>
33894
33895 <ul>
33896 <li>
33897 If there is a range error, the value is set to min or max, else
33898 </li>
33899 <li>
33900 if there is a conversion error, the value is set to 0, else
33901 </li>
33902 <li>
33903 if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
33904 </li>
33905 <li>
33906 the value is set to its error-free result.
33907 </li>
33908 </ul>
33909
33910 <p>
33911 However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
33912 </p>
33913
33914 <p>
33915 27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
33916 (whatever we decide that behavior is) for
33917 <tt>int</tt> and <tt>short</tt>, and currently does not.  I believe that the
33918 correct code fragment should look like:
33919 </p>
33920
33921 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
33922 iostate err = ios_base::goodbit;
33923 long lval;
33924 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
33925 if (lval &lt; numeric_limits&lt;int&gt;::min())
33926 {
33927   err |= ios_base::failbit;
33928   val = numeric_limits&lt;int&gt;::min();
33929 }
33930 else if (lval &gt; numeric_limits&lt;int&gt;::max())
33931 {
33932   err |= ios_base::failbit;
33933   val = numeric_limits&lt;int&gt;::max();
33934 }
33935 else
33936   val = static_cast&lt;int&gt;(lval);
33937 setstate(err);
33938 </pre></blockquote>
33939 </blockquote>
33940
33941 <p><i>[
33942 2009-07 Frankfurt
33943 ]</i></p>
33944
33945
33946 <blockquote>
33947 Move to Ready.
33948 </blockquote>
33949
33950
33951
33952 <p><b>Proposed resolution:</b></p>
33953 <p>
33954 Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
33955 </p>
33956
33957 <blockquote>
33958 -1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
33959 according to <tt>str.flags()</tt>, <tt>use_facet&lt;ctype&lt;charT&gt;
33960 &gt;(loc)</tt>, and <tt>use_facet&lt; numpunct&lt;charT&gt;
33961 &gt;(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
33962 occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
33963 </blockquote>
33964
33965 <p>
33966 Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
33967 </p>
33968
33969 <blockquote>
33970 <pre>operator&gt;&gt;(short&amp; val);
33971 </pre>
33972 <blockquote>
33973 <p>
33974 -2- The conversion occurs as if performed by the following code fragment (using the same notation as for 
33975 the preceding code fragment):
33976 </p>
33977
33978 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
33979 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
33980 long lval;
33981 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
33982 <del>if (err != 0)
33983   ;
33984 else if (lval &lt; numeric_limits&lt;short&gt;::min()
33985   || numeric_limits&lt;short&gt;::max() &lt; lval)
33986      err = ios_base::failbit;</del>
33987 <ins>if (lval &lt; numeric_limits&lt;short&gt;::min())
33988 {
33989   err |= ios_base::failbit;
33990   val = numeric_limits&lt;short&gt;::min();
33991 }
33992 else if (lval &gt; numeric_limits&lt;short&gt;::max())
33993 {
33994   err |= ios_base::failbit;
33995   val = numeric_limits&lt;short&gt;::max();
33996 }</ins>
33997 else
33998   val = static_cast&lt;short&gt;(lval);
33999 setstate(err);
34000 </pre></blockquote>
34001
34002 </blockquote>
34003
34004 <pre>operator&gt;&gt;(int&amp; val);
34005 </pre>
34006 <blockquote>
34007 <p>
34008 -3- The conversion occurs as if performed by the following code fragment (using the same notation as for 
34009 the preceding code fragment):
34010 </p>
34011
34012 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
34013 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
34014 long lval;
34015 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
34016 <del>if (err != 0)
34017   ;
34018 else if (lval &lt; numeric_limits&lt;int&gt;::min()
34019   || numeric_limits&lt;int&gt;::max() &lt; lval)
34020      err = ios_base::failbit;</del>
34021 <ins>if (lval &lt; numeric_limits&lt;int&gt;::min())
34022 {
34023   err |= ios_base::failbit;
34024   val = numeric_limits&lt;int&gt;::min();
34025 }
34026 else if (lval &gt; numeric_limits&lt;int&gt;::max())
34027 {
34028   err |= ios_base::failbit;
34029   val = numeric_limits&lt;int&gt;::max();
34030 }</ins>
34031 else
34032   val = static_cast&lt;int&gt;(lval);
34033 setstate(err);
34034 </pre></blockquote>
34035
34036 </blockquote>
34037
34038 </blockquote>
34039
34040
34041
34042
34043
34044 <hr>
34045 <h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
34046 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
34047  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2010-11-19</p>
34048 <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>
34049 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
34050 <p><b>Discussion:</b></p>
34051 <p>
34052 The most recent state of 
34053 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
34054 as well as the current draft
34055 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
34056 (section 19.5 [syserr], p.2) proposes a
34057 new
34058 enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
34059 the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
34060 <tt>std::invalid_argument</tt>. This name clashes with the exception type
34061 <tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
34062 e.g. the following snippet invalid:
34063 </p>
34064
34065 <blockquote><pre>#include &lt;system_error&gt;
34066 #include &lt;stdexcept&gt;
34067
34068 void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
34069 </pre></blockquote>
34070
34071 <p>
34072 I propose that this enumeration type (and probably the remaining parts
34073 of
34074 <tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
34075 namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
34076 due
34077 to the great number of members that <tt>std::posix_errno</tt> already contains
34078 (Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
34079 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
34080 been rejected?). A further clash <em>candidate</em> seems to be
34081 <tt>std::protocol_error</tt>
34082 (a reasonable name for an exception related to a std network library,
34083 I guess).
34084 </p>
34085
34086 <p>
34087 Another possible resolution would rely on the proposed strongly typed
34088 enums,
34089 as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
34090 But maybe the forbidden implicit conversion to integral types would
34091 make
34092 these enumerators less attractive in this special case?
34093 </p>
34094
34095
34096 <p><b>Proposed resolution:</b></p>
34097 <p>
34098 Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
34099 </p>
34100
34101
34102
34103
34104
34105
34106 <hr>
34107 <h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
34108 <p><b>Section:</b> 19.5.6.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34109  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2010-10-29</p>
34110 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34111 <p><b>Discussion:</b></p>
34112 <p>
34113 In 19.5.6.1 [syserr.syserr.overview] we have the class definition of
34114 <tt>std::system_error</tt>. In contrast to all exception classes, which
34115 are constructible with a <tt>what_arg string</tt> (see 19.2 [std.exceptions],
34116 or <tt>ios_base::failure</tt> in 27.5.2.1.1 [ios::failure]), only overloads with with
34117 <tt>const string&amp;</tt> are possible. For consistency with the re-designed
34118 remaining exception classes this class should also provide
34119 c'tors which accept a const <tt>char* what_arg</tt> string.
34120 </p>
34121 <p>
34122 Please note that this proposed addition makes sense even
34123 considering the given implementation hint for <tt>what()</tt>, because
34124 <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
34125 <tt>runtime_error</tt>, which now has the additional c'tor overload
34126 accepting a <tt>const char*</tt>.
34127 </p>
34128
34129
34130 <p><b>Proposed resolution:</b></p>
34131 <p>
34132 This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> has been accepted and applied to the working paper.
34133 </p>
34134
34135 <p>
34136 Change 19.5.6.1 [syserr.syserr.overview] Class system_error overview, as indicated:
34137 </p>
34138
34139 <blockquote><pre>public:
34140   system_error(error_code ec, const string&amp; what_arg);
34141   <ins>system_error(error_code ec, const char* what_arg);</ins>
34142   system_error(error_code ec);
34143   system_error(int ev, const error_category* ecat,
34144       const string&amp; what_arg);
34145   <ins>system_error(int ev, const error_category* ecat,
34146       const char* what_arg);</ins>
34147   system_error(int ev, const error_category* ecat);
34148 </pre></blockquote>
34149
34150 <p>
34151 To 19.5.6.2 [syserr.syserr.members] Class system_error members add:
34152 </p>
34153
34154 <blockquote>
34155 <pre>system_error(error_code ec, const char* what_arg);
34156 </pre>
34157 <blockquote>
34158 <p>
34159 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
34160 </p>
34161 <p>
34162 <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
34163 </p>
34164 </blockquote>
34165
34166 <pre>system_error(int ev, const error_category* ecat, const char* what_arg);
34167 </pre>
34168
34169 <blockquote>
34170 <p>
34171 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
34172 </p>
34173 <p>
34174 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
34175 </p>
34176 </blockquote>
34177 </blockquote>
34178
34179
34180
34181
34182
34183
34184 <hr>
34185 <h3><a name="699"></a>699. N2111 changes min/max</h3>
34186 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34187  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2010-10-29</p>
34188 <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>
34189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34190 <p><b>Discussion:</b></p>
34191 <p>
34192 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
34193 changes <tt>min/max</tt> in several places in random from member
34194 functions to static data members. I believe this introduces
34195 a needless backward compatibility problem between C++0X and
34196 TR1. I'd like us to find new names for the static data members,
34197 or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
34198 </p>
34199
34200 <p>
34201 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
34202 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
34203 for some further discussion.
34204 </p>
34205
34206
34207 <p><b>Proposed resolution:</b></p>
34208 <p>
34209 Adopt the proposed resolution in
34210 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
34211 </p>
34212
34213
34214 <p><i>[
34215 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
34216 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
34217 ]</i></p>
34218
34219
34220
34221
34222
34223 <hr>
34224 <h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
34225 <p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34226  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2010-10-29</p>
34227 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
34228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34229 <p><b>Discussion:</b></p>
34230 <p>
34231 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
34232 defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
34233 the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
34234 (not standard, but a common extension from old STL). Be nice
34235 if we could avoid this name clash for backward compatibility.
34236 </p>
34237
34238
34239 <p><b>Proposed resolution:</b></p>
34240 <p>
34241 Change 20.3.3 [forward]:
34242 </p>
34243
34244 <blockquote>
34245 <pre>template &lt;class T&gt; struct identity
34246 {
34247     typedef T type;
34248     <ins>const T&amp; operator()(const T&amp; x) const;</ins>
34249 };
34250 </pre>
34251 <blockquote>
34252 <pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
34253 </pre>
34254 <blockquote>
34255 <p>
34256 <ins><i>Returns:</i> <tt>x</tt>.</ins>
34257 </p>
34258 </blockquote>
34259 </blockquote>
34260
34261 </blockquote>
34262
34263
34264
34265
34266
34267
34268 <hr>
34269 <h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
34270 <p><b>Section:</b> 23.6.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34271  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-07-03 <b>Last modified:</b> 2010-10-29</p>
34272 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
34273 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34274 <p><b>Discussion:</b></p>
34275 <p>
34276 <tt>map::at()</tt> need a complexity specification.
34277 </p>
34278
34279
34280 <p><b>Proposed resolution:</b></p>
34281 <p>
34282 Add the following to the specification of <tt>map::at()</tt>, 23.6.1.2 [map.access]:
34283 </p>
34284 <blockquote>
34285 <p>
34286 <i>Complexity:</i> logarithmic.
34287 </p>
34288 </blockquote>
34289
34290
34291
34292
34293
34294 <hr>
34295 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
34296 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
34297  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20 <b>Last modified:</b> 2010-10-29</p>
34298 <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>
34299 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
34300 <p><b>Discussion:</b></p>
34301 <p>
34302 The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
34303 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
34304 most of the member functions of node-based containers.  But the move-related changes
34305 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
34306 require <tt>CopyAssignable</tt>.
34307 </p>
34308
34309 <p>
34310 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
34311 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
34312 work may further reduce requirements.  For purposes of an easy reference, here are the
34313 minimum sequence requirements as I currently understand them.  Those items in requirements
34314 table in the working draft which do not appear below have been purposefully omitted for
34315 brevity as they do not have any requirements of this nature.  Some items which do not
34316 have any requirements of this nature are included below just to confirm that they were
34317 not omitted by mistake.
34318 </p>
34319
34320 <table border="1">
34321 <caption>Container Requirements</caption>
34322 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
34323 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>CopyConstructible</tt></td></tr>
34324 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
34325                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
34326 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>CopyAssignable</tt>.
34327                                 Sequences containers with <tt>propagate_on_container_move_assignment == false</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
34328                                 Associative containers with <tt>propagate_on_container_move_assignment == false</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
34329 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
34330 </tbody></table>
34331
34332 <p>
34333 </p>
34334
34335 <table border="1">
34336 <caption>Sequence Requirements</caption>
34337 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
34338 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
34339 <tr><td><tt>X(i, j)</tt></td><td>Sequences require <tt>value_type</tt> to be constructible from <tt>*i</tt>.  Additionally if input_iterators
34340                                  are used, <tt>vector</tt> and <tt>deque</tt> require <tt>MoveContructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
34341 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34342                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
34343 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
34344                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
34345 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34346                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
34347 <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34348                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
34349                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
34350                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
34351 <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
34352 <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
34353 <tr><td><tt>a.clear()</tt></td><td></td></tr>
34354 <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
34355                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
34356 <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
34357 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
34358                                      The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
34359 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34360 </tbody></table>
34361
34362 <p>
34363 </p>
34364
34365 <table border="1">
34366 <caption>Optional Sequence Requirements</caption>
34367 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
34368 <tr><td><tt>a.back()</tt></td><td></td></tr>
34369 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34370 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
34371 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34372 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
34373 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
34374 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
34375 <tr><td><tt>a[n]</tt></td><td></td></tr>
34376 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
34377 </tbody></table>
34378
34379 <p>
34380 </p>
34381
34382 <table border="1">
34383 <caption>Associative Container Requirements</caption>
34384 <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34385                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
34386 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34387 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34388 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34389 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34390 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34391 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34392 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34393                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
34394 </tbody></table>
34395
34396 <p>
34397 </p>
34398
34399 <table border="1">
34400 <caption>Unordered Associative Container Requirements</caption>
34401 <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34402                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
34403 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34404 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34405 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34406 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34407 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
34408 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
34409 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
34410                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
34411 </tbody></table>
34412
34413 <p>
34414 </p>
34415
34416 <table border="1">
34417 <caption>Miscellaneous Requirements</caption>
34418 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
34419                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
34420 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
34421                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
34422 </tbody></table>
34423
34424 <p><i>[
34425 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
34426 ]</i></p>
34427
34428
34429 <p><i>[
34430 Bellevue: This should be handled as part of the concepts work.
34431 ]</i></p>
34432
34433
34434 <p><i>[
34435 2009-07-20 Reopened by Howard:
34436 ]</i></p>
34437
34438
34439 <blockquote>
34440 <p>
34441 This is one of the issues that was "solved by concepts" and is now no longer solved.
34442 </p>
34443
34444 <p>
34445 In a nutshell, concepts adopted the "minimum requirements" philosophy outlined
34446 in the discussion of this issue, and enforced it.  My strong suggestion is that
34447 we translate the concepts specification into documentation for the containers.
34448 </p>
34449
34450 <p>
34451 What this means for vendors is that they will have to implement container members
34452 being careful to only use those characteristics of a type that the concepts specification
34453 formally allowed.  Note that I <em>am not</em> talking about <tt>enable_if</tt>'ing
34454 everything.  I am simply suggesting that (for example) we tell the vendor he can't call <tt>T's</tt>
34455 copy constructor or move constructor within the <tt>emplace</tt> member function, etc.
34456 </p>
34457
34458 <p>
34459 What this means for customers is that they will be able to use types within C++03
34460 containers which are sometimes not CopyConstructible, and sometimes not even
34461 MoveConstructible, etc.
34462 </p>
34463 </blockquote>
34464
34465 <p><i>[
34466 2009-10 Santa Cruz:
34467 ]</i></p>
34468
34469
34470 <blockquote>
34471 Leave open. Howard to provide wording.
34472 </blockquote>
34473
34474 <p><i>[
34475 2010-02-06 Howard provides wording.
34476 ]</i></p>
34477
34478
34479 <p><i>[
34480 2010-02-08 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
34481 ]</i></p>
34482
34483
34484 <p><i>[
34485 2010-02-10 Howard opened.  I neglected to reduce the requirements on value_type
34486 for the insert function of the ordered and unordered associative containers when
34487 the argument is an rvalue.  Fixed it.
34488 ]</i></p>
34489
34490
34491 <p><i>[
34492 2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
34493 ]</i></p>
34494
34495
34496 <p><i>[
34497 2010-03-08 Nico opens:
34498 ]</i></p>
34499
34500
34501 <blockquote>
34502 <p>
34503 I took the task to see whether <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a> is covered by 704
34504 already.
34505 However, by doing that I have the impression that
34506 704 is a big mistake.
34507 </p>
34508
34509 <p>
34510 Take e.g. the second change of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>:
34511 </p>
34512
34513 <blockquote>
34514 <p>
34515 Change 23.3.2.1 [deque.cons] para 5:
34516 </p>
34517 <blockquote>
34518 <i>Effects:</i> Constructs a <tt>deque</tt> with <tt>n</tt> default constructed
34519 elements.
34520 </blockquote>
34521 <p>
34522 where "default constructed" should be replaced by "value-initialized".
34523 This is the constructor out of a number of elements:
34524 </p>
34525 <blockquote><pre>ContType c(num)
34526 </pre></blockquote>
34527
34528 <p>
34529 704 says:
34530 </p>
34531
34532 <blockquote>
34533 <p>
34534 Remove the entire section 23.3.2.1 [deque.cons].
34535 </p>
34536 <blockquote>
34537 [ This section is already specified by the requirements tables. ]
34538 </blockquote>
34539 </blockquote>
34540
34541 <p>
34542 BUT, there is no requirement table that lists this constructor at all,
34543 which means that we would lose the entire specification of this function
34544 !!!
34545 </p>
34546
34547 <p>
34548 In fact, I found with further investigation, if we follow
34549 704 to remove 23.3.2.1 we
34550 </p>
34551 <ul>
34552 <li>
34553 have no semantics for
34554   <tt>ContType c(num)</tt>
34555 </li>
34556 <li>
34557 have no complexity and no allocator specification for
34558   <tt>ContType c(num,val)</tt>
34559 </li>
34560 <li>
34561 have no semantics for
34562   <tt>ContType c(num,val,alloc)</tt>
34563 </li>
34564 <li>
34565 - have no complexity and no allocator specification for
34566   <tt>ContType c(beg,end)</tt>
34567 </li>
34568 <li>
34569 - have no semantics for
34570   <tt>ContType c(beg,end,alloc)</tt>
34571 </li>
34572 <li>
34573 - have different wording (which might or might not give
34574  the same guarantees) for the <tt>assign</tt> functions
34575 </li>
34576 </ul>
34577
34578 <p>
34579 because all these guarantees are given in the removed
34580 section but nowhere else (as far as I saw).
34581 </p>
34582 <p>
34583 Looks to me that 704 need a significant review before we
34584 take that change, because chances are high that there
34585 are similar flaws in other proposed changes there
34586 (provided I am not missing anything).
34587 </p>
34588 </blockquote>
34589 </blockquote>
34590
34591 <p><i>[
34592 2010 Pittsburgh:
34593 ]</i></p>
34594
34595
34596 <blockquote>
34597 <p>
34598 Removed the parts from the proposed wording that removed existing sections,
34599 and set to Ready for Pittsburgh.
34600 </p>
34601 </blockquote>
34602
34603
34604
34605 <p><b>Rationale:</b></p>
34606 <p><i>[
34607 post San Francisco:
34608 ]</i></p>
34609
34610
34611 <blockquote>
34612 Solved by
34613 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
34614 </blockquote>
34615
34616 <p>
34617 This rationale is obsolete. 
34618 </p>
34619
34620
34621
34622 <p><b>Proposed resolution:</b></p>
34623
34624
34625  
34626 <p>
34627 Change 23.2.1 [container.requirements.general]/4:
34628 </p>
34629
34630 <blockquote>
34631 4 In Tables 91 and 92, <tt>X</tt> denotes a container class containing objects
34632 of type <tt>T</tt>, <tt>a</tt> and <tt>b</tt> denote values of type <tt>X</tt>,
34633 <tt>u</tt> denotes an identifier, <tt>r</tt> denotes <del>an lvalue or a const
34634 rvalue</del> <ins>a non-const value</ins> of type <tt>X</tt>, and <tt>rv</tt>
34635 denotes a non-const rvalue of type <tt>X</tt>.
34636 </blockquote>
34637
34638 <p>
34639 Change the following rows in Table 91 \97 Container requirements
34640 23.2.1 [container.requirements.general]:
34641 </p>
34642
34643 <blockquote>
34644 <table border="1">
34645 <caption>Table 91 \97 Container requirements</caption>
34646
34647 <tbody><tr>
34648 <th>Expression</th>
34649 <th>Return type</th>
34650 <th>Assertion/note<br>pre-/post-condition</th>
34651 <th>Complexity</th>
34652 </tr>
34653
34654 <tr>
34655 <td><tt>X::value_type</tt></td>
34656 <td><tt>T</tt></td>
34657 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>Destructible</tt>.</ins></td>
34658 <td>compile time</td>
34659 </tr>
34660
34661 </tbody></table>
34662
34663 </blockquote>
34664
34665 <p>
34666 Change 23.2.1 [container.requirements.general]/10:
34667 </p>
34668
34669 <blockquote>
34670 <p>
34671 Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.2.3, and 23.3.6.4) all
34672 container types defined in this Clause meet the following additional
34673 requirements:
34674 </p>
34675
34676 <ul>
34677 <li>
34678 ..
34679 </li>
34680
34681 <li>
34682 no <tt>erase()</tt>, <ins><tt>clear()</tt>,</ins> <tt>pop_back()</tt> or
34683 <tt>pop_front()</tt> function throws an exception.
34684 </li>
34685
34686 <li>
34687 ...
34688 </li>
34689 </ul>
34690
34691 </blockquote>
34692
34693 <p>
34694 Insert a new paragraph prior to 23.2.1 [container.requirements.general]/14:
34695 </p>
34696
34697 <blockquote>
34698 <p><ins>
34699 The descriptions of the requirements of the type <tt>T</tt> in this section
34700 use the terms <tt>CopyConstructible</tt>, <tt>MoveConstructible</tt>, <i>constructible
34701 from <tt>*i</tt></i>, and <i>constructible from <tt>args</tt></i>.  These terms
34702 are equivalent to the following expression using the appropriate arguments:
34703 </ins></p>
34704
34705 <blockquote><pre><ins>
34706 allocator_traits&lt;allocator_type&gt;::construct(x.get_allocator(), q, args...);
34707 </ins></pre></blockquote>
34708
34709 <p><ins>
34710 where <tt>x</tt> is a non-const lvalue of some container type <tt>X</tt> and
34711 <tt>q</tt> has type <tt>X::value_type*</tt>.
34712 </ins></p>
34713
34714 <p><ins>
34715 [<i>Example:</i> The container is going to move construct a <tt>T</tt>, so will
34716 call:
34717 </ins></p>
34718
34719 <blockquote><pre><ins>
34720 allocator_traits&lt;allocator_type&gt;::construct(get_allocator(), q, std::move(t));
34721 </ins></pre></blockquote>
34722
34723 <p><ins>
34724 The default implementation of construct will call:
34725 </ins></p>
34726
34727 <blockquote><pre><ins>
34728 ::new (q) T(std::forward&lt;T&gt;(t)); // where forward is the same as move here, cast to rvalue
34729 </ins></pre></blockquote>
34730
34731 <p><ins>
34732 But the allocator author may override the above definition of <tt>construct</tt>
34733 and do the construction of <tt>T</tt> by some other means. \97 <i>end
34734 example</i>]
34735 </ins></p>
34736
34737 <p>
34738 14 ...
34739 </p>
34740 </blockquote>
34741
34742 <p>
34743 Add to 23.2.1 [container.requirements.general]/14:
34744 </p>
34745
34746 <blockquote>
34747 14 In Table 93, <tt>X</tt> denotes an allocator-aware container class with a
34748 <tt>value_type</tt> of <tt>T</tt> using allocator of type <tt>A</tt>, <tt>u</tt>
34749 denotes a variable, <ins><tt>a</tt> and <tt>b</tt> denote non-const lvalues of
34750 type <tt>X</tt>,</ins> <tt>t</tt> denotes an lvalue or a const rvalue of type
34751 <tt>X</tt>, <tt>rv</tt> denotes a non-const rvalue of type <tt>X</tt>,
34752 <tt>m</tt> is a value of type <tt>A</tt>, and <tt>Q</tt> is an allocator type.
34753 </blockquote>
34754
34755 <p>
34756 Change or add the following rows in Table 93 \97 Allocator-aware container
34757 requirements in 23.2.1 [container.requirements.general]:
34758 </p>
34759
34760 <blockquote>
34761 <table border="1">
34762 <caption>Table 93 \97 Allocator-aware container requirements</caption>
34763
34764 <tbody><tr>
34765 <th>Expression</th>
34766 <th>Return type</th>
34767 <th>Assertion/note<br>pre-/post-condition</th>
34768 <th>Complexity</th>
34769 </tr>
34770
34771 <tr>
34772 <td><tt>X(t, m)<br>X u(t, m);</tt></td>
34773 <td></td>
34774 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt>.</ins><br>
34775 post: <tt>u == t</tt>,<br>
34776 <tt>get_allocator() == m</tt></td>
34777 <td>linear</td>
34778 </tr>
34779
34780 <tr>
34781 <td><tt>X(rv, m)<br>X u(rv, m);</tt></td>
34782 <td></td>
34783 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>MoveConstructible</tt>.</ins><br>
34784 post: <tt>u</tt> shall have the same elements, or copies of the elements, that
34785 <tt>rv</tt> had before this construction,<br>
34786 <tt>get_allocator() == m</tt></td>
34787 <td>constant if <tt>m == rv.get_allocator()</tt>, otherwise linear</td>
34788 </tr>
34789
34790 <tr>
34791 <td><ins><tt>a = t</tt></ins></td>
34792 <td><ins><tt>X&amp;</tt></ins></td>
34793 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
34794 <tt>CopyAssignable</tt><br>
34795 post: <tt>a == t</tt>.</ins></td>
34796 <td><ins>linear</ins></td>
34797 </tr>
34798
34799 <tr>
34800 <td><ins><tt>a = rv</tt></ins></td>
34801 <td><ins><tt>X&amp;</tt></ins></td>
34802 <td><ins><i>Requires:</i> If <tt>allocator_traits&lt; allocator_type &gt;
34803 ::propagate_on_container_move_assignment ::value</tt> is <tt>false</tt>,
34804 <tt>T</tt> is <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.<br>
34805 All existing elements of <tt>a</tt> are either move assigned
34806 <ins>to</ins> or destroyed.<br>
34807 <tt>a</tt> shall be equal to the value that <tt>rv</tt> had before this
34808 assignment</ins></td>
34809 <td><ins>linear</ins></td>
34810 </tr>
34811
34812 <tr>
34813 <td><ins><tt>a.swap(b);</tt></ins></td>
34814 <td><ins><tt>void</tt></ins></td>
34815 <td><ins>exchanges the contents of <tt>a</tt> and <tt>b</tt></ins></td>
34816 <td><ins>constant</ins></td>
34817 </tr>
34818
34819 </tbody></table>
34820
34821 </blockquote>
34822
34823 <p>
34824 Change the following rows in Table 94 \97 Sequence container requirements
34825 (in addition to container) in 23.2.3 [sequence.reqmts]:
34826 </p>
34827
34828 <blockquote>
34829 <table border="1">
34830 <caption>Table 94 \97 Sequence container requirements (in addition to
34831 container)</caption>
34832
34833 <tbody><tr>
34834 <th>Expression</th>
34835 <th>Return type</th>
34836 <th>Assertion/note<br>pre-/post-condition</th>
34837 </tr>
34838
34839 <tr>
34840 <td><tt>X(i, j)<br>X a(i, j)</tt></td>
34841 <td></td>
34842 <td><i>Requires:</i> <del>If the iterator's dereference operation returns an
34843 lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt>.</del>
34844 <ins><tt>T</tt> shall be constructible from <tt>*i</tt>.</ins><br>
34845 <ins>If the iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
34846 be <tt>MoveConstructible</tt>.</ins><br>
34847 Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly
34848 once.<br>
34849 post: <tt>size() ==</tt> distance between <tt>i</tt> and <tt>j</tt><br>
34850 Constructs a sequence container equal to the range <tt>[i, j)</tt></td>
34851 </tr>
34852
34853 <tr>
34854 <td><tt>a = il;</tt></td>
34855 <td><tt>X&amp;</tt></td>
34856 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
34857 <tt>CopyAssignable</tt>.</ins><br>
34858 <del><tt>a = X(il);</tt></del><br>
34859 <ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
34860 existing elements of <tt>a</tt> are either assigned or destroyed.</ins><br>
34861 <del>r</del><ins>R</ins>eturn<ins>s</ins> <tt>*this;</tt></td>
34862 </tr>
34863
34864 <tr>
34865 <td><tt>a.emplace(p, args);</tt></td>
34866 <td><tt>iterator</tt></td>
34867 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T,
34868 Args&gt;</tt>.</del> <ins><tt>T</tt> is constructible from <tt>args</tt>. 
34869 <tt>vector</tt> and <tt>deque</tt> also require <tt>T</tt> to be
34870 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</ins> Inserts an object
34871 of type <tt>T</tt> constructed with
34872 <tt>std::forward&lt;Args&gt;(args)...</tt> <ins>before <tt>p</tt></ins>.</td>
34873 </tr>
34874
34875 <tr>
34876 <td><tt>a.insert(p, t);</tt></td>
34877 <td><tt>iterator</tt></td>
34878 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt> and
34879 <tt>T</tt> shall be <tt>CopyAssignable</tt>.</del> <ins><tt>T</tt> shall be
34880 <tt>CopyConstructible</tt>. <tt>vector</tt> and <tt>deque</tt> also require
34881 <tt>T</tt> to be <tt>CopyAssignable</tt>.</ins> Inserts a copy <tt>t</tt> before
34882 <tt>p</tt>.</td>
34883 </tr>
34884
34885 <tr>
34886 <td><tt>a.insert(p, rv);</tt></td>
34887 <td><tt>iterator</tt></td>
34888 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T,
34889 T&amp;&amp;&gt;</tt> and <tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
34890 <ins><tt>T</tt> shall be <tt>MoveConstructible</tt>. <tt>vector</tt> and
34891 <tt>deque</tt> also require <tt>T</tt> to be <tt>MoveAssignable</tt>.</ins>
34892 Inserts a copy <tt>rv</tt> before <tt>p</tt>.</td>
34893 </tr>
34894
34895 <tr>
34896 <td><tt>a.insert(p, i, j)</tt></td>
34897 <td><tt>iterator</tt></td>
34898 <td><i>Requires:</i> <del>If the iterator's dereference operation returns an
34899 lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt>.</del>
34900 <ins><tt>T</tt> shall be constructible from <tt>*i</tt>.</ins><br> <ins>If the
34901 iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
34902 be <tt>MoveConstructible</tt> and  <tt>MoveAssignable</tt>.</ins><br> Each
34903 iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly once.<br>
34904 pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.<br> Inserts
34905 copies of elements in <tt>[i, j)</tt> before <tt>p</tt></td>
34906 </tr>
34907
34908 <tr>
34909 <td><tt>a.erase(q);</tt></td>
34910 <td><tt>iterator</tt></td>
34911 <td><i>Requires:</i> <del><tt>T</tt> and <tt>T</tt> shall be
34912 <tt>MoveAssignable</tt>.</del> <ins><tt>vector</tt> and <tt>deque</tt> require
34913 <tt>T</tt> to be <tt>MoveAssignable</tt>.</ins> Erases the element pointed to by
34914 <tt>q</tt>.</td>
34915 </tr>
34916
34917 <tr>
34918 <td><tt>a.erase(q1, q2);</tt></td>
34919 <td><tt>iterator</tt></td>
34920 <td><i>Requires:</i> <del><tt>T</tt> and <tt>T</tt> shall be
34921 <tt>MoveAssignable</tt>.</del> <ins><tt>vector</tt> and <tt>deque</tt> require
34922 <tt>T</tt> to be <tt>MoveAssignable</tt>.</ins> Erases the elements in the range
34923 <tt>[q1, q2)</tt>.</td>
34924 </tr>
34925
34926 <tr>
34927 <td><tt>a.clear();</tt></td>
34928 <td><tt>void</tt></td>
34929 <td><del><tt>erase(begin(), end())</tt></del><br>
34930 <ins>Destroys all elements in <tt>a</tt>. <ins>Invalidates all references,
34931 pointers, and iterators referring to the elements of <tt>a</tt> and may
34932 invalidate the past-the-end iterator.</ins><br></ins>
34933 post: <tt><del>size() == 0</del> <ins>a.empty() == true</ins></tt></td>
34934 </tr>
34935
34936 <tr>
34937 <td><tt>a.assign(i, j)</tt></td>
34938 <td><tt>void</tt></td>
34939 <td><i>Requires:</i> <del>If the iterator's dereference operation returns an
34940 lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt> and
34941 <tt>CopyAssignable</tt>.</del>
34942 <ins><tt>T</tt> shall be constructible and assignable from <tt>*i</tt>.  If the
34943 iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
34944 be <tt>MoveConstructible</tt>.</ins><br>
34945 Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly
34946 once.<br>
34947 pre: <tt>i</tt>, <tt>j</tt> are not iterators into <tt>a</tt>.<br>
34948 Replaces elements in <tt>a</tt> with a copy of <tt>[i, j)</tt>.</td>
34949 </tr>
34950
34951 </tbody></table>
34952
34953 </blockquote>
34954
34955 <p>
34956 Change the following rows in Table 95 \97 Optional sequence container operations
34957 in 23.2.3 [sequence.reqmts]:
34958 </p>
34959
34960 <blockquote>
34961 <table border="1">
34962 <caption>Table 95 \97 Optional sequence container operations</caption>
34963
34964 <tbody><tr>
34965 <th>Expression</th>
34966 <th>Return type</th>
34967 <th>Operational semantics</th>
34968 <th>Container</th>
34969 </tr>
34970
34971 <tr>
34972 <td><tt>a.emplace_front(args)</tt></td>
34973 <td><tt>void</tt></td>
34974 <td><del><tt>a.emplace(a.begin(), std::forward&lt;Args&gt;(args)...)</tt></del><br>
34975 <ins>Prepends an object of type <tt>T</tt> constructed with
34976 <tt>std::forward&lt;Args&gt;(args)...</tt>.</ins><br>
34977 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt></del>
34978 <ins><tt>T</tt> shall be constructible from <tt>args</tt>.</ins></td>
34979 <td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
34980 </tr>
34981
34982 <tr>
34983 <td><tt>a.emplace_back(args)</tt></td>
34984 <td><tt>void</tt></td>
34985 <td><del><tt>a.emplace(a.end(), std::forward&lt;Args&gt;(args)...)</tt></del><br>
34986 <ins>Appends an object of type <tt>T</tt> constructed with
34987 <tt>std::forward&lt;Args&gt;(args)...</tt>.</ins><br>
34988 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt></del>
34989 <ins><tt>T</tt> shall be constructible from <tt>args</tt>. <tt>vector</tt> also
34990 requires <tt>T</tt> to be <tt>MoveConstructible</tt>.</ins></td>
34991 <td><tt>list</tt>, <tt>deque</tt>, <tt>vector</tt></td>
34992 </tr>
34993
34994 <tr>
34995 <td><tt>a.push_front(t)</tt></td>
34996 <td><tt>void</tt></td>
34997 <td><del><tt>a.insert(a.begin(), t)</tt></del><br>
34998 <ins>Prepends a copy of <tt>t</tt>.</ins><br>
34999 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&gt;</tt> and
35000 <tt>T</tt> shall be <tt>CopyAssignable</tt>.</del>
35001 <ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins></td>
35002 <td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
35003 </tr>
35004
35005 <tr>
35006 <td><tt>a.push_front(rv)</tt></td>
35007 <td><tt>void</tt></td>
35008 <td><del><tt>a.insert(a.begin(), t)</tt></del><br>
35009 <ins>Prepends a copy of <tt>rv</tt>.</ins><br>
35010 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&amp;&amp;&gt;</tt> and
35011 <tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
35012 <ins><tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins></td>
35013 <td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
35014 </tr>
35015
35016 <tr>
35017 <td><tt>a.push_back(t)</tt></td>
35018 <td><tt>void</tt></td>
35019 <td><del><tt>a.insert(a.end(), t)</tt></del><br>
35020 <ins>Appends a copy of <tt>t</tt>.</ins><br>
35021 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&gt;</tt> and
35022 <tt>T</tt> shall be <tt>CopyAssignable</tt>.</del>
35023 <ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins></td>
35024 <td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
35025 </tr>
35026
35027 <tr>
35028 <td><tt>a.push_back(rv)</tt></td>
35029 <td><tt>void</tt></td>
35030 <td><del><tt>a.insert(a.end(), t)</tt></del><br>
35031 <ins>Appends a copy of <tt>rv</tt>.</ins><br>
35032 <i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&amp;&amp;&gt;</tt> and
35033 <tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
35034 <ins><tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins></td>
35035 <td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
35036 </tr>
35037
35038 <tr>
35039 <td><tt>a.pop_front()</tt></td>
35040 <td><tt>void</tt></td>
35041 <td><del><tt>a.erase(a.begin())</tt></del><br>
35042 <ins>Destroys the first element.</ins><br>
35043 <ins><i>Requires:</i> <tt>a.empty()</tt> shall be <tt>false</tt>.</ins></td>
35044 <td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
35045 </tr>
35046
35047 <tr>
35048 <td><tt>a.pop_back()</tt></td>
35049 <td><tt>void</tt></td>
35050 <td><del><tt>{ iterator tmp = a.end();<br>--tmp;<br>a.erase(tmp); }</tt></del><br>
35051 <ins>Destroys the last element.</ins><br>
35052 <ins><i>Requires:</i> <tt>a.empty()</tt> shall be <tt>false</tt>.</ins></td>
35053 <td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
35054 </tr>
35055
35056 </tbody></table>
35057
35058 </blockquote>
35059
35060 <p>
35061 Insert a new paragraph prior to 23.2.4 [associative.reqmts]/7, and
35062 edit paragraph 7:
35063 </p>
35064
35065 <blockquote>
35066 <p><ins>
35067 The associative containers meet all of the requirements of Allocator-aware
35068 containers (23.2.1 [container.requirements.general]), except for the
35069 containers <tt>map</tt> and <tt>multimap</tt>, the requirements placed on
35070 <tt>value_type</tt> in Table 93 apply instead directly to <tt>key_type</tt> and
35071 <tt>mapped_type</tt>. [<i>Note:</i> For example <tt>key_type</tt> and
35072 <tt>mapped_type</tt> are sometimes required to be <tt>CopyAssignable</tt> even
35073 though the <tt>value_type</tt> (<tt>pair&lt;const key_type,
35074 mapped_type&gt;</tt>) is not <tt>CopyAssignable</tt>. \97 <i>end note</i>]
35075 </ins></p>
35076
35077 <p>
35078 7 In Table 96, <tt>X</tt> denotes an associative container class, a denotes a
35079 value of <tt>X</tt>, <tt>a_uniq</tt> denotes a value of <tt>X</tt> when
35080 <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt>
35081 when <tt>X</tt> supports multiple keys, <tt>u</tt> denotes an identifier,
35082 <del><tt>r</tt> denotes an lvalue or a const rvalue of type <tt>X</tt>,
35083 <tt>rv</tt> denotes a non-const rvalue of type <tt>X</tt>,</del> <tt>i</tt> and
35084 <tt>j</tt> satisfy input iterator requirements and refer to elements implicitly
35085 convertible to <tt>value_type</tt>, <tt>[i,j)</tt> denotes a valid range,
35086 <tt>p</tt> denotes a valid const iterator to <tt>a</tt>, <tt>q</tt> denotes a
35087 valid dereferenceable const iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a
35088 valid range of const iterators in <tt>a</tt>, <tt>il</tt> designates an object
35089 of type <tt>initializer_list&lt;value_type&gt;</tt>, <tt>t</tt> denotes a value
35090 of <tt>X::value_type</tt>, <tt>k</tt> denotes a value of <tt>X::key_type</tt>
35091 and <tt>c</tt> denotes a value of type <tt>X::key_compare</tt>. <tt>A</tt>
35092 denotes the storage allocator used by <tt>X</tt>, if any, or
35093 <tt>std::allocator&lt;X::value_type&gt;</tt> otherwise, and <tt>m</tt> denotes
35094 an allocator of a type convertible to <tt>A</tt>. </p>
35095 </blockquote>
35096
35097 <p>
35098 Change or add the following rows in Table 96 \97 Associative container
35099 requirements (in addition to container) in 23.2.4 [associative.reqmts]:
35100 </p>
35101
35102 <blockquote>
35103 <table border="1">
35104 <caption>Table 96 \97 Associative container requirements (in addition to
35105 container)</caption>
35106
35107 <tbody><tr>
35108 <th>Expression</th>
35109 <th>Return type</th>
35110 <th>Assertion/note<br>pre-/post-condition</th>
35111 <th>Complexity</th>
35112 </tr>
35113
35114 <tr>
35115 <td><tt>X::key_type</tt></td>
35116 <td><tt>Key</tt></td>
35117 <td><ins><i>Requires:</i></ins> <tt>Key</tt> is <del><tt>CopyConstructible</tt> and
35118 <tt>CopyAssignable</tt></del> <ins><tt>Destructible</tt></ins></td>
35119 <td>compile time</td>
35120 </tr>
35121
35122 <tr>
35123 <td><ins><tt>X::mapped_type</tt> (<tt>map</tt> and <tt>multimap</tt> only)</ins></td>
35124 <td><ins><tt>T</tt></ins></td>
35125 <td><ins><i>Requires:</i> <tt>T</tt> is <tt>Destructible</tt></ins></td>
35126 <td><ins>compile time</ins></td>
35127 </tr>
35128
35129 <tr>
35130 <td><tt>X(c)<br>X a(c);</tt></td>
35131 <td></td>
35132 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
35133 key_compare&gt;</tt></del>.<br>
35134 <ins><tt>key_compare</tt> is <tt>CopyConstructible</tt>.</ins><br>
35135 Constructs an empty container.<br>
35136 Uses a copy of <tt>c</tt> as a comparison object.</td>
35137 <td>constant</td>
35138 </tr>
35139
35140 <tr>
35141 <td><tt>X()<br>X a;</tt></td>
35142 <td></td>
35143 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
35144 key_compare&gt;</tt></del>.<br>
35145 <ins><tt>key_compare</tt> is <tt>DefaultConstructible</tt>.</ins><br>
35146 Constructs an empty container.<br>
35147 Uses <tt>Compare()</tt> as a comparison object.</td>
35148 <td>constant</td>
35149 </tr>
35150
35151 <tr>
35152 <td><tt>X(i, j, c)<br>X a(i, j, c);</tt></td>
35153 <td></td>
35154 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
35155 key_compare&gt;</tt></del>.<br>
35156 <ins><tt>key_compare</tt> is <tt>CopyConstructible</tt>. <tt>value_type</tt>
35157 shall be constructible from <tt>*i</tt>.</ins><br>
35158 Constructs an empty container ans inserts elements from the range <tt>[i,
35159 j)</tt> into it; uses <tt>c</tt> as a comparison object.</td>
35160 <td><tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> is the distance from
35161 <tt>i</tt> to <tt>j</tt>); linear if <tt>[i, j)</tt> is sorted with
35162 <tt>value_comp()</tt></td>
35163 </tr>
35164
35165 <tr>
35166 <td><tt>X(i, j)<br>X a(i, j);</tt></td>
35167 <td></td>
35168 <td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
35169 key_compare&gt;</tt></del>.<br> <ins><tt>value_type</tt> shall be constructible
35170 from <tt>*i</tt>. <tt>key_compare</tt> is
35171 <tt>DefaultConstructible</tt>.</ins><br> Same as above, but uses
35172 <tt>Compare()</tt> as a comparison object.</td>
35173 <td>same as above</td>
35174 </tr>
35175
35176 <tr>
35177 <td><tt>a = il</tt></td>
35178 <td><tt>X&amp;</tt></td>
35179 <td><del><tt>a = X(il);<br>
35180 return *this;</tt></del><br>
35181 <ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
35182 <tt>CopyAssignable</tt>.</ins><br>
35183 <ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
35184 existing elements of <tt>a</tt> are either assigned or destroyed.</ins></td>
35185 <td><del>Same as <tt><tt>a = X(il)</tt></tt>.</del>
35186 <ins><tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> is 
35187 <tt>il.size()</tt> added to the existing size of <tt>a</tt>); linear if
35188 <tt>[il.begin(), il.end())</tt> is sorted with <tt>value_comp()</tt></ins></td>
35189 </tr>
35190
35191 <tr>
35192 <td><tt>a_uniq.emplace(args)</tt></td>
35193 <td><tt>pair&lt;iterator, bool&gt;</tt></td>
35194 <td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
35195 <tt>args</tt></ins><br>
35196 inserts a <tt>T</tt> object <tt>t</tt> constructed with
35197 <tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in
35198 the container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt>
35199 component of the returned pair is true if and only if the insertion takes place,
35200 and the iterator component of the pair points to the element with key equivalent
35201 to the key of <tt>t</tt>.</td>
35202 <td>logarithmic</td>
35203 </tr>
35204
35205 <tr>
35206 <td><tt>a_eq.emplace(args)</tt></td>
35207 <td><tt>iterator</tt></td>
35208 <td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
35209 <tt>args</tt></ins><br>
35210 inserts a <tt>T</tt> object <tt>t</tt> constructed with
35211 <tt>std::forward&lt;Args&gt;(args)...</tt> and returns the iterator pointing to
35212 the newly inserted element.</td>
35213 <td>logarithmic</td>
35214 </tr>
35215
35216 <tr>
35217 <td><tt>a_uniq.insert(t)</tt></td>
35218 <td><tt>pair&lt;iterator, bool&gt;</tt></td>
35219 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35220 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35221 <tt>CopyConstructible</tt>.</ins><br>
35222 inserts <tt>t</tt> if and only if there is no element in the container with key
35223 equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of the returned
35224 pair is true if and only if the insertion takes place, and the iterator
35225 component of the pair points to the element with key equivalent to the key of
35226 <tt>t</tt>.</td>
35227 <td>logarithmic</td>
35228 </tr>
35229
35230 <tr>
35231 <td><tt>a_eq.insert(t)</tt></td>
35232 <td><tt>iterator</tt></td>
35233 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35234 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35235 <tt>CopyConstructible</tt>.</ins><br>
35236 inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
35237 element. If a range containing elements equivalent to <tt>t</tt> exists in
35238 <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</td>
35239 <td>logarithmic</td>
35240 </tr>
35241
35242 <tr>
35243 <td><tt>a.insert(p, t)</tt></td>
35244 <td><tt>iterator</tt></td>
35245 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35246 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35247 <tt>CopyConstructible</tt>.</ins><br>
35248 inserts <tt>t</tt> if and only if there is no element with key equivalent to the
35249 key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in
35250 containers with equivalent keys; always returns the iterator pointing to the
35251 element with key equivalent to the key of <tt>t</tt>. <tt>t</tt> is inserted as
35252 close as possible to the position just prior to <tt>p</tt>.</td>
35253 <td>logarithmic in general, but amortized constant if <tt>t</tt> is inserted
35254 right before <tt>p</tt>.</td>
35255 </tr>
35256
35257 <tr>
35258 <td><tt>a.insert(i, j)</tt></td>
35259 <td><tt>void</tt></td>
35260 <td><ins><i>Requires:</i> <tt>T</tt> shall be
35261 constructible from <tt>*i</tt>.</ins><br>
35262 pre: <tt>i</tt>, <tt>j</tt> are not iterators into <tt>a</tt>. inserts each
35263 element from the range <tt>[i,j)</tt> if and only if there is no element with
35264 key equivalent to the key of that element in containers with unique keys; always
35265 inserts that element in containers with equivalent keys.</td>
35266 <td>N log(size() + N ) (N is the distance from i to j)</td>
35267 </tr>
35268
35269 </tbody></table>
35270
35271 </blockquote>
35272
35273 <p>
35274 Insert a new paragraph prior to 23.2.5 [unord.req]/9:
35275 </p>
35276
35277 <blockquote>
35278 <p><ins>
35279 The unordered associative containers meet all of the requirements of
35280 Allocator-aware containers (23.2.1 [container.requirements.general]),
35281 except for the containers <tt>unordered_map</tt> and <tt>unordered_multimap</tt>,
35282 the requirements placed on <tt>value_type</tt> in Table 93 apply instead
35283 directly to <tt>key_type</tt> and <tt>mapped_type</tt>. [<i>Note:</i> For
35284 example <tt>key_type</tt> and <tt>mapped_type</tt> are sometimes required to be
35285 <tt>CopyAssignable</tt> even though the <tt>value_type</tt> (<tt>pair&lt;const
35286 key_type, mapped_type&gt;</tt>) is not <tt>CopyAssignable</tt>. \97 <i>end
35287 note</i>]
35288 </ins></p>
35289
35290 <p>
35291 9 ...
35292 </p>
35293 </blockquote>
35294
35295 <p>
35296 Change or add the following rows in Table 98 \97 Unordered associative
35297 container requirements (in addition to container) in 23.2.5 [unord.req]:
35298 </p>
35299
35300 <blockquote>
35301 <table border="1">
35302 <caption>Table 98 \97 Unordered associative
35303 container requirements (in addition to container)</caption>
35304
35305 <tbody><tr>
35306 <th>Expression</th>
35307 <th>Return type</th>
35308 <th>Assertion/note<br>pre-/post-condition</th>
35309 <th>Complexity</th>
35310 </tr>
35311
35312 <tr>
35313 <td><tt>X::key_type</tt></td>
35314 <td><tt>Key</tt></td>
35315 <td><ins><i>Requires:</i></ins> <tt>Key</tt> shall be <del><tt>CopyAssignable</tt> and
35316 <tt>CopyConstructible</tt></del> <ins><tt>Destructible</tt></ins></td>
35317 <td>compile time</td>
35318 </tr>
35319
35320 <tr>
35321 <td><ins><tt>X::mapped_type</tt> (<tt>unordered_map</tt> and
35322 <tt>unordered_multimap</tt> only)</ins></td>
35323 <td><ins><tt>T</tt></ins></td>
35324 <td><ins><i>Requires:</i><tt>T</tt> is <tt>Destructible</tt></ins></td>
35325 <td><ins>compile time</ins></td>
35326 </tr>
35327
35328 <tr>
35329 <td><tt>X(n, hf, eq)<br>X a(n, hf, eq)</tt></td>
35330 <td><tt>X</tt></td>
35331 <td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
35332 <tt>CopyConstructible</tt>.</ins> Constructs an empty container with at least
35333 <tt>n</tt> buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as
35334 the key equality predicate. </td>
35335 <td><tt>O(N)</tt></td>
35336 </tr>
35337
35338 <tr>
35339 <td><tt>X(n, hf)<br>X a(n, hf)</tt></td>
35340 <td><tt>X</tt></td>
35341 <td><ins><i>Requires:</i> <tt>hasher</tt> is <tt>CopyConstructible</tt> and 
35342 <tt>key_equal</tt> is <tt>DefaultConstructible</tt>.</ins> Constructs an empty
35343 container with at least <tt>n</tt> buckets, using <tt>hf</tt> as the hash
35344 function and <tt>key_equal()</tt> as the key equality predicate.</td>
35345 <td><tt>O(N)</tt></td>
35346 </tr>
35347
35348 <tr>
35349 <td><tt>X(n)<br>X a(n)</tt></td>
35350 <td><tt>X</tt></td>
35351 <td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
35352 <tt>DefaultConstructible</tt>.</ins> Constructs an empty container with at least
35353 <tt>n</tt> buckets, using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as
35354 the key equality predicate. </td>
35355 <td><tt>O(N)</tt></td>
35356 </tr>
35357
35358 <tr>
35359 <td><tt>X()<br>X a</tt></td>
35360 <td><tt>X</tt></td>
35361 <td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
35362 <tt>DefaultConstructible</tt>.</ins> Constructs an empty container an unspecified number of buckets,
35363 using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as
35364 the key equality predicate. </td>
35365 <td>constant</td>
35366 </tr>
35367
35368 <tr>
35369 <td><tt>X(i, j, n, hf, eq)<br>X a(i, j, n, hf, eq)</tt></td>
35370 <td><tt>X</tt></td>
35371 <td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from
35372 <tt>*i</tt>. <tt>hasher</tt>  and <tt>key_equal</tt> are
35373 <tt>CopyConstructible</tt>.</ins><br>
35374 Constructs an empty container with at least <tt>n</tt> buckets, using
35375 <tt>hf</tt> as the hash function and <tt>eq</tt> as the key equality predicate,
35376 and inserts elements from <tt>[i, j)</tt> into it.</td>
35377 <td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
35378 case <tt>O(N<sup>2</sup>)</tt></td>
35379 </tr>
35380
35381 <tr>
35382 <td><tt>X(i, j, n, hf)<br>X a(i, j, n, hf)</tt></td>
35383 <td><tt>X</tt></td>
35384 <td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
35385 <tt>hasher</tt> is <tt>CopyConstructible</tt> and <tt>key_equal</tt> is
35386 <tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with at
35387 least <tt>n</tt> buckets, using <tt>hf</tt> as the hash function and
35388 <tt>key_equal()</tt> as the key equality predicate, and inserts elements from
35389 <tt>[i, j)</tt> into it.</td>
35390 <td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
35391 case <tt>O(N<sup>2</sup>)</tt></td>
35392 </tr>
35393
35394 <tr>
35395 <td><tt>X(i, j, n)<br>X a(i, j, n)</tt></td>
35396 <td><tt>X</tt></td>
35397 <td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
35398 <tt>hasher</tt> and <tt>key_equal</tt> are
35399 <tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with at
35400 least <tt>n</tt> buckets, using <tt>hasher()</tt> as the hash function and
35401 <tt>key_equal()</tt> as the key equality predicate, and inserts elements from
35402 <tt>[i, j)</tt> into it.</td>
35403 <td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
35404 case <tt>O(N<sup>2</sup>)</tt></td>
35405 </tr>
35406
35407 <tr>
35408 <td><tt>X(i, j)<br>X a(i, j)</tt></td>
35409 <td><tt>X</tt></td>
35410 <td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
35411 <tt>hasher</tt> and <tt>key_equal</tt> are
35412 <tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with an
35413 unspecified number of buckets, using <tt>hasher()</tt> as the hash function and
35414 <tt>key_equal()</tt> as the key equality predicate, and inserts elements from
35415 <tt>[i, j)</tt> into it.</td>
35416 <td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
35417 case <tt>O(N<sup>2</sup>)</tt></td>
35418 </tr>
35419
35420 <tr>
35421 <td><tt>X(b)<br>X a(b)</tt></td>
35422 <td><tt>X</tt></td>
35423 <td>Copy constructor. In addition to the <del>contained elements</del>
35424 <ins>requirements of Table 93 (23.2.1 [container.requirements.general])</ins>, copies the hash function,
35425 predicate, and maximum load factor.</td>
35426 <td>Average case linear in <tt>b.size()</tt>, worst case quadratic.</td>
35427 </tr>
35428
35429 <tr>
35430 <td><tt>a = b</tt></td>
35431 <td><tt>X&amp;</tt></td>
35432 <td>Copy assignment operator. In addition to the <del>contained elements</del>
35433 <ins>requirements of Table 93 (23.2.1 [container.requirements.general])</ins>, copies the hash function,
35434 predicate, and maximum load factor.</td>
35435 <td>Average case linear in <tt>b.size()</tt>, worst case quadratic.</td>
35436 </tr>
35437
35438 <tr>
35439 <td><tt>a = il</tt></td>
35440 <td><tt>X&amp;</tt></td>
35441 <td><del><tt>a = X(il); return *this;</tt></del><br>
35442 <ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
35443 <tt>CopyAssignable</tt>.</ins><br>
35444 <ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
35445 existing elements of <tt>a</tt> are either assigned or destroyed.</ins></td>
35446 <td>Average case linear in <tt>il.size()</tt>, worst case quadratic.</td>
35447 </tr>
35448
35449 <tr>
35450 <td><tt>a_uniq.emplace(args)</tt></td>
35451 <td><tt>pair&lt;iterator, bool&gt;</tt></td>
35452 <td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
35453 <tt>args</tt></ins><br>
35454 inserts a <tt>T</tt> object <tt>t</tt> constructed with
35455 <tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in
35456 the container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt>
35457 component of the returned pair is true if and only if the insertion takes place,
35458 and the iterator component of the pair points to the element with key equivalent
35459 to the key of <tt>t</tt>.</td>
35460 <td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
35461 </tr>
35462
35463 <tr>
35464 <td><tt>a_eq.emplace(args)</tt></td>
35465 <td><tt>iterator</tt></td>
35466 <td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
35467 <tt>args</tt></ins><br>
35468 inserts a <tt>T</tt> object <tt>t</tt> constructed with
35469 <tt>std::forward&lt;Args&gt;(args)...</tt> and returns the iterator pointing to
35470 the newly inserted element.</td>
35471 <td>Average case O(1), worst case O(<tt>a_eq.size()</tt>).</td>
35472 </tr>
35473
35474 <tr>
35475 <td><tt>a.emplace_hint(p, args)</tt></td>
35476 <td><tt>iterator</tt></td>
35477 <td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
35478 <tt>args</tt></ins><br>
35479 equivalent to <tt>a.emplace( std::forward&lt;Args&gt;(args)...)</tt>. Return
35480 value is an iterator pointing to the element with the key equivalent to the
35481 newly inserted element. The <tt>const_iterator p</tt> is a hint pointing to
35482 where the search should start. Implementations are permitted to ignore the
35483 hint.</td>
35484 <td>Average case O(1), worst case O(<tt>a.size()</tt>).</td>
35485 </tr>
35486
35487 <tr>
35488 <td><tt>a_uniq.insert(t)</tt></td>
35489 <td><tt>pair&lt;iterator, bool&gt;</tt></td>
35490 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35491 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35492 <tt>CopyConstructible</tt>.</ins><br>
35493 Inserts <tt>t</tt> if and only if there is no element in the container with key
35494 equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of the returned
35495 pair indicates whether the insertion takes place, and the iterator component
35496 points to the element with key equivalent to the key of <tt>t</tt>.</td>
35497 <td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
35498 </tr>
35499
35500 <tr>
35501 <td><tt>a_eq.insert(t)</tt></td>
35502 <td><tt>iterator</tt></td>
35503 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35504 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35505 <tt>CopyConstructible</tt>.</ins><br>
35506 Inserts <tt>t</tt>, and returns an iterator pointing to the newly inserted
35507 element.</td>
35508 <td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
35509 </tr>
35510
35511 <tr>
35512 <td><tt>a.insert(q, t)</tt></td>
35513 <td><tt>iterator</tt></td>
35514 <td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
35515 <tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
35516 <tt>CopyConstructible</tt>.</ins><br>
35517 Equivalent to <tt>a.insert(t)</tt>. Return value is an iterator pointing to the
35518 element with the key equivalent to that of <tt>t</tt>. The iterator <tt>q</tt>
35519 is a hint pointing to where the search should start. Implementations are
35520 permitted to ignore the hint.</td>
35521 <td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
35522 </tr>
35523
35524 <tr>
35525 <td><tt>a.insert(i, j)</tt></td>
35526 <td><tt>void</tt></td>
35527 <td><ins><i>Requires:</i> <tt>T</tt> shall be
35528 constructible from <tt>*i</tt>.</ins><br>
35529 Pre: <tt>i</tt> and <tt>j</tt> are not iterators in <tt>a</tt>. Equivalent to
35530 <tt>a.insert(t)</tt> for each element in <tt>[i,j)</tt>.</td>
35531 <td>Average case O(<tt>N</tt>), where <tt>N</tt> is <tt>distance(i, j)</tt>.
35532 Worst case O(<tt>N * a.size()</tt>).</td>
35533 </tr>
35534
35535 </tbody></table>
35536
35537 </blockquote>
35538
35539 <p>
35540 Change 23.3.3 [forwardlist]/2:
35541 </p>
35542
35543 <blockquote>
35544 2 A <tt>forward_list</tt> satisfies all of the requirements of a container
35545 (table 91), except that the <tt>size()</tt> member function is not provided.
35546 <ins>A <tt>forward_list</tt> also satisfies all of the requirements of an
35547 allocator-aware container (table 93).  And <tt>forward_list</tt> provides the
35548 <tt>assign</tt> member functions as specified in Table 94, Sequence container
35549 requirements, and several of the optional sequence container requirements (Table
35550 95).</ins>
35551 Descriptions are provided here only for operations on <tt>forward_list</tt> that
35552 are not described in that table or for operations where there is additional
35553 semantic information.
35554 </blockquote>
35555
35556 <p>
35557 Add a new paragraph after 23.3.3.4 [forwardlist.modifiers]/23:
35558 </p>
35559
35560 <blockquote><pre>void clear();
35561 </pre>
35562
35563 <blockquote>
35564 <p>
35565 23 <i>Effects:</i> Erases all elements in the range <tt>[begin(),end())</tt>.
35566 </p>
35567 <p><ins>
35568 <i>Remarks:</i> Does not invalidate past-the-end iterators.
35569 </ins></p>
35570 </blockquote>
35571 </blockquote>
35572
35573 <p>
35574 Change 23.4.1.2 [vector.capacity]/13:
35575 </p>
35576
35577 <blockquote><pre>void resize(size_type sz, const T&amp; c);
35578 </pre>
35579 <blockquote>
35580 13 <i>Requires:</i> <ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins>
35581 If <tt>value_type</tt> has a move constructor, that constructor shall not throw
35582 any exceptions.
35583 </blockquote>
35584 </blockquote>
35585
35586 <p>
35587 In 23.7.3 [unord.set] and 23.7.4 [unord.multiset] substitute
35588 "<tt>Key</tt>" for "<tt>Value</tt>".
35589 </p>
35590
35591 <blockquote>
35592 <p><i>[
35593 The above substitution is normative as it ties into the requirements table.
35594 ]</i></p>
35595
35596 </blockquote>
35597
35598
35599
35600
35601
35602
35603 <hr>
35604 <h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
35605 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35606  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2010-10-29</p>
35607 <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>
35608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35609 <p><b>Discussion:</b></p>
35610 <p>
35611 The current working draft has a type-trait <tt>decay</tt> in 20.7.7.6 [meta.trans.other].
35612 </p>
35613
35614 <p>
35615 Its use is to turn C++03 pass-by-value parameters into efficient C++0x
35616 pass-by-rvalue-reference parameters. However, the current definition
35617 introduces an incompatible change where the cv-qualification of the
35618 parameter type is retained. The deduced type should loose such
35619 cv-qualification, as pass-by-value does.
35620 </p>
35621
35622
35623 <p><b>Proposed resolution:</b></p>
35624 <p>
35625 In 20.7.7.6 [meta.trans.other] change the last sentence:
35626 </p>
35627
35628 <blockquote><p>
35629 Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
35630 </p></blockquote>
35631
35632 <p>
35633 In 20.4.2.4 [tuple.creation]/1 change:
35634 </p>
35635
35636 <blockquote><p>
35637 <del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
35638 corresponding type <tt>Ti</tt> in <tt>Types</tt>,
35639 <tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
35640 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
35641 <tt>decay&lt;Ti&gt;::type</tt>.</del>
35642 <ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
35643 <tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
35644 is <tt>X&amp;</tt> if <tt>Ui</tt> equals
35645 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
35646 <tt>Ui</tt>.</ins>
35647 </p></blockquote>
35648
35649
35650
35651
35652
35653
35654 <hr>
35655 <h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
35656 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35657  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2010-10-29</p>
35658 <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>
35659 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35660 <p><b>Discussion:</b></p>
35661 <p>
35662 The current draft has <tt>make_pair()</tt> in 20.3.5 [pairs]/16
35663 and <tt>make_tuple()</tt> in 20.4.2.4 [tuple.creation].
35664 <tt>make_tuple()</tt> detects the presence of
35665 <tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
35666 such cases. <tt>make_pair()</tt> would OTOH create a
35667 <tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
35668 functions are made to behave similar in this respect to minimize
35669 confusion.
35670 </p>
35671
35672
35673 <p><b>Proposed resolution:</b></p>
35674 <p>
35675 In 20.3 [utility] change the synopsis for make_pair() to read
35676 </p>
35677
35678 <blockquote><pre>template &lt;class T1, class T2&gt;
35679   pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
35680 </pre></blockquote>
35681
35682 <p>
35683 In 20.3.5 [pairs]/16 change the declaration to match the above synopsis.
35684 Then change the 20.3.5 [pairs]/17 to:
35685 </p>
35686
35687 <blockquote>
35688 <p>
35689 <i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
35690 <tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
35691 <tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
35692 <tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
35693 <tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
35694 <tt>Ui</tt>.</ins>
35695 </p>
35696 </blockquote>
35697
35698
35699
35700
35701
35702
35703 <hr>
35704 <h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
35705 <p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35706  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-13 <b>Last modified:</b> 2010-10-29</p>
35707 <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>
35708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35709 <p><b>Discussion:</b></p>
35710 <p>
35711 The changes made for <tt>constexpr</tt> in 21.2.3 [char.traits.specializations] have 
35712 not only changed the <tt>not_eof</tt> function from pass by const reference to 
35713 pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
35714 <tt>char_type</tt>.
35715 </p>
35716 <p>
35717 This doesn't work for type <tt>char</tt>, and is inconsistent with the 
35718 requirements in Table 56, Traits requirements, 21.2.1 [char.traits.require].
35719 </p>
35720
35721 <p>
35722 Pete adds:
35723 </p>
35724
35725 <blockquote><p>
35726 For what it's worth, that may not have been an intentional change. 
35727 N2349, which detailed the changes for adding constant expressions to 
35728 the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
35729 surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
35730 So the intention may have been just to change to pass by value, with 
35731 text incorrectly copied from the standard.
35732 </p></blockquote>
35733
35734
35735
35736 <p><b>Proposed resolution:</b></p>
35737 <p>
35738 Change the signature in 21.2.3.1 [char.traits.specializations.char],
35739 21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t],
35740 and 21.2.3.4 [char.traits.specializations.wchar.t] to
35741 </p>
35742
35743 <blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
35744 </pre></blockquote>
35745
35746
35747
35748 <p><i>[
35749 Bellevue:
35750 ]</i></p>
35751
35752
35753 <blockquote>
35754 Resolution: NAD editorial - up to Pete's judgment
35755 </blockquote>
35756
35757 <p><i>[
35758 Post Sophia Antipolis
35759 ]</i></p>
35760
35761
35762 <blockquote>
35763 Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
35764 </blockquote>
35765
35766
35767
35768
35769 <hr>
35770 <h3><a name="710"></a>710. Missing postconditions</h3>
35771 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35772  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2010-10-29</p>
35773 <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>
35774 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35775 <p><b>Discussion:</b></p>
35776 <p>
35777 A discussion on
35778 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
35779 has identified a contradiction in the <tt>shared_ptr</tt> specification.
35780 The <tt>shared_ptr</tt> move constructor and the cast functions are
35781 missing postconditions for the <tt>get()</tt> accessor.
35782 </p>
35783
35784 <p><i>[
35785 Bellevue:
35786 ]</i></p>
35787
35788
35789 <blockquote>
35790 <p>
35791 Move to "ready", adopting the first (Peter's) proposed resolution.
35792 </p>
35793 <p>
35794 Note to the project editor: there is an editorial issue here. The
35795 wording for the postconditions of the casts is slightly awkward, and the
35796 editor should consider rewording "If w is the return value...", e. g. as
35797 "For a return value w...".
35798 </p>
35799 </blockquote>
35800
35801
35802 <p><b>Proposed resolution:</b></p>
35803 <p>
35804 Add to 20.9.10.2.1 [util.smartptr.shared.const]:
35805 </p>
35806
35807 <blockquote>
35808 <pre>shared_ptr(shared_ptr&amp;&amp; r);
35809 template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
35810 </pre>
35811 <blockquote>
35812 <p>
35813 <i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
35814 shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
35815 </p>
35816 </blockquote>
35817 </blockquote>
35818
35819 <p>
35820 Add to 20.9.10.2.10 [util.smartptr.shared.cast]:
35821 </p>
35822
35823 <blockquote>
35824 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
35825 </pre>
35826 <blockquote>
35827 <p>
35828 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
35829 <tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
35830 </p>
35831 </blockquote>
35832 </blockquote>
35833
35834 <blockquote>
35835 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
35836 </pre>
35837 <blockquote>
35838 <p>
35839 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
35840 </p>
35841 </blockquote>
35842 </blockquote>
35843
35844 <blockquote>
35845 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
35846 </pre>
35847 <blockquote>
35848 <p>
35849 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
35850 <tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
35851 </p>
35852 </blockquote>
35853 </blockquote>
35854
35855 <p>
35856 Alberto Ganesh Barbati has written an
35857 <a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
35858 where he suggests (among other things) that the casts be respecified in terms of
35859 the aliasing constructor as follows:
35860 </p>
35861
35862 <p>
35863 Change 20.9.10.2.10 [util.smartptr.shared.cast]:
35864 </p>
35865
35866 <blockquote>
35867 <p>
35868 -2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
35869 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
35870 object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
35871 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
35872 </p>
35873 </blockquote>
35874
35875 <blockquote>
35876 <p>
35877 -6- <i>Returns:</i>
35878 </p>
35879 <ul>
35880 <li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
35881 a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
35882 of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
35883 <li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
35884 <li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
35885 <li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
35886 </ul>
35887 </blockquote>
35888
35889 <blockquote>
35890 <p>
35891 -10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
35892 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
35893 object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
35894 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
35895 </p>
35896 </blockquote>
35897
35898 <p>
35899 This takes care of the missing postconditions for the casts by bringing
35900 in the aliasing constructor postcondition "by reference".
35901 </p>
35902
35903
35904
35905
35906
35907
35908 <hr>
35909 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
35910 <p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
35911  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2010-10-29</p>
35912 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
35913 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
35914 <p><b>Discussion:</b></p>
35915 <p>
35916 A discussion on
35917 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
35918 has identified a contradiction in the <tt>shared_ptr</tt> specification.
35919 The note:
35920 </p>
35921
35922 <blockquote><p>
35923 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
35924 -end note ]
35925 </p></blockquote>
35926
35927 <p>
35928 after the aliasing constructor
35929 </p>
35930
35931 <blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
35932 </pre></blockquote>
35933
35934 <p>
35935 reflects the intent of
35936 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
35937 to, well, allow the creation of an empty <tt>shared_ptr</tt>
35938 with a non-NULL stored pointer.
35939 </p>
35940
35941 <p>
35942 This is contradicted by the second sentence in the Returns clause of 20.9.10.2.5 [util.smartptr.shared.obs]:
35943 </p>
35944
35945 <blockquote>
35946 <pre>T* get() const;
35947 </pre>
35948 <blockquote><p>
35949 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
35950 </p></blockquote>
35951 </blockquote>
35952
35953 <p><i>[
35954 Bellevue:
35955 ]</i></p>
35956
35957
35958 <blockquote>
35959 <p>
35960 Adopt option 1 and move to review, not ready.
35961 </p>
35962 <p>
35963 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
35964 isn't defined anywhere), and whether we have a good mental model for how
35965 one behaves. We think it might be possible to deduce what the definition
35966 should be, but the words just aren't there. We need to open an issue on
35967 the use of this undefined term. (The resolution of that issue might
35968 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.)
35969 </p>
35970 <p>
35971 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
35972 now that we realize some of its implications, and we need to keep an eye
35973 on it, but there isn't support for removing this feature at this time.
35974 </p>
35975 </blockquote>
35976
35977 <p><i>[
35978 Sophia Antipolis:
35979 ]</i></p>
35980
35981
35982 <blockquote>
35983 <p>
35984 We heard from Peter Dimov, who explained his reason for preferring solution 1.
35985 </p>
35986 <p>
35987 Because it doesn't seem to add anything. It simply makes the behavior
35988 for p = 0 undefined. For programmers who don't create empty pointers
35989 with p = 0, there is no difference. Those who do insist on creating them
35990 presumably have a good reason, and it costs nothing for us to define the
35991 behavior in this case.
35992 </p>
35993 <p>
35994 The aliasing constructor is sharp enough as it is, so "protecting" users
35995 doesn't make much sense in this particular case.
35996 </p>
35997 <p>
35998 &gt; Do you have a use case for r being empty and r being non-null? 
35999 </p>
36000 <p>
36001 I have received a few requests for it from "performance-conscious"
36002 people (you should be familiar with this mindset) who don't like the
36003 overhead of allocating and maintaining a control block when a null
36004 deleter is used to approximate a raw pointer. It is obviously an "at
36005 your own risk", low-level feature; essentially a raw pointer behind a
36006 shared_ptr facade.
36007 </p>
36008 <p>
36009 We could not agree upon a resolution to the issue; some of us thought
36010 that Peter's description above is supporting an undesirable behavior.
36011 </p>
36012 </blockquote>
36013
36014 <p><i>[
36015 2009-07 Frankfurt:
36016 ]</i></p>
36017
36018
36019 <blockquote>
36020 <p>
36021 We favor option 1, move to Ready.
36022 </p>
36023 <p><i>[
36024 Howard:  Option 2 commented out for clarity, and can be brought back.
36025 ]</i></p>
36026
36027 </blockquote>
36028
36029
36030
36031 <p><b>Proposed resolution:</b></p>
36032 <p>
36033 In keeping the N2351 spirit and obviously my preference, change 20.9.10.2.5 [util.smartptr.shared.obs]:
36034 </p>
36035
36036 <blockquote>
36037 <pre>T* get() const;
36038 </pre>
36039 <blockquote><p>
36040 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
36041 </p></blockquote>
36042 </blockquote>
36043
36044
36045
36046
36047
36048
36049
36050
36051 <hr>
36052 <h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
36053 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36054  <b>Submitter:</b> Marc Paterno <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-10-29</p>
36055 <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>
36056 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36057 <p><b>Discussion:</b></p>
36058 <p>
36059 One of the motivations for incorporating <tt>seed_seq::size()</tt>
36060 was to simplify the wording
36061 in other parts of 26.5 [rand].
36062 As a side effect of resolving related issues,
36063 all such references
36064 to <tt>seed_seq::size()</tt> will have been excised.
36065 More importantly,
36066 the present specification is contradictory,
36067 as "The number of 32-bit units the object can deliver"
36068 is not the same as "the result of <tt>v.size()</tt>."
36069 </p>
36070
36071 <p>
36072 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
36073 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
36074 for some further discussion.
36075 </p>
36076
36077
36078 <p><b>Proposed resolution:</b></p>
36079 <p>
36080 Adopt the proposed resolution in
36081 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
36082 </p>
36083
36084
36085 <p><i>[
36086 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
36087 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
36088 ]</i></p>
36089
36090
36091
36092
36093
36094 <hr>
36095 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
36096 <p><b>Section:</b> 25.4.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36097  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
36098 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36099 <p><b>Discussion:</b></p>
36100 <p>
36101 The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
36102 log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
36103 average", with no worst case complicity specified. The intention was to
36104 allow a median-of-three quicksort implementation, which is usually <tt>O(N
36105 log N)</tt> but can be quadratic for pathological inputs. However, there is
36106 no longer any reason to allow implementers the freedom to have a
36107 worst-cast-quadratic sort algorithm. Implementers who want to use
36108 quicksort can use a variant like David Musser's "Introsort" (Software
36109 Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
36110 log N)</tt> in the worst case without incurring additional overhead in the
36111 average case. Most C++ library implementers already do this, and there
36112 is no reason not to guarantee it in the standard.
36113 </p>
36114
36115
36116 <p><b>Proposed resolution:</b></p>
36117 <p>
36118 In 25.4.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
36119 </p>
36120
36121 <blockquote>
36122 <p>
36123 <i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
36124 comparisons<del> on the average</del>.<del><sup>266)</sup></del>
36125 </p>
36126 <p>
36127 <del><sup>266)</sup>
36128 If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
36129 (25.3.1.3) should be used.</del>
36130 </p>
36131 </blockquote>
36132
36133
36134
36135
36136
36137
36138 <hr>
36139 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
36140 <p><b>Section:</b> 25.2.13 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36141  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
36142 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
36143 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36144 <p><b>Discussion:</b></p>
36145 <p>
36146 The complexity for <tt>search_n</tt> (25.2.13 [alg.search] par 7) is specified as "At most
36147 (last - first ) * count applications of the corresponding predicate if
36148 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
36149 Regardless of the value of count, there is no reason to examine any
36150 element in the range more than once.
36151 </p>
36152
36153
36154 <p><b>Proposed resolution:</b></p>
36155 <p>
36156 Change the complexity to "At most (last - first) applications of the corresponding predicate".
36157 </p>
36158
36159 <blockquote>
36160 <pre>template&lt;class ForwardIterator, class Size, class T&gt; 
36161   ForwardIterator 
36162     search_n(ForwardIterator first , ForwardIterator last , Size count , 
36163              const T&amp; value ); 
36164
36165 template&lt;class ForwardIterator, class Size, class T, 
36166          class BinaryPredicate&gt; 
36167   ForwardIterator 
36168     search_n(ForwardIterator first , ForwardIterator last , Size count , 
36169              const T&amp; value , BinaryPredicate pred );
36170 </pre>
36171 <blockquote>
36172 <p>
36173 <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
36174 <del>if <tt>count</tt> is positive, or 0 otherwise</del>.
36175 </p>
36176 </blockquote>
36177 </blockquote>
36178
36179
36180
36181
36182
36183
36184 <hr>
36185 <h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
36186 <p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36187  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
36188 <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>
36189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36190 <p><b>Discussion:</b></p>
36191 <p>
36192 The complexity for <tt>minmax_element</tt> (25.4.7 [alg.min.max] par 16) says "At most <tt>max(2 *
36193 (last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
36194 i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
36195 <tt>max_element</tt> separately. This is gratuitously inefficient. There is a
36196 well known technique that does better: see section 9.1 of CLRS
36197 (Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
36198 </p>
36199
36200
36201 <p><b>Proposed resolution:</b></p>
36202 <p>
36203 Change 25.4.7 [alg.min.max] to:
36204 </p>
36205
36206 <blockquote>
36207 <pre>template&lt;class ForwardIterator&gt; 
36208   pair&lt;ForwardIterator, ForwardIterator&gt; 
36209     minmax_element(ForwardIterator first , ForwardIterator last); 
36210 template&lt;class ForwardIterator, class Compare&gt; 
36211   pair&lt;ForwardIterator, ForwardIterator&gt; 
36212     minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
36213 </pre>
36214 <blockquote>
36215 <p>
36216 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
36217 <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
36218 comp)</tt></del> <ins>the first iterator in <tt>[first,
36219 last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
36220 <ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
36221 <tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
36222 in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
36223 </p>
36224 <p>
36225 <i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
36226 <ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
36227 corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
36228 </p>
36229 </blockquote>
36230 </blockquote>
36231
36232
36233
36234
36235
36236
36237 <hr>
36238 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
36239 <p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
36240  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31 <b>Last modified:</b> 2010-10-29</p>
36241 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36242 <p><b>Discussion:</b></p>
36243 <p>
36244 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
36245 </p>
36246
36247 <blockquote>
36248 <p>
36249 The following productions within the ECMAScript grammar are modified as follows:
36250 </p>
36251
36252 <blockquote><pre>CharacterClass ::
36253 [ [lookahead &#8713; {^}] ClassRanges ]
36254 [ ^ ClassRanges ]
36255 </pre></blockquote>
36256
36257 </blockquote>
36258
36259 <p>
36260 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
36261 </p>
36262
36263 <p>
36264 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
36265 </p>
36266
36267 <p><i>[
36268 Batavia (2009-05):
36269 ]</i></p>
36270
36271 <blockquote>
36272 <p>
36273 We agree that what is specified is identical to what ECMA-262 specifies.
36274 Pete would like to take a bit of time to assess whether we had intended,
36275 but failed, to make a change.
36276 It would also be useful to hear from John Maddock on the issue.
36277 </p>
36278 <p>
36279 Move to Open.
36280 </p>
36281 </blockquote>
36282
36283 <p><i>[
36284 2009-07 Frankfurt:
36285 ]</i></p>
36286
36287
36288 <blockquote>
36289 Move to Ready.
36290 </blockquote>
36291
36292
36293
36294 <p><b>Proposed resolution:</b></p>
36295 <p>
36296 Remove this mention of the CharacterClass production.
36297 </p>
36298
36299 <blockquote><pre><del>CharacterClass ::
36300 [ [lookahead &#8713; {^}] ClassRanges ]
36301 [ ^ ClassRanges ]</del>
36302 </pre></blockquote>
36303
36304
36305
36306
36307
36308
36309 <hr>
36310 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
36311 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
36312  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-11-20</p>
36313 <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>
36314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
36315 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a></p>
36316 <p><b>Discussion:</b></p>
36317 <p>
36318 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
36319 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
36320 </p>
36321
36322 <blockquote>
36323 <p>
36324 -11- A type is a <i>literal</i> type if it is:
36325 </p>
36326 <ul>
36327 <li>a scalar type; or</li>
36328 <li><p>a class type (clause 9) with</p>
36329 <ul>
36330 <li>a trivial copy constructor,</li>
36331 <li>a trivial destructor,</li>
36332 <li>at least one constexpr constructor other than the copy constructor,</li>
36333 <li>no virtual base classes, and</li>
36334 <li>all non-static data members and base classes of literal types; or</li>
36335 </ul>
36336 </li>
36337 <li>an array of literal type.</li>
36338 </ul>
36339 </blockquote>
36340
36341 <p>
36342 I strongly suggest that the standard provides a type traits for
36343 literal types in 20.7.4.3 [meta.unary.prop] for several reasons:
36344 </p>
36345
36346 <ol type="a">
36347 <li>To keep the traits in sync with existing types.</li>
36348 <li>I see many reasons for programmers to use this trait in template
36349    code to provide optimized template definitions for these types,
36350    see below.</li>
36351 <li>A user-provided definition of this trait is practically impossible
36352 to write portably.</li>
36353 </ol>
36354
36355 <p>
36356 The special problem of reason (c) is that I don't see currently a
36357 way to portably test the condition for literal class types:
36358 </p>
36359
36360 <blockquote>
36361 <ul>
36362 <li>at least one constexpr constructor other than the copy constructor,</li>
36363 </ul>
36364 </blockquote>
36365
36366 <p><i>[
36367 Alisdair is considering preparing a paper listing a number of missing
36368 type traits, and feels that it might be useful to handle them all
36369 together rather than piecemeal. This would affect issue 719 and 750.
36370 These two issues should move to OPEN pending AM paper on type traits.
36371 ]</i></p>
36372
36373
36374 <p><i>[
36375 2009-07 Frankfurt:
36376 ]</i></p>
36377
36378
36379 <blockquote>
36380 Beman, Daniel, and Alisdair will work on a paper proposing new type traits.
36381 </blockquote>
36382
36383 <p><i>[
36384 Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
36385 ]</i></p>
36386
36387
36388 <p><i>[
36389 2009-10 Santa Cruz:
36390 ]</i></p>
36391
36392
36393 <blockquote>
36394 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
36395 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.htm">N2984</a>.
36396 </blockquote>
36397
36398
36399
36400 <p><b>Proposed resolution:</b></p>
36401 <p>
36402 In 20.7.2 [meta.type.synop] in the group "type properties",
36403 just below the line
36404 </p>
36405
36406 <blockquote><pre>template &lt;class T&gt; struct is_pod;
36407 </pre></blockquote>
36408
36409 <p>
36410 add a new one:
36411 </p>
36412
36413 <blockquote><pre>template &lt;class T&gt; struct is_literal;
36414 </pre></blockquote>
36415
36416 <p>
36417 In 20.7.4.3 [meta.unary.prop], table Type Property Predicates, just
36418 below the line for the <tt>is_pod</tt> property add a new line:
36419 </p>
36420
36421 <table border="1">
36422 <tbody><tr>
36423 <th>Template</th><th>Condition</th><th>Preconditions</th>
36424 </tr>
36425 <tr>
36426 <td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
36427 <td><tt>T</tt> is a literal type (3.9)</td>
36428 <td><tt>T</tt> shall be a complete type, an
36429 array of unknown bound, or
36430 (possibly cv-qualified) <tt>void</tt>.</td>
36431 </tr>
36432 </tbody></table>
36433
36434
36435
36436
36437
36438
36439 <hr>
36440 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
36441 <p><b>Section:</b> 23.3.1 [array], 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36442  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-10-29</p>
36443 <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>
36444 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36445 <p><b>Discussion:</b></p>
36446 <ol>
36447 <li>
36448 The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
36449 <tt>constexpr</tt> because this is easily to proof and to implement following it's operational
36450 semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
36451 </li>
36452 <li>
36453 The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
36454 <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
36455 bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
36456 </li>
36457 <li>
36458 I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
36459 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
36460 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
36461 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
36462 initialisation. What have I overlooked here?
36463 </li>
36464 </ol>
36465
36466 <p><i>[
36467 Sophia Antipolis:
36468 ]</i></p>
36469
36470
36471 <blockquote>
36472 <p>
36473 We handle this as two parts
36474 </p>
36475 <ol>
36476 <li>
36477 The proposed resolution is correct; move to ready.
36478 </li>
36479 <li>
36480 The issue points out a real problem, but the issue is larger than just
36481 this solution. We believe a paper is needed, applying the full new
36482 features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
36483 We note that we do not consider this new work, and that is should be
36484 handled by the Library Working Group.
36485 </li>
36486 </ol>
36487 <p>
36488 In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
36489 </p>
36490 </blockquote>
36491
36492
36493
36494 <p><b>Proposed resolution:</b></p>
36495 <ol>
36496 <li>
36497 <p>In the class template definition of 23.3.1 [array]/p. 3 change</p>
36498 <blockquote><pre><ins>constexpr</ins> bool empty() const;
36499 </pre></blockquote>
36500 </li>
36501
36502 <li>
36503 <p>In the class template definition of 20.5 [template.bitset]/p. 1 change</p>
36504 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
36505 </pre></blockquote>
36506
36507 <p>
36508 and in 20.5.2 [bitset.members] change
36509 </p>
36510
36511 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
36512 </pre></blockquote>
36513
36514 </li>
36515 </ol>
36516
36517
36518
36519
36520
36521 <hr>
36522 <h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
36523 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36524  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2010-10-29</p>
36525 <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>
36526 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36527 <p><b>Discussion:</b></p>
36528 <p>
36529 In the listing of 26.8 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
36530 the following C99 functions (from 7.12.11.2):
36531 </p>
36532
36533 <blockquote><pre>float nanf(const char *tagp);
36534 long double nanl(const char *tagp);
36535 </pre></blockquote>
36536
36537 <p>
36538 (Note: These functions cannot be overloaded and they are also not
36539 listed anywhere else)
36540 </p>
36541
36542
36543 <p><b>Proposed resolution:</b></p>
36544 <p>
36545 In 26.8 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
36546 just after the existing entry <tt>nan</tt>.
36547 </p>
36548
36549
36550
36551
36552
36553 <hr>
36554 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
36555 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
36556  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-29 <b>Last modified:</b> 2010-10-29</p>
36557 <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>
36558 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36559 <p><b>Discussion:</b></p>
36560
36561 <p><b>Addresses UK 316</b></p>
36562
36563 <p>
36564 According to the current state of the standard draft, the class
36565 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
36566 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
36567 IMO it should be, because typical regex state machines tend
36568 to have a rather large data quantum and I have seen several
36569 use cases, where a factory function returns regex values,
36570 which would take advantage of moveabilities.
36571 </p>
36572
36573 <p><i>[
36574 Sophia Antipolis:
36575 ]</i></p>
36576
36577
36578 <blockquote>
36579 Needs wording for the semantics, the idea is agreed upon.
36580 </blockquote>
36581
36582 <p><i>[
36583 Post Summit Daniel updated wording to reflect new "swap rules".
36584 ]</i></p>
36585
36586
36587 <p><i>[
36588 2009-07 Frankfurt:
36589 ]</i></p>
36590
36591
36592 <blockquote>
36593 Move to Ready.
36594 </blockquote>
36595
36596
36597
36598 <p><b>Proposed resolution:</b></p>
36599 <p>
36600 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
36601 perform the following changes:
36602 </p>
36603
36604 <ol type="a">
36605 <li>
36606 <p>
36607 Just after <tt>basic_regex(const basic_regex&amp;);</tt> insert:
36608 </p>
36609
36610 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
36611 </pre></blockquote>
36612 </li>
36613 <li>
36614 <p>
36615 Just after <tt>basic_regex&amp; operator=(const basic_regex&amp;);</tt> insert:
36616 </p>
36617 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
36618 </pre></blockquote>
36619 </li>
36620 <li>
36621 <p>
36622 Just after <tt>basic_regex&amp; assign(const basic_regex&amp; that);</tt> insert:
36623 </p>
36624 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
36625 </pre></blockquote>
36626 </li>
36627 <li>
36628 <p>
36629 In 28.8.2 [re.regex.construct], just after p.11 add the following
36630 new member definition:
36631 </p>
36632 <blockquote><pre>basic_regex(basic_regex&amp;&amp; e);
36633 </pre>
36634 <blockquote>
36635 <p>
36636 <i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
36637 </p>
36638 <p>
36639 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
36640 <tt>e.mark_count()</tt>, respectively,
36641 that <tt>e</tt> had before construction, leaving
36642 <tt>e</tt> in a valid state with an unspecified value.
36643 </p>
36644 <p>
36645 <i>Throws:</i> nothing.
36646 </p>
36647 </blockquote>
36648 </blockquote>
36649 </li>
36650 <li>
36651 <p>
36652 Also in 28.8.2 [re.regex.construct], just after p.18 add the
36653 following new member definition:
36654 </p>
36655
36656 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp; e);
36657 </pre>
36658 <blockquote>
36659 <i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
36660 </blockquote>
36661 </blockquote>
36662 </li>
36663 <li>
36664 <p>
36665 In 28.8.3 [re.regex.assign], just after p. 2 add the following new
36666 member definition:
36667 </p>
36668 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; rhs);
36669 </pre>
36670 <blockquote>
36671 <p>
36672 <i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
36673 </p>
36674 <p>
36675 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
36676 and <tt>rhs.mark_count()</tt>, respectively, that
36677 <tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
36678 in a valid state with an unspecified value.
36679 </p>
36680 <p>
36681 <i>Throws:</i> nothing.
36682 </p>
36683 </blockquote>
36684 </blockquote>
36685 </li>
36686 </ol>
36687
36688
36689
36690
36691
36692 <hr>
36693 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
36694 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
36695  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12 <b>Last modified:</b> 2010-10-29</p>
36696 <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>
36697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36698 <p><b>Discussion:</b></p>
36699 <p>
36700 The <tt>DefaultConstructible</tt> requirement is referenced in
36701 several places in the August 2007 working draft
36702 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
36703 but is not defined anywhere.
36704 </p>
36705
36706 <p><i>[
36707 Bellevue:
36708 ]</i></p>
36709
36710
36711 <blockquote>
36712 <p>
36713 Walking into the default/value-initialization mess...
36714 </p>
36715 <p>
36716 Why two lines? Because we need both expressions to be valid.
36717 </p>
36718 <p>
36719 AJM not sure what the phrase "default constructed" means. This is
36720 unfortunate, as the phrase is already used 24 times in the library!
36721 </p>
36722 <p>
36723 Example: const int would not accept first line, but will accept the second.
36724 </p>
36725 <p>
36726 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
36727 </p>
36728 <p>
36729 It seems that the requirements are the syntax in the proposed first
36730 column is valid, but not clear what semantics we need.
36731 </p>
36732 <p>
36733 A table where there is no post-condition seems odd, but appears to sum up our position best.
36734 </p>
36735 <p>
36736 At a minimum an object is declared and is destuctible.
36737 </p>
36738 <p>
36739 Move to open, as no-one happy to produce wording on the fly.
36740 </p>
36741 </blockquote>
36742
36743 <p><i>[
36744 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
36745 ]</i></p>
36746
36747
36748 <p><i>[
36749 2009-08-17 Daniel adds "[defaultconstructible]" to table title.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>
36750 depends upon this issue.
36751 ]</i></p>
36752
36753
36754 <p><i>[
36755 2009-08-18 Alisdair adds:
36756 ]</i></p>
36757
36758
36759 <blockquote>
36760 <p>
36761 Looking at the proposed table in this issue, it really needs two rows:
36762 </p>
36763
36764 <blockquote>
36765 <table border="1">
36766 <caption>Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>
36767 <tbody><tr>
36768 <th>expression</th><th>post-condition</th>
36769 </tr>
36770
36771 <tr>
36772 <td><tt>T t;</tt></td><td><tt>t</tt> is default-initialized.</td>
36773 </tr>
36774
36775 <tr>
36776 <td><tt>T{}</tt></td><td>Object of type <tt>T</tt> is value-initialized.</td>
36777 </tr>
36778 </tbody></table>
36779 </blockquote>
36780
36781 <p>
36782 Note I am using the new brace-initialization syntax that is unambiguous
36783 in all use cases (no most vexing parse.)
36784 </p>
36785 </blockquote>
36786
36787 <p><i>[
36788 2009-10-03 Daniel adds:
36789 ]</i></p>
36790
36791
36792 <blockquote>
36793 <p>
36794 The suggested definition <tt>T{}</tt> describing it as
36795 value-initialization is wrong, because it belongs to list-initialization
36796 which would - as the current rules are - always prefer a
36797 initializer-list constructor over a default-constructor. I don't
36798 consider this as an appropriate definition of
36799 <tt>DefaultConstructible</tt>. My primary suggestion is to ask core,
36800 whether the special case <tt>T{}</tt> (which also easily leads to
36801 ambiguity situations for more than one initializer-list in a class)
36802 would always prefer a default-constructor - if any - before considering
36803 an initializer-list constructor or to provide another syntax form to
36804 prefer value-initialization over list-initialization. If that fails I
36805 would fall back to suggest to use the expression <tt>T()</tt> instead of
36806 <tt>T{}</tt> with all it's disadvantages for the meaning of the
36807 expression
36808 </p>
36809
36810 <blockquote><pre>T t();
36811 </pre></blockquote>
36812 </blockquote>
36813
36814 <p><i>[
36815 2009-10 Santa Cruz:
36816 ]</i></p>
36817
36818
36819 <blockquote>
36820 Leave Open. Core is looking to make Alisdair's proposed
36821 resolution correct.
36822 </blockquote>
36823
36824 <p><i>[
36825 2010-01-24 At Alisdiar's request, moved his proposal into the proposed wording
36826 seciton.  The old wording is preserved here:
36827 ]</i></p>
36828
36829
36830 <blockquote>
36831 <p>
36832 In section 20.2.1 [utility.arg.requirements], before table 33, add the
36833 following table:
36834 </p>
36835
36836 <p align="center" style="text-align:center">Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</p>
36837
36838 <div align="center">
36839
36840 <table border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
36841  <tbody><tr>
36842   <td width="114" valign="top" style="width:85.5pt;border-top:solid navy 1.0pt;
36843   border-left:solid navy 1.0pt;border-bottom:double navy 1.5pt;border-right:
36844   none;padding:0in 5.4pt 0in 5.4pt">
36845   <p align="center" style="margin:0in;margin-bottom:.0001pt;text-align:center">expression</p>
36846   </td>
36847   <td width="324" valign="top" style="width:243.0pt;border-top:solid navy 1.0pt;
36848   border-left:none;border-bottom:double navy 1.5pt;border-right:solid navy 1.0pt;
36849   padding:0in 5.4pt 0in 5.4pt">
36850   <p align="center" style="margin:0in;margin-bottom:.0001pt;text-align:center">post-condition</p>
36851   </td>
36852  </tr>
36853  <tr>
36854   <td width="114" valign="top" style="width:85.5pt;border-top:none;border-left:
36855   solid navy 1.0pt;border-bottom:solid navy 1.0pt;border-right:none;padding:
36856   0in 5.4pt 0in 5.4pt">
36857   <p style="margin:0in;margin-bottom:.0001pt"><tt>T
36858   t;</tt><br>
36859   <tt>T()</tt></p>
36860   </td>
36861   <td width="324" valign="top" style="width:243.0pt;border-top:none;border-left:
36862   none;border-bottom:solid navy 1.0pt;border-right:solid navy 1.0pt;padding:
36863   0in 5.4pt 0in 5.4pt">
36864   <p style="margin:0in;margin-bottom:.0001pt"><tt>T</tt>
36865   is <i>default constructed.</i></p>
36866   </td>
36867  </tr>
36868 </tbody></table>
36869
36870 </div>
36871
36872 </blockquote>
36873
36874 <p><i>[
36875 2010-02-04: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
36876 ]</i></p>
36877
36878
36879
36880
36881 <p><b>Rationale:</b></p>
36882 <p><i>[
36883 San Francisco:
36884 ]</i></p>
36885
36886 <blockquote>
36887 We believe concepts will solve this problem
36888 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
36889 </blockquote>
36890
36891 <p><i>[
36892 Rationale is obsolete.
36893 ]</i></p>
36894
36895
36896
36897 <p><b>Proposed resolution:</b></p>
36898 <p>
36899 In section 20.2.1 [utility.arg.requirements], before table 33, add the
36900 following table:
36901 </p>
36902
36903 <blockquote>
36904 <table border="1">
36905 <caption>Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>
36906 <tbody><tr>
36907 <th>expression</th><th>post-condition</th>
36908 </tr>
36909
36910 <tr>
36911 <td><tt>T t;</tt></td><td>Object <tt>t</tt> is default-initialized.</td>
36912 </tr>
36913
36914 <tr>
36915 <td><tt>T u{};</tt></td><td>Object <tt>u</tt> is value-initialized.</td>
36916 </tr>
36917
36918 <tr>
36919 <td><tt>T()<br>T{}</tt></td><td>A temporary object of type <tt>T</tt> is value-initialized.</td>
36920 </tr>
36921
36922 </tbody></table>
36923 </blockquote>
36924
36925
36926
36927
36928
36929
36930 <hr>
36931 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
36932 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
36933  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2010-10-29</p>
36934 <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>
36935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36936 <p><b>Discussion:</b></p>
36937 <p>
36938 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
36939 SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
36940 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
36941 allocators.
36942 </p>
36943
36944 <p>
36945 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
36946 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
36947 SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
36948 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
36949 existing code using TR1 and giving explicit template arguments to
36950 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
36951 arguments.
36952 </p>
36953
36954 <p><i>[
36955 Batavia (2009-05):
36956 ]</i></p>
36957
36958 <blockquote>
36959 <p>
36960 Bill comments, "We need to look at the depth of this change."
36961 </p>
36962 <p>
36963 Pete remarks that we are here dealing with a convenience function
36964 that saves a user from calling the iterato-based overload.
36965 </p>
36966 <p>
36967 Move to Open.
36968 </p>
36969 </blockquote>
36970
36971 <p><i>[
36972 2009-07 Frankfurt:
36973 ]</i></p>
36974
36975
36976 <blockquote>
36977 Howard to ask Stephan Lavavej to provide wording.
36978 </blockquote>
36979
36980 <p><i>[
36981 2009-07-17 Stephan provided wording.
36982 ]</i></p>
36983
36984
36985 <p><i>[
36986 2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>.
36987 ]</i></p>
36988
36989
36990 <blockquote>
36991 <p>
36992 One relevant part of the proposed resolution below suggests
36993 to add a new overload of the format member function in the
36994 <tt>match_results</tt> class template that accepts two character pointers
36995 defining the <tt>begin</tt> and <tt>end</tt> of a format range. A more general
36996 approach could have proposed a pair of iterators instead, but
36997 the used pair of char pointers reflects existing practice. If the
36998 committee strongly favors an iterator-based signature, this
36999 could be simply changed. I think that the minimum requirement
37000 should be a <tt>BidirectionalIterator</tt>, but current implementations
37001 take advantage (at least partially) of the <tt>RandomAccessIterator</tt>
37002 sub interface of the char pointers.
37003 </p>
37004
37005 <p><b>Suggested Resolution:</b></p>
37006
37007 <p><i>[Moved into the proposed resloution]</i></p>
37008
37009
37010
37011 </blockquote>
37012
37013 <p><i>[
37014 2009-07-30 Stephan agrees with Daniel's wording.  Howard places Daniel's wording
37015 in the Proposed Resolution.
37016 ]</i></p>
37017
37018
37019 <p><i>[
37020 2009-10 Santa Cruz:
37021 ]</i></p>
37022
37023
37024 <blockquote>
37025 Move to Review. Chair is anxious to move this to Ready in Pittsburgh.
37026 </blockquote>
37027
37028 <p><i>[
37029 2010-01-27 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
37030 ]</i></p>
37031
37032
37033
37034
37035 <p><b>Proposed resolution:</b></p>
37036
37037 <ol>
37038 <li>
37039 <p>
37040 Change 28.4 [re.syn] as indicated:
37041 </p>
37042
37043 <blockquote><pre>// 28.11.4, function template regex_replace:
37044 template &lt;class OutputIterator, class BidirectionalIterator,
37045           class traits, class charT<ins>, class ST, class SA</ins>&gt;
37046   OutputIterator
37047   regex_replace(OutputIterator out,
37048                 BidirectionalIterator first, BidirectionalIterator last,
37049                 const basic_regex&lt;charT, traits&gt;&amp; e,
37050                 const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
37051                 regex_constants::match_flag_type flags =
37052                   regex_constants::match_default);
37053
37054 <ins>
37055 template &lt;class OutputIterator, class BidirectionalIterator,
37056           class traits, class charT&gt;
37057   OutputIterator
37058   regex_replace(OutputIterator out,
37059                 BidirectionalIterator first, BidirectionalIterator last,
37060                 const basic_regex&lt;charT, traits&gt;&amp; e,
37061                 const charT* fmt,
37062                 regex_constants::match_flag_type flags =
37063                   regex_constants::match_default);
37064 </ins>
37065
37066 template &lt;class traits, class charT<ins>, class ST, class SA,
37067           class FST, class FSA</ins>&gt;
37068   basic_string&lt;charT<ins>, ST, SA</ins>&gt;
37069   regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
37070                 const basic_regex&lt;charT, traits&gt;&amp; e,
37071                 const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
37072                 regex_constants::match_flag_type flags =
37073                   regex_constants::match_default);
37074
37075 <ins>
37076 template &lt;class traits, class charT, class ST, class SA&gt;
37077   basic_string&lt;charT, ST, SA&gt;
37078   regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
37079                 const basic_regex&lt;charT, traits&gt;&amp; e,
37080                 const charT* fmt,
37081                 regex_constants::match_flag_type flags =
37082                   regex_constants::match_default);
37083 </ins>
37084
37085 <ins>
37086 template &lt;class traits, class charT, class ST, class SA&gt;
37087   basic_string&lt;charT&gt;
37088   regex_replace(const charT* s,
37089                 const basic_regex&lt;charT, traits&gt;&amp; e,
37090                 const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
37091                 regex_constants::match_flag_type flags =
37092                   regex_constants::match_default);
37093 </ins>
37094
37095 <ins>
37096 template &lt;class traits, class charT&gt;
37097   basic_string&lt;charT&gt;
37098   regex_replace(const charT* s,
37099                 const basic_regex&lt;charT, traits&gt;&amp; e,
37100                 const charT* fmt,
37101                 regex_constants::match_flag_type flags =
37102                   regex_constants::match_default);
37103 </ins>
37104 </pre></blockquote>
37105 </li>
37106
37107 <li>
37108 <p>
37109 Change 28.10 [re.results]/3, class template <tt>match_results</tt> as
37110 indicated:
37111 </p>
37112
37113 <blockquote><pre><ins>
37114 template &lt;class OutputIter&gt;
37115   OutputIter
37116   format(OutputIter out,
37117          const char_type* fmt_first, const char_type* fmt_last,
37118          regex_constants::match_flag_type flags =
37119            regex_constants::format_default) const;
37120 </ins>
37121
37122 template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
37123   OutputIter
37124   format(OutputIter out,
37125          const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
37126          regex_constants::match_flag_type flags =
37127            regex_constants::format_default) const;
37128
37129 <ins>template &lt;class ST, class SA&gt;</ins>
37130   <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
37131   format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
37132          regex_constants::match_flag_type flags =
37133            regex_constants::format_default) const;
37134
37135 <ins>
37136 string_type
37137 format(const char_type* fmt,
37138        regex_constants::match_flag_type flags =
37139          regex_constants::format_default) const;
37140 </ins>
37141 </pre></blockquote>
37142 </li>
37143
37144 <li>
37145 <p>
37146 Insert at the very beginning of 28.10.5 [re.results.form] the following:
37147 </p>
37148
37149 <blockquote><pre><ins>
37150 template &lt;class OutputIter&gt;
37151   OutputIter
37152   format(OutputIter out,
37153          const char_type* fmt_first, const char_type* fmt_last,
37154          regex_constants::match_flag_type flags =
37155            regex_constants::format_default) const;
37156 </ins>
37157 </pre>
37158 <blockquote>
37159
37160 <p><ins>
37161 1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for an
37162 Output Iterator (24.2.4 [output.iterators]).
37163 </ins></p>
37164
37165 <p><ins>
37166 2 <i>Effects:</i> Copies the character sequence <tt>[fmt_first,fmt_last)</tt> to
37167 <tt>OutputIter out</tt>. Replaces each format specifier or escape sequence in
37168 the copied range with either the character(s) it represents or the sequence of
37169 characters within <tt>*this</tt> to which it refers.  The bitmasks specified in
37170 <tt>flags</tt> determine which format specifiers and escape sequences are
37171 recognized.
37172 </ins></p>
37173
37174 <p><ins>
37175 3 <i>Returns:</i> <tt>out</tt>.
37176 </ins></p>
37177 </blockquote>
37178 </blockquote>
37179 </li>
37180
37181 <li>
37182 <p>
37183 Change 28.10.5 [re.results.form], before p. 1 until p. 3 as indicated:
37184 </p>
37185
37186 <blockquote><pre>template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
37187   OutputIter
37188   format(OutputIter out,
37189          const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
37190          regex_constants::match_flag_type flags =
37191            regex_constants::format_default) const;
37192 </pre>
37193
37194 <blockquote>
37195 <p>
37196 <del>1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for
37197 an Output Iterator (24.2.3).</del>
37198 </p>
37199
37200 <p>
37201 2 <i>Effects:</i> <del>Copies the character sequence
37202 <tt>[fmt.begin(),fmt.end())</tt> to <tt>OutputIter out</tt>. Replaces each
37203 format specifier or escape sequence in <tt>fmt</tt> with either the character(s)
37204 it represents or the sequence of characters within <tt>*this</tt> to which it
37205 refers. The bitmasks specified in <tt>flags</tt> determines what format
37206 specifiers and escape sequences are recognized</del> <ins>Equivalent to
37207 <tt>return format(out, fmt.data(), fmt.data() + fmt.size(), flags)</tt></ins>.
37208 </p>
37209
37210 <p>
37211 <del>3 <i>Returns:</i> <tt>out</tt>.</del>
37212 </p>
37213 </blockquote>
37214 </blockquote>
37215 </li>
37216
37217 <li>
37218 <p>
37219 Change 28.10.5 [re.results.form], before p. 4 until p. 4 as indicated:
37220 </p>
37221
37222 <blockquote><pre><ins>template &lt;class ST, class SA&gt;</ins>
37223   <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
37224   format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
37225          regex_constants::match_flag_type flags =
37226            regex_constants::format_default) const;
37227 </pre>
37228
37229 <blockquote>
37230 <p>
37231 <i>Effects:</i> <del>Returns a copy of the string <tt>fmt</tt>. Replaces each format
37232 specifier or escape sequence
37233 in <tt>fmt</tt> with either the character(s) it represents or the sequence of
37234 characters within <tt>*this</tt> to which
37235 it refers. The bitmasks specified in flags determines what format
37236 specifiers and escape sequences are
37237 recognized.</del> <ins>Constructs an empty string <tt>result</tt> of type
37238 <tt>basic_string&lt;char_type, ST, SA&gt;</tt>,
37239 and calls <tt>format(back_inserter(result), fmt, flags)</tt>.</ins>
37240 </p>
37241
37242 <p>
37243 <ins><i>Returns:</i> <tt>result</tt></ins>
37244 </p>
37245 </blockquote>
37246 </blockquote>
37247 </li>
37248
37249 <li>
37250 <p>
37251 At the end of 28.10.5 [re.results.form] insert as indicated:
37252 </p>
37253
37254 <blockquote><pre><ins>
37255 string_type
37256   format(const char_type* fmt,
37257          regex_constants::match_flag_type flags =
37258            regex_constants::format_default) const;
37259 </ins></pre>
37260
37261 <blockquote>
37262 <p>
37263 <ins><i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>string_type</tt>, and calls
37264 <tt>format(back_inserter(result), fmt, fmt +
37265 char_traits&lt;char_type&gt;::length(fmt), flags)</tt>.</ins>
37266 </p>
37267 <p>
37268 <ins><i>Returns:</i> <tt>result</tt></ins>
37269 </p>
37270 </blockquote>
37271 </blockquote>
37272
37273 </li>
37274
37275 <li>
37276 <p>
37277 Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
37278 </p>
37279
37280 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
37281           class traits, class charT<ins>, class ST, class SA</ins>&gt;
37282   OutputIterator
37283   regex_replace(OutputIterator out,
37284                 BidirectionalIterator first, BidirectionalIterator last,
37285                 const basic_regex&lt;charT, traits&gt;&amp; e,
37286                 const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
37287                 regex_constants::match_flag_type flags =
37288                   regex_constants::match_default);
37289
37290 <ins>
37291 template &lt;class OutputIterator, class BidirectionalIterator,
37292           class traits, class charT&gt;
37293   OutputIterator
37294   regex_replace(OutputIterator out,
37295                 BidirectionalIterator first, BidirectionalIterator last,
37296                 const basic_regex&lt;charT, traits&gt;&amp; e,
37297                 const charT* fmt,
37298                 regex_constants::match_flag_type flags =
37299                   regex_constants::match_default);
37300 </ins></pre>
37301
37302 <blockquote>
37303 <i>Effects:</i> [..]. If any matches are found then, for each such match, if <tt>!(flags &amp;
37304  regex_constants::format_no_copy)</tt> calls <tt>std::copy(m.prefix().first,
37305 m.prefix().second,
37306  out)</tt>, and then calls <tt>m.format(out, fmt, flags)</tt> <ins>for the first
37307 form of the function
37308  and <tt>m.format(out, fmt, fmt + char_traits&lt;charT&gt;::length(fmt), flags)</tt>
37309 for the second
37310  form</ins>. [..].
37311 </blockquote>
37312 </blockquote>
37313 </li>
37314
37315 <li>
37316 <p>
37317 Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
37318 </p>
37319
37320 <blockquote><pre>template &lt;class traits, class charT<ins>, class ST, class SA,
37321           class FST, class FSA</ins>&gt;
37322   basic_string&lt;charT<ins>, ST, SA</ins>&gt;
37323   regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
37324                 const basic_regex&lt;charT, traits&gt;&amp; e,
37325                 const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
37326                 regex_constants::match_flag_type flags =
37327                   regex_constants::match_default);
37328
37329 <ins>
37330 template &lt;class traits, class charT, class ST, class SA&gt;
37331   basic_string&lt;charT, ST, SA&gt;
37332   regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
37333                 const basic_regex&lt;charT, traits&gt;&amp; e,
37334                 const charT* fmt,
37335                 regex_constants::match_flag_type flags =
37336                   regex_constants::match_default);
37337 </ins></pre>
37338
37339 <blockquote>
37340 <i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT<ins>,
37341 ST, SA</ins>&gt;</tt>, calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(),
37342 e, fmt, flags)</tt>, and then returns <tt>result</tt>.
37343 </blockquote>
37344 </blockquote>
37345 </li>
37346
37347 <li>
37348 <p>
37349 At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
37350 </p>
37351
37352 <blockquote><pre><ins>
37353 template &lt;class traits, class charT, class ST, class SA&gt;
37354   basic_string&lt;charT&gt;
37355   regex_replace(const charT* s,
37356                 const basic_regex&lt;charT, traits&gt;&amp; e,
37357                 const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
37358                 regex_constants::match_flag_type flags =
37359                   regex_constants::match_default);
37360 </ins>
37361
37362 <ins>
37363 template &lt;class traits, class charT&gt;
37364   basic_string&lt;charT&gt;
37365   regex_replace(const charT* s,
37366                 const basic_regex&lt;charT, traits&gt;&amp; e,
37367                 const charT* fmt,
37368                 regex_constants::match_flag_type flags =
37369                   regex_constants::match_default);
37370 </ins></pre>
37371
37372 <blockquote>
37373 <ins>
37374 <i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT&gt;</tt>,
37375 calls <tt>regex_replace(back_inserter(result), s, s +
37376 char_traits&lt;charT&gt;::length(s),
37377 e, fmt, flags)</tt>, and then returns <tt>result</tt>.
37378 </ins>
37379 </blockquote>
37380 </blockquote>
37381 </li>
37382
37383 </ol>
37384
37385
37386
37387
37388
37389
37390
37391 <hr>
37392 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
37393 <p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37394  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
37395 <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>
37396 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37397 <p><b>Discussion:</b></p>
37398 <p>
37399 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
37400 as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
37401 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
37402 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
37403 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
37404 Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
37405 [<a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
37406 </p>
37407
37408 <p>
37409 I see two possible resolutions: 
37410 </p>
37411
37412 <ol type="a">
37413 <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the 
37414 multiplier from [the above reference] for the 64-bit case (my preference)</li>
37415 <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte 
37416 order) and always employ the 32-bit algorithm for seeding
37417 </li>
37418 </ol>
37419
37420 <p>
37421 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
37422 for further discussion.
37423 </p>
37424
37425 <p><i>[
37426 Bellevue:
37427 ]</i></p>
37428
37429
37430 <blockquote>
37431 <p>
37432 Stephan Tolksdorf has additional comments on N2424. He comments: "there
37433 is a typo in the required behaviour for mt19937_64: It should be the
37434 10000th (not 100000th) invocation whose value is given, and the value
37435 should be 9981545732273789042 (not 14002232017267485025)." These values
37436 need checking.
37437 </p>
37438 <p>
37439 Take the proposed recommendation in N2424 and move to REVIEW.
37440 </p>
37441 </blockquote>
37442
37443
37444
37445
37446 <p><b>Proposed resolution:</b></p>
37447
37448 <p>
37449 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
37450 for the proposed resolution.
37451 </p>
37452
37453 <p><i>[
37454 Stephan Tolksdorf adds pre-Bellevue:
37455 ]</i></p>
37456
37457
37458 <blockquote>
37459 I support the proposed resolution in
37460 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
37461 but there is a typo in the
37462 required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
37463 100000<sup>th</sup>) invocation whose value is given, and the value should be
37464 9981545732273789042 (not 14002232017267485025). The change to para. 8
37465 proposed by Charles Karney should also be included in the proposed
37466 wording.
37467 </blockquote>
37468
37469 <p><i>[
37470 Sophia Antipolis:
37471 ]</i></p>
37472
37473
37474 <blockquote>
37475 Note the main part of the issue is resolved by
37476 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
37477 </blockquote>
37478
37479
37480
37481
37482
37483
37484 <hr>
37485 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
37486 <p><b>Section:</b> 26.5.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37487  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
37488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37489 <p><b>Discussion:</b></p>
37490 <p>
37491 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
37492 have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the 
37493 following two reasons this is an unnecessary restriction: First, in many applications such as 
37494 Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
37495 eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
37496 O(1) algorithms) 
37497 for simulating from these distributions work with floating-point parameters anyway (all three 
37498 distributions could be easily implemented using the Gamma distribution, for instance).
37499 </p>
37500
37501 <p>
37502 Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete 
37503 <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
37504 parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
37505 the implementation would be significantly complicated by a non-discrete parameter (in most 
37506 implementations one would need an approximation of the log-gamma function instead of just the 
37507 log-factorial function).
37508 </p>
37509
37510 <p>
37511 <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters 
37512 to double.
37513 </p>
37514
37515 <p><i>[
37516 Bellevue:
37517 ]</i></p>
37518
37519
37520 <blockquote>
37521 In N2424. Not wildly enthusiastic, not really felt necessary. Less
37522 frequently used in practice. Not terribly bad either. Move to OPEN.
37523 </blockquote>
37524
37525 <p><i>[
37526 Sophia Antipolis:
37527 ]</i></p>
37528
37529
37530 <blockquote>
37531 <p>
37532 Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
37533 </p>
37534 <p>
37535 Marc Paterno: Ask implementers whether floating-point is a significant burden.
37536 </p>
37537 <p>
37538 Alisdair: It's neater to do it now, do ask Bill Plauger.
37539 </p>
37540 <p>
37541 Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
37542 </p>
37543 </blockquote>
37544
37545
37546
37547 <p><b>Proposed resolution:</b></p>
37548 <p>
37549 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
37550 for the proposed resolution.
37551 </p>
37552
37553 <p><i>[
37554 Stephan Tolksdorf adds pre-Bellevue:
37555 ]</i></p>
37556
37557
37558 <blockquote>
37559 <p>
37560 In 26.5.8.4.3 [rand.dist.norm.chisq]:
37561 </p>
37562
37563 <blockquote>
37564 <p>
37565 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
37566 </p>
37567
37568 <p>
37569 Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
37570 with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
37571 </p>
37572
37573 <p>
37574 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
37575 </p>
37576
37577 </blockquote>
37578
37579 <p>
37580 In 26.5.8.4.5 [rand.dist.norm.f]:
37581 </p>
37582 <blockquote>
37583 <p>
37584 Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
37585 </p>
37586
37587 <p>
37588 Replace both occurrences of
37589 </p>
37590 <blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
37591 </pre></blockquote>
37592 <p>
37593 with
37594 </p>
37595 <blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
37596 </pre></blockquote>
37597
37598 <p>
37599 Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
37600 </p>
37601
37602 <p>
37603 Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
37604 </p>
37605 </blockquote>
37606
37607 <p>
37608 In 26.5.8.4.6 [rand.dist.norm.t]:
37609 </p>
37610
37611 <blockquote>
37612 <p>
37613 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
37614 </p>
37615
37616 <p>
37617 Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
37618 with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
37619 </p>
37620
37621 <p>
37622 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
37623 </p>
37624 </blockquote>
37625
37626 </blockquote>
37627
37628
37629
37630
37631
37632 <hr>
37633 <h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
37634 <p><b>Section:</b> X [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37635  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-10-04 <b>Last modified:</b> 2010-10-29</p>
37636 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37637 <p><b>Discussion:</b></p>
37638 <p>
37639 Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
37640 bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
37641 <tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
37642 immediately falters on <tt>op--</tt> which can't reliably dereference because we
37643 don't know the lower bound). Also, most buffers you'd want to point to
37644 don't have a compile-time known size.
37645 </p>
37646
37647 <p>
37648 To enable any bounds-checking would require run-time information, with
37649 the usual triplet: base (lower bound), current offset, and max offset
37650 (upper  bound). And I can sympathize with the point of view that you
37651 wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
37652 follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
37653 query the bounds etc., because this sets wrong user expectations by
37654 embarking on a path that doesn't go all the way to bounds checking as it
37655 seems to imply.
37656 </p>
37657
37658 <p>
37659 If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
37660 <tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
37661 user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
37662 debug builds and not doing so on release builds (for example).
37663 </p>
37664
37665 <p>
37666 Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
37667 pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
37668 don't agree, but if that were true that would be another reason to
37669 remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
37670 <tt>std::array.</tt> :-)
37671 </p>
37672
37673 <p><i>[
37674 Bellevue:
37675 ]</i></p>
37676
37677
37678 <blockquote>
37679 <p>
37680 Suggestion that fixed-size array instantiations are going to fail at compile time anyway (if we remove specialization) due to pointer decay, at least that appears to be result from available compilers.
37681 </p>
37682 <p>
37683 So concerns about about requiring static_assert seem unfounded.
37684 </p>
37685 <p>
37686 After a little more experimentation with compiler, it appears that fixed size arrays would only work at all if we supply these explicit specialization. So removing them appears less breaking than originally thought.
37687 </p>
37688 <p>
37689 straw poll unanimous move to Ready.
37690 </p>
37691 </blockquote>
37692
37693
37694
37695 <p><b>Proposed resolution:</b></p>
37696 <p>
37697 Change the synopsis under 20.9.9 [unique.ptr] p2:
37698 </p>
37699
37700 <blockquote><pre>...
37701 template&lt;class T&gt; struct default_delete; 
37702 template&lt;class T&gt; struct default_delete&lt;T[]&gt;; 
37703 <del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
37704
37705 template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr; 
37706 template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;; 
37707 <del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
37708 ...
37709 </pre></blockquote>
37710
37711 <p>
37712 Remove the entire section  [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
37713 </p>
37714
37715 <p>
37716 Remove the entire section X [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
37717 and its subsections:  [unique.ptr.compiletime.dtor],  [unique.ptr.compiletime.observers],
37718  [unique.ptr.compiletime.modifiers].
37719 </p>
37720
37721
37722
37723
37724
37725
37726 <hr>
37727 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
37728 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
37729  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-11-20</p>
37730 <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>
37731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
37732 <p><b>Discussion:</b></p>
37733 <p>
37734 This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
37735 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
37736 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
37737 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
37738 </p>
37739
37740 <p>
37741 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
37742 is example code:
37743 </p>
37744
37745 <blockquote><pre>namespace Mine {
37746
37747 template &lt;class T&gt;
37748 struct proxy {...};
37749
37750 template &lt;class T&gt;
37751 struct proxied_iterator
37752 {
37753    typedef T value_type;
37754    typedef proxy&lt;T&gt; reference;
37755    reference operator*() const;
37756    ...
37757 };
37758
37759 struct A
37760 {
37761    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
37762    void swap(A&amp;);
37763    ...
37764 };
37765
37766 void swap(A&amp;, A&amp;);
37767 void swap(proxy&lt;A&gt;, A&amp;);
37768 void swap(A&amp;, proxy&lt;A&gt;);
37769 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
37770
37771 }  // Mine
37772
37773 ...
37774
37775 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
37776 Mine::A a;
37777 <b>swap(*i1, a);</b>
37778 </pre></blockquote>
37779
37780 <p>
37781 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
37782 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
37783 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
37784 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
37785 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
37786 to take rvalues.
37787 </p>
37788
37789 <p>
37790 That is, no standard library code needs to change.  We simply need to have a more flexible
37791 definition of <tt>Swappable</tt>.
37792 </p>
37793
37794 <p><i>[
37795 Bellevue:
37796 ]</i></p>
37797
37798
37799 <blockquote>
37800 <p>
37801 While we believe Concepts work will define a swappable concept, we
37802 should still resolve this issue if possible to give guidance to the
37803 Concepts work.
37804 </p>
37805 <p>
37806 Would an ambiguous swap function in two namespaces found by ADL break
37807 this wording? Suggest that the phrase "valid expression" means such a
37808 pair of types would still not be swappable.
37809 </p>
37810 <p>
37811 Motivation is proxy-iterators, but facility is considerably more
37812 general. Are we happy going so far?
37813 </p>
37814 <p>
37815 We think this wording is probably correct and probably an improvement on
37816 what's there in the WP. On the other hand, what's already there in the
37817 WP is awfully complicated. Why do we need the two bullet points? They're
37818 too implementation-centric. They don't add anything to the semantics of
37819 what swap() means, which is there in the post-condition. What's wrong
37820 with saying that types are swappable if you can call swap() and it
37821 satisfies the semantics of swapping?
37822 </p>
37823 </blockquote>
37824
37825 <p><i>[
37826 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
37827 ]</i></p>
37828
37829
37830 <p><i>[
37831 2009-10 Santa Cruz:
37832 ]</i></p>
37833
37834
37835 <blockquote>
37836 Leave as Open. Dave to provide wording.
37837 </blockquote>
37838
37839 <p><i>[
37840 2009-11-08 Howard adds:
37841 ]</i></p>
37842
37843
37844 <blockquote>
37845 Updated wording to sync with
37846 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>.
37847 Also this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.
37848 </blockquote>
37849
37850 <p><i>[
37851 2010 Pittsburgh:
37852 ]</i></p>
37853
37854
37855 <blockquote>
37856 Moved to <del>NAD Editorial</del><ins>Resolved</ins>.  Rationale added.
37857 </blockquote>
37858
37859
37860
37861 <p><b>Rationale:</b></p>
37862 <p>
37863 Solved by N3048.
37864 </p>
37865
37866
37867 <p><b>Proposed resolution:</b></p>
37868 <p>
37869 Change 20.2.1 [utility.arg.requirements]:
37870 </p>
37871
37872 <blockquote>
37873
37874 <p>
37875 -1- The template definitions in the C++ Standard Library refer to various
37876 named requirements whose details are set out in tables 31-38. In these
37877 tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
37878 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
37879 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
37880 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
37881 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
37882 rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
37883 </p>
37884
37885 <table border="1">
37886 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
37887 <tbody><tr><th>expression</th><th>Return type</th><th>Post-condition</th></tr>
37888 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
37889 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
37890 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
37891 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
37892 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
37893 <tr><td colspan="3">
37894 <p>
37895 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
37896 </p>
37897 <ul>
37898 <li>
37899 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
37900 the same type and </ins> <tt>T</tt> satisfies the
37901 <tt>MoveConstructible</tt> requirements (Table 
37902 33) and the 
37903 <tt>MoveAssignable</tt> requirements (Table 
37904 35);
37905 </li>
37906 <li>
37907 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
37908 <tt>swap</tt> exists in the same namespace as the definition of
37909 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
37910 <tt>swap(<del>s</del><ins>w</ins>,<del>t</del> <ins>v</ins>)</tt> is valid and has the
37911 semantics described in this table.
37912 </li>
37913 <li>
37914 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose
37915 element type is <tt>Swappable</tt>.
37916 </li>
37917 </ul>
37918 </td></tr>
37919 </tbody></table>
37920 </blockquote>
37921
37922
37923
37924 <p><b>Rationale:</b></p>
37925 <p><i>[
37926 post San Francisco:
37927 ]</i></p>
37928
37929
37930 <blockquote>
37931 Solved by
37932 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
37933 </blockquote>
37934
37935
37936
37937
37938
37939
37940 <hr>
37941 <h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
37942 <p><b>Section:</b> 20.9.10.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37943  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
37944 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37945 <p><b>Discussion:</b></p>
37946 <p>
37947 When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
37948 </p>
37949
37950 <blockquote><p>
37951 We may need to open an issue to deal with the question of
37952 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
37953 </p></blockquote>
37954
37955 <p>
37956 This issue was opened in response to that note.
37957 </p>
37958
37959 <p>
37960 I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
37961 appropriate, and consistent with how other library components are currently specified.
37962 </p>
37963
37964 <p><i>[
37965 Bellevue:
37966 ]</i></p>
37967
37968
37969 <blockquote>
37970 <p>
37971 Concern that the three signatures for swap is needlessly complicated,
37972 but this issue merely brings shared_ptr into equal complexity with the
37973 rest of the library. Will open a new issue for concern about triplicate
37974 signatures.
37975 </p>
37976 <p>
37977 Adopt issue as written.
37978 </p>
37979 </blockquote>
37980
37981
37982 <p><b>Proposed resolution:</b></p>
37983 <p>
37984 Change the synopsis in 20.9.10.2 [util.smartptr.shared]:
37985 </p>
37986
37987 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
37988 ...
37989 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
37990 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
37991 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
37992 </pre></blockquote>
37993
37994 <p>
37995 Change 20.9.10.2.4 [util.smartptr.shared.mod]:
37996 </p>
37997
37998 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
37999 </pre></blockquote>
38000
38001 <p>
38002 Change 20.9.10.2.9 [util.smartptr.shared.spec]:
38003 </p>
38004
38005 <blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
38006 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
38007 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
38008 </pre></blockquote>
38009
38010
38011
38012
38013
38014 <hr>
38015 <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
38016 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38017  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
38018 <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>
38019 <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>
38020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38021 <p><b>Discussion:</b></p>
38022 <p>
38023 Without some lifetime guarantee, it is hard to know how this type can be
38024 used.  Very specifically, I don't see how the current wording would
38025 guarantee and exception_ptr caught at the end of one thread could be safely
38026 stored and rethrown in another thread - the original motivation for this
38027 API.
38028 </p>
38029 <p>
38030 (Peter Dimov agreed it should be clearer, maybe a non-normative note to
38031 explain?)
38032 </p>
38033
38034 <p><i>[
38035 Bellevue:
38036 ]</i></p>
38037
38038
38039 <blockquote>
38040 <p>
38041 Agree the issue is real.
38042 </p>
38043 <p>
38044 Intent is lifetime is similar to a shared_ptr (and we might even want to
38045 consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
38046 </p>
38047 <p>
38048 We expect that most implementations will use shared_ptr, and the
38049 standard should be clear that the exception_ptr type is intended to be
38050 something whose semantics are smart-pointer-like so that the user does
38051 not need to worry about lifetime management. We still need someone to
38052 draught those words - suggest emailing Peter Dimov.
38053 </p>
38054 <p>
38055 Move to Open.
38056 </p>
38057 </blockquote>
38058
38059
38060 <p><b>Proposed resolution:</b></p>
38061 <p>
38062 Change 18.8.5 [propagation]/7:
38063 </p>
38064
38065 <blockquote>
38066 -7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
38067 handled exception or a copy of the currently handled exception, or a
38068 null <tt>exception_ptr</tt> object if no exception is being handled.
38069 <ins>The referenced object remains valid at least as long as there is an
38070 <tt>exception_ptr</tt> that refers to it.</ins>
38071 If the function needs to allocate memory and the attempt
38072 fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
38073 <tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
38074 calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
38075 that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
38076 each time it is called. <i>--end note</i>]
38077 </blockquote>
38078
38079
38080
38081
38082
38083 <hr>
38084 <h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
38085 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38086  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
38087 <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>
38088 <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>
38089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38090 <p><b>Discussion:</b></p>
38091 <p>
38092 I understand that the attempt to copy an exception may run out of memory,
38093 but I believe this is the only part of the standard that mandates failure
38094 with specifically <tt>bad_alloc</tt>, as opposed to allowing an
38095 implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
38096 language for a failed new expression is:
38097 </p>
38098 <blockquote>
38099 <p>
38100 Any other allocation function that fails to allocate storage shall indicate
38101 failure only by throwing an exception of a type that would match a handler
38102 (15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
38103 </p>
38104 </blockquote>
38105 <p>
38106 I think we should allow similar freedom here (or add a blanket
38107 compatible-exception freedom paragraph in 17)
38108 </p>
38109 <p>
38110 I prefer the clause 17 approach myself, and maybe clean up any outstanding
38111 wording that could also rely on it.
38112 </p>
38113 <p>
38114 Although filed against a specific case, this issue is a problem throughout
38115 the library. 
38116 </p>
38117
38118 <p><i>[
38119 Bellevue:
38120 ]</i></p>
38121
38122
38123 <blockquote>
38124 <p>
38125 Is issue bigger than library?
38126 </p>
38127 <p>
38128 No - Core are already very clear about their wording, which is inspiration for the issue.
38129 </p>
38130 <p>
38131 While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
38132 </p>
38133 <p>
38134 Accept the broad view and move to ready
38135 </p>
38136 </blockquote>
38137
38138
38139 <p><b>Proposed resolution:</b></p>
38140 <p>
38141 Add the following exemption clause to 17.6.4.12 [res.on.exception.handling]:
38142 </p>
38143
38144 <blockquote>
38145 A function may throw a type not listed in its <i>Throws</i> clause so long as it is
38146 derived from a class named in the <i>Throws</i> clause, and would be caught by an
38147 exception handler for the base type.
38148 </blockquote>
38149
38150
38151
38152
38153
38154 <hr>
38155 <h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
38156 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38157  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
38158 <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>
38159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38160 <p><b>Discussion:</b></p>
38161 <p>
38162 Unfortunately a class can have multiple copy constructors, and I believe to
38163 be useful this trait should only return true is ALL copy constructors are
38164 no-throw.
38165 </p>
38166 <p>
38167 For instance:
38168 </p>
38169 <blockquote>
38170 <pre>struct awkward {
38171  awkward( const awkward &amp; ) throw() {}
38172  awkward( awkward &amp; ) { throw "oops"; } };
38173 </pre>
38174 </blockquote>
38175
38176
38177 <p><b>Proposed resolution:</b></p>
38178 <p>
38179 Change 20.7.4.3 [meta.unary.prop]:
38180 </p>
38181
38182 <blockquote>
38183 <pre>has_trivial_copy_constructor</pre>
38184 <blockquote>
38185 <tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
38186 <ins>where all copy constructors are trivial</ins> (12.8).
38187 </blockquote>
38188 </blockquote>
38189
38190 <blockquote>
38191 <pre>has_trivial_assign</pre>
38192 <blockquote>
38193 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
38194 or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
38195 </blockquote>
38196 </blockquote>
38197
38198 <blockquote>
38199 <pre>has_nothrow_copy_constructor</pre>
38200 <blockquote>
38201 <tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
38202 a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> 
38203 known not to throw any exceptions or <tt>T</tt> is an
38204 array of such a class type
38205 </blockquote>
38206 </blockquote>
38207
38208 <blockquote>
38209 <pre>has_nothrow_assign</pre>
38210 <blockquote>
38211 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and
38212 <tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
38213 <ins>where all</ins> copy
38214 assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
38215 throw any exceptions or <tt>T</tt> is an array of such a class type.
38216 </blockquote>
38217 </blockquote>
38218
38219
38220
38221
38222
38223
38224 <hr>
38225 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
38226 <p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
38227  <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2007-10-11 <b>Last modified:</b> 2010-10-29</p>
38228 <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>
38229 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
38230 <p><b>Discussion:</b></p>
38231 <p>
38232 Did LWG recently discuss 20.2.5 [allocator.requirements]-2, which states that "All the operations
38233 on the allocators are expected to be amortized constant time."?
38234 </p>
38235 <p>
38236 As I think I pointed out earlier, this is currently fiction for
38237 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
38238 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
38239 large objects.  Would it be controversial to officially let these take
38240 time linear in the size of the object, as they already do in real life?
38241 </p>
38242 <p>
38243 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
38244 object if you mix in GC.  But it's not really a new problem, and I think
38245 we'd be confusing things by leaving the bogus requirements there.  The
38246 current requirement on <tt>allocate()</tt> is generally not important anyway,
38247 since it takes O(size) to construct objects in the resulting space.
38248 There are real performance issues here, but they're all concerned with
38249 the constants, not the asymptotic complexity.
38250 </p>
38251
38252
38253 <p><b>Proposed resolution:</b></p>
38254 <p>
38255 Change 20.2.5 [allocator.requirements]/2:
38256 </p>
38257
38258 <blockquote>
38259 <p>
38260 -2- Table 39 describes the requirements on types manipulated through
38261 allocators. <del>All the operations on the allocators are expected to be
38262 amortized constant time.</del> Table 40 describes the
38263 requirements on allocator types.
38264 </p>
38265 </blockquote>
38266
38267
38268
38269
38270
38271 <hr>
38272 <h3><a name="753"></a>753. Move constructor in draft</h3>
38273 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
38274  <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2007-10-14 <b>Last modified:</b> 2010-10-29</p>
38275 <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>
38276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
38277 <p><b>Discussion:</b></p>
38278 <p>
38279 The draft standard n2369 uses the term <i>move constructor</i> in a few
38280 places, but doesn't seem to define it.
38281 </p>
38282
38283 <p>
38284 <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.2.1 [utility.arg.requirements] as
38285 follows:
38286 </p>
38287
38288 <blockquote>
38289 <table border="1">
38290 <caption><tt>MoveConstructible</tt> requirements</caption>
38291 <tbody><tr>
38292 <th>expression</th> <th>post-condition</th>
38293 </tr>
38294 <tr>
38295 <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
38296 </tr>
38297 <tr>
38298 <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the 
38299 construction. <i>-- end note</i>]</td>
38300 </tr>
38301 </tbody></table>
38302 </blockquote>
38303
38304 <p>
38305 (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
38306 </p>
38307
38308 <p>
38309 So I assume the move constructor is the constructor that would be used
38310 in filling the above requirement.
38311 </p>
38312
38313 <p>
38314 For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
38315 23.4.1.4 [vector.modifiers] we have
38316 </p>
38317
38318 <blockquote>
38319 <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
38320 not throw any exceptions.
38321 </blockquote>
38322
38323 <p>
38324 Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
38325 type which can be put into a <tt>vector</tt> has a move constructor (a copy
38326 constructor is also a move constructor). Secondly it means that for
38327 any <tt>value_type</tt> which has a throwing copy constructor and no other move
38328 constructor these functions cannot be used -- which I think will come
38329 as a shock to people who have been using such types in <tt>vector</tt> until
38330 now!
38331 </p>
38332
38333 <p>
38334 I can see two ways to correct this. The simpler, which is presumably
38335 what was intended, is to say "If <tt>value_type</tt> has a move constructor and
38336 no copy constructor, the move constructor shall not throw any
38337 exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
38338 value of its parameter,".
38339 </p>
38340
38341 <p>
38342 The other alternative is add to <tt>MoveConstructible</tt> the requirement that
38343 the expression does not throw. This would mean that not every type
38344 that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
38345 <tt>MoveConstructible</tt> requirements. It would mean changing requirements in
38346 various places in the draft to allow either <tt>MoveConstructible</tt> or
38347 <tt>CopyConstructible</tt>, but I think the result would be clearer and
38348 possibly more concise too.
38349 </p>
38350
38351
38352 <p><b>Proposed resolution:</b></p>
38353 <p>
38354 Add new defintions to 17.3 [definitions]:
38355 </p>
38356
38357 <blockquote>
38358 <p>
38359 <b>move constructor</b>
38360 </p>
38361 <p>
38362 a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
38363 side effect during the construction.
38364 </p>
38365 <p>
38366 <b>move assignment operator</b>
38367 </p>
38368 <p>
38369 an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
38370 side effect during the assignment.
38371 </p>
38372 <p>
38373 <b>move assignment</b>
38374 </p>
38375 <p>
38376 use of the move assignment operator.
38377 </p>
38378 </blockquote>
38379
38380 <p><i>[
38381 Howard adds post-Bellevue:
38382 ]</i></p>
38383
38384
38385 <blockquote>
38386 <p>
38387 Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
38388 if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
38389 used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
38390 is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
38391 unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
38392 </p>
38393 </blockquote>
38394
38395
38396
38397
38398
38399
38400 <hr>
38401 <h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
38402 <p><b>Section:</b> 23.4.1.2 [vector.capacity], 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38403  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2010-10-29</p>
38404 <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>
38405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38406 <p><b>Discussion:</b></p>
38407 <p>
38408 A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
38409 </p>
38410
38411 <blockquote><pre>vector&lt;int&gt; v;
38412 ...
38413 v.swap(vector&lt;int&gt;(v));  // shrink to fit
38414 </pre>
38415 <blockquote><p>
38416 or:
38417 </p></blockquote>
38418 <pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
38419 </pre>
38420 <blockquote><p>
38421 or:
38422 </p></blockquote>
38423 <pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
38424 </pre>
38425 </blockquote>
38426
38427 <p>
38428 A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
38429 </p>
38430
38431 <blockquote><pre>string s;
38432 ...
38433 s.reserve(0);
38434 </pre></blockquote>
38435
38436 <p>
38437 Neither of these is at all obvious to beginners, and even some
38438 experienced C++ programmers are not aware that shrink-to-fit is
38439 trivially available.
38440 </p>
38441 <p>
38442 Lack of explicit functions to perform these commonly requested
38443 operations makes vector and string less usable for non-experts. Because
38444 the idioms are somewhat obscure, code readability is impaired. It is
38445 also unfortunate that two similar vector-like containers use different
38446 syntax for the same operation.
38447 </p>
38448 <p>
38449 The proposed resolution addresses these concerns. The proposed function
38450 takes no arguments to keep the solution simple and focused.
38451 </p>
38452
38453
38454 <p><b>Proposed resolution:</b></p>
38455 <p>
38456 To Class template basic_string 21.4 [basic.string] synopsis,
38457 Class template vector 23.4.1 [vector] synopsis, and Class
38458 vector&lt;bool&gt; 23.4.2 [vector.bool] synopsis, add:
38459 </p>
38460
38461 <blockquote><pre>    
38462 void shrink_to_fit();
38463 </pre></blockquote>
38464
38465 <p>
38466 To basic_string capacity 21.4.4 [string.capacity] and vector
38467 capacity 23.4.1.2 [vector.capacity], add:
38468 </p>
38469
38470 <blockquote>
38471 <pre>void shrink_to_fit();
38472 </pre>
38473 <blockquote>
38474 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
38475 <tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
38476 allow latitude for implementation-specific optimizations.
38477 <i>-- end note</i>]
38478 </blockquote>
38479 </blockquote>
38480
38481 <p><i>[
38482 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
38483 ]</i></p>
38484
38485
38486
38487
38488
38489
38490 <hr>
38491 <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
38492 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
38493  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2010-10-29</p>
38494 <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>
38495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
38496 <p><b>Discussion:</b></p>
38497 <p>
38498 Consider the following program:
38499 </p>
38500
38501 <blockquote><pre>int main() {
38502    shared_ptr&lt;int&gt; p(nullptr); 
38503    return 0;
38504 }
38505 </pre></blockquote>
38506
38507 <p>
38508 This program will fail to compile because <tt>shared_ptr</tt> uses the following 
38509 template constructor to construct itself from pointers:
38510 </p>
38511
38512 <blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
38513 </pre></blockquote>
38514
38515 <p>
38516 According
38517 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
38518 the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
38519 deducible, so the above constructor will not be found.  There are similar problems with the
38520 constructors that take a pointer and a <tt>deleter</tt> or a
38521 pointer, a <tt>deleter</tt> and an allocator, as well as the
38522 corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
38523 will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
38524 <tt>deleters</tt> or allocators or for <tt>reset()</tt>.
38525 </p>
38526
38527 <p>
38528 In the case of the functions that take deleters, there is the additional
38529 question of what argument should be passed to the deleter when it is
38530 eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
38531 <tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
38532 <tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
38533 <tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
38534 constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
38535 will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
38536 is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
38537 from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
38538 </p>
38539
38540 <p><i>[
38541 Bellevue:
38542 ]</i></p>
38543
38544
38545 <blockquote>
38546 <p>
38547 The general idea is right, we need to be able to pass a nullptr to a
38548 shared_ptr, but there are a few borderline editorial issues here. (For
38549 example, the single-argument nullptr_t constructor in the class synopsis
38550 isn't marked explicit, but it is marked explicit in the proposed wording
38551 for 20.6.6.2.1. There is a missing empty parenthesis in the form that
38552 takes a nullptr_t, a deleter, and an allocator.)
38553 </p>
38554 <p>
38555 More seriously: this issue says that a shared_ptr constructed from a
38556 nullptr is empty. Since "empty" is undefined, it's hard to know whether
38557 that's right. This issue is pending on handling that term better.
38558 </p>
38559 <p>
38560 Peter suggests definition of empty should be "does not own anything"
38561 </p>
38562 <p>
38563 Is there an editorial issue that post-conditions should refer to get() =
38564 nullptr, rather than get() = 0?
38565 </p>
38566 <p>
38567 No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
38568 </p>
38569 <p>
38570 Seems there are no technical merits between NAD and Ready, comes down to
38571 "Do we intentially want to allow/disallow null pointers with these
38572 functions". Staw Poll - support null pointers 5 - No null pointers 0
38573 </p>
38574 <p>
38575 Move to Ready, modulo editorial comments
38576 </p>
38577 </blockquote>
38578
38579 <p><i>[
38580 post Bellevue Peter adds:
38581 ]</i></p>
38582
38583
38584 <blockquote>
38585 <p>
38586 The following wording changes are less intrusive:
38587 </p>
38588
38589 <p>
38590 In 20.9.10.2.1 [util.smartptr.shared.const], add:
38591 </p>
38592
38593 <blockquote><pre>shared_ptr(nullptr_t);
38594 </pre></blockquote>
38595
38596 <p>
38597 after:
38598 </p>
38599
38600 <blockquote><pre>shared_ptr();
38601 </pre></blockquote>
38602
38603 <p>
38604 (Absence of explicit intentional.)
38605 </p>
38606
38607 <p>
38608 <tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
38609 I'm not convinced of its utility.
38610 </p>
38611 <p>
38612 It's similarly not clear to me whether the deleter constructors need to be
38613 extended to take <tt>nullptr</tt>, but if they need to:
38614 </p>
38615 <p>
38616 Add
38617 </p>
38618
38619 <blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
38620 template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
38621 </pre></blockquote>
38622
38623 <p>
38624 after
38625 </p>
38626
38627 <blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
38628 template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
38629 </pre></blockquote>
38630
38631 <p>
38632 Note that this changes the semantics of the new constructors such that they
38633 consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
38634 </p>
38635 <p>
38636 The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
38637 has repeatedly been requested by users, but the other additions that the
38638 proposed resolution makes are not supported by real world demand or
38639 motivating examples.
38640 </p>
38641 <p>
38642 It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
38643 constructor into a separate issue. Waiting for "empty" to be clarified is
38644 unnecessary; this is effectively an alias for the default constructor.
38645 </p>
38646 </blockquote>
38647
38648 <p><i>[
38649 Sophia Antipolis:
38650 ]</i></p>
38651
38652
38653 <blockquote>
38654 <p>
38655 We want to remove the reset functions from the proposed resolution.
38656 </p>
38657 <p>
38658 The remaining proposed resolution text (addressing the constructors) are wanted.
38659 </p>
38660 <p>
38661 Disposition: move to review. The review should check the wording in the then-current working draft.
38662 </p>
38663 </blockquote>
38664
38665
38666
38667 <p><b>Proposed resolution:</b></p>
38668 <p>
38669 In 20.9.10.2 [util.smartptr.shared] p4, add to the definition/synopsis
38670 of <tt>shared_ptr</tt>:
38671 </p>
38672
38673 <blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
38674 template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
38675 </pre></blockquote>
38676
38677 <p>
38678 after
38679 </p>
38680
38681 <blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
38682 template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
38683 </pre></blockquote>
38684
38685 <p>
38686 In 20.9.10.2.1 [util.smartptr.shared.const] add:
38687 </p>
38688
38689 <blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
38690 template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
38691 </pre></blockquote>
38692
38693 <p>
38694 after
38695 </p>
38696
38697 <blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
38698 template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
38699 </pre></blockquote>
38700
38701 <p>
38702 (reusing the following paragraphs 20.9.10.2.1 [util.smartptr.shared.const]/9-13 that speak of p.)
38703 </p>
38704
38705 <p>
38706 In 20.9.10.2.1 [util.smartptr.shared.const]/10,  change
38707 </p>
38708
38709 <blockquote>
38710 <i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the
38711 <del>pointer</del> <ins>object</ins> <tt>p</tt> and the deleter <tt>d</tt>. The second 
38712 constructor shall use a copy of <tt>a</tt> to allocate memory for internal use.
38713 </blockquote>
38714
38715
38716 <p><b>Rationale:</b></p>
38717 <p><i>[
38718 San Francisco:
38719 ]</i></p>
38720
38721
38722 <blockquote>
38723 "pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer.
38724 </blockquote>
38725
38726
38727
38728
38729
38730
38731 <hr>
38732 <h3><a name="759"></a>759. A reference is not an object</h3>
38733 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38734  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-11-06 <b>Last modified:</b> 2010-10-29</p>
38735 <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>
38736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38737 <p><b>Discussion:</b></p>
38738 <p>
38739 23.2 [container.requirements] says:
38740 </p>
38741
38742 <blockquote>
38743 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
38744 diagnostic required.
38745 </blockquote>
38746
38747 <p>
38748 A reference is not an object, but this sentence appears to claim so.
38749 </p>
38750
38751 <p>
38752 What is probably meant here:
38753 </p>
38754 <blockquote>
38755 An object bound to an rvalue
38756 reference parameter of a member function of a container shall not be
38757 an element of that container; no diagnostic required.
38758 </blockquote>
38759
38760
38761
38762 <p><b>Proposed resolution:</b></p>
38763 <p>
38764 Change 23.2 [container.requirements]:
38765 </p>
38766
38767 <blockquote>
38768 -12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
38769 <ins>An object bound to an rvalue
38770 reference parameter of a member function of a container shall not be
38771 an element</ins>
38772 of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o 
38773 diagnostic required.
38774 </blockquote>
38775
38776
38777
38778
38779
38780
38781 <hr>
38782 <h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
38783 <p><b>Section:</b> 23.7.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38784  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-15 <b>Last modified:</b> 2010-10-29</p>
38785 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38786 <p><b>Discussion:</b></p>
38787 <p>
38788 The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts 
38789 like <tt>operator[]()</tt>, except it throws an exception when the input key is 
38790 not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the 
38791 key doesn't have  a default constructor, it is an error if the key is 
38792 not found, or the user wants to avoid accidentally adding an element to 
38793 the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful 
38794 in <tt>std::unordered_map</tt>.
38795 </p>
38796
38797
38798 <p><b>Proposed resolution:</b></p>
38799 <p>
38800 Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.7.1 [unord.map]):
38801 </p>
38802
38803 <blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
38804 const mapped_type &amp;at(const key_type &amp;k) const;
38805 </pre></blockquote>
38806
38807 <p>
38808 Add the following definitions to 23.7.1.2 [unord.map.elem]:
38809 </p>
38810
38811 <blockquote>
38812 <pre>mapped_type&amp; at(const key_type&amp; k);
38813 const mapped_type &amp;at(const key_type &amp;k) const;
38814 </pre>
38815 <blockquote>
38816 <p>
38817 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element 
38818 whose key is equivalent to <tt>k</tt>.
38819 </p>
38820 <p>
38821 <i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
38822 is present.
38823 </p>
38824 </blockquote>
38825 </blockquote>
38826
38827 <p><i>[
38828 Bellevue:  Editorial note: the "(unique)" differs from map.
38829 ]</i></p>
38830
38831
38832
38833
38834
38835
38836
38837 <hr>
38838 <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
38839 <p><b>Section:</b> 20.9.9 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38840  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-11-30 <b>Last modified:</b> 2010-10-29</p>
38841 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
38842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38843 <p><b>Discussion:</b></p>
38844 <p>
38845 In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
38846 does currently not support incomplete types, because it
38847 gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
38848 an incomplete pointee type <tt>T</tt> automatically belongs to
38849 undefined behaviour according to 17.6.3.8 [res.on.functions]/2, last
38850 bullet. This is an unnecessary restriction and prevents
38851 many well-established patterns - like the bridge pattern -
38852 for <tt>std::unique_ptr</tt>.
38853 </p>
38854
38855 <p><i>[
38856 Bellevue:
38857 ]</i></p>
38858
38859
38860 <blockquote>
38861 Move to open. The LWG is comfortable with the intent of allowing
38862 incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
38863 not comfortable with the wording. The specification for <tt>unique_ptr</tt>
38864 should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
38865 member functions, which ones require their types to be complete. The
38866 <tt>shared_ptr</tt> specification is careful to say that for each function, and
38867 we need the same level of care here. We also aren't comfortable with the
38868 "part of the operational semantic" language; it's not used elsewhere in
38869 the standard, and it's not clear what it means. We need a volunteer to
38870 produce new wording.
38871 </blockquote>
38872
38873
38874 <p><b>Proposed resolution:</b></p>
38875 <p>
38876 The proposed changes in the following revision refers to the current state of
38877 N2521 including the assumption that X [unique.ptr.compiletime] will be removed
38878 according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
38879 </p>
38880 <p>
38881 The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
38882 type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
38883 try to cope with that. If the committee sees less usefulness on relaxed
38884 constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
38885 e.g. by adding one further bullet to 20.9.9.3 [unique.ptr.runtime]/1:
38886 "<tt>T</tt> shall be a complete type, if used as template argument of
38887 <tt>unique_ptr&lt;T[], D&gt;</tt>
38888 </p>
38889 <p>
38890 This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
38891 problems with this one,
38892 because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
38893 with the here discussed
38894 ones, provided that <tt>D::pointer</tt>'s operations (including default
38895 construction, copy construction/assignment,
38896 and pointer conversion) are specified <em>not</em> to throw, otherwise this
38897 would have impact on the
38898 current specification of <tt>unique_ptr</tt>.
38899 </p>
38900
38901 <ol>
38902 <li>
38903 <p>
38904 In 20.9.9 [unique.ptr]/2 add as the last sentence to the existing para:
38905 </p>
38906
38907 <blockquote>
38908 The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
38909 <tt>unique_ptr</tt> owns the object it holds a pointer to. A
38910 <tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
38911 <tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
38912 <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
38913 <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
38914 uses of <tt>unique_ptr</tt> include providing exception safety for
38915 dynamically allcoated memory, passing ownership of dynamically allocated
38916 memory to a function, and returning dynamically allocated memory from a
38917 function. -- <i>end note</i> ]
38918 </blockquote>
38919 </li>
38920
38921 <li>
38922 <p>
38923 20.9.9.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
38924 </p>
38925
38926 <blockquote>
38927 <p><i>[
38928 N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
38929 The current wording says just this.
38930 ]</i></p>
38931
38932 </blockquote>
38933 </li>
38934
38935 <li>
38936 <p>
38937 In 20.9.9.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
38938 </p>
38939
38940 <blockquote>
38941 <p>
38942 <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
38943 of <tt>D</tt> shall not throw an exception.</del>
38944 <del><tt>D</tt> must not be a reference type.</del>
38945 <ins>
38946 <tt>D</tt> shall be default constructible, and that construction
38947 shall not throw an exception.
38948 </ins>
38949 </p>
38950 <p><i>[
38951 N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
38952 this point. I assume that the current wording is based on the
38953 corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
38954 requirement is necessary, because the corresponding c'tor *can* fail
38955 and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
38956 this regard. The *only* functions that must insist on well-formedness
38957 and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
38958 the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
38959 explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
38960 invocation of
38961 <tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
38962 we do *not* need the
38963 requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
38964 <tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
38965 potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
38966 again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
38967 ]</i></p>
38968
38969 </blockquote>
38970 </li>
38971
38972 <li>
38973 <p>
38974 Merge 20.9.9.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
38975 of 12, but transferring the "requires" to 13:
38976 </p>
38977
38978 <blockquote>
38979 <p>
38980 <i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
38981 </p>
38982 <p><i>[
38983 N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
38984 well-formed/well-defined at this point. The current wording guarantees
38985 all what we need, namely that the initialization of both the <tt>T*</tt>
38986 pointer and the <tt>D</tt> deleter are well-formed and well-defined.
38987 ]</i></p>
38988
38989 </blockquote>
38990 </li>
38991
38992 <li>
38993 20.9.9.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
38994 </li>
38995 <li>
38996 <p>20.9.9.2.1 [unique.ptr.single.ctor]/21:</p>
38997
38998 <blockquote>
38999 <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
39000 the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
39001 formed and shall not throw an exception. If <tt>D</tt> is a reference
39002 type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
39003 required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
39004 <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
39005 be complete types. <i>-- end note</i>]</ins>
39006 </blockquote>
39007
39008 <p><i>[
39009 N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
39010 is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
39011 true. If the committee wishes this explicit requirement can be added,
39012 e.g. "<tt>U</tt> shall be a complete type."
39013 ]</i></p>
39014
39015 </li>
39016
39017 <li>
39018 <p>
39019 20.9.9.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
39020 </p>
39021 <blockquote>
39022 <p>
39023 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
39024 shall have well-defined behavior, and shall not throw exceptions.
39025 <ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
39026 be a complete type. <i>-- end note</i>]</ins>
39027 </p>
39028 <p><i>[
39029 N.B.: This requirement ensures that the whole responsibility on
39030 type-completeness of <tt>T</tt> is delegated to this expression.
39031 ]</i></p>
39032
39033 </blockquote>
39034 </li>
39035
39036 <li>
39037 <p>
39038 20.9.9.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
39039 current editorial issue, that "must shall" has to be changed to
39040 "shall", but this change is not a special part of this resolution.
39041 </p>
39042
39043 <p><i>[
39044 N.B. The current wording is sufficient, because we can delegate all
39045 further requirements on the requirements of the effects clause
39046 ]</i></p>
39047
39048 </li>
39049
39050 <li>
39051 <p>
39052 20.9.9.2.3 [unique.ptr.single.asgn]/6:
39053 </p>
39054
39055 <blockquote>
39056 <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
39057 <tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
39058 convertible to <tt>T*</tt>.
39059 <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
39060 be complete types. <i>-- end note</i>]</ins>
39061 </blockquote>
39062
39063 <p><i>[
39064 N.B.: The current wording of p. 6 already implicitly guarantees that
39065 <tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
39066 is true, see (6)+(8).
39067 ]</i></p>
39068
39069 </li>
39070
39071 <li>
39072 <p>
39073 20.9.9.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
39074 </p>
39075 <p><i>[
39076 N.B.: Delegation to requirements of effects clause is sufficient.
39077 ]</i></p>
39078
39079 </li>
39080
39081 <li>
39082 20.9.9.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
39083 </li>
39084
39085 <blockquote>
39086 <pre>T* operator-&gt;() const;</pre>
39087 <blockquote>
39088 <ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
39089 </blockquote>
39090 </blockquote>
39091
39092 <li>
39093 20.9.9.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
39094 </li>
39095
39096 <li>
39097 <p>
39098 20.9.9.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
39099 </p>
39100 <blockquote>
39101 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
39102 shall have well-defined behavior, and shall not throw exceptions.
39103 </blockquote>
39104 </li>
39105
39106 <li>
39107 20.9.9.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
39108 </li>
39109
39110 <li>
39111 <p>
39112 20.9.9.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
39113 </p>
39114
39115 <blockquote>
39116 <p>
39117 A specialization for array types is provided with a slightly altered interface.
39118 </p>
39119
39120 <ul>
39121 <li>
39122 ...
39123 </li>
39124 <li>
39125 <ins><tt>T</tt> shall be a complete type.</ins>
39126 </li>
39127 </ul>
39128 </blockquote>
39129 </li>
39130 </ol>
39131
39132 <p><i>[
39133 post Bellevue: Daniel provided revised wording.
39134 ]</i></p>
39135
39136
39137
39138
39139
39140
39141
39142 <hr>
39143 <h3><a name="765"></a>765. more on iterator validity</h3>
39144 <p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
39145  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14 <b>Last modified:</b> 2010-10-29</p>
39146 <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>
39147 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39148 <p><b>Discussion:</b></p>
39149        <p>
39150
39151 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
39152 defines the meaning of the term "invalid iterator" as one that may be
39153 singular.
39154
39155        </p>
39156        <p>
39157
39158 Consider the following code:
39159
39160        </p>
39161        <pre>   std::deque&lt;int&gt; x, y;
39162    std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
39163    x.swap(y);
39164        </pre>
39165        <p>
39166
39167 Given that <code>swap()</code> is required not to invalidate iterators
39168 and using the definition above, what should be the expected result of
39169 comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
39170 and <code>y.end()</code>, respectively, after the <code>swap()</code>?
39171
39172        </p>
39173        <p>
39174
39175 I.e., is the expression below required to evaluate
39176 to <code>true</code>?
39177
39178        </p>
39179        <pre>   i == y.end() &amp;&amp; j == x.end()
39180        </pre>
39181        <p>
39182
39183 (There are at least two implementations where the expression
39184 returns <code>false</code>.)
39185
39186        </p>
39187        <p>
39188
39189 More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
39190 make any guarantees about whether iterators actually point to the same
39191 elements or be associated with the same containers after a
39192 non-invalidating operation as they did before?
39193
39194        </p>
39195        <p>
39196
39197 Here's a motivating example intended to demonstrate the importance of
39198 the question:
39199
39200        </p>
39201        <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
39202    Container::iterator i = y.begin() + 1;
39203    Container::iterator j = y.end();
39204    std::swap(x, y);
39205    std::find(i, j, 3);
39206        </pre>
39207        <p>
39208
39209 <code>swap()</code> guarantees that <code>i</code> and <code>j</code>
39210 continue to be valid. Unless the spec says that even though they are
39211 valid they may no longer denote a valid range the code above must be
39212 well-defined. Expert opinions on this differ as does the behavior of
39213 popular implementations for some standard <code>Containers</code>.
39214
39215        </p>
39216 <p><i>[
39217 San Francisco:
39218 ]</i></p>
39219
39220
39221 <blockquote>
39222 <p>
39223 Pablo: add a note to the last bullet of paragraph 11 of 23.1.1 clarifying that the end() iterator doesn't refer to an element and that it can therefore be invalidated.
39224 </p>
39225 <p>
39226 Proposed wording:
39227 </p>
39228 <blockquote>
39229 [<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can
39230 therefore be invalidated. <i>-- end note</i>]
39231 </blockquote>
39232 <p>
39233 Howard will add this proposed wording to the issue and then move it to Review.
39234 </p>
39235 </blockquote>
39236
39237 <p><i>[
39238 Post Summit:
39239 ]</i></p>
39240
39241
39242 <blockquote>
39243 <p>
39244 Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element"
39245 </p>
39246 <p>
39247 Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated,
39248 because it does not refer to any element."
39249 </p>
39250 <p>
39251 Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore
39252 subject to being invalidated."
39253 </p>
39254 <p>
39255 Consensus: go with Nick
39256 </p>
39257 <p>
39258 With that update, Recommend Tentatively Ready.
39259 </p>
39260 </blockquote>
39261
39262
39263
39264 <p><b>Proposed resolution:</b></p>
39265 <p>
39266 Add to 23.2.1 [container.requirements.general], p11:
39267 </p>
39268
39269 <blockquote>
39270 <p>
39271 Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
39272 23.2.6.4) all container types defined in this Clause meet the following
39273 additional requirements:
39274 </p>
39275 <ul>
39276 <li>...</li>
39277 <li>
39278 no <tt>swap()</tt> function invalidates any references, pointers, or
39279 iterators referring to the elements of the containers being swapped.
39280 <ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore
39281 subject to being invalidated. <i>-- end note</i>]</ins>
39282 </li>
39283 </ul>
39284 </blockquote>
39285
39286
39287
39288
39289
39290 <hr>
39291 <h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
39292 <p><b>Section:</b> 23.2 [container.requirements], 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39293  <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2007-12-22 <b>Last modified:</b> 2010-10-29</p>
39294 <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>
39295 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39296 <p><b>Discussion:</b></p>
39297 <p>
39298 23.2 [container.requirements]p10 states:
39299 </p>
39300
39301 <blockquote>
39302 <p>
39303 Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
39304 additional requirements:
39305 </p>
39306 <ul>
39307
39308 <li>[...]</li>
39309
39310 <li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
39311
39312 </ul>
39313 </blockquote>
39314
39315 <p>
39316 23.3.2.3 [deque.modifiers] and 23.4.1.4 [vector.modifiers] offer
39317 additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
39318 <tt>erase()</tt> members. However, 23.2 [container.requirements]p10 does not mention 23.2.5.1 [unord.req.except] that specifies exception safety guarantees
39319 for unordered containers. In addition,  23.2.5.1 [unord.req.except]p1 offers the following guaratee for
39320 <tt>erase()</tt>:
39321 </p>
39322
39323 <blockquote>
39324 No <tt>erase()</tt> function throws an exception unless that exception
39325 is thrown by the container's Hash or Pred object (if any).
39326 </blockquote>
39327
39328 <p>
39329 Summary:
39330 </p>
39331
39332 <p>
39333 According to 23.2 [container.requirements]p10 no
39334 <tt>erase()</tt> function should throw an exception unless otherwise
39335 specified. Although does not explicitly mention 23.2.5.1 [unord.req.except], this section offers additional guarantees
39336 for unordered containers, allowing <tt>erase()</tt> to throw if
39337 predicate or hash function throws.
39338 </p>
39339
39340 <p>
39341 In contrast, associative containers have no exception safety guarantees
39342 section so no <tt>erase()</tt> function should throw, <em>including
39343 <tt>erase(k)</tt></em> that needs to use the predicate function to
39344 perform its work. This means that the predicate of an associative
39345 container is not allowed to throw.
39346 </p>
39347
39348 <p>
39349 So:
39350 </p>
39351
39352 <ol>
39353 <li>
39354 <tt>erase(k)</tt> for associative containers is not allowed to throw. On
39355 the other hand, <tt>erase(k)</tt> for unordered associative containers
39356 is allowed to throw.
39357 </li>
39358 <li>
39359 <tt>erase(q)</tt> for associative containers is not allowed to throw. On
39360 the other hand, <tt>erase(q)</tt> for unordered associative containers
39361 is allowed to throw if it uses the hash or predicate.
39362 </li>
39363 <li>
39364 To fulfill 1), predicates of associative containers are not allowed to throw.
39365 Predicates of unordered associative containers are allowed to throw.
39366 </li>
39367 <li>
39368 2) breaks a widely used programming pattern (flyweight pattern) for
39369 unordered containers, where objects are registered in a global map in
39370 their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
39371 allowed to throw, the destructor of the object would need to rethrow the
39372 exception or swallow it, leaving the object registered.
39373 </li>
39374 </ol>
39375
39376
39377 <p><b>Proposed resolution:</b></p>
39378 <p>
39379 Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
39380 safety guarantees".
39381 </p>
39382
39383 <blockquote>
39384 <p>
39385 1 For associative containers, no <tt>clear()</tt> function throws an exception.
39386 <tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
39387 the container's Pred object (if any).
39388 </p>
39389
39390 <p>
39391 2 For associative containers, if an exception is thrown by any operation
39392 from within an <tt>insert()</tt> function inserting a single element, the
39393 <tt>insert()</tt> function has no effect.
39394 </p>
39395
39396 <p>
39397 3 For associative containers, no <tt>swap</tt> function throws an exception
39398 unless that exception is thrown by the copy constructor or copy
39399 assignment operator of the container's Pred object (if any).
39400 </p>
39401 </blockquote>
39402
39403 <p>
39404 Change 23.2.5.1 [unord.req.except]p1:
39405 </p>
39406
39407 <blockquote>
39408 For unordered associative containers, no <tt>clear()</tt> function
39409 throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
39410 <del>function</del> <ins>does not</ins> throw<del>s</del> an exception
39411 unless that exception is thrown by the container's Hash or Pred object
39412 (if any).
39413 </blockquote>
39414
39415 <p>
39416 Change 23.2 [container.requirements]p10 to add references to new sections:
39417 </p>
39418
39419 <blockquote>
39420 Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
39421 <del>and</del> [vector.modifiers]<ins>, [associative.req.except],
39422 [unord.req.except]</ins>) all container types defined in this clause meet
39423 the following additional requirements:
39424 </blockquote>
39425
39426 <p>
39427 Change 23.2 [container.requirements]p10 referring to <tt>swap</tt>:
39428 </p>
39429
39430 <blockquote>
39431 <ul>
39432 <li>
39433 no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
39434 by the copy constructor or assignment operator of the container's
39435 Compare object (if any; see [associative.reqmts])</del>.
39436 </li>
39437 </ul>
39438 </blockquote>
39439
39440
39441
39442
39443
39444
39445 <hr>
39446 <h3><a name="768"></a>768. Typos in [atomics]?</h3>
39447 <p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39448  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2010-10-29</p>
39449 <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>
39450 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39451 <p><b>Discussion:</b></p>
39452 <p>
39453 in the latest publicly available draft, paper
39454 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
39455 in section 29.5 [atomics.types.generic], the following specialization of the template
39456 <tt>atomic&lt;&gt;</tt> is provided for pointers:
39457 </p>
39458
39459 <blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
39460   T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
39461   T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
39462
39463   atomic() = default; 
39464   constexpr explicit atomic(T); 
39465   atomic(const atomic&amp;) = delete; 
39466   atomic&amp; operator=(const atomic&amp;) = delete; 
39467
39468   T* operator=(T*) volatile; 
39469   T* operator++(int) volatile; 
39470   T* operator--(int) volatile; 
39471   T* operator++() volatile; 
39472   T* operator--() volatile; 
39473   T* operator+=(ptrdiff_t) volatile;
39474   T* operator-=(ptrdiff_t) volatile; 
39475 };
39476 </pre></blockquote>
39477
39478 <p>
39479 First of all, there is a typo in the non-default constructor which
39480 should take a <tt>T*</tt> rather than a <tt>T</tt>.
39481 </p>
39482
39483 <p>
39484 As you can see, the specialization redefine and therefore hide a few
39485 methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
39486 <tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
39487 to the other methods, in particular these ones:
39488 </p>
39489
39490 <blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
39491 T* load( memory_order = memory_order_seq_cst ) volatile;
39492 T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
39493 bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
39494 bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
39495 </pre></blockquote>
39496
39497 <p>
39498 By reading paper
39499 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
39500 I see that the
39501 definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
39502 draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
39503 and <tt>compare_swap()</tt> are indeed present.
39504 </p>
39505
39506 <p>
39507 Strangely, the example implementation does not redefine the method
39508 <tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
39509 hiding the <tt>void*</tt> signature from the base class makes the class
39510 error-prone to say the least: it lets you assign pointers of any type to
39511 a <tt>T*</tt>, without any hint from the compiler.
39512 </p>
39513
39514 <p>
39515 Is there a true intent to remove them from the specialization or are
39516 they just missing from the definition because of a mistake?
39517 </p>
39518
39519 <p><i>[
39520 Bellevue:
39521 ]</i></p>
39522
39523
39524 <blockquote>
39525 <p>
39526 The proposed revisions are accepted.
39527 </p>
39528 <p>
39529 Further discussion: why is the ctor labeled "constexpr"? Lawrence said
39530 this permits the object to be statically initialized, and that's
39531 important because otherwise there would be a race condition on
39532 initialization.
39533 </p>
39534 </blockquote>
39535
39536
39537 <p><b>Proposed resolution:</b></p>
39538 <p>
39539 Change the synopsis in 29.5 [atomics.types.generic]:
39540 </p>
39541
39542 <blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
39543   <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
39544   <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
39545   <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
39546   <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
39547   <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
39548
39549   T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
39550   T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
39551
39552   atomic() = default; 
39553   constexpr explicit atomic(T<ins>*</ins>); 
39554   atomic(const atomic&amp;) = delete; 
39555   atomic&amp; operator=(const atomic&amp;) = delete; 
39556
39557   T* operator=(T*) volatile; 
39558   T* operator++(int) volatile; 
39559   T* operator--(int) volatile; 
39560   T* operator++() volatile; 
39561   T* operator--() volatile; 
39562   T* operator+=(ptrdiff_t) volatile;
39563   T* operator-=(ptrdiff_t) volatile; 
39564 };
39565 </pre></blockquote>
39566
39567
39568
39569
39570
39571
39572 <hr>
39573 <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
39574 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39575  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2010-10-29</p>
39576 <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>
39577 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39578 <p><b>Discussion:</b></p>
39579 <p>
39580 N2461 already replaced in 20.8.14.2 [func.wrap.func] it's originally proposed
39581 (implicit) conversion operator to "unspecified-bool-type" by the new
39582 explicit bool conversion, but the inverse conversion should also
39583 use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
39584 type".
39585 </p>
39586
39587
39588 <p><b>Proposed resolution:</b></p>
39589
39590 <p>
39591 In 20.8 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
39592 </p>
39593
39594 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
39595   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39596 template&lt;class R, class... ArgTypes&gt;
39597   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
39598 template&lt;class R, class... ArgTypes&gt;
39599   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39600 template&lt;class R, class... ArgTypes&gt;
39601   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
39602 </pre></blockquote>
39603
39604 <p>
39605 In the class function synopsis of 20.8.14.2 [func.wrap.func] replace
39606 </p>
39607
39608 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39609 ...
39610 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39611 </pre></blockquote>
39612
39613 <p>
39614 In 20.8.14.2 [func.wrap.func], "Null pointer comparisons" replace:
39615 </p>
39616
39617 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
39618   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39619 template &lt;class R, class... ArgTypes&gt;
39620   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
39621 template &lt;class R, class... ArgTypes&gt;
39622   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39623 template &lt;class R, class... ArgTypes&gt;
39624   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
39625 </pre></blockquote>
39626
39627 <p>
39628 In 20.8.14.2.1 [func.wrap.func.con], replace
39629 </p>
39630
39631 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39632 ...
39633 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39634 </pre></blockquote>
39635
39636 <p>
39637 In 20.8.14.2.6 [func.wrap.func.nullptr], replace
39638 </p>
39639
39640 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
39641   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39642 template &lt;class R, class... ArgTypes&gt;
39643   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
39644 </pre></blockquote>
39645
39646 <p>
39647 and replace
39648 </p>
39649
39650 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
39651   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
39652 template &lt;class R, class... ArgTypes&gt;
39653   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
39654 </pre></blockquote>
39655
39656
39657
39658
39659
39660
39661 <hr>
39662 <h3><a name="770"></a>770. std::function should use rvalue swap</h3>
39663 <p><b>Section:</b> 20.8.14 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39664  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2010-10-29</p>
39665 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39666 <p><b>Discussion:</b></p>
39667 <p>
39668 It is expected that typical implementations of <tt>std::function</tt> will
39669 use dynamic memory allocations at least under given conditions,
39670 so it seems appropriate to change the current lvalue swappabilty of
39671 this class to rvalue swappability.
39672 </p>
39673
39674
39675 <p><b>Proposed resolution:</b></p>
39676 <p>
39677 In 20.8 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
39678 </p>
39679
39680 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
39681   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39682 <ins>template&lt;class R, class... ArgTypes&gt;
39683   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39684 template&lt;class R, class... ArgTypes&gt;
39685   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
39686 </pre></blockquote>
39687
39688 <p>
39689 In 20.8.14.2 [func.wrap.func] class <tt>function</tt> definition, change
39690 </p>
39691
39692 <blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
39693 </pre></blockquote>
39694
39695 <p>
39696 In 20.8.14.2 [func.wrap.func], just below of
39697 </p>
39698
39699 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
39700   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39701 <ins>template &lt;class R, class... ArgTypes&gt;
39702   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39703 template &lt;class R, class... ArgTypes&gt;
39704   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
39705 </pre></blockquote>
39706
39707 <p>
39708 In 20.8.14.2.2 [func.wrap.func.mod] change
39709 </p>
39710
39711 <blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
39712 </pre></blockquote>
39713
39714 <p>
39715 In 20.8.14.2.7 [func.wrap.func.alg] add the two overloads
39716 </p>
39717
39718 <blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
39719   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
39720 template&lt;class R, class... ArgTypes&gt;
39721   void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
39722 </pre></blockquote>
39723
39724
39725
39726
39727
39728
39729 <hr>
39730 <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
39731 <p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39732  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2010-10-29</p>
39733 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
39734 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39735 <p><b>Discussion:</b></p>
39736 <p>
39737 The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.5 [string.conversions]
39738 have throws clauses (paragraphs 8 and 16) which say:
39739 </p>
39740
39741 <blockquote>
39742 <i>Throws:</i> nothing
39743 </blockquote>
39744
39745 <p>
39746 Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
39747 this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
39748 constructors can fail due to out-of-memory conditions. Either these throws
39749 clauses should be removed or should be more detailled like:
39750 </p>
39751
39752 <blockquote>
39753 <i>Throws:</i> Nothing if the string construction throws nothing
39754 </blockquote>
39755
39756 <p>
39757 Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
39758 overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
39759 header <tt>&lt;string&gt;</tt> synopsis of 21.3 [string.classes] is correct in this
39760 regard).
39761 </p>
39762
39763
39764
39765 <p><b>Proposed resolution:</b></p>
39766 <p>
39767 In 21.5 [string.conversions], remove the paragraphs 8 and 16.
39768 </p>
39769
39770 <blockquote>
39771 <pre>string to_string(long long val); 
39772 string to_string(unsigned long long val); 
39773 string to_string(long double val); 
39774 </pre>
39775 <blockquote>
39776 <del><i>Throws:</i> nothing</del>
39777 </blockquote>
39778 </blockquote>
39779
39780 <blockquote>
39781 <pre><ins>w</ins>string to_wstring(long long val); 
39782 <ins>w</ins>string to_wstring(unsigned long long val); 
39783 <ins>w</ins>string to_wstring(long double val); 
39784 </pre>
39785 <blockquote>
39786 <del><i>Throws:</i> nothing</del>
39787 </blockquote>
39788 </blockquote>
39789
39790
39791
39792
39793
39794
39795 <hr>
39796 <h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
39797 <p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
39798  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2010-10-29</p>
39799 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
39800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39801 <p><b>Discussion:</b></p>
39802 <p>
39803 The return clause 21.5 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
39804 overloads says:
39805 </p>
39806
39807 <blockquote>
39808 <i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
39809 representation of the value of its argument that would be generated by
39810 calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
39811 or <tt>L"%f"</tt>, respectively.
39812 </blockquote>
39813
39814 <p>
39815 Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
39816 the 2nd edition of ISO 9899, and the first and the second corrigenda from
39817 2001-09-01 and 2004-11-15). What probably meant here is the function
39818 <tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
39819 declaration:
39820 </p>
39821
39822 <blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
39823 const wchar_t * restrict format, ...);
39824 </pre></blockquote>
39825
39826 <p>
39827 therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
39828 </p>
39829
39830
39831
39832 <p><b>Proposed resolution:</b></p>
39833 <p>
39834 Change the current wording of 21.5 [string.conversions]/p. 15 to:
39835 </p>
39836
39837 <blockquote>
39838 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
39839 <tt>wstring</tt> object holding the character representation of the
39840 value of its argument that would be generated by calling
39841 <tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
39842 val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
39843 <tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
39844 designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
39845 </blockquote>
39846
39847 <p>
39848 [Hint to the editor: The resolution also adds to mention the name of
39849 the format specifier "fmt"]
39850 </p>
39851
39852 <p>
39853 I also would like to remark that the current wording of it's equivalent
39854 paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
39855 </p>
39856
39857 <p>
39858 Change the current wording of 21.5 [string.conversions]/p. 7 to:
39859 </p>
39860
39861 <blockquote>
39862 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
39863 character representation of the value of its argument that would be
39864 generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
39865 <tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
39866 character buffer of sufficient size</ins>.
39867 </blockquote>
39868
39869
39870
39871
39872
39873
39874 <hr>
39875 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
39876 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
39877  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14 <b>Last modified:</b> 2010-10-29</p>
39878 <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>
39879 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39880 <p><b>Discussion:</b></p>
39881 <p>
39882 It appears most containers declare but do not define a member-swap
39883 function.
39884 </p>
39885
39886 <p>
39887 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
39888 member-swap function!
39889 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
39890 [Table 87])
39891 </p>
39892
39893 <p>
39894 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
39895 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
39896 definition.
39897 </p>
39898
39899 <p>
39900 A quick survey of clause 23 shows that the following containers provide a
39901 definition for member-swap:
39902 </p>
39903
39904 <blockquote><pre>array
39905 queue
39906 stack
39907 vector
39908 </pre></blockquote>
39909
39910 <p>
39911 Whereas the following declare it, but do not define the semantics:
39912 </p>
39913
39914 <blockquote><pre>deque
39915 list
39916 map
39917 multimap
39918 multiset
39919 priority_queue
39920 set
39921 unordered_map
39922 unordered_multi_map
39923 unordered_multi_set
39924 unordered_set
39925 </pre></blockquote>
39926
39927 <p>
39928 Suggested resolution:
39929 </p>
39930 <blockquote>
39931 Provide a definition for each of the affected containers...
39932 </blockquote>
39933
39934 <p><i>[
39935 Bellevue:
39936 ]</i></p>
39937
39938
39939 <blockquote>
39940 Move to Open and ask Alisdair to provide wording.
39941 </blockquote>
39942
39943 <p><i>[
39944 2009-07 Frankfurt:
39945 ]</i></p>
39946
39947
39948 <blockquote>
39949 Daniel to provide wording.
39950 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>
39951 is no longer applicable.
39952 </blockquote>
39953
39954 <p><i>[
39955 2009-07-28 Daniel provided wording.
39956 ]</i></p>
39957
39958
39959 <blockquote>
39960 <ol>
39961 <li>
39962 It assumes that the proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> is applied,
39963 which breaks the circularity of definition between member
39964 <tt>swap</tt> and free <tt>swap</tt>.
39965 </li>
39966
39967 <li>
39968 It uses the notation of the pre-concept allocator trait
39969 <tt>allocator_propagation_map</tt>, which might be renamed after the
39970 next refactoring phase of generalized allocators.
39971 </li>
39972
39973 <li>
39974 It requires that compare objects, key equal functions and
39975 hash functions in containers are swapped via unqualified free
39976 <tt>swap</tt> according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.
39977 </li>
39978 </ol>
39979 </blockquote>
39980
39981 <p><i>[
39982 2009-09-30 Daniel adds:
39983 ]</i></p>
39984
39985
39986 <blockquote>
39987 The outcome of this issue should be considered with the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a> both in style and in content (e.g. bullet 9 suggests to
39988 define the semantic of <tt>void
39989 priority_queue::swap(priority_queue&amp;)</tt> in terms of the member
39990 <tt>swap</tt> of the container).
39991 </blockquote>
39992
39993 <p><i>[
39994 2009-10 Santa Cruz:
39995 ]</i></p>
39996
39997
39998 <blockquote>
39999 Looked at, but took no action on as it overlaps too much with
40000 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
40001 Waiting for a new draft WP.
40002 </blockquote>
40003
40004 <p><i>[
40005 2009-10 Santa Cruz:
40006 ]</i></p>
40007
40008
40009 <blockquote>
40010 Leave as open. Pablo to provide wording.
40011 </blockquote>
40012
40013 <p><i>[
40014 2009-10-26 Pablo updated wording.  Here is the wording he replaced:
40015 ]</i></p>
40016
40017
40018 <blockquote class="note">
40019 <ol>
40020 <li>
40021 <p>
40022 Add a new Throws clause just after X [allocator.propagation.map]/5:
40023 </p>
40024
40025 <blockquote><pre>static void swap(Alloc&amp; a, Alloc&amp; b);
40026 </pre>
40027 <blockquote>
40028 <p>
40029 <i>Effects:</i> [..]
40030 </p>
40031
40032 <p>
40033 <ins><i>Throws:</i> Nothing.</ins>
40034 </p>
40035 </blockquote>
40036 </blockquote>
40037 <p><i>[
40038 This exception requirement is added, such that it's combination with the
40039 general container requirements of
40040 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
40041 [container.requirements.general]/9
40042 make it unambiguously clear that the following descriptions of "swaps the
40043 allocators" have the following meaning: (a) This swap is done by calling
40044 <tt>allocator_propagation_map&lt;allocator_type&gt;::swap</tt> and (b) This allocator
40045 swap does never propagate an exception
40046 ]</i></p>
40047
40048 </li>
40049
40050 <li>
40051 <p>
40052 Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
40053 </p>
40054
40055 <blockquote>
40056 For associative containers, no <tt>swap</tt> function throws an exception unless that
40057 exception is thrown by the <del>copy constructor or copy assignment
40058 operator</del>
40059 <ins><tt>swap</tt></ins> of the container's <tt>Pred</tt> object<ins>s</ins><del> (if any)</del>.
40060 </blockquote>
40061 </li>
40062
40063 <li>
40064 <p>
40065 Change 23.2.5.1 [unord.req.except]/3 as indicated:
40066 </p>
40067
40068 <blockquote>
40069 For unordered associative containers, no <tt>swap</tt> function throws an
40070 exception unless
40071 that exception is thrown by the <del>copy constructor or copy
40072 assignment operator</del>
40073 <ins><tt>swap</tt></ins> of the container's <tt>Hash</tt> or <tt>Pred</tt> object<ins>s,
40074 respectively</ins><del> (if any)</del>.
40075 </blockquote>
40076 </li>
40077
40078 <li>
40079 <p>
40080 Insert a new paragraph just after 23.3 [sequences]/1:
40081 </p>
40082
40083 <blockquote>
40084 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
40085 the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when the
40086 header <tt>&lt;queue&gt;</tt> is included.</ins>
40087 </blockquote>
40088
40089 <p><i>[
40090 There is a new issue in process that will suggest a minimum header for <tt>swap</tt>
40091 and <tt>move</tt>. If this one is provided, this text can be removed and the header
40092 dependency should be added to <tt>&lt;queue&gt;</tt>
40093 ]</i></p>
40094
40095
40096 </li>
40097
40098 <li>
40099 <p>
40100 Add one further clause at the end of 23.3.1.2 [array.special]:
40101 </p>
40102 <p><i>[This part is added, because otherwise <tt>array::swap</tt> would otherwise
40103 contradict the
40104 general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]</i></p>
40105
40106
40107 <blockquote>
40108 <ins><i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throws
40109 an exception.</ins>
40110 </blockquote>
40111 </li>
40112
40113 <li>
40114 <ol type="a">
40115 <li>
40116 <p>
40117 In 23.3.2 [deque], class template deque synopsis change as indicated:
40118 </p>
40119 <blockquote><pre>void swap(deque<del>&lt;T,Alloc&gt;</del>&amp;);
40120 </pre></blockquote>
40121 </li>
40122
40123 <li>
40124 <p>
40125 At the end of 23.3.2.3 [deque.modifiers] add as indicated:
40126 </p>
40127
40128 <blockquote><pre><ins>void swap(deque&amp; x);</ins>
40129 </pre>
40130 <blockquote>
40131 <p>
40132 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40133 with that of <tt>x</tt>.</ins>
40134 </p>
40135 <p>
40136 <ins><i>Complexity:</i> Constant time.</ins>
40137 </p>
40138 </blockquote>
40139 </blockquote>
40140 </li>
40141 </ol>
40142 </li>
40143
40144 <li>
40145 <ol type="a">
40146 <li>
40147 <p>
40148 In 23.3.3 [forwardlist], class template <tt>forward_list</tt> synposis change as indicated:
40149 </p>
40150
40151 <blockquote><pre>void swap(forward_list<del>&lt;T,Allocator&gt;</del>&amp;);
40152 </pre></blockquote>
40153 </li>
40154
40155 <li>
40156 <p>
40157 At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
40158 </p>
40159
40160 <blockquote><pre><ins>void swap(forward_list&amp; x);</ins>
40161 </pre>
40162 <blockquote>
40163 <p>
40164 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40165 with that of <tt>x</tt>.</ins>
40166 </p>
40167 <p>
40168 <ins><i>Complexity:</i> Constant time.</ins>
40169 </p>
40170 </blockquote>
40171 </blockquote>
40172 </li>
40173 </ol>
40174 </li>
40175
40176 <li>
40177 <ol type="a">
40178 <li>
40179 <p>
40180 In 23.3.4 [list], class template <tt>list</tt> synopsis change as indicated:
40181 </p>
40182
40183 <blockquote><pre>void swap(list<del>&lt;T,Allocator&gt;</del>&amp;);
40184 </pre></blockquote>
40185 </li>
40186
40187 <li>
40188 <p>
40189 At the end of 23.3.4.3 [list.modifiers] add as indicated:
40190 </p>
40191
40192 <blockquote><pre><ins>void swap(list&amp; x);</ins>
40193 </pre>
40194
40195 <blockquote>
40196 <p>
40197 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40198 with that of <tt>x</tt>.</ins>
40199 </p>
40200
40201 <p>
40202 <ins><i>Complexity:</i> Constant time.</ins>
40203 </p>
40204 </blockquote>
40205 </blockquote>
40206 </li>
40207 </ol>
40208 </li>
40209
40210 <li>
40211 <p>
40212 At the end of 23.5.2.3 [priqueue.members] add a new prototype description:
40213 </p>
40214
40215 <blockquote><pre><ins>void swap(priority_queue&amp; q);</ins>
40216 </pre>
40217 <blockquote>
40218 <p>
40219 <ins><i>Requires:</i> <tt>Compare</tt> shall satisfy the <tt>Swappable</tt> requirements
40220 ( [swappable]).</ins>
40221 </p>
40222
40223 <p><i>[
40224 This requirement is added to ensure that even a user defined <tt>swap</tt>
40225 which is found by
40226 ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt> requirements
40227 ]</i></p>
40228
40229
40230 <p>
40231 <ins><i>Effects:</i> <tt>this-&gt;c.swap(q.c); swap(this-&gt;comp, q.comp);</tt></ins>
40232 </p>
40233 <p>
40234 <ins><i>Throws:</i> What and if <tt>c.swap(q.c)</tt> and <tt>swap(comp, q.comp)</tt> throws.</ins>
40235 </p>
40236 </blockquote>
40237 </blockquote>
40238 <p><i>[
40239 This part is added, because otherwise <tt>priority_queue::swap</tt> would otherwise
40240 contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5
40241 ]</i></p>
40242
40243 </li>
40244
40245 <li>
40246 <ol type="a">
40247 <li>
40248 <p>
40249 In 23.4.1 [vector], class template <tt>vector</tt> synopsis change as indicated:
40250 </p>
40251
40252 <blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp;);
40253 </pre></blockquote>
40254 </li>
40255
40256 <li>
40257 <p>
40258 Change 23.4.1.2 [vector.capacity]/8 as indicated:
40259 </p>
40260
40261 <blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp; x);
40262 </pre>
40263
40264 <blockquote>
40265 <i>Effects:</i> Exchanges the contents and <tt>capacity()</tt> <ins>and swaps the
40266 allocators</ins>
40267 of <tt>*this</tt> with that of <tt>x</tt>.
40268 </blockquote>
40269 </blockquote>
40270 </li>
40271 </ol>
40272 </li>
40273
40274 <li>
40275 <p>
40276 Insert a new paragraph just before 23.6 [associative]/1:
40277 </p>
40278
40279 <blockquote>
40280 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
40281 the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
40282 headers <tt>&lt;map&gt;</tt> or <tt>&lt;set&gt;</tt> are included.</ins>
40283 </blockquote>
40284 </li>
40285
40286 <li>
40287 <ol type="a">
40288 <li>
40289 <p>
40290 In 23.6.1 [map], class template <tt>map</tt> synopsis change as indicated:
40291 </p>
40292
40293 <blockquote><pre>void swap(map<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
40294 </pre></blockquote>
40295 </li>
40296
40297 <li>
40298 <p>
40299 At the end of 23.6.1.3 [map.modifiers] add as indicated:
40300 </p>
40301
40302 <blockquote><pre><ins>void swap(map&amp; x);</ins>
40303 </pre>
40304
40305 <blockquote>
40306 <p>
40307 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
40308 ( [swappable]).</ins>
40309 </p>
40310
40311 <p><i>[
40312 This requirement is added to ensure that even a user defined <tt>swap</tt>
40313 which is found by ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt>
40314 requirements
40315 ]</i></p>
40316
40317
40318 <p>
40319 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40320 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
40321 of <tt>*this</tt> and <tt>x</tt>.</ins>
40322 </p>
40323
40324 <p>
40325 <ins><i>Complexity:</i> Constant time</ins>
40326 </p>
40327 </blockquote>
40328 </blockquote>
40329 </li>
40330 </ol>
40331 </li>
40332
40333 <li>
40334 <ol type="a">
40335 <li>
40336 <p>
40337 In 23.6.2 [multimap], class template <tt>multimap</tt> synopsis change as indicated:
40338 </p>
40339
40340 <blockquote><pre>void swap(multimap<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
40341 </pre></blockquote>
40342 </li>
40343
40344 <li>
40345 <p>
40346 At the end of 23.6.2.2 [multimap.modifiers] add as indicated:
40347 </p>
40348
40349 <blockquote><pre><ins>void swap(multimap&amp; x);</ins>
40350 </pre>
40351
40352 <blockquote>
40353 <p>
40354 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
40355 ( [swappable]).</ins>
40356 </p>
40357 <p>
40358 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40359 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
40360 of <tt>*this</tt> and <tt>x</tt>.</ins>
40361 </p>
40362 <p>
40363 <ins><i>Complexity:</i> Constant time</ins>
40364 </p>
40365 </blockquote>
40366 </blockquote>
40367 </li>
40368 </ol>
40369 </li>
40370
40371 <li>
40372 <ol type="a">
40373 <li>
40374 <p>
40375 In 23.6.3 [set], class template <tt>set</tt> synopsis change as indicated:
40376 </p>
40377
40378 <blockquote><pre>void swap(set<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
40379 </pre></blockquote>
40380 </li>
40381
40382 <li>
40383 <p>
40384 After section 23.6.3.1 [set.cons] add a new section <ins><tt>set</tt> modifiers
40385  [set.modifiers]</ins>
40386 and add the following paragraphs:
40387 </p>
40388
40389 <blockquote><pre><ins>void swap(set&amp; x);</ins>
40390 </pre>
40391
40392 <blockquote>
40393 <p>
40394 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
40395 ( [swappable]).</ins>
40396 </p>
40397
40398 <p>
40399 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40400 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
40401 of <tt>*this</tt> and <tt>x</tt>.</ins>
40402 </p>
40403
40404 <p>
40405 <ins>Complexity: Constant time</ins>
40406 </p>
40407 </blockquote>
40408 </blockquote>
40409 </li>
40410 </ol>
40411 </li>
40412
40413 <li>
40414 <ol type="a">
40415 <li>
40416 <p>
40417 In 23.6.4 [multiset], class template <tt>multiset</tt> synosis, change as indicated:
40418 </p>
40419
40420 <blockquote><pre>void swap(multiset<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
40421 </pre></blockquote>
40422 </li>
40423
40424 <li>
40425 <p>
40426 After section 23.6.4.1 [multiset.cons] add a new section <ins><tt>multiset</tt> modifiers
40427  [multiset.modifiers]</ins> and add the following paragraphs:
40428 </p>
40429
40430 <blockquote><pre><ins>void swap(multiset&amp; x);</ins>
40431 </pre>
40432
40433 <blockquote>
40434 <p>
40435 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
40436 ( [swappable]).</ins>
40437 </p>
40438
40439 <p>
40440 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
40441 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
40442 of <tt>*this</tt> and <tt>x</tt>.</ins>
40443 </p>
40444
40445 <p>
40446 <ins><i>Complexity:</i> Constant time</ins>
40447 </p>
40448 </blockquote>
40449 </blockquote>
40450 </li>
40451 </ol>
40452 </li>
40453
40454 <li>
40455 <p>
40456 Insert a new paragraph just before 23.7 [unord]/1:
40457 </p>
40458
40459 <blockquote>
40460 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
40461 the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
40462 headers <tt>&lt;unordered_map&gt;</tt> or <tt>&lt;unordered_set&gt;</tt> are included.</ins>
40463 </blockquote>
40464
40465 </li>
40466
40467 <li>
40468 <p>
40469 After section 23.7.1.2 [unord.map.elem] add a new section <ins>unordered_map
40470 modifiers  [unord.map.modifiers]</ins> and add the following paragraphs:
40471 </p>
40472
40473 <blockquote><pre><ins>void swap(unordered_map&amp; x);</ins>
40474 </pre>
40475
40476 <blockquote>
40477 <p>
40478 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
40479 ( [swappable]).</ins>
40480 </p>
40481
40482 <p><i>[
40483 This requirement is added to ensure that even a user defined <tt>swap</tt>
40484 which is found by ADL for <tt>Hash</tt> and <tt>Pred</tt> satisfies the <tt>Swappable</tt>
40485 requirements
40486 ]</i></p>
40487
40488
40489 <p>
40490 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
40491 allocators of <tt>*this</tt>
40492 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
40493 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt>.</ins>
40494 </p>
40495
40496 <p>
40497 <ins><i>Complexity:</i> Constant time</ins>
40498 </p>
40499 </blockquote>
40500 </blockquote>
40501 </li>
40502
40503 <li>
40504 <p>
40505 After section 23.7.2.1 [unord.multimap.cnstr] add a new section
40506 <ins>unordered_multimap
40507 modifiers  [unord.multimap.modifiers]</ins> and add the following paragraphs:
40508 </p>
40509
40510 <blockquote><pre><ins>void swap(unordered_multimap&amp; x);</ins>
40511 </pre>
40512
40513 <blockquote>
40514 <p>
40515 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
40516 ( [swappable]).</ins>
40517 </p>
40518
40519 <p>
40520 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
40521 allocators of <tt>*this</tt>
40522 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
40523 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
40524 </p>
40525 <p>
40526 <ins><i>Complexity:</i> Constant time</ins>
40527 </p>
40528 </blockquote>
40529 </blockquote>
40530 </li>
40531
40532 <li>
40533 <p>
40534 After section 23.7.3.1 [unord.set.cnstr] add a new section
40535 <ins>unordered_set modifiers
40536  [unord.set.modifiers]</ins> and add the following paragraphs:
40537 </p>
40538
40539 <blockquote><pre><ins>void swap(unordered_set&amp; x);</ins>
40540 </pre>
40541
40542 <blockquote>
40543 <p>
40544 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
40545 ( [swappable]).</ins>
40546 </p>
40547
40548 <p>
40549 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
40550 allocators of <tt>*this</tt>
40551 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
40552 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
40553 </p>
40554
40555 <p>
40556 <ins><i>Complexity:</i> Constant time</ins>
40557 </p>
40558 </blockquote>
40559 </blockquote>
40560 </li>
40561
40562 <li>
40563 <p>
40564 After section 23.7.4.1 [unord.multiset.cnstr] add a new section
40565 <ins>unordered_multiset
40566 modifiers  [unord.multiset.modifiers]</ins> and add the following paragraphs:
40567 </p>
40568
40569 <blockquote><pre><ins>void swap(unordered_multiset&amp; x);</ins>
40570 </pre>
40571
40572 <blockquote>
40573 <p>
40574 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
40575 ( [swappable]).</ins>
40576 </p>
40577
40578 <p>
40579 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
40580 allocators of <tt>*this</tt>
40581 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
40582 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
40583 </p>
40584 <p>
40585 <ins><i>Complexity:</i> Constant time</ins>
40586 </p>
40587 </blockquote>
40588 </blockquote>
40589 </li>
40590
40591 </ol>
40592
40593 </blockquote>
40594
40595 <p><i>[
40596 2009-10-30 Pablo and Daniel updated wording.
40597 ]</i></p>
40598
40599
40600 <p><i>[
40601 2010 Pittsburgh:  Ready for Pittsburgh.
40602 ]</i></p>
40603
40604
40605
40606
40607 <p><b>Proposed resolution:</b></p>
40608
40609 <p><i>[
40610 This resolution is based on the September 2009 WP,
40611 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>,
40612 except that it
40613 assumes that
40614 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
40615 and issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a> have already been applied.  Note in
40616 particular that Table 91 in
40617 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
40618 is refered to as Table 90 because
40619 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
40620 removed the old Table 90.  This resolution also addresses issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>.
40621 ]</i></p>
40622
40623 <p>
40624 In 23.2.1 [container.requirements.general], replace the a.swap(b) row in table 90,
40625 "container requirements" (was table 91 before the application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to the
40626 WP):
40627 </p>
40628 <blockquote>
40629 <table border="1">
40630   <tbody><tr>
40631     <td><code>a.swap(b)</code></td>
40632     <td><code>void</code></td>
40633     <td>&nbsp;&nbsp;&nbsp;</td>
40634     <td><code><del>swap(a,b)</del><ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></code></td>
40635     <td>(Note A)</td>
40636   </tr>
40637   <tr>
40638     <td><ins><code>swap(a,b)</code></ins></td>
40639     <td><ins><code>void</code></ins></td>
40640     <td><code>&nbsp;&nbsp;&nbsp;</code></td>
40641     <td><ins><code>a.swap(b)</code></ins></td>
40642     <td><ins>(Note A)</ins></td>
40643   </tr>
40644 </tbody></table>
40645 </blockquote>
40646 <p>
40647 Modify the notes immediately following Table 90 in
40648 23.2.1 [container.requirements.general] as follows (The wording below is after the
40649 application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>.  The editor might also want to combine Notes
40650 A and B into one.):
40651 </p>
40652 <blockquote><p>
40653 Notes: the algorithms<del> swap(),</del> equal() and lexicographical_compare()
40654 are defined in Clause 25.  Those entries marked "(Note A)" or "(Note B)"
40655 <del>should</del> have <ins>linear complexity for array and</ins> constant
40656 complexity <ins>for all other standard containers</ins>.
40657 </p></blockquote>
40658 <p>
40659 In 23.2.1 [container.requirements.general], before paragraph 8, add:
40660 </p>
40661 <blockquote><p><ins>
40662 The expression <code>a.swap(b)</code>, for containers <code>a</code>
40663 and <code>b</code> of a standard container type other than <code>array</code>,
40664 exchanges the values of <code>a</code> and <code>b</code> without invoking any
40665 move, copy, or swap operations on the individual container elements.
40666 Any <code>Compare</code>, <code>Pred</code>, or <code>Hash</code> function
40667 objects belonging to <code>a</code> and <code>b</code> shall be
40668 <code>swappable</code> and are exchanged by unqualified calls
40669 to non-member <code>swap</code>.  If
40670 <code>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value
40671 == true</code>, then the allocators of <code>a</code> and <code>b</code> are
40672 also exchanged using an unqualified call to non-member <code>swap</code>.
40673 Otherwise, the behavior is undefined unless <code>a.get_allocator() ==
40674 b.get_allocator()</code>.  Each iterator refering to an element in one
40675 container before the swap shall refer to the same element in the other
40676 container after the swap.  It is unspecified whether an iterator with
40677 value <code>a.end()</code> before the swap will have
40678 value <code>b.end()</code> after the swap.  In addition to being available via
40679 inclusion of the <code>&lt;utility&gt;</code> header, the <code>swap</code>
40680 function template in 25.3.3 [alg.swap] is also available within the definition of
40681 every standard container's <code>swap</code> function.
40682 </ins></p></blockquote>
40683 <p><i>[
40684 Note to the editor: Paragraph 2 starts with a sentence fragment,
40685 clearly from an editing or source-control error.
40686 ]</i></p>
40687
40688 <p>
40689 Modify 23.2.4.1 [associative.reqmts.except] as follows:
40690 </p>
40691 <blockquote>
40692 <p>
40693 <b>23.2.4.1 Exception safety guarantees 23.2.4.1 [associative.reqmts.except]</b>
40694 </p>
40695 <p>
40696 For associative containers, no <code>clear()</code> function throws an
40697 exception. <code>erase(k)</code> does not throw an exception unless that
40698 exception is thrown by the
40699 container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
40700 </p>
40701 <p>
40702 For associative containers, if an exception is thrown by any operation from
40703 within an <code>insert()</code> function inserting a single element,
40704 the <code>insert()</code> function has no effect.
40705 </p>
40706 <p>
40707 For associative containers, no <code>swap</code> function throws an exception
40708 unless that exception is thrown by the <del>copy constructor
40709 or copy assignment operator</del><ins>swap</ins> of the
40710 container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
40711 </p></blockquote>
40712 <p>
40713 Modify 23.2.5.1 [unord.req.except], paragraph 3 as follows:
40714 </p>
40715 <blockquote><p>
40716 For unordered associative containers, no <code>swap</code> function throws an
40717 exception unless that exception is thrown by the <del>copy constructor or copy
40718 assignment operator</del><ins>swap</ins> of the container's <code>Hash</code>
40719 or <code>Pred</code> object (if any).
40720 </p></blockquote>
40721 <p>
40722 Modify section 23.3.1.2 [array.special]:
40723 </p>
40724 <blockquote>
40725 <p>
40726 <b>array specialized algorithms 23.3.1.2 [array.special]</b>
40727 </p>
40728 <p>
40729 <code>template &lt;class T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x,array&lt;T,N&gt;&amp; y);</code>
40730 </p>
40731 <blockquote>
40732 <p>
40733 <i>Effects:</i> <code><del>swap_ranges(x.begin(), x.end(), y.begin() );</del><ins>x.swap(y);</ins></code>
40734 </p>
40735 </blockquote>
40736 </blockquote>
40737 <p>
40738 Add a new section after 23.3.1.5 [array.fill] (Note to the editor: array::fill make use
40739 of a concept requirement that must be removed or changed to text.):
40740 </p>
40741 <blockquote>
40742 <p>
40743 <ins><b>array::swap [array.swap]</b></ins>
40744 </p>
40745 <p>
40746 <ins><code>void swap(array&amp; y);</code></ins>
40747 </p>
40748 <blockquote>
40749 <p><ins>
40750 <i>Effects:</i> <code>swap_ranges(this-&gt;begin(), this-&gt;end(), y.begin() );</code>
40751 </ins></p>
40752 <p><ins>
40753 <i>Throws:</i> Nothing unless one of the element-wise swap calls throws an
40754 exception.
40755 </ins></p>
40756 <p><ins>
40757 [<i>Note</i>: Unlike other containers' <code>swap</code> functions,
40758 <code>array::swap</code> takes linear, not constant, time, may exit via an
40759 exception, and does not cause iterators to become associated with the other
40760 container. \97 <i>end note</i>]
40761 </ins></p>
40762 </blockquote>
40763 </blockquote>
40764
40765 <p>
40766 Insert a new paragraph just after 23.5 [container.adaptors]/1:
40767 </p>
40768 <blockquote><p><ins>
40769 For container adaptors, no <code>swap</code> function throws an exception
40770 unless that exception is thrown by the swap of the
40771 adaptor's <code>Container</code> or <code>Compare</code> object (if any).
40772 </ins></p></blockquote>
40773
40774
40775
40776
40777
40778
40779
40780
40781
40782
40783
40784
40785 <hr>
40786 <h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
40787 <p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
40788  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-16 <b>Last modified:</b> 2010-10-29</p>
40789 <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>
40790 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
40791 <p><b>Discussion:</b></p>
40792 <p>
40793 The tuple element access API identifies the element in the sequence
40794 using signed integers, and then goes on to enforce the requirement that
40795 I be &gt;= 0.  There is a much easier way to do this - declare I as
40796 <tt>unsigned</tt>.
40797 </p>
40798 <p>
40799 In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
40800 </p>
40801 <p>
40802 A second suggestion is that it is hard to imagine an API that deduces
40803 and index at compile time and returns a reference throwing an exception.
40804 Add a specific <em>Throws:</em> Nothing paragraph to each element
40805 access API.
40806 </p>
40807 <p>
40808 In addition to <code>tuple</code>, update the API applies to
40809 <code>pair</code> and <code>array</code>, and should be updated
40810 accordingly.
40811 </p>
40812
40813 <p>
40814 A third observation is that the return type of the <code>get</code>
40815 functions for <code>std::pair</code> is pseudo-code, but it is not
40816 clearly marked as such.  There is actually no need for pseudo-code as
40817 the return type can be specified precisely with a call to
40818 <code>tuple_element</code>.  This is already done for
40819 <code>std::tuple</code>, and <code>std::array</code> does not have a
40820 problem as all elements are of type <code>T</code>.
40821 </p>
40822
40823
40824 <p><b>Proposed resolution:</b></p>
40825 <p>
40826 Update header &lt;utility&gt; synopsis in 20.3 [utility]
40827 </p>
40828 <pre><em>// 20.2.3, tuple-like access to pair:</em>
40829 template &lt;class T&gt; class tuple_size;
40830 template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
40831
40832 template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
40833 template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
40834 template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
40835
40836 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
40837   <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
40838 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
40839   const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
40840 </pre>
40841 <p>
40842 Update <strong>20.3.5 [pairs] Pairs</strong>
40843 </p>
40844 <pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
40845   <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
40846 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
40847   const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
40848 </pre>
40849 <p>
40850 <del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
40851 </p>
40852 <p>
40853 25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
40854 </p>
40855 <p>
40856 <ins><em>Throws:</em> Nothing.</ins>
40857 </p>
40858
40859
40860 <p>
40861 Update header &lt;tuple&gt; synopsis in 20.4 [tuple] with a APIs as below:
40862 </p>
40863 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
40864 template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
40865
40866 <em>// 20.3.1.4, element access:</em>
40867 template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
40868   typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
40869 template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
40870   typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
40871 </pre>
40872
40873 <p>
40874 Update <strong>20.4.2.5 [tuple.helper] Tuple helper classes</strong>
40875 </p>
40876 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
40877 class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
40878 public:
40879   typedef TI type;
40880 };</pre>
40881 <p>
40882 1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
40883 </p>
40884 <p>
40885 2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
40886 </p>
40887 <p>
40888 Update <strong>20.4.2.6 [tuple.elem] Element access</strong>
40889 </p>
40890 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
40891 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
40892 </pre>
40893 1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
40894 <p>
40895 2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
40896 </p>
40897 <ins><em>Throws:</em> Nothing.</ins>
40898 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
40899 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
40900 </pre>
40901 <p>
40902 3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
40903 </p>
40904 <p>
40905 4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
40906 </p>
40907 <p>
40908 <ins><em>Throws:</em> Nothing.</ins>
40909 </p>
40910
40911
40912 <p>
40913 Update header &lt;array&gt; synopsis in 20.3 [utility]
40914 </p>
40915 <pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
40916 template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
40917 template &lt;class T, size_t N&gt;
40918   struct tuple_size&lt;array&lt;T, N&gt; &gt;;
40919 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
40920   struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
40921 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
40922   T&amp; get(array&lt;T, N&gt;&amp;);
40923 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
40924   const T&amp; get(const array&lt;T, N&gt;&amp;);
40925 </pre>
40926
40927 <p>
40928 Update <strong>23.3.1.8 [array.tuple] Tuple interface to class template array</strong>
40929 </p>
40930 <pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
40931 </pre>
40932 <p>
40933 3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
40934 </p>
40935 <p>
40936 4 <em>Value:</em> The type <code>T</code>.
40937 </p>
40938 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
40939 </pre>
40940 <p>
40941 5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
40942 </p>
40943 <p>
40944 <em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
40945 </p>
40946 <p>
40947 <ins><em>Throws:</em> Nothing.</ins>
40948 </p>
40949 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
40950 </pre>
40951 <p>
40952 6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
40953 </p>
40954 <p>
40955 7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
40956 </p>
40957 <p>
40958 <ins><em>Throws:</em> Nothing.</ins>
40959 </p>
40960
40961
40962 <p><i>[
40963 Bellevue: Note also that the phrase "The program is ill-formed if I is
40964 out of bounds" in the requires clauses are probably unnecessary, and
40965 could be removed at the editor's discretion. Also std:: qualification
40966 for pair is also unnecessary.
40967 ]</i></p>
40968
40969
40970
40971
40972 <hr>
40973 <h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
40974 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
40975  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-20 <b>Last modified:</b> 2010-10-29</p>
40976 <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>
40977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
40978 <p><b>Discussion:</b></p>
40979 <p>
40980 The class template array synopsis in 23.3.1 [array]/3 declares a member
40981 function
40982 </p>
40983
40984 <blockquote><pre>void assign(const T&amp; u);
40985 </pre></blockquote>
40986
40987 <p>
40988 which's semantic is no-where described. Since this signature is
40989 not part of the container requirements, such a semantic cannot
40990 be derived by those.
40991 </p>
40992
40993 <p>
40994 I found only one reference to this function in the issue list,
40995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a> where the question is raised:
40996 </p>
40997
40998 <blockquote>
40999 what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
41000 </blockquote>
41001
41002 <p>
41003 which does not answer the basic question of this issue.
41004 </p>
41005
41006 <p>
41007 If this function shall be part of the <tt>std::array</tt>, it's probable
41008 semantic should correspond to that of <tt>boost::array</tt>, but of
41009 course such wording must be added.
41010 </p>
41011
41012
41013 <p><b>Proposed resolution:</b></p>
41014 <p>
41015 Just after the section 23.3.1.4 [array.data] add the following new section:
41016 </p>
41017
41018 <p>
41019 23.2.1.5 array::fill [array.fill]
41020 </p>
41021
41022 <blockquote>
41023 <pre>void fill(const T&amp; u);
41024 </pre>
41025
41026 <p>
41027 1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
41028 </p>
41029 </blockquote>
41030
41031 <p>
41032 [N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
41033 section. If it had, then <tt>assign</tt> would naturally belong to it]
41034 </p>
41035
41036 <p>
41037 Change the synopsis in 23.3.1 [array]/3:
41038 </p>
41039
41040 <blockquote><pre>template &lt;class T, size_t N&gt;
41041 struct array { 
41042   ...
41043   void <del>assign</del> <ins>fill</ins>(const T&amp; u);
41044   ...
41045 </pre></blockquote>
41046
41047
41048 <p><i>[
41049 Bellevue:
41050 ]</i></p>
41051
41052
41053 <blockquote>
41054 <p>
41055 Suggest substituting "fill" instead of "assign".
41056 </p>
41057 <p>
41058 Set state to Review given substitution of "fill" for "assign".
41059 </p>
41060 </blockquote>
41061
41062
41063
41064
41065 <hr>
41066 <h3><a name="777"></a>777. Atomics Library Issue</h3>
41067 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41068  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-01-21 <b>Last modified:</b> 2010-10-29</p>
41069 <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>
41070 <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>
41071 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41072 <p><b>Discussion:</b></p>
41073 <p>
41074 The load functions are defined as
41075 </p>
41076
41077 <blockquote><pre>C atomic_load(volatile A* object);
41078 C atomic_load_explicit(volatile A* object, memory_order);
41079 C A::load(memory_order order = memory_order_seq_cst) volatile;
41080 </pre></blockquote>
41081
41082 <p>
41083 which prevents their use in <tt>const</tt> contexts.
41084 </p>
41085
41086 <p><i>[
41087 post Bellevue Peter adds:
41088 ]</i></p>
41089
41090
41091 <blockquote>
41092 <p>
41093 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
41094 subtle point here. Atomic loads do not generally write to the object, except
41095 potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
41096 architecture, a dummy write with the same value may be required to be issued
41097 by the atomic load to maintain sequential consistency. This, in turn, may
41098 make the following code:
41099 </p>
41100
41101 <blockquote><pre>const atomic_int x{};
41102
41103 int main()
41104 {
41105   x.load();
41106 }
41107 </pre></blockquote>
41108
41109 <p>
41110 dump core under a straightforward implementation that puts const objects in
41111 a read-only section.
41112 </p>
41113 <p>
41114 There are ways to sidestep the problem, but it needs to be considered.
41115 </p>
41116 <p>
41117 The tradeoff is between making the data member of the atomic types
41118 mutable and requiring the user to explicitly mark atomic members as
41119 mutable, as is already the case with mutexes.
41120 </p>
41121 </blockquote>
41122
41123
41124
41125 <p><b>Proposed resolution:</b></p>
41126 <p>
41127 Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
41128 </p>
41129
41130 <blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
41131 C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
41132 C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
41133 </pre></blockquote>
41134
41135
41136
41137
41138
41139
41140 <hr>
41141 <h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
41142 <p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41143  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-01-24 <b>Last modified:</b> 2010-10-29</p>
41144 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
41145 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41146 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
41147 <p><b>Discussion:</b></p>
41148 <p>
41149 A small issue with <tt>std::bitset</tt>: it does not have any constructor
41150 taking a string literal, which is clumsy and looks like an oversigt when
41151 we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
41152 </p>
41153
41154 <p>
41155 Suggestion: Add
41156 </p>
41157
41158 <blockquote><pre>explicit bitset( const char* str );
41159 </pre></blockquote>
41160
41161 <p>
41162 to std::bitset.
41163 </p>
41164
41165
41166 <p><b>Proposed resolution:</b></p>
41167 <p>
41168 Add to synopsis in 20.5 [template.bitset]
41169 </p>
41170
41171 <blockquote><pre>explicit bitset( const char* str );
41172 </pre></blockquote>
41173
41174 <p>
41175 Add to synopsis in 20.5.1 [bitset.cons]
41176 </p>
41177
41178 <blockquote><pre>explicit bitset( const char* str );
41179 </pre>
41180 <p>
41181 <i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
41182 </p>
41183 </blockquote>
41184
41185
41186
41187
41188
41189
41190 <hr>
41191 <h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
41192 <p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41193  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2010-10-29</p>
41194 <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>
41195 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41196 <p><b>Discussion:</b></p>
41197 <p>
41198 The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
41199 <tt>remove_copy[_if]</tt>,
41200 which seems to be an oversight.
41201 </p>
41202
41203
41204 <p><b>Proposed resolution:</b></p>
41205 <p>
41206 In 25.3.8 [alg.remove]/p.6, replace the N2461 requires clause with:
41207 </p>
41208
41209 <blockquote>
41210 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
41211 and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
41212 valid.</ins>
41213 </blockquote>
41214
41215
41216
41217
41218
41219
41220 <hr>
41221 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
41222 <p><b>Section:</b> 25.4.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
41223  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2010-10-29</p>
41224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41225 <p><b>Discussion:</b></p>
41226 <p>
41227 Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
41228 </p>
41229
41230 <p>
41231 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.4.4 [alg.merge] in N2461
41232 have no Requires element and the Effects element contains some requirements,
41233 which is probably editorial. Worse is that:
41234 </p>
41235
41236 <ul>
41237 <li>
41238 no assignment requirements are specified (neither implicit nor explicit).
41239 </li>
41240
41241 <li>
41242 the effects clause just speaks of "merges", which is badly worded
41243 near to a circular definition.
41244 </li>
41245
41246 <li>
41247 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
41248 function arguments or otherwise.
41249 </li>
41250
41251 <li>
41252 p. 2 says "according to the ordering defined by comp" which is both
41253 incomplete (because
41254 this excludes the first variant with &lt;) and redundant (because the
41255 following subordinate
41256 clause mentions comp again)
41257 </li>
41258 </ul>
41259
41260 <p><i>[
41261 Post Summit Alisdair adds:
41262 ]</i></p>
41263
41264
41265 <blockquote>
41266 <p>
41267 Suggest:
41268 </p>
41269 <blockquote>
41270 (where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
41271 distance(first2, last2))</tt>, such that resulting range will be sorted in
41272 non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
41273 than <tt>result</tt>, the condition <tt>*i &lt; *prev(i)</tt> or, respectively, <tt>comp(*i,
41274 *prev(i))</tt> will be <tt>false</tt>.
41275 </blockquote>
41276
41277 <p>
41278 Note that this might still not be technically accurate in the case of
41279 <tt>InputIterators</tt>, depending on other resolutions working their way through the
41280 system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>).
41281 </p>
41282 </blockquote>
41283
41284 <p><i>[
41285 Post Summit Daniel adds:
41286 ]</i></p>
41287
41288
41289 <blockquote>
41290 If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
41291 is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
41292 25 [algorithms]/6, but I can currently not propose any good wording for this.
41293 </blockquote>
41294
41295 <p><i>[
41296 Batavia (2009-05):
41297 ]</i></p>
41298
41299 <blockquote>
41300 <p>
41301 Pete points out the existing wording in [algorithms]/4
41302 that permits the use of + in algorithm specifications.
41303 </p>
41304 <p>
41305 Alisdair points out that that wording may not apply to input iterators.
41306 </p>
41307 <p>
41308 Move to Review.
41309 </p>
41310 </blockquote>
41311
41312 <p><i>[
41313 2009-07 Frankfurt:
41314 ]</i></p>
41315
41316
41317 <blockquote>
41318 Move to Ready.
41319 </blockquote>
41320
41321 <p><i>[
41322 2009-08-23 Daniel reopens:
41323 ]</i></p>
41324
41325
41326 <blockquote>
41327 <p>
41328 The proposed wording must be rephrased, because the part
41329 </p>
41330
41331 <blockquote>
41332 for every iterator <tt>i</tt> in <tt>[result,last)</tt> other than <tt>result</tt>, the condition
41333 <tt>*i &lt; *(i - 1)</tt> or, respectively, <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>"
41334 </blockquote>
41335
41336 <p>
41337 isn't meaningful, because the range <tt>[result,last)</tt> is that of a pure
41338 <tt>OutputIterator</tt>, which is not <em>readable</em> in general.
41339 </p>
41340
41341 <p><i>[Howard:  Proposed wording updated by Daniel, status moved from Ready to Review.]</i></p>
41342
41343 </blockquote>
41344
41345 <p><i>[
41346 2009-10 Santa Cruz:
41347 ]</i></p>
41348
41349
41350 <blockquote>
41351 <p>
41352 Matt has some different words to propose.  Those words have been moved into
41353 the proposed wording section, and the original proposed wording now appears
41354 here:
41355 </p>
41356 <blockquote>
41357 <p>
41358 In 25.4.4 [alg.merge] replace p.1+ 2:
41359 </p>
41360
41361 <blockquote>
41362 <p>
41363 <i>Effects:</i> <del>Merges</del><ins>Copies all the elements of the</ins>
41364 two sorted ranges
41365 <tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range <tt>[result,result +
41366 (last1 - first1) + (last2 - first2))</tt>
41367 <ins>, such that resulting range will be sorted in non-decreasing
41368 order; that is for every
41369 pair of iterators <tt>i</tt> and <tt>j</tt> of either input ranges, where <tt>*i</tt> was copied
41370 to the output range
41371 before <tt>*j</tt> was copied to the output range, the condition <tt>*j &lt; *i</tt> or,
41372 respectively, <tt>comp(*j, *i)</tt>
41373 will be <tt>false</tt>.</ins>
41374 </p>
41375
41376 <p>
41377 <ins><i>Requires:</i></ins>The resulting range shall not overlap with either
41378 of the original ranges.
41379 <del>The list will be sorted in non-decreasing order according to the
41380 ordering defined by
41381 <tt>comp</tt>; that is, for every iterator <tt>i</tt> in <tt>[first,last)</tt> other than <tt>first</tt>,
41382 the condition <tt>*i &lt; *(i - 1)</tt> or
41383 <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
41384 </p>
41385 </blockquote>
41386 </blockquote>
41387 </blockquote>
41388
41389 <p><i>[
41390 2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
41391 ]</i></p>
41392
41393
41394
41395
41396 <p><b>Proposed resolution:</b></p>
41397
41398 <p>
41399 Change 25.4.4 [alg.merge] 1 and 2:
41400 </p>
41401
41402 <blockquote>
41403 <p>1 <del>
41404 <i>Effects:</i> Merges two sorted ranges <tt>[first1,last1)</tt> and
41405 <tt>[first2,last2)</tt> into the range <tt>[result, result + (last1 -
41406 first1) + (last2 - first2))</tt>.
41407 </del></p>
41408 <p><ins>
41409 <i>Effects:</i> Copies all the elements of the two ranges
41410 <tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range
41411 <tt>[result, result_last)</tt>, where <tt>result_last</tt> is <tt>result
41412 + (last1 - first1) + (last2 - first2)</tt>, such that the resulting
41413 range satisfies <tt>is_sorted(result, result_last)</tt> or
41414 <tt>is_sorted(result, result_last, comp)</tt>, respectively.
41415 </ins></p>
41416
41417 <p>
41418 2 <ins><i>Requires:</i></ins> <ins>The ranges <tt>[first1,last1)</tt> and
41419 <tt>[first2,last2)</tt> shall be sorted with respect to <tt>operator&lt;</tt> or
41420 <tt>comp</tt>.</ins> The resulting range shall not overlap with either of the
41421 original ranges.  <del>The list will be sorted in non-decreasing order according
41422 to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt>
41423 in <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt;
41424 *(i - 1)</tt> or <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
41425 </p>
41426
41427 </blockquote>
41428
41429 <p>
41430 Change 25.4.4 [alg.merge]/6+7 as indicated <i>[This ensures harmonization
41431 between <tt>inplace_merge</tt> and <tt>merge</tt>]</i>
41432 </p>
41433
41434 <blockquote>
41435 <p>
41436 6 <i>Effects:</i> Merges two <del>sorted</del> consecutive ranges
41437 <tt>[first,middle)</tt> and <tt>[middle,last)</tt>, putting the result of the
41438 merge into the range <tt>[first,last)</tt>. The resulting range will be in
41439 non-decreasing order; that is, for every iterator <tt>i</tt> in
41440 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i -
41441 1)</tt> or, respectively, <tt>comp(*i, *(i - 1))</tt> will be false.
41442 </p>
41443
41444 <p>
41445 7 <i>Requires:</i> <ins>The ranges <tt>[first,middle)</tt> and
41446 <tt>[middle,last)</tt> shall be sorted with respect to <tt>operator&lt;</tt> or
41447 <tt>comp</tt>.</ins> The type of <tt>*first</tt> shall satisfy the
41448 <tt>Swappable</tt> requirements (37), the <tt>MoveConstructible</tt>
41449 requirements (Table 33), and the the <tt>MoveAssignable</tt> requirements (Table
41450 35).
41451 </p>
41452 </blockquote>
41453
41454
41455
41456
41457
41458
41459 <hr>
41460 <h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
41461 <p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41462  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-26 <b>Last modified:</b> 2010-10-29</p>
41463 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
41464 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41465 <p><b>Discussion:</b></p>
41466 <p>
41467 A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
41468 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
41469 some complex functions that are missing in C++. These are:
41470 </p>
41471
41472 <ol>
41473 <li>
41474 7.3.9.4: (required elements of the C99 library)<br>
41475 The <tt>cproj</tt> functions
41476 </li>
41477 <li>
41478 7.26.1: (optional elements of the C99 library)<br>
41479 <pre>cerf    cerfc    cexp2
41480 cexpm1  clog10   clog1p
41481 clog2   clgamma  ctgamma
41482 </pre>
41483 </li>
41484 </ol>
41485
41486 <p>
41487 I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
41488 C++ functions. This addition is easy to do in one sentence (delegation to C99
41489 function).
41490 </p>
41491
41492 <p>
41493 Please note also that the current entry <tt>polar</tt>
41494 in 26.4.9 [cmplx.over]/1
41495 should be removed from the mentioned overload list. It does not make sense to require that a
41496 function already expecting <em>scalar</em> arguments
41497 should cast these arguments into corresponding
41498 <tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
41499 this function.
41500 </p>
41501
41502
41503 <p><b>Proposed resolution:</b></p>
41504 <p>
41505 In 26.4.1 [complex.syn] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
41506 </p>
41507
41508 <blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
41509 <ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
41510 template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
41511 </pre></blockquote>
41512
41513 <p>
41514 In 26.4.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
41515 </p>
41516
41517 <blockquote>
41518 <pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
41519 </pre>
41520 <blockquote>
41521
41522 <i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
41523 subclause 7.3.9.4."
41524 </blockquote>
41525 </blockquote>
41526
41527 <p>
41528 In 26.4.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
41529 the overload list.
41530 </p>
41531
41532 <blockquote>
41533 <p>
41534 The following function templates shall have additional overloads:
41535 </p>
41536 <blockquote><pre>arg           norm 
41537 conj          <del>polar</del> <ins>proj</ins>
41538 imag          real
41539 </pre></blockquote>
41540 </blockquote>
41541
41542
41543
41544
41545
41546
41547 <hr>
41548 <h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
41549 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41550  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-27 <b>Last modified:</b> 2010-10-29</p>
41551 <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>
41552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41553 <p><b>Discussion:</b></p>
41554 <p>
41555 Part of the resolution of n2423, issue 8 was the proposal to
41556 extend the <tt>seed_seq</tt> constructor accepting an input range
41557 as follows (which is now part of N2461):
41558 </p>
41559
41560 <blockquote><pre>template&lt;class InputIterator,
41561 size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
41562 seed_seq(InputIterator begin, InputIterator end);
41563 </pre></blockquote>
41564
41565 <p>
41566 First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
41567 is invalid due to missing <tt>typename</tt> keyword, which is easy to
41568 fix.
41569 </p>
41570
41571 <p>
41572 Second (and worse), while the language now supports default
41573 template arguments of function templates, this customization
41574 point via the second <tt>size_t</tt> template parameter is of no advantage,
41575 because <tt>u</tt> can never be deduced, and worse - because it is a
41576 constructor function template - it can also never be explicitly
41577 provided (14.8.1 [temp.arg.explicit]/7).
41578 </p>
41579
41580 <p>
41581 The question arises, which advantages result from a compile-time
41582 knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
41583 suffices, this parameter should be provided as normal function
41584 default argument [Resolution marked (A)], if compile-time knowledge
41585 is important, this could be done via a tagging template or more
41586 user-friendly via a standardized helper generator function
41587 (<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
41588 </p>
41589
41590 <p><i>[
41591 Bellevue:
41592 ]</i></p>
41593
41594
41595 <blockquote>
41596 <p>
41597 Fermilab does not have a strong opinion. Would prefer to go with
41598 solution A. Bill agrees that solution A is a lot simpler and does the
41599 job.
41600 </p>
41601 <p>
41602 Proposed Resolution: Accept Solution A.
41603 </p>
41604 </blockquote>
41605
41606 <p>
41607 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> claims to make this issue moot.
41608 </p>
41609
41610
41611
41612 <p><b>Proposed resolution:</b></p>
41613 <ol type="A">
41614 <li>
41615 <p>
41616 In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
41617 </p>
41618
41619 <blockquote><pre>class seed_seq 
41620
41621 public:
41622    ...
41623    template&lt;class InputIterator<del>,
41624       size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
41625           seed_seq(InputIterator begin, InputIterator end<ins>,
41626           size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
41627    ...
41628 };
41629 </pre></blockquote>
41630
41631 <p>
41632 and do a similar replacement in the member description between
41633 p.3 and p.4.
41634 </p>
41635 </li>
41636
41637 <li>
41638 <p>
41639 In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
41640 member description between p.3 and p.4 replace:
41641 </p>
41642
41643 <blockquote><pre>template&lt;class InputIterator<del>,
41644   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
41645       seed_seq(InputIterator begin, InputIterator end);
41646 <ins>template&lt;class InputIterator, size_t u&gt;
41647 seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
41648 </pre></blockquote>
41649
41650 <p>
41651 In 26.5.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
41652 class <tt>seed_seq</tt> declaration <em>and</em> in 26.5.7.1 [rand.util.seedseq]/2, immediately
41653 after the class <tt>seed_seq</tt> definition add:
41654 </p>
41655
41656 <blockquote><pre>template&lt;size_t u, class InputIterator&gt;
41657   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
41658 </pre></blockquote>
41659
41660 <p>
41661 In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
41662 </p>
41663
41664 <blockquote>
41665 <p>
41666 The first constructor behaves as if it would provide an
41667 integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
41668 <tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
41669 </p>
41670 <p>
41671 The second constructor uses an implementation-defined mechanism
41672 to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
41673 is called by the function <tt>make_seed_seq</tt>.
41674 </p>
41675 </blockquote>
41676
41677 <p>
41678 In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add:
41679 </p>
41680
41681 <blockquote>
41682 <pre>template&lt;size_t u, class InputIterator&gt;
41683    seed_seq make_seed_seq(InputIterator begin, InputIterator end);
41684 </pre>
41685 <blockquote>
41686 <p>
41687 where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
41688 </p>
41689 <p>
41690 <i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
41691 </p>
41692 </blockquote>
41693 </blockquote>
41694
41695 </li>
41696 </ol>
41697
41698
41699
41700
41701
41702
41703 <hr>
41704 <h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
41705 <p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41706  <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-02-01 <b>Last modified:</b> 2010-10-29</p>
41707 <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>
41708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41709 <p><b>Discussion:</b></p>
41710 <p>
41711 The current working paper 
41712 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
41713 integrated just before Bellevue) is
41714 not completely clear whether a given <tt>thread::id</tt> value may be reused once
41715 a thread has exited and has been joined or detached.  Posix allows
41716 thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
41717 not completely clear whether this originally was the right decision, it
41718 is clearly the established practice, and we believe it was always the
41719 intent of the C++ threads API to follow Posix and allow this.  Howard
41720 Hinnant's example implementation implicitly relies on allowing reuse
41721 of ids, since it uses Posix thread ids directly.
41722 </p>
41723
41724 <p>
41725 It is important to be clear on this point, since it the reuse of thread
41726 ids often requires extra care in client code, which would not be
41727 necessary if thread ids were unique across all time.  For example, a
41728 hash table indexed by thread id may have to be careful not to associate
41729 data values from an old thread with a new one that happens to reuse the
41730 id.  Simply removing the old entry after joining a thread may not be
41731 sufficient, if it creates a visible window between the join and removal
41732 during which a new thread with the same id could have been created and
41733 added to the table.
41734 </p>
41735
41736 <p><i>[
41737 post Bellevue Peter adds:
41738 ]</i></p>
41739
41740
41741 <blockquote>
41742 <p>
41743 There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
41744 reconsider fixing this by disallowing reuse, rather than explicitly allowing
41745 it. Dealing with thread id reuse is an incredibly painful exercise that
41746 would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
41747 and over.
41748 </p>
41749 <p>
41750 In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
41751 atomically in a lock-free manner, as motivated by the recursive lock
41752 example:
41753 </p>
41754
41755 <p>
41756 <a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
41757 </p>
41758 </blockquote>
41759
41760
41761
41762 <p><b>Proposed resolution:</b></p>
41763 <p>
41764 Add a sentence to 30.3.1.1 [thread.thread.id]/p1:
41765 </p>
41766
41767 <blockquote>
41768 <p>
41769 An object of type <code>thread::id</code> provides
41770 a unique identifier for each thread of execution
41771 and a single distinct value for all thread objects
41772 that do not represent a thread of execution ([thread.threads.class]).
41773 Each thread of execution has a <code>thread::id</code>
41774 that is not equal to the <code>thread::id</code>
41775 of other threads of execution
41776 and that is not equal to
41777 the <code>thread::id</code> of <code>std::thread</code> objects
41778 that do not represent threads of execution.
41779 <ins>The library may reuse the value of a <code>thread::id</code> of a
41780 terminated thread that can no longer be joined.</ins>
41781 </p>
41782 </blockquote>
41783
41784
41785
41786
41787
41788 <hr>
41789 <h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
41790 <p><b>Section:</b> 20.11 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
41791  <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Opened:</b> 2008-02-03 <b>Last modified:</b> 2010-11-19</p>
41792 <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>
41793 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
41794 <p><b>Discussion:</b></p>
41795 <p>
41796 The draft C++0x thread library requires that the time points of type
41797 <tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
41798 Universal Time (UTC) (section  [datetime.system]). This can lead to
41799 surprising behavior when a library user performs a duration-based wait,
41800 such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
41801 problem may be found in the
41802 <a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
41803 section in POSIX, but in summary:
41804 </p>
41805
41806 <ul>
41807 <li>
41808 Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
41809 equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
41810 to address the problem of spurious wakeups.
41811 </li>
41812
41813 <li>
41814 The typical use of the timed wait operations is to perform a relative
41815 wait. This may be achieved by first calculating an absolute time as the
41816 sum of the current time and the desired duration. In fact, the C++0x
41817 thread library includes duration-based overloads of
41818 <tt>condition_variable::timed_wait()</tt> that behave as if by calling the
41819 corresponding absolute time overload with a time point value of
41820 <tt>get_system_time() + rel_time</tt>.
41821 </li>
41822
41823 <li>
41824 A UTC clock may be affected by changes to the system time, such as
41825 synchronization with an external source, leap seconds, or manual changes
41826 to the clock.
41827 </li>
41828
41829 <li>
41830 Should the clock change during a timed wait operation, the actual
41831 duration of the wait will not be the expected length. For example, a
41832 user may intend a timed wait of one second duration but, due to an
41833 adjustment of the system clock backwards by a minute, the wait instead
41834 takes 61 seconds.
41835 </li>
41836 </ul>
41837
41838 <p>
41839 POSIX solves the problem by introducing a new monotonic clock, which is
41840 unaffected by changes to the system time. When a condition variable is
41841 initialized, the user may specify whether the monotonic clock is to be
41842 used. (It is worth noting that on POSIX systems it is not possible to
41843 use <tt>condition_variable::native_handle()</tt> to access this facility, since
41844 the desired clock type must be specified during construction of the
41845 condition variable object.)
41846 </p>
41847
41848 <p>
41849 In the context of the C++0x thread library, there are added dimensions
41850 to the problem due to the need to support platforms other than POSIX:
41851 </p>
41852
41853 <ul>
41854 <li>
41855 Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
41856 </li>
41857
41858 <li>
41859 Some environments do not have a monotonic clock, but do have a UTC clock.
41860 </li>
41861
41862 <li>
41863 The Microsoft Windows API's synchronization functions use relative
41864 timeouts based on an implied monotonic clock. A program that switches
41865 from the Windows API to the C++0x thread library will now find itself
41866 susceptible to clock changes.
41867 </li>
41868 </ul>
41869
41870 <p>
41871 One possible minimal solution:
41872 </p>
41873
41874 <ul>
41875 <li>
41876 Strike normative references to UTC and an epoch based on 1970-01-01.
41877 </li>
41878
41879 <li>
41880 Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
41881 implementation-defined (i.e standard library implementors may choose the
41882 appropriate underlying clock based on the capabilities of the target
41883 platform).
41884 </li>
41885
41886 <li>
41887 Add a non-normative note encouraging use of a monotonic clock.
41888 </li>
41889
41890 <li>
41891 Remove <tt>system_time::seconds_since_epoch()</tt>.
41892 </li>
41893
41894 <li>
41895 Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
41896 = 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
41897 </li>
41898 </ul>
41899
41900
41901
41902 <p><b>Proposed resolution:</b></p>
41903 <p>
41904 </p>
41905
41906
41907 <p><b>Rationale:</b></p>
41908 Addressed by
41909 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
41910
41911
41912
41913
41914
41915 <hr>
41916 <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
41917 <p><b>Section:</b> 25.4.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
41918  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-09-08 <b>Last modified:</b> 2010-10-29</p>
41919 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
41920 <p><b>Discussion:</b></p>
41921 <p>
41922 In 25.4.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
41923 </p>
41924
41925 <blockquote>
41926 At most <tt>log(last - first) + 2</tt> comparisons.
41927 </blockquote>
41928
41929 <p>
41930 This should be precised and brought in line with the nomenclature used for
41931 <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
41932 </p>
41933
41934 <p>
41935 All existing libraries I'm aware of, delegate to
41936 <tt>lower_bound</tt> (+ one further comparison). Since
41937 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
41938 has now WP status, the resolution of #787 should
41939 be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
41940 to <tt>+ O(1)</tt>.
41941 </p>
41942
41943 <p><i>[
41944 Sophia Antipolis:
41945 ]</i></p>
41946
41947
41948 <blockquote>
41949 Alisdair prefers to apply an upper bound instead of O(1), but that would
41950 require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
41951 cares about it, he'll send an issue to Howard.
41952 </blockquote>
41953
41954
41955
41956 <p><b>Proposed resolution:</b></p>
41957 <p>
41958 Change 25.4.3.4 [binary.search]/3
41959 </p>
41960
41961 <blockquote>
41962 <i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
41963 </blockquote>
41964
41965
41966
41967
41968
41969 <hr>
41970 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
41971 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
41972  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06 <b>Last modified:</b> 2010-10-29</p>
41973 <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>
41974 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41975 <p><b>Discussion:</b></p>
41976
41977 <p><b>Addresses UK 287</b></p>
41978
41979 <blockquote>
41980 <p>
41981 It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
41982 _value_ initialized by reading the stream, or default/value initialized? If
41983 it is initialized by reading the stream, what happens if the initialization
41984 is deferred until first dereference, when ideally the iterator value should
41985 have been that of an end-of-stream iterator which is not safely
41986 dereferencable?
41987 </p>
41988
41989 <p>
41990 Recommendation: Specify _value_ is initialized by reading the stream, or
41991 the iterator takes on the end-of-stream value if the stream is empty.
41992 </p>
41993 </blockquote>
41994
41995 <p>
41996 The description of how an istream_iterator object becomes an
41997 end-of-stream iterator is a) ambiguous and b) out of date WRT
41998 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
41999 </p>
42000
42001 <blockquote>
42002 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
42003 input stream for which it was constructed. After it is constructed, and
42004 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
42005 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
42006 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
42007 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
42008 an end of stream input iterator object, which is the only legitimate
42009 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
42010 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
42011 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
42012 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
42013 store things into istream iterators. The main peculiarity of the istream
42014 iterators is the fact that <tt>++</tt> operators are not equality preserving,
42015 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
42016 is used a new value is read.
42017 </blockquote>
42018
42019 <p>
42020 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
42021 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
42022 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
42023 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
42024 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
42025 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
42026 void*()</tt> will return a non-null value).
42027 </p>
42028
42029 <p>
42030 Also I would prefer to be explicit about calling <tt>fail()</tt> here
42031 (there is no <tt>operator void*()</tt> anymore.)
42032 </p>
42033
42034 <p><i>[
42035 Summit:
42036 ]</i></p>
42037
42038
42039 <blockquote>
42040 Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
42041 Martin to handle.
42042 </blockquote>
42043
42044 <p><i>[
42045 2009-07 Frankfurt:
42046 ]</i></p>
42047
42048
42049 <blockquote>
42050 <p>
42051 This improves the wording.
42052 </p>
42053 <p>
42054 Move to Ready.
42055 </p>
42056 </blockquote>
42057
42058
42059
42060 <p><b>Proposed resolution:</b></p>
42061 <p>
42062 Change 24.6.1 [istream.iterator]/1:
42063 </p>
42064
42065 <blockquote>
42066 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
42067 input stream for which it was constructed. After it is constructed, and
42068 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
42069 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
42070 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
42071 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
42072 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
42073 an end of stream input iterator object, which is the only legitimate
42074 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
42075 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
42076 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
42077 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
42078 store things into istream iterators. The main peculiarity of the istream
42079 iterators is the fact that <tt>++</tt> operators are not equality preserving,
42080 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
42081 is used a new value is read.
42082 </blockquote>
42083
42084
42085
42086
42087
42088 <hr>
42089 <h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
42090 <p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
42091  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
42092 <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>
42093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
42094 <p><b>Discussion:</b></p>
42095 <p>
42096 <tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
42097 </p>
42098
42099 <p><i>[
42100 Bellevue:
42101 ]</i></p>
42102
42103
42104 <blockquote>
42105 Non-controversial. Bill is right, but Fermilab believes that this is
42106 easy to use badly and hard to use right, and so it should be removed
42107 entirely. Got into TR1 by well defined route, do we have permission to
42108 remove stuff? Should probably check with Jens, as it is believed he is
42109 the originator. Broad consensus that this is not a robust engine
42110 adapter.
42111 </blockquote>
42112
42113
42114 <p><b>Proposed resolution:</b></p>
42115 <p>
42116 Remove xor_combine_engine from synopsis of 26.5.2 [rand.synopsis].
42117 </p>
42118 <p>
42119 Remove X [rand.adapt.xor] <tt>xor_combine_engine</tt>.
42120 </p>
42121
42122
42123
42124
42125
42126 <hr>
42127 <h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
42128 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
42129  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
42130 <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>
42131 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
42132 <p><b>Discussion:</b></p>
42133 <p>
42134 <tt>piecewise_constant_distribution</tt> is undefined for a range with just one
42135 endpoint. (Probably should be the same as an empty range.)
42136 </p>
42137
42138
42139 <p><b>Proposed resolution:</b></p>
42140 <p>
42141 Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
42142 </p>
42143
42144 <blockquote>
42145 b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
42146 </blockquote>
42147
42148
42149
42150
42151
42152 <hr>
42153 <h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
42154 <p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
42155  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-14 <b>Last modified:</b> 2010-10-29</p>
42156 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
42157 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
42158 <p><b>Discussion:</b></p>
42159 <p>
42160 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
42161 and its earlier predecessors have moved the old binders from
42162 [lib.binders] to D.11 [depr.lib.binders] thereby introducing some renaming
42163 of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
42164 renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
42165 <tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
42166 this user access point is probably rarely used.
42167 </p>
42168
42169
42170 <p><b>Proposed resolution:</b></p>
42171 <p>
42172 Change D.11.1 [depr.lib.binder.1st]:
42173 </p>
42174
42175 <blockquote>
42176 <pre>template &lt;class Fn&gt; 
42177 class binder1st 
42178   : public unary_function&lt;typename Fn::second_argument_type, 
42179                           typename Fn::result_type&gt; { 
42180 protected: 
42181   Fn <del>fn</del> <ins>op</ins>; 
42182   typename Fn::first_argument_type value; 
42183 public: 
42184   binder1st(const Fn&amp; x, 
42185             const typename Fn::first_argument_type&amp; y); 
42186   typename Fn::result_type 
42187     operator()(const typename Fn::second_argument_type&amp; x) const; 
42188   typename Fn::result_type 
42189     operator()(typename Fn::second_argument_type&amp; x) const; 
42190 };
42191 </pre>
42192
42193 <blockquote>
42194 <p>
42195 -1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
42196 </p>
42197 <p>
42198 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
42199 </p>
42200 </blockquote>
42201 </blockquote>
42202
42203 <p>
42204 Change D.11.3 [depr.lib.binder.2nd]:
42205 </p>
42206
42207 <blockquote>
42208 <pre>template &lt;class Fn&gt; 
42209 class binder2nd
42210   : public unary_function&lt;typename Fn::first_argument_type, 
42211                           typename Fn::result_type&gt; { 
42212 protected: 
42213   Fn <del>fn</del> <ins>op</ins>; 
42214   typename Fn::second_argument_type value; 
42215 public: 
42216   binder2nd(const Fn&amp; x, 
42217             const typename Fn::second_argument_type&amp; y); 
42218   typename Fn::result_type 
42219     operator()(const typename Fn::first_argument_type&amp; x) const; 
42220   typename Fn::result_type 
42221     operator()(typename Fn::first_argument_type&amp; x) const; 
42222 };
42223 </pre>
42224
42225 <blockquote>
42226 <p>
42227 -1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
42228 </p>
42229 <p>
42230 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
42231 </p>
42232 </blockquote>
42233 </blockquote>
42234
42235
42236
42237
42238
42239
42240 <hr>
42241 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
42242 <p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
42243  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2010-11-26</p>
42244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
42245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
42246 <p><b>Discussion:</b></p>
42247 <p>
42248 Classes with trivial special member functions are inherently more
42249 efficient than classes without such functions.  This efficiency is
42250 particularly pronounced on modern ABIs that can pass small classes
42251 in registers.  Examples include value classes such as complex numbers
42252 and floating-point intervals.  Perhaps more important, though, are
42253 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
42254 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
42255 themselves can be trivial, leading to substantial performance wins.
42256 </p>
42257 <p>
42258 The current working draft make specification of trivial functions
42259 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
42260 As long as the semantics of defaulted and deleted functions match
42261 the intended semantics, specification of defaulted and deleted
42262 functions will yield more efficient programs.
42263 </p>
42264 <p>
42265 There are at least two cases where specification of an explicitly
42266 defaulted function may be desirable.
42267 </p>
42268 <p>
42269 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
42270 which prevents static initialization of the pair even when the
42271 types are statically initializable.  Changing the definition to
42272 </p>
42273
42274 <blockquote><pre>pair() = default;
42275 </pre></blockquote>
42276
42277 <p>
42278 would enable such initialization.  Unfortunately, the change is
42279 not semantically neutral in that the current definition effectively
42280 forces value initialization whereas the change would not value
42281 initialize in some contexts.
42282 </p>
42283
42284 <p>
42285 ** Does the committee confirm that forced value initialization
42286 was the intent?  If not, does the committee wish to change the
42287 behavior of <tt>std::pair</tt> in C++0x?
42288 </p>
42289 <p>
42290 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
42291 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
42292 which effectively prevents passing it in registers.  To enable
42293 passing <tt>tuples</tt> in registers, the copy constructor should be
42294 make explicitly <tt>default</tt>ed.  The new declarations are:
42295 </p>
42296
42297 <blockquote><pre>tuple() = default;
42298 tuple(const tuple&amp;) = default;
42299 </pre></blockquote>
42300
42301 <p>
42302 This changes is not implementation neutral.  In particular, it
42303 prevents implementations based on pointers to the parameter
42304 types.  It does however, permit implementations using the
42305 parameter types as bases.
42306 </p>
42307 <p>
42308 ** How does the committee wish to trade implementation
42309 efficiency versus implementation flexibility?
42310 </p>
42311
42312 <p><i>[
42313 Bellevue:
42314 ]</i></p>
42315
42316
42317 <blockquote>
42318 <p>
42319 General agreement; the first half of the issue is NAD.
42320 </p>
42321 <p>
42322 Before voting on the second half, it was agreed that a "Strongly Favor"
42323 vote meant support for trivial tuples (assuming usual requirements met),
42324 even at the expense of other desired qualities. A "Weakly Favor" vote
42325 meant support only if not at the expense of other desired qualities.
42326 </p>
42327 <p>
42328 Concensus: Go forward, but not at expense of other desired qualities.
42329 </p>
42330 <p>
42331 It was agreed to Alisdair should fold this work in with his other
42332 pair/tuple action items, above, and that issue 801 should be "open", but
42333 tabled until Alisdair's proposals are disposed of.
42334 </p>
42335 </blockquote>
42336
42337 <p><i>[
42338 2009-05-27 Daniel adds:
42339 ]</i></p>
42340
42341
42342 <blockquote>
42343 This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>.
42344 </blockquote>
42345
42346 <p><i>[
42347 2009-07 Frankfurt:
42348 ]</i></p>
42349
42350
42351 <blockquote>
42352 Wait for dust to settle from fixing exception safety problem
42353 with rvalue refs.
42354 </blockquote>
42355
42356 <p><i>[
42357 2009-07-20 Alisdair adds:
42358 ]</i></p>
42359
42360
42361 <blockquote>
42362 <p>
42363 Basically, this issue is what should we do with the default constructor
42364 for pairs and tuples of trivial types.  The motivation of the issue was
42365 to force static initialization rather than dynamic initialization, and
42366 was rejected in the case of pair as it would change the meaning of
42367 existing programs.  The advice was "do the best we can" for tuple
42368 without changing existing meaning.
42369 </p>
42370
42371 <p>
42372 Frankfurt seems to simply wait and see the resolution on no-throw move
42373 constructors, which (I believe) is only tangentially related to this
42374 issue, but as good as any to defer until Santa Cruz.
42375 </p>
42376
42377 <p>
42378 Looking again now, I think constant (static) initialization for pair can
42379 be salvaged by making the default construct constexpr.  I have a
42380 clarification from Core that this is intended to work, even if the
42381 constructor is not trivial/constexpr, so long as no temporaries are
42382 implied in the process (even if elided).
42383 </p>
42384 </blockquote>
42385
42386 <p><i>[
42387 2009-10 Santa Cruz:
42388 ]</i></p>
42389
42390
42391 <blockquote>
42392 Leave as open. Alisdair to provide wording.
42393 </blockquote>
42394
42395 <p><i>[
42396 2010 Pittsburgh:
42397 ]</i></p>
42398
42399
42400 <blockquote>
42401 <p>
42402 We believe this may be NAD Editorial since both pair and tuple now have
42403 constexpr default constructors, but we're not sure.
42404 </p>
42405 </blockquote>
42406
42407
42408 <p><i>[
42409 2010 Rapperswil:
42410 ]</i></p>
42411
42412
42413 <blockquote>
42414 Daniel believes his pair/tuple paper will resolve this issue. <tt>constexpr</tt> will allow static initialization, and he is already changing the move and copy constructors to be defaulted.
42415 </blockquote>
42416
42417 <p><i>[
42418 2010-10-24 Daniel adds:
42419 ]</i></p>
42420
42421
42422 <blockquote>
42423 The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> should resolve this issue.
42424 </blockquote>
42425
42426
42427
42428 <p><b>Proposed resolution:</b></p>
42429 <p>
42430 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
42431 </p>
42432
42433
42434
42435
42436
42437 <hr>
42438 <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
42439 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
42440  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2010-10-29</p>
42441 <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>
42442 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
42443 <p><b>Discussion:</b></p>
42444 <ol type="A">
42445 <li>
42446 <p>
42447 19.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
42448 19.5.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
42449 declare an expository data member <tt>cat_</tt>:
42450 </p>
42451 <blockquote><pre>const error_category&amp; cat_; // exposition only
42452 </pre></blockquote>
42453 <p>
42454 which is used to define the semantics of several members. The decision
42455 to use a member of reference type lead to several problems:
42456 </p>
42457 <ol>
42458 <li>
42459 The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
42460 </li>
42461 <li>
42462 The post conditions of all modifiers from
42463 19.5.2.3 [syserr.errcode.modifiers] and 19.5.3.3 [syserr.errcondition.modifiers], resp.,
42464 cannot be fulfilled.
42465 </li>
42466 </ol>
42467 <p>
42468 The simple fix would be to replace the reference by a pointer member.
42469 </p>
42470 </li>
42471
42472 <li>
42473 I would like to give the editorial remark that in both classes the
42474 constrained <tt>operator=</tt>
42475 overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
42476 usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
42477 parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
42478 valid circumstances - this return type must be explicitly provided (In
42479 <tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
42480 type).
42481 </li>
42482
42483 <li>
42484 The member function <tt>message</tt> throws clauses (
42485 19.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.4 [syserr.errcode.observers]/8, and
42486 19.5.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
42487 although
42488 they return a <tt>std::string</tt> by value, which might throw in out-of-memory
42489 conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>).
42490 </li>
42491 </ol>
42492
42493 <p><i>[
42494 Sophia Antipolis:
42495 ]</i></p>
42496
42497
42498 <blockquote>
42499 <p>
42500 Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.
42501 </p>
42502 <p>
42503 Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
42504 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
42505 </p>
42506 <p>
42507 Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>.
42508 </p>
42509 <p>
42510 Howard: please ping Beman, asking him to clear away parts A and B from
42511 the wording in the proposed resolution, so it is clear to the editor
42512 what needs to be applied to the working paper.
42513 </p>
42514 <p>
42515 Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> is not going
42516 forward, the provided wording includes resolution of part A.
42517 </p>
42518 </blockquote>
42519
42520
42521
42522 <p><b>Proposed resolution:</b></p>
42523
42524 <p>
42525 Resolution of part A:
42526 </p>
42527 <blockquote>
42528 <p>
42529 Change 19.5.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
42530 </p>
42531
42532 <blockquote><pre>private:
42533   int val_;                    // exposition only
42534   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
42535 </pre></blockquote>
42536
42537 <p>
42538 Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
42539 </p>
42540
42541 <blockquote>
42542 <pre>error_code();
42543 </pre>
42544 <blockquote>
42545 <p>
42546 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
42547 </p>
42548 <p>
42549 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
42550 </p>
42551 <p>
42552 <i>Throws:</i> Nothing.
42553 </p>
42554 </blockquote>
42555 <pre>error_code(int val, const error_category&amp; cat);
42556 </pre>
42557 <blockquote>
42558 <p>
42559 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
42560 </p>
42561 <p>
42562 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
42563 </p>
42564 <p>
42565 <i>Throws:</i> Nothing.
42566 </p>
42567 </blockquote>
42568 </blockquote>
42569
42570 <p>
42571 Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
42572 </p>
42573
42574 <blockquote>
42575 <pre>void assign(int val, const error_category&amp; cat);
42576 </pre>
42577 <blockquote>
42578 <p>
42579 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
42580 </p>
42581 <p>
42582 <i>Throws:</i> Nothing.
42583 </p>
42584 </blockquote>
42585 </blockquote>
42586
42587 <p>
42588 Change 19.5.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
42589 </p>
42590
42591 <blockquote>
42592 const error_category&amp; category() const;
42593 <blockquote>
42594 <p>
42595 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
42596 </p>
42597 <p>
42598 <i>Throws:</i> Nothing.
42599 </p>
42600 </blockquote>
42601 </blockquote>
42602
42603 <p>
42604 Change 19.5.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
42605 </p>
42606
42607 <blockquote><pre>private:
42608   int val_;                    // exposition only
42609   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
42610 </pre></blockquote>
42611
42612 <p>
42613 Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
42614 </p>
42615 <p><i>[
42616 (If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has already been applied, the
42617 name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
42618 no effect on this resolution.)
42619 ]</i></p>
42620
42621
42622 <blockquote>
42623 <pre>error_condition();
42624 </pre>
42625 <blockquote>
42626 <p>
42627 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
42628 </p>
42629 <p>
42630 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
42631 </p>
42632 <p>
42633 <i>Throws:</i> Nothing.
42634 </p>
42635 </blockquote>
42636 <pre>error_condition(int val, const error_category&amp; cat);
42637 </pre>
42638 <blockquote>
42639 <p>
42640 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
42641 </p>
42642 <p>
42643 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
42644 </p>
42645 <p>
42646 <i>Throws:</i> Nothing.
42647 </p>
42648 </blockquote>
42649 </blockquote>
42650
42651 <p>
42652 Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
42653 </p>
42654
42655 <blockquote>
42656 void assign(int val, const error_category&amp; cat);
42657 <blockquote>
42658 <p>
42659 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
42660 </p>
42661 <p>
42662 <i>Throws:</i> Nothing.
42663 </p>
42664 </blockquote>
42665 </blockquote>
42666
42667 <p>
42668 Change 19.5.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
42669 </p>
42670
42671 <blockquote>
42672 const error_category&amp; category() const;
42673 <blockquote>
42674 <p>
42675 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
42676 </p>
42677 <p>
42678 <i>Throws:</i> Nothing.
42679 </p>
42680 </blockquote>
42681 </blockquote>
42682 </blockquote>
42683
42684 <p>
42685 Resolution of part C:
42686 </p>
42687
42688 <blockquote>
42689
42690 <p>
42691 In 19.5.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
42692 </p>
42693
42694 <blockquote>
42695 <pre>virtual string message(int ev) const = 0;
42696 </pre>
42697
42698 <blockquote>
42699 <p>
42700 <i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
42701 </p>
42702 <p>
42703 <del><i>Throws:</i> Nothing.</del>
42704 </p>
42705 </blockquote>
42706 </blockquote>
42707
42708 <p>
42709 In 19.5.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
42710 </p>
42711
42712 <blockquote>
42713 <pre>string message() const;
42714 </pre>
42715 <blockquote>
42716 <p>
42717 <i>Returns:</i> <tt>category().message(value())</tt>.
42718 </p>
42719 <p>
42720 <del><i>Throws:</i> Nothing.</del>
42721 </p>
42722 </blockquote>
42723 </blockquote>
42724
42725 <p>
42726 In 19.5.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
42727 </p>
42728
42729 <blockquote>
42730 <pre>string message() const;
42731 </pre>
42732 <blockquote>
42733 <p>
42734 <i>Returns:</i> <tt>category().message(value())</tt>.
42735 </p>
42736 <p>
42737 <del><i>Throws:</i> Nothing.</del>
42738 </p>
42739 </blockquote>
42740 </blockquote>
42741
42742 </blockquote>
42743
42744
42745
42746
42747
42748
42749 <hr>
42750 <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
42751 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
42752  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2010-10-29</p>
42753 <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>
42754 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
42755 <p><b>Discussion:</b></p>
42756 <p>
42757 19.5 [syserr]
42758 </p>
42759
42760 <blockquote><pre>namespace posix_error {
42761   enum posix_errno {
42762     address_family_not_supported, // EAFNOSUPPORT
42763     ...
42764 </pre></blockquote>
42765
42766 <p>
42767 should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
42768 which would avoid the necessity for a new <tt>posix_error</tt>
42769 namespace, if I understand correctly.
42770 </p>
42771
42772 <p><i>[
42773 Further discussion:
42774 ]</i></p>
42775
42776
42777 <blockquote>
42778 <p>
42779 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
42780 Strongly Typed Enums, since renamed Scoped Enums.
42781 </p>
42782 <p>
42783 Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
42784 </p>
42785 <p>
42786 Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
42787 </p>
42788 <p>
42789 The wording for the Proposed resolution was provided by Beman Dawes.
42790 </p>
42791 </blockquote>
42792
42793
42794 <p><b>Proposed resolution:</b></p>
42795 <p>
42796 Change System error support 19.5 [syserr] as indicated:
42797 </p>
42798
42799 <blockquote><pre><del>namespace posix_error {</del>
42800   enum <del>posix_errno</del> <ins>class errc</ins> {
42801     address_family_not_supported, // EAFNOSUPPORT
42802     ...
42803     wrong_protocol_type, // EPROTOTYPE
42804   };
42805 <del>} // namespace posix_error</del>
42806
42807 template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
42808   : public true_type {}
42809
42810 <del>namespace posix_error {</del>
42811   error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
42812   error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
42813 <del>} // namespace posix_error</del>
42814 </pre></blockquote>
42815
42816 <p>
42817 Change System error support 19.5 [syserr] :
42818 </p>
42819
42820 <blockquote>
42821 <del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
42822 specialized for user-defined types to indicate that such a type is
42823 eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
42824 conversions, respectively.</del>
42825 </blockquote>
42826
42827 <p>
42828 Change System error support 19.5 [syserr] and its subsections:
42829 </p>
42830
42831 <blockquote>
42832 <ul>
42833 <li>
42834 remove all occurrences of <tt>posix_error::</tt>
42835 </li>
42836 <li>
42837 change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
42838 </li>
42839 <li>
42840 change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
42841 </li>
42842 <li>
42843 change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
42844 </li>
42845 </ul>
42846 </blockquote>
42847
42848 <p>
42849 Change Error category objects 19.5.1.5 [syserr.errcat.objects], paragraph 2:
42850 </p>
42851
42852 <blockquote>
42853 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
42854 functions shall behave as specified for the class <tt>error_category</tt>. The
42855 object's name virtual function shall return a pointer to the string
42856 <del>"POSIX"</del> <ins>"generic"</ins>.
42857 </blockquote>
42858
42859 <p>
42860 Change 19.5.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
42861 </p>
42862
42863 <blockquote>
42864 <pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
42865 </pre>
42866
42867 <blockquote>
42868 <i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
42869 </blockquote>
42870 </blockquote>
42871
42872 <p>
42873 Change 19.5.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
42874 </p>
42875
42876 <blockquote>
42877 <pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
42878 </pre>
42879
42880 <blockquote>
42881 <i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
42882 </blockquote>
42883 </blockquote>
42884
42885
42886
42887 <p><b>Rationale:</b></p>
42888 <table border="1">
42889 <tbody><tr>
42890 <th colspan="2">Names Considered</th>
42891 </tr>
42892
42893 <tr>
42894 <td><tt>portable</tt></td>
42895 <td>
42896 Too non-specific. Did not wish to reserve such a common word in
42897 namespace std. Not quite the right meaning, either.
42898 </td>
42899 </tr>
42900
42901 <tr>
42902 <td><tt>portable_error</tt></td>
42903 <td>
42904 Too long. Explicit qualification is always required for scoped enums, so
42905 a short name is desirable. Not quite the right meaning, either. May be
42906 misleading because <tt>*_error</tt> in the std lib is usually an exception class
42907 name.
42908 </td>
42909 </tr>
42910
42911 <tr>
42912 <td><tt>std_error</tt></td>
42913 <td>
42914 Fairly short, yet explicit. But in fully qualified names like
42915 <tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
42916 quite the right meaning, either. May be misleading because <tt>*_error</tt> in
42917 the std lib is usually an exception class name.
42918 </td>
42919 </tr>
42920
42921 <tr>
42922 <td><tt>generic</tt></td>
42923 <td>
42924 Short enough. The category could be <tt>generic_category</tt>. Fully qualified
42925 names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
42926 namespace std seems dicey.
42927 </td>
42928 </tr>
42929
42930 <tr>
42931 <td><tt>generic_error</tt></td>
42932 <td>
42933 Longish. The category could be <tt>generic_category</tt>. Fully qualified names
42934 like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
42935 <tt>*_error</tt> in the std lib is usually an exception class name.
42936 </td>
42937 </tr>
42938
42939 <tr>
42940 <td><tt>generic_err</tt></td>
42941 <td>
42942 A bit less longish. The category could be <tt>generic_category</tt>. Fully
42943 qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
42944 </td>
42945 </tr>
42946
42947 <tr>
42948 <td><tt>gen_err</tt></td>
42949 <td>
42950 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
42951 names like <tt>std::gen_err::not_enough_memory</tt> read well.
42952 </td>
42953 </tr>
42954
42955 <tr>
42956 <td><tt>generr</tt></td>
42957 <td>
42958 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
42959 names like <tt>std::generr::not_enough_memory</tt> read well.
42960 </td>
42961 </tr>
42962
42963 <tr>
42964 <td><tt>error</tt></td>
42965 <td>
42966 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
42967 names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
42968 this general a name?
42969 </td>
42970 </tr>
42971
42972 <tr>
42973 <td><tt>err</tt></td>
42974 <td>
42975 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
42976 names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
42977 looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
42978 it seems fairly intuitive.
42979 Problem: <tt>err</tt> is used throughout the standard library as an argument name
42980 and in examples as a variable name; it seems too confusing to add yet
42981 another use of the name.
42982 </td>
42983 </tr>
42984
42985 <tr>
42986 <td><tt>errc</tt></td>
42987 <td>
42988 Short enough. The "c" stands for "constant". The category could be
42989 <tt>generic_category</tt>. Fully qualified names like
42990 <tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
42991 name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
42992 intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
42993 </td>
42994 </tr>
42995 </tbody></table>
42996
42997
42998
42999
43000
43001 <hr>
43002 <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
43003 <p><b>Section:</b> 20.9.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
43004  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
43005 <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>
43006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
43007 <p><b>Discussion:</b></p>
43008 <p>
43009 <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
43010 </p>
43011
43012 <blockquote>
43013 <i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
43014 </blockquote>
43015
43016 <p>
43017 There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
43018 deleter is called with a NULL pointer, and this is probably not what's
43019 intended (the destructor avoids calling the deleter with 0.)
43020 </p>
43021
43022 <p>
43023 Two, the special check for <tt>get() == p</tt> is generally not needed and such a
43024 situation usually indicates an error in the client code, which is being
43025 masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
43026 self-resets in 2001 and there were no complaints.
43027 </p>
43028
43029 <p>
43030 One might think that self-resets are necessary for operator= to work; it's specified to perform
43031 </p>
43032
43033 <blockquote><pre>reset( u.release() );
43034 </pre></blockquote>
43035
43036 <p>
43037 and the self-assignment
43038 </p>
43039
43040 <blockquote><pre>p = move(p);
43041 </pre></blockquote>
43042
43043 <p>
43044 might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
43045 performed first, zeroing the stored pointer. In other words, <tt>p.reset(
43046 q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
43047 is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
43048 scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
43049 </p>
43050
43051
43052
43053 <p><b>Proposed resolution:</b></p>
43054
43055 <p>
43056 Change 20.9.9.2.5 [unique.ptr.single.modifiers]:
43057 </p>
43058
43059 <blockquote>
43060 <pre>void reset(T* p = 0);
43061 </pre>
43062 <blockquote>
43063 -4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
43064 </blockquote>
43065 </blockquote>
43066
43067 <p>
43068 Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]:
43069 </p>
43070
43071 <blockquote>
43072 <pre>void reset(T* p = 0);
43073 </pre>
43074 <blockquote>
43075 <p>...</p>
43076 <p>
43077 -2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
43078 </p>
43079 </blockquote>
43080 </blockquote>
43081
43082
43083
43084
43085
43086
43087 <hr>
43088 <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
43089 <p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
43090  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
43091 <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>
43092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
43093 <p><b>Discussion:</b></p>
43094 <p>
43095 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
43096 should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
43097 </p>
43098
43099
43100 <p><b>Proposed resolution:</b></p>
43101 <p>
43102 Add to 20.4.2.1 [tuple.cnstr]:
43103 </p>
43104
43105 <blockquote>
43106 <p>
43107 For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
43108 or assignment of one of the types in <tt>Types</tt> throws an exception.
43109 </p>
43110 </blockquote>
43111
43112
43113
43114
43115
43116 <hr>
43117 <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
43118 <p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
43119  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
43120 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
43121 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
43122 <p><b>Discussion:</b></p>
43123 <p>
43124 p4 (forward) says:
43125 </p>
43126 <blockquote>
43127 <i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
43128 </blockquote>
43129
43130 <p>
43131 First of all, lvalue-ness and rvalue-ness are properties of an expression,
43132 not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
43133 Second, the phrase says exactly what the core language wording says for
43134 folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
43135 in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
43136 at most be a note with cross-references to those sections.)
43137 </p>
43138 <p>
43139 The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
43140 In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
43141 property of an expression, orthogonal to its type.  (Btw, expressions cannot
43142 have reference type, ever.)
43143 </p>
43144 <p>
43145 Similar with move:
43146 </p>
43147 <blockquote>
43148 Return type: an rvalue.
43149 </blockquote>
43150 <p>
43151 is just wrong and also redundant.
43152 </p>
43153
43154
43155 <p><b>Proposed resolution:</b></p>
43156 <p>
43157 Change 20.3.3 [forward] as indicated:
43158 </p>
43159
43160 <blockquote>
43161 <pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
43162 </pre>
43163
43164 <blockquote>
43165 <p>...</p>
43166 <p>
43167 <del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
43168 </p>
43169 <p>...</p>
43170 <p>
43171 -7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
43172 as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
43173 as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
43174 In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
43175 <del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
43176 </p>
43177 </blockquote>
43178
43179 <pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
43180 </pre>
43181
43182 <blockquote>
43183 <p>...</p>
43184 <p>
43185 <del><i>Return type:</i>  an rvalue.</del>
43186 </p>
43187 </blockquote>
43188
43189 </blockquote>
43190
43191
43192
43193
43194
43195
43196 <hr>
43197 <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
43198 <p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
43199  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-02-28 <b>Last modified:</b> 2010-10-29</p>
43200 <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>
43201 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
43202 <p><b>Discussion:</b></p>
43203 <p>
43204 For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
43205 overload of <code>std::swap</code> for array types:
43206 </p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
43207 </pre>
43208 <p></p>
43209
43210 <p>
43211 It became apparent to me that this overload is missing, when I considered how to write a swap
43212 function for a generic wrapper class template.
43213 (Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
43214 Please look at the following template, <code>W</code>, and suppose that is intended to be a very
43215 <em>generic</em> wrapper:
43216 </p><pre>template&lt;class T&gt; class W {
43217 public:
43218    T data;
43219 };
43220 </pre>
43221 Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
43222 <em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
43223 Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
43224 whose element type is CopyConstructible and CopyAssignable.
43225 Still it is recommended to add a <em>custom</em> swap function template to such a class template,
43226 for the sake of efficiency and exception safety.
43227 (E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
43228 swap</em>.)
43229 This function template is typically written as follows:
43230 <pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
43231   using std::swap;
43232   swap(x.data, y.data);
43233 }
43234 </pre>
43235 Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
43236 For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
43237 allow calling the custom swap function that was especially written for <code>W</code>!
43238 <pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
43239 std::swap(w1, w2);  // Well-defined, but inefficient.
43240 using std::swap;
43241 swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
43242 </pre>
43243
43244 <code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
43245 <code>std::string[8]</code>, which is not supported by the Standard Library.
43246 This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
43247 This swap function should be implemented in terms of swapping the elements of the arrays, so that
43248 it would be non-throwing for arrays whose element types have a non-throwing swap.
43249 <p></p>
43250
43251 <p>
43252 Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
43253 arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
43254 means of recursion.
43255 </p>
43256
43257 <p>
43258 For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
43259 Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
43260 </p>
43261
43262
43263 <p><b>Proposed resolution:</b></p>
43264 <p>
43265 Add an extra condition to the definition of Swappable requirements [swappable] in 20.2.1 [utility.arg.requirements]:
43266 </p>
43267 <blockquote>
43268 - <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
43269 </blockquote>
43270 <p>
43271 Add the following to 25.3.3 [alg.swap]:
43272 </p>
43273 <blockquote>
43274 <pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
43275 </pre>
43276 <blockquote>
43277 <i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
43278 </blockquote>
43279 <blockquote>
43280 <i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
43281 </blockquote>
43282 </blockquote>
43283
43284
43285
43286
43287
43288 <hr>
43289 <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
43290 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43291  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-03-01 <b>Last modified:</b> 2010-10-29</p>
43292 <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>
43293 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43294 <p><b>Discussion:</b></p>
43295 <p>
43296 The recent draft (as well as the original proposal n2072) uses an
43297 operational semantic
43298 for <tt>get_money</tt> ([ext.manip]/4) and <tt>put_money</tt> ([ext.manip]/6), which uses
43299 </p>
43300
43301 <blockquote><pre>istreambuf_iterator&lt;charT&gt;
43302 </pre></blockquote>
43303
43304 <p>
43305 and
43306 </p>
43307
43308 <blockquote><pre>ostreambuf_iterator&lt;charT&gt;
43309 </pre></blockquote>
43310
43311 <p>
43312 resp, instead of the iterator instances, with explicitly provided
43313 traits argument (The operational semantic defined by <tt>f</tt> is also traits
43314 dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
43315 c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
43316 </p>
43317 <p>
43318 The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic 
43319 where additional to the problem we
43320 have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
43321 <tt>istreambuf_iterator</tt>).
43322 </p>
43323
43324 <p><i>[
43325 Batavia (2009-05):
43326 ]</i></p>
43327
43328 <blockquote>
43329 <p>
43330 This appears to be an issue of presentation.
43331 </p>
43332 <p>
43333 We agree with the proposed resolution.
43334 Move to Tentatively Ready.
43335 </p>
43336 </blockquote>
43337
43338
43339 <p><b>Proposed resolution:</b></p>
43340 <p>
43341 In 27.7.4 [ext.manip]/4 within function <tt>f</tt> replace the first line
43342 </p>
43343
43344 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
43345 void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
43346    typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
43347    ...
43348 </pre></blockquote>
43349
43350 <p>
43351 In 27.7.4 [ext.manip]/5 remove the first template <tt>charT</tt> parameter:
43352 </p>
43353
43354 <blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
43355 </pre></blockquote>
43356
43357 <p>
43358 In 27.7.4 [ext.manip]/6 within function <tt>f</tt> replace the first line
43359 </p>
43360
43361 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
43362 void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
43363   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
43364   ...
43365 </pre></blockquote>
43366
43367 <p>
43368 In 27.7.4 [ext.manip]/8 within function <tt>f</tt> replace the first line
43369 </p>
43370
43371 <blockquote><pre>template &lt;class charT, class traits&gt; 
43372 void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
43373   typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
43374   ...
43375 </pre></blockquote>
43376
43377 <p>
43378 In 27.7.4 [ext.manip]/10 within function <tt>f</tt> replace the first line
43379 </p>
43380
43381 <blockquote><pre>template &lt;class charT, class traits&gt; 
43382 void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
43383   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
43384   ...
43385 </pre></blockquote>
43386
43387 <p>
43388 In 27.7 [iostream.format], Header <tt>&lt;iomanip&gt;</tt> synopsis change:
43389 </p>
43390
43391 <blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; T8 put_money(const moneyT&amp; mon, bool intl = false);
43392 </pre></blockquote>
43393
43394
43395
43396
43397
43398 <hr>
43399 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
43400 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43401  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14 <b>Last modified:</b> 2010-10-29</p>
43402 <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>
43403 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43404 <p><b>Discussion:</b></p>
43405 <blockquote><pre>#include &lt;utility&gt;
43406
43407 int main()
43408 {
43409    std::pair&lt;char *, char *&gt; p (0,0);
43410 }
43411 </pre></blockquote>
43412
43413 <p>
43414 I just got a bug report about that, because it's valid C++03, but not
43415 C++0x. The important realization, for me, is that the emplace
43416 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
43417 issue---didn't cause this break in backward compatibility. The break
43418 actually happened when we added this pair constructor as part of adding
43419 rvalue references into the language, long before variadic templates or
43420 emplace came along:
43421 </p>
43422
43423 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
43424 </pre></blockquote>
43425
43426 <p>
43427 Now, concepts will address this issue by constraining that <tt>pair</tt>
43428 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
43429 "second", e.g. (from
43430 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
43431 </p>
43432
43433 <blockquote><pre>template&lt;class U , class V &gt;
43434 requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
43435 pair(U&amp;&amp; x , V&amp;&amp; y );
43436 </pre></blockquote>
43437
43438 <p><i>[
43439 San Francisco:
43440 ]</i></p>
43441
43442
43443 <blockquote>
43444 <p>
43445 Suggested to resolve using pass-by-value for that case.
43446 </p>
43447 <p>
43448 Side question: Should pair interoperate with tuples? Can construct a
43449 tuple of a pair, but not a pair from a two-element tuple.
43450 </p>
43451 <p>
43452 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>.
43453 </p>
43454 </blockquote>
43455
43456 <p><i>[
43457 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
43458 ]</i></p>
43459
43460
43461 <p><i>[
43462 2009-10 Santa Cruz:
43463 ]</i></p>
43464
43465
43466 <blockquote>
43467 Leave as open. Howard to provide wording.
43468 </blockquote>
43469
43470 <p><i>[
43471 2010-02-06 Howard provided wording.
43472 ]</i></p>
43473
43474
43475 <p><i>[
43476 2010-02-09 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
43477 ]</i></p>
43478
43479
43480
43481
43482 <p><b>Rationale:</b></p>
43483 <p><i>[
43484 San Francisco:
43485 ]</i></p>
43486
43487
43488 <blockquote>
43489 Solved by
43490 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
43491 </blockquote>
43492
43493 <p><i>[
43494 The rationale is obsolete.
43495 ]</i></p>
43496
43497
43498
43499
43500 <p><b>Proposed resolution:</b></p>
43501 <p>
43502 Add a paragraph to 20.3.5 [pairs]:
43503 </p>
43504
43505 <blockquote>
43506 <pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
43507 </pre>
43508 <blockquote>
43509 <p>
43510 6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
43511 <tt>std::forward&lt;U&gt;(x)</tt> and second with
43512 <tt>std::forward&lt;V&gt;(y)</tt>.
43513 </p>
43514
43515 <p>
43516 <ins><i>Remarks:</i> <tt>U</tt> shall be implicitly convertible to
43517 <tt>first_type</tt> and <tt>V</tt> shall be implicitly convertible to
43518 <tt>second_type</tt>, else this constructor shall not participate in overload
43519 resolution.</ins>
43520 </p>
43521 </blockquote>
43522 </blockquote>
43523
43524
43525
43526
43527
43528
43529 <hr>
43530 <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
43531 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
43532  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2008-02-26 <b>Last modified:</b> 2010-10-29</p>
43533 <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>
43534 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
43535 <p><b>Discussion:</b></p>
43536 <p>
43537 Several places in 20.9.10.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
43538 However, that term is nowhere defined. The closest thing we have to a
43539 definition is that the default constructor creates an empty <tt>shared_ptr</tt>
43540 and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
43541 other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
43542 are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
43543 term or stop using it.
43544 </p><p>
43545 </p>
43546 One reason it's not good enough to leave this term up to the reader's
43547 intuition is that, in light of
43548 <a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
43549 and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, most readers'
43550 intuitive understanding is likely to be wrong. Intuitively one might
43551 expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
43552 but, whatever the definition is, that isn't it.
43553 <p></p>
43554
43555 <p><i>[
43556 Peter adds:
43557 ]</i></p>
43558
43559
43560 <blockquote>
43561 <p>
43562 Or, what is an "empty" <tt>shared_ptr</tt>?
43563 </p>
43564
43565 <ul>
43566 <li>
43567 <p>
43568 Are any other <tt>shared_ptrs</tt> empty?
43569 </p>
43570 <p>
43571 Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
43572 completely specified by the last mutating operation on that instance.
43573 Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
43574 not.
43575 </p>
43576 <blockquote>
43577 (*) If it isn't, this is a legitimate defect.
43578 </blockquote>
43579 </li>
43580
43581 <li>
43582 <p>
43583 For example, is <tt>shared_ptr((T*) 0)</tt> empty?
43584 </p>
43585 <p>
43586 No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
43587 specified to have an <tt>use_count()</tt> of 1.
43588 </p>
43589 </li>
43590
43591 <li>
43592 <p>
43593 What are the properties of an empty <tt>shared_ptr</tt>?
43594 </p>
43595 <p>
43596 The properties of an empty <tt>shared_ptr</tt> can be derived from the
43597 specification. One example is that its destructor is a no-op. Another is
43598 that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
43599 really like.
43600 </p>
43601 </li>
43602
43603 <li>
43604 <p>
43605 We should either clarify this term or stop using it.
43606 </p>
43607 <p>
43608 I don't agree with the imperative tone
43609 </p>
43610 <p>
43611 A clarification would be either a no-op - if it doesn't contradict the
43612 existing wording - or a big mistake if it does.
43613 </p>
43614 <p>
43615 I agree that a clarification that is formally a no-op may add value.
43616 </p>
43617 </li>
43618
43619 <li>
43620 <p>
43621 However, that term is nowhere defined.
43622 </p>
43623 <p>
43624 Terms can be useful without a definition. Consider the following
43625 simplistic example. We have a type <tt>X</tt> with the following operations
43626 defined:
43627 </p>
43628 <blockquote><pre>X x;
43629 X x2(x);
43630 X f(X x);
43631 X g(X x1, X x2);
43632 </pre></blockquote>
43633 <p>
43634 A default-constructed value is green.<br>
43635 A copy has the same color as the original.<br>
43636 <tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
43637 <tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
43638 </p>
43639
43640 <p>
43641 Given these definitions, you can determine the color of every instance
43642 of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
43643 </p>
43644
43645 <p>
43646 Green and red are "nowhere defined" and completely defined at the same time.
43647 </p>
43648 </li>
43649 </ul>
43650
43651 <p>
43652 Alisdair's wording is fine.
43653 </p>
43654 </blockquote>
43655
43656
43657 <p><b>Proposed resolution:</b></p>
43658 <p>
43659 Append the following sentance to 20.9.10.2 [util.smartptr.shared]
43660 </p>
43661 <blockquote>
43662 The <code>shared_ptr</code> class template stores a pointer, usually obtained
43663 via <code>new</code>. <code>shared_ptr</code> implements semantics of
43664 shared ownership; the last remaining owner of the pointer is responsible for
43665 destroying the object, or otherwise releasing  the resources associated with
43666 the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
43667 a pointer is said to be <i>empty</i>.</ins>
43668 </blockquote>
43669
43670
43671
43672
43673
43674 <hr>
43675 <h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
43676 <p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43677  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2010-10-29</p>
43678 <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>
43679 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43680 <p><b>Discussion:</b></p>
43681 <p>
43682 <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
43683 </p>
43684
43685 <p><i>[
43686 San Francisco:
43687 ]</i></p>
43688
43689
43690 <blockquote>
43691 Move to Open. Alisdair to provide a resolution.
43692 </blockquote>
43693
43694 <p><i>[
43695 Post Summit Daniel provided wording.
43696 ]</i></p>
43697
43698
43699 <p><i>[
43700 Batavia (2009-05):
43701 ]</i></p>
43702
43703 <blockquote>
43704 We agree with the proposed resolution.
43705 Move to Tentatively Ready.
43706 </blockquote>
43707
43708
43709 <p><b>Proposed resolution:</b></p>
43710 <p>
43711 Just after 23.4.2 [vector.bool]/5 add the following prototype and description:
43712 </p>
43713
43714 <blockquote>
43715 <p>
43716 <ins>static void swap(reference x, reference y);</ins>
43717 </p>
43718 <blockquote>
43719 <p>
43720 <ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by:
43721 </p>
43722 <blockquote><pre><ins>
43723 bool b = x;
43724 x = y;
43725 y = b;
43726 </ins></pre></blockquote>
43727 </blockquote>
43728 </blockquote>
43729
43730
43731
43732
43733
43734 <hr>
43735 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
43736 <p><b>Section:</b> 20.8.14.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
43737  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16 <b>Last modified:</b> 2010-11-19</p>
43738 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.inv">issues</a> in [func.wrap.func.inv].</p>
43739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
43740 <p><b>Discussion:</b></p>
43741 <p>
43742 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
43743 described in the rvalue core proposal.
43744 </p>
43745
43746 <p><i>[
43747 Sophia Antipolis:
43748 ]</i></p>
43749
43750
43751 <blockquote>
43752 According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
43753 forwarding can not be obtained because of type erasure. Not everyone
43754 agreed with this diagnosis of forwarding.
43755 </blockquote>
43756
43757 <p><i>[
43758 2009-05-01 Howard adds:
43759 ]</i></p>
43760
43761
43762 <blockquote>
43763 <p>
43764 Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
43765 requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
43766 restriction.
43767 </p>
43768
43769 <blockquote><pre>template&lt;Returnable R, <b>CopyConstructible</b>... ArgTypes&gt;
43770 class function&lt;R(ArgTypes...)&gt;
43771 ...
43772 </pre></blockquote>
43773
43774 <p>
43775 On further investigation, this complaint seemed to be the same
43776 issue as this one.  I believe the reason <tt>CopyConstructible</tt> was put
43777 on <tt>ArgTypes</tt> in the first place was because of the nature of the
43778 <i>invoke</i> member:
43779 </p>
43780
43781 <blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
43782 R
43783 function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
43784 {
43785     if (f_ == 0)
43786         throw bad_function_call();
43787     return (*f_)(arg...);
43788 }
43789 </pre></blockquote>
43790
43791 <p>
43792 However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
43793 (as Sebastian correctly points out).  If rvalue arguments are supplied, <tt>MoveConstructible</tt>
43794 is sufficient.  Furthermore, the constraint need not be applied in <tt>function</tt>
43795 if I understand correctly.  Rather the client must apply the proper constraints
43796 at the call site.  Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
43797 be removed from the template class <tt>function</tt>.
43798 </p>
43799
43800 <p>
43801 Furthermore we need to mandate that the <i>invoker</i> is coded as:
43802 </p>
43803
43804 <blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
43805 R
43806 function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
43807 {
43808     if (f_ == 0)
43809         throw bad_function_call();
43810     return (*f_)(<b>std::forward&lt;ArgTypes&gt;(</b>arg<b>)</b>...);
43811 }
43812 </pre></blockquote>
43813
43814 <p>
43815 Note that <tt>ArgTypes&amp;&amp;</tt> (the "perfect forwarding signature") is not 
43816 appropriate here as this is not a deduced context for <tt>ArgTypes</tt>.  Instead
43817 the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
43818 type.  Catching these arguments by value makes sense to enable decay.
43819 </p>
43820
43821 <p>
43822 Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
43823 possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
43824 to the type-erased functor.  For object types, this will be a <tt>move</tt>.  For
43825 reference type <tt>ArgTypes</tt>, this will be a copy.  The end result <em>must</em> be
43826 that the following is a valid program:
43827 </p>
43828
43829 <blockquote><pre>#include &lt;functional&gt;
43830 #include &lt;memory&gt;
43831 #include &lt;cassert&gt;
43832
43833 std::unique_ptr&lt;int&gt;
43834 f(std::unique_ptr&lt;int&gt; p, int&amp; i)
43835 {
43836     ++i;
43837     return std::move(p);
43838 }
43839
43840 int main()
43841 {
43842     int i = 2;
43843     std::function&lt;std::unique_ptr&lt;int&gt;(std::unique_ptr&lt;int&gt;,
43844                                        int&amp;&gt; g(f);
43845     std::unique_ptr&lt;int&gt; p = g(std::unique_ptr&lt;int&gt;(new int(1)), i);
43846     assert(*p == 1);
43847     assert(i == 3);
43848 }
43849 </pre></blockquote>
43850
43851 <p><i>[
43852 Tested in pre-concepts rvalue-ref-enabled compiler.
43853 ]</i></p>
43854
43855
43856 <p>
43857 In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr&lt;int&gt;</tt>
43858 and the second <tt>ArgType</tt> is <tt>int&amp;</tt>.  Both <em>must</em> work!
43859 </p>
43860
43861 </blockquote>
43862
43863 <p><i>[
43864 2009-05-27 Daniel adds:
43865 ]</i></p>
43866
43867
43868 <blockquote>
43869 <p>
43870 in the 2009-05-01 comment of above mentioned issue Howard
43871 </p>
43872
43873 <ol type="a">
43874 <li>
43875 Recommends to replace the <tt>CopyConstructible</tt> requirement by a
43876 <tt>MoveConstructible</tt> requirement
43877 </li>
43878 <li>
43879 Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
43880 understand correctly. Rather the client must apply the proper constraints
43881 at the call site"
43882 </li>
43883 </ol>
43884 <p>
43885 I'm fine with (a), but I think comment (b) is incorrect, at least in the
43886 sense I read these sentences. Let's look at Howard's example code:
43887 </p>
43888
43889 <blockquote><pre>function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
43890 {
43891    if (f_ == 0)
43892        throw bad_function_call();
43893    return (*f_)(std::forward&lt;ArgTypes&gt;(arg)...);
43894 }
43895 </pre></blockquote>
43896
43897 <p>
43898 In the constrained scope of this <tt>operator()</tt> overload the expression
43899 "<tt>(*f_)(std::forward&lt;ArgTypes&gt;(arg)...)</tt>" must be valid. How can it
43900 do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
43901 </p>
43902 </blockquote>
43903
43904 <p><i>[
43905 2009-07 Frankfurt:
43906 ]</i></p>
43907
43908
43909 <blockquote>
43910 Leave this open and wait until concepts are removed from the Working
43911 Draft so that we know how to write the proposed resolution in terms of
43912 diffs to otherwise stable text.
43913 </blockquote>
43914
43915 <p><i>[
43916 2009-10 Santa Cruz:
43917 ]</i></p>
43918
43919
43920 <blockquote>
43921 Leave as open. Howard to provide wording. Howard welcomes any help.
43922 </blockquote>
43923
43924 <p><i>[
43925 2009-12-12 Jonathan Wakely adds:
43926 ]</i></p>
43927
43928
43929 <blockquote>
43930 <p>
43931 20.8.14.2 [func.wrap.func] says
43932 </p>
43933
43934 <blockquote>
43935 2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
43936 types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt> and a return type
43937 <tt>R</tt>, if, given lvalues <tt>t1, t2, ..., tN</tt> of types <tt>T1, T2, ...,
43938 TN</tt>, respectively, <tt>INVOKE (f, t1, t2, ..., tN)</tt> is well formed
43939 (20.7.2) and, if <tt>R</tt> is not <tt>void</tt>, convertible to <tt>R</tt>.
43940 </blockquote>
43941
43942 <p>
43943 N.B. lvalues, which means you can't use <tt>function&lt;R(T&amp;&amp;)&gt;</tt>
43944 or <tt>function&lt;R(unique_ptr&lt;T&gt;)&gt;</tt>
43945 </p>
43946
43947 <p>
43948 I recently implemented rvalue arguments in GCC's <tt>std::function</tt>, all
43949 that was needed was to use <tt>std::forward&lt;ArgTypes&gt;</tt> in a few
43950 places. The example in issue 815 works.
43951 </p>
43952
43953 <p>
43954 I think 815 could be resolved by removing the requirement that the target
43955 function be callable with lvalues.  Saying <tt>ArgTypes</tt> need to be
43956 <tt>CopyConstructible</tt> is wrong, and IMHO saying <tt>MoveConstructible</tt>
43957 is unnecessary, since the by-value signature implies that already, but if it is
43958 needed it should only be on <tt>operator()</tt>, not the whole class (you could
43959 in theory instantiate <tt>std::function&lt;R(noncopyable)&gt;</tt> as long as
43960 you don't invoke the call operator.)
43961 </p>
43962
43963 <p>
43964 I think defining invocation in terms of <tt>INVOKE</tt> already implies perfect
43965 forwarding, so we don't need to say explicitly that <tt>std::forward</tt> should
43966 be used (N.B. the types that are forwarded are those in <tt>ArgTypes</tt>, which
43967 can differ from the actual parameter types of the target function.  The actual
43968 parameter types have gone via type erasure, but that's not a problem - IMHO
43969 forwarding the arguments as <tt>ArgTypes</tt> is the right thing to do anyway.)
43970 </p>
43971
43972 <p>
43973 Is it sufficient to simply replace "lvalues" with "values"? or do we need to say
43974 something like "lvalues when <tt>Ti</tt> is an lvalue-reference and rvalues
43975 otherwise"?  I prefer the former, so I propose the following resolution for 815:
43976 </p>
43977
43978 <p>
43979 Edit 20.8.14.2 [func.wrap.func] paragraph 2:
43980 </p>
43981
43982 <blockquote>
43983 2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
43984 types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt> and a return type
43985 <tt>R</tt>, if, given <del>l</del>values <tt>t1, t2, ..., tN</tt> of types
43986 <tt>T1, T2, ..., TN</tt>, respectively, <tt>INVOKE (f, t1, t2, ..., tN)</tt> is
43987 well formed (20.7.2) and, if <tt>R</tt> is not <tt>void</tt>, convertible to
43988 <tt>R</tt>.
43989 </blockquote>
43990 </blockquote>
43991
43992 <p><i>[
43993 2009-12-12 Daniel adds:
43994 ]</i></p>
43995
43996
43997 <blockquote>
43998 I don't like the reduction to "values" and prefer the alternative solution
43999 suggested using "lvalues when Ti is an lvalue-reference and rvalues otherwise".
44000 The reason why I dislike the shorter version is based on different usages of
44001 "values" as part of defining the semantics of requirement tables via
44002 expressions. E.g. 20.2.1 [utility.arg.requirements]/1 says "<tt>a</tt>,
44003 <tt>b</tt>, and <tt>c</tt> are values of type <tt>const T;</tt>" or similar in
44004 23.2.1 [container.requirements.general]/4 or /14 etc. My current reading
44005 of all these parts is that <em>both</em> rvalues and lvalues are required to be
44006 supported, but this interpretation would violate the intention of the suggested
44007 fix of #815, if I correctly understand Jonathan's rationale.
44008 </blockquote>
44009
44010 <p><i>[
44011 2009-12-12 Howard adds:
44012 ]</i></p>
44013
44014
44015 <blockquote>
44016 <blockquote>
44017 "lvalues when Ti is an lvalue-reference and rvalues otherwise"
44018 </blockquote>
44019 <p>
44020 doesn't quite work here because the <tt>Ti</tt> aren't deduced.  They are
44021 specified by the <tt>function</tt> type.  <tt>Ti</tt> might be <tt>const
44022 int&amp;</tt> (an lvalue reference) and a valid <tt>ti</tt> might be <tt>2</tt>
44023 (a non-const rvalue).  I've taken another stab at the wording using
44024 "expressions" and "bindable to".
44025 </p>
44026 </blockquote>
44027
44028 <p><i>[
44029 2010-02-09 Wording updated by Jonathan, Ganesh and Daniel.
44030 ]</i></p>
44031
44032
44033 <p><i>[
44034 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
44035 ]</i></p>
44036
44037
44038 <p><i>[
44039 2010-02-10 Daniel opens to improve wording.
44040 ]</i></p>
44041
44042
44043 <p><i>[
44044 2010-02-11 This issue is now addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>.
44045 ]</i></p>
44046
44047
44048 <p><i>[
44049 2010-02-12 Moved to Tentatively NAD Editorial after 5 positive votes on
44050 c++std-lib.  Rationale added below.
44051 ]</i></p>
44052
44053
44054
44055
44056 <p><b>Rationale:</b></p>
44057 <p>
44058 Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>.
44059 </p>
44060
44061
44062 <p><b>Proposed resolution:</b></p>
44063 <p>
44064 Edit 20.8.14.2 [func.wrap.func] paragraph 2:
44065 </p>
44066
44067 <blockquote>
44068 <p>
44069 2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
44070 types <del><tt>T1, T2, ..., TN</tt> in</del> <tt>ArgTypes</tt> and <del>a</del>
44071 return type <tt>R</tt><del>,</del> if<del>, given lvalues <tt>t1, t2, ...,
44072 tN</tt> of types <tt>T1, T2, ..., TN</tt>, respectively,</del> <ins>the
44073 expression</ins> <tt><i>INVOKE</i>(f, <ins>declval&lt;ArgTypes&gt;()...,
44074 R</ins><del>t1, t2, ..., tN</del>)</tt><ins>, considered as an unevaluated
44075 operand (5 [expr]),</ins> is well formed (20.7.2)<del> and, if
44076 <tt>R</tt> is not <tt>void</tt>, convertible to <tt>R</tt></del>.
44077 </p>
44078
44079 </blockquote>
44080
44081
44082
44083
44084
44085 <hr>
44086 <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
44087 <p><b>Section:</b> 20.8.10.1.2 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
44088  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08 <b>Last modified:</b> 2010-11-19</p>
44089 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
44090 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
44091 <p><b>Discussion:</b></p>
44092 <p>
44093 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
44094 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
44095 </p>
44096 <p>
44097 However, no guarantees are provided for the copy ctor of the functor
44098 returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
44099 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
44100 call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
44101 TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
44102 Everything without an exception-specification may throw
44103 implementation-defined exceptions unless otherwise specified, C++03
44104 17.4.4.8/3.)
44105 </p>
44106 <p>
44107 Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
44108 to cover both calling <tt>bind()</tt> and copying the returned functor?
44109 </p>
44110
44111 <p><i>[
44112 Howard adds:
44113 ]</i></p>
44114
44115
44116 <blockquote>
44117 <tt>tuple</tt> construction should probably have a similar guarantee.
44118 </blockquote>
44119
44120 <p><i>[
44121 San Francisco:
44122 ]</i></p>
44123
44124
44125 <blockquote>
44126 Howard to provide wording.
44127 </blockquote>
44128
44129 <p><i>[
44130 Post Summit, Anthony provided wording.
44131 ]</i></p>
44132
44133
44134 <p><i>[
44135 Batavia (2009-05):
44136 ]</i></p>
44137
44138 <blockquote>
44139 Part of all of this issue appears to be rendered moot
44140 by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a> (q.v.).
44141 We recommend the issues be considered simultaneously
44142 (or possibly even merged)
44143 to ensure there is no overlap.
44144 Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
44145 </blockquote>
44146
44147 <p><i>[
44148 2009-07 Frankfurt:
44149 ]</i></p>
44150
44151
44152 <blockquote>
44153 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a> (see below). Leave Open.
44154 </blockquote>
44155
44156 <p><i>[
44157 2009-10 Santa Cruz:
44158 ]</i></p>
44159
44160
44161 <blockquote>
44162 Move to Ready. Decoupling from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
44163 </blockquote>
44164
44165 <p><i>[
44166 2010-02-11 Moved from Ready to Tentatively NAD Editorial, rationale added below.
44167 ]</i></p>
44168
44169
44170
44171
44172 <p><b>Rationale:</b></p>
44173 <p>
44174 This issue is solved as proposed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
44175 </p>
44176
44177
44178 <p><b>Proposed resolution:</b></p>
44179 <p>
44180 Add a new sentence to the end of paragraphs 2 and 4 of 20.8.10.1.2 [func.bind.bind]:
44181 </p>
44182
44183 <blockquote>
44184 <p>
44185 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
44186 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
44187 represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
44188 <tt>v1, v2, ..., vN</tt> are determined as specified below.
44189 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
44190 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
44191 in <tt>BoundArgs...</tt> throw an exception.</ins>
44192 </p>
44193 <p>...</p>
44194 <p>
44195 -5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
44196 for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
44197 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
44198 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
44199 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
44200 in <tt>BoundArgs...</tt> throw an exception.</ins>
44201 </p>
44202
44203 </blockquote>
44204
44205
44206
44207
44208
44209 <hr>
44210 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
44211 <p><b>Section:</b> 20.8.10.1.2 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
44212  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2010-10-29</p>
44213 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
44214 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
44215 <p><b>Discussion:</b></p>
44216 <p><b>Addresses US 72, JP 38 and DE 21</b></p>
44217
44218 <p>
44219 The functor returned by <tt>bind()</tt> should have a move constructor that
44220 requires only move construction of its contained functor and bound arguments.
44221 That way move-only functors can be passed to objects such as <tt>thread</tt>.
44222 </p>
44223 <p>
44224 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>.
44225 </p>
44226
44227 <p>
44228 US 72:
44229 </p>
44230
44231 <blockquote>
44232 <tt>bind</tt> should support move-only functors and bound arguments.
44233 </blockquote>
44234
44235 <p>
44236 JP 38:
44237 </p>
44238
44239 <blockquote>
44240 <p>
44241 add the move requirement for bind's return type.
44242 </p>
44243 <p>
44244 For example, assume following <tt>th1</tt> and <tt>th2</tt>,
44245 </p>
44246
44247 <blockquote><pre>void f(vector&lt;int&gt; v) { }
44248
44249 vector&lt;int&gt; v{ ... };
44250 thread th1([v]{ f(v); });
44251 thread th2(bind(f, v));
44252 </pre></blockquote>
44253
44254 <p>
44255 When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
44256 expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
44257 expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
44258 return type doesn't have the requirement of Move, so it may not
44259 moved but copied.
44260 </p>
44261 <p>
44262 Add the requirement of move to get rid of this useless copy.
44263 </p>
44264 <p>
44265 And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
44266 </p>
44267 </blockquote>
44268
44269 <p>
44270 DE 21
44271 </p>
44272
44273 <blockquote>
44274 The specification for bind claims twice that "the values and types for
44275 the bound arguments v1, v2, ..., vN are determined as specified below".
44276 No such specification appears to exist.
44277 </blockquote>
44278
44279 <p><i>[
44280 San Francisco:
44281 ]</i></p>
44282
44283
44284 <blockquote>
44285 Howard to provide wording.
44286 </blockquote>
44287
44288 <p><i>[
44289 Post Summit Alisdair and Howard provided wording.
44290 ]</i></p>
44291
44292
44293 <blockquote>
44294 <p>
44295 Several issues are being combined in this resolution.  They are all touching the
44296 same words so this is an attempt to keep one issue from stepping on another, and
44297 a place to see the complete solution in one place.
44298 </p>
44299
44300 <ol>
44301 <li>
44302 <tt>bind</tt> needs to be "moved".
44303 </li>
44304 <li>
44305 20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
44306 </li>
44307 <li>
44308 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> argues for a way to pass by &amp;&amp; for
44309 efficiency but retain the decaying behavior of pass by value for the
44310 <tt>thread</tt> constructor.  That same solution is applicable here.
44311 </li>
44312 </ol>
44313 </blockquote>
44314
44315 <p><i>[
44316 Batavia (2009-05):
44317 ]</i></p>
44318
44319 <blockquote>
44320 <p>
44321 We were going to recommend moving this issue to Tentatively Ready
44322 until we noticed potential overlap with issue 816 (q.v.).
44323 </p>
44324 <p>
44325 Move to Open,
44326 and recommend both issues be considered together
44327 (and possibly merged).
44328 </p>
44329 </blockquote>
44330
44331 <p><i>[
44332 2009-07 Frankfurt:
44333 ]</i></p>
44334
44335
44336 <blockquote>
44337 The proposed resolution uses concepts. Leave Open.
44338 </blockquote>
44339
44340 <p><i>[
44341 2009-10 Santa Cruz:
44342 ]</i></p>
44343
44344
44345 <blockquote>
44346 Leave as Open. Howard to provide deconceptified wording.
44347 </blockquote>
44348
44349 <p><i>[
44350 2009-11-07 Howard updates wording.
44351 ]</i></p>
44352
44353
44354 <p><i>[
44355 2009-11-15 Further updates by Peter, Chris and Daniel.
44356 ]</i></p>
44357
44358
44359 <p><i>[
44360 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
44361 ]</i></p>
44362
44363
44364
44365 <p><b>Proposed resolution:</b></p>
44366 <p>
44367 Change 20.8 [function.objects] p2:
44368 </p>
44369
44370 <blockquote><pre>template&lt;class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
44371   <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
44372 template&lt;class R, class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
44373   <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
44374 </pre></blockquote>
44375
44376 <p>
44377 Change 20.8.2 [func.require]:
44378 </p>
44379
44380 <blockquote>
44381 <p>
44382 4 Every call wrapper (20.8.1 [func.def]) shall be
44383 <tt><del>Copy</del><ins>Move</ins>Constructible</tt>. A <i>simple call
44384 wrapper</i> is a call wrapper that is <ins><tt>CopyConstructible</tt> and</ins>
44385 <tt>CopyAssignable</tt> and whose copy constructor<ins>, move constructor</ins> and assignment operator do not
44386 throw exceptions. A <i>forwarding call wrapper</i> is a call wrapper that can be
44387 called with an argument list. [<i>Note:</i> in a typical implementation
44388 forwarding call wrappers have an overloaded function call operator of the form
44389 </p>
44390 <blockquote><pre>template&lt;class... <del>ArgTypes</del><ins>UnBoundsArgs</ins>&gt;
44391 R operator()(<del>ArgTypes</del><ins>UnBoundsArgs</ins>&amp;&amp;... <ins>unbound_</ins>args) cv-qual;
44392 </pre></blockquote>
44393 <p>
44394 \97 <i>end note</i>]
44395 </p>
44396 </blockquote>
44397
44398 <p>
44399 Change 20.8.10.1.2 [func.bind.bind]:
44400 </p>
44401
44402 <blockquote>
44403 <p><ins>
44404 Within this clause:
44405 </ins></p>
44406
44407 <ul>
44408 <li><ins>
44409 Let <tt>FD</tt> be a synonym for the type <tt>decay&lt;F&gt;::type</tt>.
44410 </ins></li>
44411 <li><ins>
44412 Let <tt>fd</tt> be an lvalue of type <tt>FD</tt> constructed from
44413 <tt>std::forward&lt;F&gt;(f)</tt>.
44414 </ins></li>
44415 <li><ins>
44416 Let <tt>Ti</tt> be a synonym for the i<sup><i>th</i></sup> type in the
44417 template parameter pack <tt>BoundArgs</tt>.
44418 </ins></li>
44419 <li><ins>
44420 Let <tt>TiD</tt> be a synonym for the type <tt>decay&lt;Ti&gt;::type</tt>.
44421 </ins></li>
44422 <li><ins>
44423 Let <tt>ti</tt> be the i<sup><i>th</i></sup> argument in the function parameter
44424 pack <tt>bound_args</tt>.
44425 </ins></li>
44426 <li><ins>
44427 Let <tt>tid</tt> be an lvalue of type <tt>TiD</tt> constructed from
44428 <tt>std::forward&lt;Ti&gt;(ti)</tt>.
44429 </ins></li>
44430 <li><ins>
44431 Let <tt>Uj</tt> be the j<sup><i>th</i></sup> deduced type of the <tt>UnBoundArgs&amp;&amp;...</tt>
44432 parameter of the <tt>operator()</tt> of the forwarding call wrapper.
44433 </ins></li>
44434 <li><ins>
44435 Let <tt>uj</tt> be the j<sup><i>th</i></sup> argument associated with <tt>Uj</tt>.
44436 </ins></li>
44437 </ul>
44438
44439 <pre>template&lt;class F, class... BoundArgs&gt;
44440   <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
44441 </pre>
44442
44443 <blockquote>
44444 <p>
44445 -1- <i>Requires:</i>
44446 <ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
44447 shall be <tt>true</tt>.</ins>
44448 <ins>For each <tt>Ti</tt> in <tt>BoundArgs</tt>,
44449 <tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be
44450 <tt>true</tt></ins>.
44451 <del><tt>F</tt> and each <tt>Ti</tt> in
44452 <tt>BoundArgs</tt> shall be CopyConstructible.</del>
44453 <tt><i>INVOKE</i>(f<ins>d</ins>, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for some values
44454 <i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
44455 </p>
44456 <p>
44457 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak
44458 result type (20.8.2 [func.require]). The effect of <tt>g(u1, u2,
44459 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1, v2, ..., vN,
44460 result_of&lt;F<ins>D</ins> <i>cv</i> (V1, V2, ..., VN)&gt;::type)</tt>, where
44461 <i>cv</i> represents the <i>cv</i>-qualifiers of <tt>g</tt> and the
44462 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are
44463 determined as specified below.
44464 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
44465 exception if and only if the corresponding constructor of <tt>FD</tt> or of any of the types
44466 <tt>TiD</tt> throws an exception.</ins>
44467 </p>
44468 <p>
44469 -3- <i>Throws:</i> Nothing unless the <del>copy</del>
44470 construct<ins>ion</ins><del>or</del> of
44471 <tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
44472 <tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
44473 expansion</del> throws an exception.
44474 </p>
44475 <p>
44476 <ins>
44477 <i>Remarks:</i> The <i>unspecified</i> return type shall satisfy the
44478 requirements of <tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and
44479 <tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt> then
44480 the <i>unspecified</i> return type shall satisfy the requirements of
44481 <tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
44482 <tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> \97
44483 <i>end note</i>]
44484 </ins>
44485 </p>
44486 </blockquote>
44487
44488 <pre>template&lt;class R, class F, class... BoundArgs&gt;
44489   <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
44490 </pre>
44491
44492 <blockquote>
44493 <p>
44494 -4- <i>Requires:</i>
44495 <ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
44496 shall be <tt>true</tt>.</ins>
44497 <ins>For each <tt>Ti</tt> in <tt>BoundArgs</tt>,
44498 <tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be
44499 <tt>true</tt></ins>.
44500 <del><tt>F</tt> and each <tt>Ti</tt> in
44501 <tt>BoundArgs</tt> shall be CopyConstructible.</del>
44502 <tt><i>INVOKE</i>(f<ins>d</ins>, w1,
44503 w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2,
44504 ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
44505 </p>
44506 <p>
44507 -5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested
44508 type <tt>result_type</tt> defined as a synonym for <tt>R</tt>. The
44509 effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1,
44510 v2, ..., vN, R)</tt>, where the values and types of the bound arguments
44511 <tt>v1, v2, ..., vN</tt> are determined as specified below.
44512 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
44513 exception if and only if the corresponding constructor of <tt>FD</tt> or of any of the types
44514 <tt>TiD</tt> throws an exception.</ins>
44515 </p>
44516 <p>
44517 -6- <i>Throws:</i> Nothing unless the <del>copy</del>
44518 construct<ins>ion</ins><del>or</del> of
44519 <tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
44520 <tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
44521 expansion</del> throws an exception.
44522 </p>
44523 <p>
44524 <ins>
44525 <i>Remarks:</i> The <i>unspecified</i> return type shall satisfy the
44526 requirements of <tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and
44527 <tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt> then
44528 the <i>unspecified</i> return type shall satisfy the requirements of
44529 <tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
44530 <tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> \97
44531 <i>end note</i>]
44532 </ins>
44533 </p>
44534 </blockquote>
44535
44536 <p>
44537 -7- The values of the <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
44538 their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type<ins>s
44539 <tt>TiD</tt> derived from</ins>
44540 <del>of the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> of type
44541 <tt>Ti</tt> in <tt>BoundArgs</tt> in</del>
44542 the call to <tt>bind</tt> and the
44543 <i>cv</i>-qualifiers <i>cv</i> of the call wrapper <tt>g</tt> as
44544 follows:
44545 </p>
44546
44547 <ul>
44548 <li>
44549 if <tt><del>ti</del> <ins>TiD</ins></tt> is <del>of type</del>
44550 <tt>reference_wrapper&lt;T&gt;</tt> the argument is
44551 <tt>ti<ins>d</ins>.get()</tt> and its type <tt>Vi</tt> is <tt>T&amp;</tt>;
44552 </li>
44553 <li>
44554 if the value of
44555 <tt><del>std::</del>is_bind_expression&lt;Ti<ins>D</ins>&gt;::value</tt> is
44556 <tt>true</tt> the argument is <tt>ti<ins>d</ins>(<ins>std::forward&lt;Uj&gt;(uj)...</ins> <del>u1, u2, ..., uM</del>)</tt>
44557 and its type <tt>Vi</tt> is <tt>result_of&lt;Ti<ins>D</ins> <i>cv</i>
44558 (<ins>Uj...</ins> <del>U1&amp;, U2&amp;, ..., UM&amp;</del>)&gt;::type</tt>;
44559 </li>
44560 <li>
44561 if the value <tt>j</tt> of
44562 <tt><del>std::</del>is_placeholder&lt;Ti<ins>D</ins>&gt;::value</tt> is not zero
44563 the argument is <tt>std::forward&lt;Uj&gt;(uj)</tt> and its type
44564 <tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;
44565 </li>
44566 <li>
44567 otherwise the value is <tt>ti<ins>d</ins></tt> and its type <tt>Vi</tt>
44568 is <tt>Ti<ins>D</ins> <i>cv</i> &amp;</tt>.
44569 </li>
44570 </ul>
44571
44572 </blockquote>
44573
44574
44575
44576
44577
44578
44579 <hr>
44580 <h3><a name="818"></a>818. wording for memory ordering</h3>
44581 <p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
44582  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22 <b>Last modified:</b> 2010-10-29</p>
44583 <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>
44584 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
44585 <p><b>Discussion:</b></p>
44586 <p>
44587 29.3 [atomics.order] p1 says in the table that
44588 </p>
44589
44590 <blockquote>
44591 <table border="1">
44592 <tbody><tr>
44593 <th>Element</th><th>Meaning</th>
44594 </tr>
44595 <tr>
44596 <td><tt>memory_order_acq_rel</tt></td>
44597 <td>the operation has both acquire and release semantics</td>
44598 </tr>
44599 </tbody></table>
44600 </blockquote>
44601
44602 <p>
44603 To my naked eye, that seems to imply that even an atomic read has both
44604 acquire and release semantics.
44605 </p>
44606
44607 <p>
44608 Then, p1 says in the table:
44609 </p>
44610
44611 <blockquote>
44612 <table border="1">
44613 <tbody><tr>
44614 <th>Element</th><th>Meaning</th>
44615 </tr>
44616 <tr>
44617 <td><tt>memory_order_seq_cst</tt></td>
44618 <td>the operation has both acquire and release semantics,
44619     and, in addition, has sequentially-consistent operation ordering</td>
44620 </tr>
44621 </tbody></table>
44622 </blockquote>
44623
44624 <p>
44625 So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
44626 constraints.
44627 </p>
44628
44629 <p>
44630 I'm then reading p2, where it says:
44631 </p>
44632
44633 <blockquote>
44634 The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
44635 on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
44636 are release operations on the affected locations.
44637 </blockquote>
44638
44639 <p>
44640 That seems to imply that atomic reads only have acquire semantics.  If that
44641 is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
44642 load/store operations as well?
44643 </p>
44644
44645 <p>
44646 Also, the table in p1 contains phrases with "thus" that seem to indicate
44647 consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
44648 normative text, for the fear of redundant or inconsistent specification with
44649 the other normative text.
44650 </p>
44651
44652 <p>
44653 Double-check 29.6 [atomics.types.operations] that each
44654 operation clearly says whether it's a load or a store operation, or
44655 both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
44656 </p>
44657
44658 <p>
44659 29.3 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
44660 1.10 [intro.multithread], it's just used in notes there.
44661 </p>
44662
44663 <p>
44664 And why does 29.6 [atomics.types.operations] p9 for "load" say:
44665 </p>
44666
44667
44668 <blockquote>
44669 <i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
44670 nor <tt>memory_order_acq_rel</tt>.
44671 </blockquote>
44672
44673 <p>
44674 (Since this is exactly the same restriction as for "store", it seems to be a typo.)
44675 </p>
44676
44677 <p>
44678 And then: 29.6 [atomics.types.operations] p12:
44679 </p>
44680
44681 <blockquote>
44682 These operations are read-modify-write operations in the sense of the
44683 "synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
44684 evaluation that produced the input value synchronize with any evaluation
44685 that reads the updated value.
44686 </blockquote>
44687
44688 <p>
44689 This is redundant with 1.10 [intro.multithread], see above for the reasoning.
44690 </p>
44691
44692 <p><i>[
44693 San Francisco:
44694 ]</i></p>
44695
44696
44697 <blockquote>
44698 <p>
44699 Boehm: "I don't think that this changes anything terribly substantive,
44700 but it improves the text."
44701 </p>
44702 <p>
44703 Note that "Rephrase the table in as [sic] follows..." should read
44704 "Replace the table in [atomics.order] with the following...."
44705 </p>
44706 <p>
44707 The proposed resolution needs more work. Crowl volunteered to address
44708 all of the atomics issues in one paper.
44709 </p>
44710
44711 <p>
44712 This issue is addressed in
44713 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
44714 </p>
44715 </blockquote>
44716
44717
44718 <p><b>Proposed resolution:</b></p>
44719 <p>
44720 edit 29.3 [atomics.order], paragraph 1 as follows.
44721 </p>
44722
44723 <blockquote>
44724 <p>
44725 The enumeration <code>memory_order</code>
44726 specifies the detailed regular (non-atomic) memory synchronization order
44727 as defined in <del>Clause 1.7</del> <ins>section 1.10</ins>
44728 and may provide for operation ordering.
44729 Its enumerated values and their meanings are as follows:
44730 </p>
44731 <blockquote>
44732 <dl>
44733 <dt><ins>For <code>memory_order_relaxed</code>,</ins></dt>
44734 <dd><ins>no operation orders memory.</ins></dd>
44735 <dt><ins>For <code>memory_order_release</code>,
44736 <code>memory_order_acq_rel</code>,
44737 and <code>memory_order_seq_cst</code>,</ins></dt>
44738 <dd><ins>a store operation performs a release operation
44739 on the affected memory location.</ins></dd>
44740 <dt><ins>For <code>memory_order_consume</code>,</ins></dt>
44741 <dd><ins>a load operation performs a consume operation
44742 on the affected memory location.</ins></dd>
44743 <dt><ins>For <code>memory_order_acquire</code>,
44744 <code>memory_order_acq_rel</code>,
44745 and <code>memory_order_seq_cst</code>,</ins></dt>
44746 <dd><ins>a load operation performs an acquire operation
44747 on the affected memory location.</ins></dd>
44748 </dl>
44749 </blockquote>
44750 </blockquote>
44751
44752 <p>
44753 remove table 136 in 29.3 [atomics.order].
44754 </p>
44755
44756 <blockquote>
44757 <table border="1">
44758 <caption><del>Table 136 \97 memory_order effects</del></caption>
44759 <tbody><tr><th><del>Element</del></th><th><del>Meaning</del></th></tr>
44760 <tr><td valign="top"><del><code>memory_order_relaxed</code></del></td>
44761 <td valign="top"><del>the operation does not order memory</del></td></tr>
44762 <tr><td valign="top"><del><code>memory_order_release</code></del></td>
44763 <td valign="top"><del>the operation
44764 performs a release operation on the affected memory location,
44765 thus making regular memory writes visible to other threads
44766 through the atomic variable to which it is applied</del></td></tr>
44767 <tr><td valign="top"><del><code>memory_order_acquire</code></del></td>
44768 <td valign="top"><del>the operation
44769 performs an acquire operation on the affected memory location,
44770 thus making regular memory writes in other threads
44771 released through the atomic variable to which it is applied
44772 visible to the current thread</del></td></tr>
44773 <tr><td valign="top"><del><code>memory_order_consume</code></del></td>
44774 <td valign="top"><del>the operation
44775 performs a consume operation on the affected memory location,
44776 thus making regular memory writes in other threads
44777 released through the atomic variable to which it is applied
44778 visible to the regular memory reads
44779 that are dependencies of this consume operation.</del></td></tr>
44780 <tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td>
44781 <td valign="top"><del>the operation has both acquire and release semantics</del></td></tr>
44782 <tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td>
44783 <td valign="top"><del>the operation has both acquire and release semantics,
44784 and, in addition, has sequentially-consistent operation ordering</del></td></tr>
44785 </tbody></table>
44786 </blockquote>
44787
44788 <p>
44789 edit 29.3 [atomics.order], paragraph 2 as follows.
44790 </p>
44791
44792 <blockquote>
44793 <p>
44794 <del>The <code>memory_order_seq_cst</code> operations that load a value
44795 are acquire operations on the affected locations.
44796 The <code>memory_order_seq_cst</code> operations that store a value
44797 are release operations on the affected locations.
44798 In addition, in a consistent execution,
44799 there</del> <ins>There</ins> <del>must be</del> <ins>is</ins>
44800 a single total order <var>S</var>
44801 on all <code>memory_order_seq_cst</code> operations,
44802 consistent with the happens before order
44803 and modification orders for all affected locations,
44804 such that each <code>memory_order_seq_cst</code> operation
44805 observes either the last preceding modification
44806 according to this order <var>S</var>,
44807 or the result of an operation that is not <code>memory_order_seq_cst</code>.
44808 [<i>Note:</i>
44809 Although it is not explicitly required that <var>S</var> include locks,
44810 it can always be extended to an order
44811 that does include lock and unlock operations,
44812 since the ordering between those
44813 is already included in the happens before ordering.
44814 \97<i>end note</i>]
44815 </p>
44816 </blockquote>
44817
44818
44819
44820
44821
44822
44823 <hr>
44824 <h3><a name="819"></a>819. rethrow_if_nested</h3>
44825 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
44826  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25 <b>Last modified:</b> 2010-10-29</p>
44827 <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>
44828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
44829 <p><b>Discussion:</b></p>
44830 <p>
44831 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
44832 got it quite right.
44833 </p>
44834
44835 <p>
44836 The current wording says:
44837 </p>
44838
44839 <blockquote>
44840 <pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
44841 </pre>
44842 <blockquote>
44843 <p>
44844 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
44845 is publicly derived from <tt>nested_exception</tt>.
44846 </p>
44847 </blockquote>
44848 </blockquote>
44849
44850 <p>
44851 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
44852 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
44853 required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
44854 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
44855 </p>
44856
44857 <p><i>[
44858 San Francisco:
44859 ]</i></p>
44860
44861
44862 <blockquote>
44863 Alisdair was volunteered to provide wording.
44864 </blockquote>
44865
44866 <p><i>[
44867 2009-10 Santa Cruz:
44868 ]</i></p>
44869
44870
44871 <blockquote>
44872 Leave as Open. Alisdair to provide wording.
44873 </blockquote>
44874
44875 <p><i>[
44876 2009-11-09 Alisdair provided wording.
44877 ]</i></p>
44878
44879
44880 <p><i>[
44881 2010-03-10 Dietmar updated wording.
44882 ]</i></p>
44883
44884
44885 <p><i>[
44886 2010 Pittsburgh:
44887 ]</i></p>
44888
44889
44890 <blockquote>
44891 Moved to Ready for Pittsburgh.
44892 </blockquote>
44893
44894
44895
44896 <p><b>Proposed resolution:</b></p>
44897 <p>
44898 Change 18.8.6 [except.nested], p8:
44899 </p>
44900
44901 <blockquote><pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
44902 </pre>
44903 <blockquote>
44904 -8- <i>Effects:</i> <del>Calls <tt>e.rethrow_nested()</tt>
44905 o</del><ins>O</ins>nly if <ins>the dynamic type of</ins> <tt>e</tt> is
44906 publicly <ins>and unambiguously</ins> derived from
44907 <tt>nested_exception</tt> <ins>this calls
44908 <tt>dynamic_cast&lt;const nested_exception&amp;&gt;(e).rethrow_nested()</tt></ins>.
44909 </blockquote>
44910 </blockquote>
44911
44912
44913
44914
44915
44916
44917 <hr>
44918 <h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
44919 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
44920  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-03-26 <b>Last modified:</b> 2010-10-29</p>
44921 <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>
44922 <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>
44923 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
44924 <p><b>Discussion:</b></p>
44925 <p>
44926 As of N2521, the Working Paper appears to be silent about what
44927 <tt>current_exception()</tt> should do if it tries to copy the currently handled
44928 exception and its copy constructor throws.  18.8.5 [propagation]/7 says "If the
44929 function needs to allocate memory and the attempt fails, it returns an
44930 <tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
44931 doesn't say anything about what should happen if memory allocation
44932 succeeds but the actual copying fails.
44933 </p>
44934
44935 <p>
44936 I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
44937 to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
44938 object that refers to an instance of the copy ctor's thrown exception
44939 (but if that has a throwing copy ctor, an infinite loop can occur), or
44940 (3) call <tt>terminate()</tt>.
44941 </p>
44942
44943 <p>
44944 I believe that <tt>terminate()</tt> is the most reasonable course of action, but
44945 before we go implement that, I wanted to raise this issue.
44946 </p>
44947
44948 <p><i>[
44949 Peter's summary:
44950 ]</i></p>
44951
44952
44953 <blockquote>
44954 <p>
44955 The current practice is to not have throwing copy constructors in
44956 exception classes, because this can lead to <tt>terminate()</tt> as described in
44957 15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
44958 consistent and does not introduce any new problems.
44959 </p>
44960
44961 <p>
44962 However, the resolution of core issue 475 may relax this requirement:
44963 </p>
44964
44965 <blockquote>
44966 The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
44967 return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
44968 should not be called if that constructor exits with an exception.
44969 </blockquote>
44970
44971 <p>
44972 Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
44973 (3) doesn't seem reasonable as it is deemed too drastic a response in a
44974 recoverable situation.
44975 </p>
44976
44977 <p>
44978 Option (2) cannot be adopted by itself, because a potential infinite
44979 recursion will need to be terminated by one of the other options.
44980 </p>
44981
44982 </blockquote>
44983
44984
44985 <p><b>Proposed resolution:</b></p>
44986 <p>
44987 Add the following paragraph after 18.8.5 [propagation]/7:
44988 </p>
44989
44990 <blockquote>
44991 <p>
44992 <i>Returns (continued):</i> If the attempt to copy the current exception
44993 object throws an exception, the function returns an <tt>exception_ptr</tt> that
44994 refers to the thrown exception or, if this is not possible, to an
44995 instance of <tt>bad_exception</tt>.
44996 </p>
44997 <p>
44998 [<i>Note:</i> The copy constructor of the thrown exception may also fail, so
44999 the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
45000 infinite recursion. <i>-- end note.</i>]
45001 </p>
45002 </blockquote>
45003
45004
45005
45006 <p><b>Rationale:</b></p>
45007 <p><i>[
45008 San Francisco:
45009 ]</i></p>
45010
45011
45012 <blockquote>
45013 <p>
45014 Pete: there may be an implied assumption in the proposed wording that
45015 current_exception() copies the existing exception object; the
45016 implementation may not actually do that.
45017 </p>
45018 <p>
45019 Pete will make the required editorial tweaks to rectify this.
45020 </p>
45021 </blockquote>
45022
45023
45024
45025
45026
45027 <hr>
45028 <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
45029 <p><b>Section:</b> 20.9.9.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
45030  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-30 <b>Last modified:</b> 2010-10-29</p>
45031 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
45032 <p><b>Discussion:</b></p>
45033 <p>
45034 Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
45035 </p>
45036
45037 <blockquote>
45038 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
45039 </pre>
45040
45041 <p>
45042 -1- <i>Requires:</i> Does not accept pointer types which are convertible
45043 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
45044 required). [<i>Note:</i> One implementation technique is to create a private
45045 templated overload. <i>-- end note</i>]
45046 </p>
45047 </blockquote>
45048
45049 <p>
45050 This could be cleaned up by mandating the overload as a public deleted
45051 function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
45052 to be a stronger match than the deleted overload. Words...
45053 </p>
45054
45055
45056 <p><b>Proposed resolution:</b></p>
45057 <p>
45058 Add to class template definition in 20.9.9.3 [unique.ptr.runtime]
45059 </p>
45060
45061 <blockquote>
45062 <pre>// modifiers 
45063 pointer release(); 
45064 void reset(pointer p = pointer()); 
45065 <ins>void reset( nullptr_t );</ins>
45066 <ins>template&lt; typename U &gt; void reset( U ) = delete;</ins>
45067 void swap(unique_ptr&amp;&amp; u);
45068 </pre>
45069 </blockquote>
45070
45071 <p>
45072 Update 20.9.9.3.3 [unique.ptr.runtime.modifiers]
45073 </p>
45074
45075 <blockquote>
45076 <pre>void reset(pointer p = pointer());
45077 <ins>void reset(nullptr_t);</ins>
45078 </pre>
45079
45080 <p>
45081 <del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
45082 to <tt>pointer</tt> (diagnostic
45083 required). [<i>Note:</i> One implementation technique is to create a private
45084 templated overload. <i>-- end note</i>]</del>
45085 </p>
45086 <p>
45087 <i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
45088 </p>
45089 <p>...</p>
45090 </blockquote>
45091
45092 <p><i>[
45093 Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
45094 ]</i></p>
45095
45096
45097
45098
45099
45100
45101 <hr>
45102 <h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
45103 <p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
45104  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09 <b>Last modified:</b> 2010-11-20</p>
45105 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
45106 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
45107 <p><b>Discussion:</b></p>
45108 <p>
45109 N2588 seems to have added an <tt>operator()</tt> member function to the
45110 <tt>identity&lt;&gt;</tt> helper in 20.3.3 [forward].  I believe this change makes it no
45111 longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
45112 forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
45113 </p>
45114
45115 <p>
45116 Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
45117 the member function's presence.
45118 </p>
45119
45120 <p><i>[
45121 Sophia Antipolis:
45122 ]</i></p>
45123
45124
45125 <blockquote>
45126 <p>
45127 Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
45128 </p>
45129 <p>
45130 Alisdair: also consider cv-qualified <tt>void</tt>.
45131 </p>
45132 <p>
45133 Alberto provided proposed wording.
45134 </p>
45135 </blockquote>
45136
45137 <p><i>[
45138 2009-07-30 Daniel reopens:
45139 ]</i></p>
45140
45141
45142 <blockquote>
45143 <p>
45144 This issue became closed, because the <tt>ReferentType</tt> requirement
45145 fixed the problem - this is no longer the case. In retrospective it seems
45146 to be that the root of current issues around <tt>std::identity</tt> (823, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>,
45147 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>)
45148 is that it was standardized as something very different (an unconditional
45149 type mapper) than traditional usage indicated (a function object that should
45150 derive from <tt>std::unary_function)</tt>, as the SGI definition does. This issue could
45151 be solved, if <tt>std::identity</tt> is removed (one proposal of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>), but until this
45152 has been decided, this issue should remain open. An alternative for
45153 removing it, would be, to do the following:
45154 </p>
45155
45156 <ol type="a">
45157 <li>
45158 <p>
45159 Let <tt>identity</tt> stay as a <em>real</em> function object, which would
45160 now properly
45161 derive from <tt>unary_function</tt>:
45162 </p>
45163
45164 <blockquote><pre>template &lt;class T&gt; struct identity : unary_function&lt;T, T&gt; {
45165   const T&amp; operator()(const T&amp;) const;
45166 };
45167 </pre></blockquote>
45168 </li>
45169
45170 <li>
45171 <p>
45172 Invent (if needed) a generic type wrapper (corresponding to concept
45173 <tt>IdentityOf</tt>),
45174 e.g. <tt>identity_of</tt>, and move it's prototype description back to 20.3.3 [forward]:
45175 </p>
45176
45177 <blockquote><pre>template &lt;class T&gt; struct identity_of {
45178   typedef T type;
45179 };
45180 </pre></blockquote>
45181
45182 <p>
45183 and adapt the <tt>std::forward</tt> signature to use <tt>identity_of</tt>
45184 instead of <tt>identity</tt>.
45185 </p>
45186 </li>
45187 </ol>
45188 </blockquote>
45189
45190 <p><i>[
45191 2009-10 Santa Cruz:
45192 ]</i></p>
45193
45194
45195 <blockquote>
45196 Mark as <del>NAD Editorial</del><ins>Resolved</ins>, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>.
45197 </blockquote>
45198
45199
45200
45201 <p><b>Proposed resolution:</b></p>
45202 <p>
45203 Change definition of <tt>identity</tt> in 20.3.3 [forward], paragraph 2, to:
45204 </p>
45205
45206 <blockquote><pre>template &lt;class T&gt;  struct identity {
45207     typedef T type;
45208
45209     <ins>requires ReferentType&lt;T&gt;</ins>
45210       const T&amp; operator()(const T&amp; x) const;
45211   };
45212 </pre></blockquote>
45213 <p>...</p>
45214 <blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
45215     const T&amp; operator()(const T&amp; x) const;
45216 </pre></blockquote>
45217
45218
45219 <p><b>Rationale:</b></p>
45220 <p>
45221 The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
45222 precisely the concept that guarantees so, according to N2677
45223 (Foundational concepts). Because of this, it seems preferable than an
45224 explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
45225 in Sophia. In particular, Daniel remarked that there may be types other
45226 than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
45227 </p>
45228
45229
45230
45231
45232
45233 <hr>
45234 <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
45235 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
45236  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2010-10-29</p>
45237 <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>
45238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
45239 <p><b>Discussion:</b></p>
45240 <p>
45241 In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
45242 21.3 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
45243 for <tt>basic_string</tt>.
45244 </p>
45245
45246 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
45247  basic_ostream&lt;charT, traits&gt;&amp;
45248    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
45249               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
45250 </pre></blockquote>
45251
45252 <p>
45253 The definition in 21.4.8.9 [string.io] lists two:
45254 </p>
45255
45256 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
45257  basic_ostream&lt;charT, traits&gt;&amp;
45258    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
45259               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
45260
45261 template&lt;class charT, class traits, class Allocator&gt;
45262  basic_ostream&lt;charT, traits&gt;&amp;
45263    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
45264               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
45265 </pre></blockquote>
45266
45267 <p>
45268 I believe the synopsis in 21.3 [string.classes] is correct, and the first of the two
45269 signatures in 21.4.8.9 [string.io] should be deleted.
45270 </p>
45271
45272
45273 <p><b>Proposed resolution:</b></p>
45274 <p>
45275 Delete the first of the two signatures in 21.4.8.9 [string.io]:
45276 </p>
45277
45278 <blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
45279  basic_ostream&lt;charT, traits&gt;&amp;
45280    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
45281               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
45282
45283 template&lt;class charT, class traits, class Allocator&gt;
45284  basic_ostream&lt;charT, traits&gt;&amp;
45285    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
45286               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
45287 </pre></blockquote>
45288
45289
45290
45291
45292
45293 <hr>
45294 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
45295 <p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
45296  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11 <b>Last modified:</b> 2010-11-20</p>
45297 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
45298 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
45299 <p><b>Discussion:</b></p>
45300 <p>
45301 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
45302 <tt>weak_ptr</tt> and <tt>enable_shared_from_this</tt>) <tt>constexpr</tt>? This would enable
45303 static initialization for <tt>shared_ptr</tt> variables, eliminating another
45304 unfair advantage of raw pointers.
45305 </p>
45306
45307 <p><i>[
45308 San Francisco:
45309 ]</i></p>
45310
45311
45312 <blockquote>
45313 <p>
45314 It's not clear to us that you can initialize a pointer with the literal
45315 0 in a constant expression. We need to ask CWG to make sure this works.
45316 Bjarne has been appointed to do this.
45317 </p>
45318 <p>
45319 Core got back to us and assured as that <tt>nullptr</tt> would do the job
45320 nicely here.
45321 </p>
45322 </blockquote>
45323
45324 <p><i>[
45325 2009-05-01 Alisdair adds:
45326 ]</i></p>
45327
45328
45329 <blockquote>
45330 <p>
45331 I don't believe that <tt>constexpr</tt> will buy anything in this case.
45332 <tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
45333 have a non-trivial copy constructor.  As they do not produce literal types,
45334 then the <tt>constexpr</tt> default constructor will <em>not</em> guarantee constant
45335 initialization, and so not buy the hoped for optimization.
45336 </p>
45337 <p>
45338 I recommend referring this back to Core to see if we can get static
45339 initialization for types with <tt>constexpr</tt> constructors, even if they are not
45340 literal types.  Otherwise this should be closed as NAD.
45341 </p>
45342 </blockquote>
45343
45344 <p><i>[
45345 2009-05-26 Daniel adds:
45346 ]</i></p>
45347
45348
45349 <blockquote>
45350 If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
45351 <tt>constexpr mutex()</tt> useless, because this class has a non-trivial
45352 destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>)
45353 </blockquote>
45354
45355 <p><i>[
45356 2009-07-21 Alisdair adds:
45357 ]</i></p>
45358
45359
45360 <blockquote>
45361 <p>
45362 The feedback from core is that this and similar uses of <tt>constexpr</tt>
45363 constructors to force static initialization should be supported.  If
45364 there are any problems with this in the working draught, we should file
45365 core issues.
45366 </p>
45367
45368 <p>
45369 Recommend we declare the default constructor <tt>constexpr</tt> as the issue suggests
45370 (proposed wording added).
45371 </p>
45372 </blockquote>
45373
45374 <p><i>[
45375 2009-10 Santa Cruz:
45376 ]</i></p>
45377
45378
45379 <blockquote>
45380 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
45381 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
45382 </blockquote>
45383
45384
45385 <p><b>Proposed resolution:</b></p>
45386 <p>
45387 Change 20.9.10.2 [util.smartptr.shared] and 20.9.10.2.1 [util.smartptr.shared.const]:
45388 </p>
45389
45390 <blockquote><pre><ins>constexpr</ins> shared_ptr();
45391 </pre></blockquote>
45392
45393 <p>
45394 Change 20.9.10.3 [util.smartptr.weak] and 20.9.10.3.1 [util.smartptr.weak.const]:
45395 </p>
45396
45397 <blockquote><pre><ins>constexpr</ins> weak_ptr();
45398 </pre></blockquote>
45399
45400 <p>
45401 Change 20.9.10.4 [util.smartptr.enab] (2 places):
45402 </p>
45403
45404 <blockquote><pre><ins>constexpr</ins> enable_shared_from_this();
45405 </pre></blockquote>
45406
45407
45408
45409
45410
45411
45412 <hr>
45413 <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
45414 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
45415  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-04-20 <b>Last modified:</b> 2010-10-29</p>
45416 <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>
45417 <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>
45418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
45419 <p><b>Discussion:</b></p>
45420 <p>Consider this code:</p>
45421
45422 <blockquote>
45423 <pre>exception_ptr xp;</pre>
45424 <pre>try {do_something(); }
45425
45426 catch (const runtime_error&amp; ) {xp = current_exception();}
45427
45428 ...
45429
45430 rethrow_exception(xp);</pre>
45431 </blockquote>
45432
45433 <p>
45434 Say <code>do_something()</code> throws an exception object of type <code>
45435 range_error</code>. What is the type of the exception object thrown by <code>
45436 rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
45437 if it were of type <code>runtime_error</code> it still isn't possible to 
45438 propagate an exception and the exception_ptr/current_exception/rethrow_exception 
45439 machinery serves no useful purpose.
45440 </p>
45441
45442 <p>
45443 Unfortunately, the current wording does not explicitly say that. Different 
45444 people read the current wording and come to different conclusions. While it may 
45445 be possible to deduce the correct type from the current wording, it would be 
45446 much clearer to come right out and explicitly say what the type of the referred 
45447 to exception is.
45448 </p>
45449
45450 <p><i>[
45451 Peter adds:
45452 ]</i></p>
45453
45454
45455 <blockquote>
45456 <p>
45457 I don't like the proposed resolution of 829. The normative text is
45458 unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
45459 exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
45460 exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
45461 </p>
45462 <p>
45463 A better way to address this is to simply add the non-normative example
45464 in question as a clarification. The term <i>currently handled exception</i>
45465 should be italicized and cross-referenced. A [<i>Note:</i> the currently
45466 handled exception is the exception that a throw expression without an
45467 operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
45468 </p>
45469 </blockquote>
45470
45471
45472
45473 <p><b>Proposed resolution:</b></p>
45474
45475 <p>
45476 After 18.8.5 [propagation] , paragraph 7, add the indicated text:
45477 </p>
45478
45479 <blockquote>
45480 <pre>exception_ptr current_exception();</pre>
45481
45482 <blockquote>
45483 <p>
45484 <i>Returns:</i> <code>exception_ptr</code> object that refers 
45485 to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled 
45486 exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
45487 the function needs to allocate memory and the attempt fails, it returns an
45488 <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
45489 It is unspecified whether the return values of two successive calls to
45490 <code>current_exception</code> refer to the same exception object. 
45491 [<i>Note:</i> that is, it 
45492 is unspecified whether <code>current_exception</code>
45493 creates a new copy each time it is called.
45494 <i>-- end note</i>]
45495 </p>
45496
45497 <p>
45498 <i>Throws:</i> nothing.
45499 </p>
45500
45501 </blockquote>
45502 </blockquote>
45503
45504
45505
45506
45507
45508
45509 <hr>
45510 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
45511 <p><b>Section:</b> 20.9.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
45512  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2010-11-19</p>
45513 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
45514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
45515 <p><b>Discussion:</b></p>
45516 <p>
45517 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
45518 extension point for <tt>unique_ptr</tt> by granting support for an optional
45519 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
45520 (In the following: <tt>pointer</tt>).
45521 </p>
45522 <p>
45523 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
45524 impact on at least two key features of <tt>unique_ptr</tt>:
45525 </p>
45526
45527 <ol>
45528 <li>Operational fail-safety.</li>
45529 <li>(Well-)Definedness of expressions.</li>
45530 </ol>
45531
45532 <p>
45533 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
45534 operations cannot throw and therefore adds proper wording to the affected
45535 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
45536 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
45537 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
45538 an exception"-clauses or it has to be said explicitly that all used
45539 operations of
45540 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
45541 to be as near as possible to the advantages of native pointers which cannot
45542 fail and thus strongly favor the second choice. Also, the alternative position
45543 would make it much harder to write safe and simple template code for
45544 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
45545 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
45546 be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
45547 </p>
45548
45549 <p><i>[
45550 Sophia Antipolis:
45551 ]</i></p>
45552
45553
45554 <blockquote>
45555 <p>
45556 Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
45557 arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
45558 </p>
45559 <p>
45560 Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
45561 </p>
45562 </blockquote>
45563
45564 <p><i>[
45565 2009-07 Frankfurt:
45566 ]</i></p>
45567
45568
45569 <blockquote>
45570 Move to Ready.
45571 </blockquote>
45572
45573 <p><i>[
45574 2009-10-15 Alisdair pulls from Ready:
45575 ]</i></p>
45576
45577
45578 <blockquote>
45579 <p>
45580 I hate to pull an issue out of Ready status, but I don't think 834 is
45581 fully baked yet.
45582 </p>
45583
45584 <p>
45585 For reference the proposed resolution is to add the following words:
45586 </p>
45587
45588 <blockquote>
45589 <tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be
45590 well-formed, shall have well defined behavior, and shall not throw
45591 exceptions.
45592 </blockquote>
45593
45594 <p>
45595 This leaves me with a big question : which operations?
45596 </p>
45597
45598 <p>
45599 Are all pointer operations required to be nothrow, including operations
45600 that have nothing to do with interactions with <tt>unique_ptr</tt>?  This was
45601 much simpler with concepts where we could point to operations within a
45602 certain concept, and so nail down the interactions.
45603 </p>
45604 </blockquote>
45605
45606 <p><i>[
45607 2009-10-15 Daniel adds:
45608 ]</i></p>
45609
45610
45611 <blockquote>
45612 I volunteer to prepare a more fine-grained solution, but I would like
45613 to ask for feedback that helps me doing so. If this question is asked
45614 early in the meeting I might be able to fix it within the week, but I
45615 cannot promise that now.
45616 </blockquote>
45617
45618 <p><i>[
45619 2009-10 Santa Cruz:
45620 ]</i></p>
45621
45622
45623 <blockquote>
45624 Leave in open. Daniel to provide wording as already suggested.
45625 </blockquote>
45626
45627 <p><i>[
45628 2009-12-22 Daniel provided wording and rationale.
45629 ]</i></p>
45630
45631
45632 <p><i>[
45633 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
45634 ]</i></p>
45635
45636
45637
45638
45639 <p><b>Rationale:</b></p>
45640 <p>
45641 The here proposed resolution has considerable overlap with the requirements that
45642 are used in the allocator requirements.
45643 </p>
45644
45645 <p>
45646 This might be a convincing argument to isolate the common subset into one
45647 requirement. The reason I did not do that is basically because we might find out
45648 that they are either over-constraining or under-constraining at this late point
45649 of specification. Note also that as a result of the idea of a general
45650 requirement set I added the requirement
45651 </p>
45652
45653 <blockquote>
45654 A default-initialized object may have a singular value
45655 </blockquote>
45656
45657 <p>
45658 even though this does not play a relevant role for <tt>unique_ptr</tt>.
45659 </p>
45660
45661 <p>
45662 One further characteristics of the resolution is that availability of relational
45663 operators of <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is not part of the basic
45664 requirements, which is in sync with the allocator requirements on pointer-like
45665 (this means that <tt>unique_ptr</tt> can hold a <tt>void_pointer</tt> or
45666 <tt>const_void_pointer</tt>).
45667 </p>
45668
45669 <p>
45670 Solved by
45671 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
45672 </p>
45673
45674
45675
45676 <p><b>Proposed resolution:</b></p>
45677
45678 <ol>
45679
45680 <li>
45681 <p>
45682 Change 20.9.9.2 [unique.ptr.single]/1 as indicated: <i>[The intent is to
45683 replace the coupling between <tt>T*</tt> and the deleter's <tt>operator()</tt>
45684 by a coupling between <tt>unique_ptr&lt;T, D&gt;::pointer</tt> and this
45685 <tt>operator()</tt>]</i>
45686 </p>
45687
45688 <blockquote>
45689 1 - The default type for the template parameter <tt>D</tt> is
45690 <tt>default_delete</tt>. A client-supplied template argument <tt>D</tt> shall be
45691 a function pointer or functor for which, given a value <tt>d</tt> of type
45692 <tt>D</tt> and a <del>pointer</del> <ins>value</ins> <tt>ptr</tt> of type
45693 <tt><del>T*</del> <ins>unique_ptr&lt;T, D&gt;::pointer</ins></tt>, the
45694 expression <tt>d(ptr)</tt> is valid and has the effect of deallocating the
45695 pointer as appropriate for that deleter. <tt>D</tt> may also be an
45696 lvalue-reference to a deleter.
45697 </blockquote>
45698 </li>
45699
45700 <li>
45701 <p>
45702 Change 20.9.9.2 [unique.ptr.single]/3 as indicated:
45703 </p>
45704
45705 <blockquote>
45706 <p>
45707 3 - If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt> exists, then
45708 <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be a synonym for
45709 <tt>remove_reference&lt;D&gt;::type::pointer</tt>. Otherwise
45710 <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be a synonym for <tt>T*</tt>. The
45711 type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall <del>be</del> <ins>satisfy
45712 the requirements of <tt>EqualityComparable</tt>,
45713 <tt>DefaultConstructible</tt>,</ins> <tt>CopyConstructible</tt> <del>(Table 34)
45714 and</del><ins>,</ins> <tt>CopyAssignable</tt> <del>(Table 36)</del><ins>,
45715 <tt>Swappable</tt>, and <tt>Destructible</tt> (20.2.1 [utility.arg.requirements]). A default-initialized object may have a
45716 singular value.  A value-initialized object produces the null value of the type.
45717 The null value shall be equivalent only to itself. An object of this type can be
45718 copy-initialized with a value of type <tt>nullptr_t</tt>, compared for equality
45719 with a value of type <tt>nullptr_t</tt>, and assigned a value of type
45720 <tt>nullptr_t</tt>. The effect shall be as if a value-initialized object had
45721 been used in place of the null pointer constant. An object <tt>p</tt> of this
45722 type can be contextually converted to <tt>bool</tt>. The effect shall be as if
45723 <tt>p != nullptr</tt> had been evaluated in place of <tt>p</tt>. No operation on
45724 this type which is part of the above mentioned requirements shall exit via an
45725 exception.
45726 </ins>
45727 </p>
45728 <p><ins>
45729 [<i>Note:</i> Given an allocator type <tt>X</tt> (20.2.5 [allocator.requirements]), the types <tt>X::pointer</tt>,
45730 <tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and
45731 <tt>X::const_void_pointer</tt> may be used as <tt>unique_ptr&lt;T,
45732 D&gt;::pointer</tt> \97 <i>end note</i>]
45733 </ins></p>
45734
45735 <p><ins>
45736 In addition to being available via inclusion of the <tt>&lt;utility&gt;</tt>
45737 header, the <tt>swap</tt> function template in 20.3.2 [utility.swap] is
45738 also available within the definition of <tt>unique_ptr</tt>'s <tt>swap</tt>
45739 function.
45740 </ins></p>
45741 </blockquote>
45742 </li>
45743
45744 <li>
45745 <p>
45746 Change 20.9.9.2.1 [unique.ptr.single.ctor]/2+3 as indicated: <i>[The first
45747 change ensures that we explicitly say, how the stored pointer is initialized.
45748 This is important for a <tt>constexpr</tt> function, because this may make a
45749 difference for user-defined pointer-like types]</i>
45750 </p>
45751
45752 <blockquote><pre>constexpr unique_ptr();
45753 </pre>
45754 <blockquote>
45755 <p>...</p>
45756 <p>
45757 2 - <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns nothing<ins>,
45758 value-initializing the stored pointer</ins>.
45759 </p>
45760
45761 <p>
45762 3 - <i>Postconditions:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>.
45763 </p>
45764 </blockquote>
45765 </blockquote>
45766 </li>
45767
45768 <li>
45769 <p>
45770 Change 20.9.9.2.1 [unique.ptr.single.ctor]/6+7 as indicated: <i>[This is a
45771 step-by-fix to ensure consistency to the changes of
45772 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2976.html">N2976</a>]</i>
45773 </p>
45774
45775 <blockquote><pre>unique_ptr(pointer p);
45776 </pre>
45777 <blockquote>
45778 <p>...</p>
45779 <p>
45780 6 - <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns <tt>p</tt><ins>,
45781 initializing the stored pointer with <tt>p</tt></ins>.
45782 </p>
45783
45784 <p>
45785 7 - <i>Postconditions:</i> <tt>get() == p</tt>. <tt>get_deleter()</tt> returns a
45786 reference to a <del>default constructed</del> <ins>value-initialized</ins>
45787 deleter <tt>D</tt>.
45788 </p>
45789 </blockquote>
45790 </blockquote>
45791 </li>
45792
45793 <li>
45794 <p>
45795 Insert a new effects clause in 20.9.9.2.1 [unique.ptr.single.ctor] just
45796 before p. 14: <i>[The intent is to fix the current lack of specification in
45797 which way the stored pointer is initialized]</i>
45798 </p>
45799
45800 <blockquote><pre>unique_ptr(pointer p, <i><del>implementation-defined</del> <ins>see below</ins></i> d1);
45801 unique_ptr(pointer p, <i><del>implementation-defined</del> <ins>see below</ins></i> d2);
45802 </pre>
45803 <blockquote>
45804 <p>...</p>
45805 <p><ins>
45806 <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns <tt>p</tt>,
45807 initializing the stored pointer with <tt>p</tt> and the initializing the deleter
45808 as described above.
45809 </ins></p>
45810
45811 <p>
45812 14 - <i>Postconditions:</i> <tt>get() == p</tt>. <tt>get_deleter()</tt> returns a
45813 reference to the internally stored deleter. If <tt>D</tt> is a reference type
45814 then <tt>get_deleter()</tt> returns a reference to the lvalue <tt>d</tt>.
45815 </p>
45816 </blockquote>
45817 </blockquote>
45818 </li>
45819
45820 <li>
45821 <p>
45822 Change 20.9.9.2.1 [unique.ptr.single.ctor]/18+22 as indicated: <i>[The intent
45823 is to clarify that the moved-from source must contain a null pointer, there is
45824 no other choice left]</i>
45825 </p>
45826
45827 <blockquote><pre>unique_ptr(unique_ptr&amp;&amp; u);
45828 </pre>
45829 <blockquote>
45830 <p>
45831 [..]
45832 </p>
45833
45834 <p>
45835 18 - <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before the
45836 construction<ins> and <tt>u.get() == nullptr</tt></ins>. <tt>get_deleter()</tt>
45837 returns a reference to the internally stored deleter which was constructed from
45838 <tt>u.get_deleter()</tt>. If <tt>D</tt> is a reference type then
45839 <tt>get_deleter()</tt> and <tt>u.get_deleter()</tt> both reference the same
45840 lvalue deleter.
45841 </p>
45842
45843 </blockquote>
45844
45845 <pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
45846 </pre>
45847
45848 <blockquote>
45849
45850 <p>
45851 [..]
45852 </p>
45853
45854 <p>
45855 22 - <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before the
45856 construction, modulo any required offset adjustments resulting from the cast
45857 from <tt>unique_ptr&lt;U, E&gt;::pointer</tt> to <tt>pointer</tt><ins> and
45858 <tt>u.get() == nullptr</tt></ins>. <tt>get_deleter()</tt> returns a reference to
45859 the internally stored deleter which was constructed from
45860 <tt>u.get_deleter()</tt>.
45861 </p>
45862 </blockquote>
45863 </blockquote>
45864 </li>
45865
45866 <li>
45867 <p>
45868 Change 20.9.9.2.1 [unique.ptr.single.ctor]/20 as indicated: <i>[With the
45869 possibility of user-defined pointer-like types the implication does only exist,
45870 if those are built-in pointers. Note that this change should also be applied
45871 with the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>]</i>
45872 </p>
45873
45874 <blockquote><pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
45875 </pre>
45876 <blockquote>
45877 20 - <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of the
45878 deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well formed and
45879 shall not throw an exception. If <tt>D</tt> is a reference type, then <tt>E</tt>
45880 shall be the same type as <tt>D</tt> (diagnostic required). <tt>unique_ptr&lt;U,
45881 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
45882 <del>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> are
45883 complete types. \97 <i>end note</i>]</del>
45884 </blockquote>
45885 </blockquote>
45886 </li>
45887
45888 <li>
45889 <p>
45890 Change 20.9.9.2.2 [unique.ptr.single.dtor]/2 as indicated:
45891 </p>
45892
45893 <blockquote><pre>~unique_ptr();
45894 </pre>
45895 <blockquote>
45896 <p>...</p>
45897 <p>
45898 2 - <i>Effects:</i> If <tt>get() == <del>0</del> <ins>nullptr</ins></tt> there
45899 are no effects. Otherwise <tt>get_deleter()(get())</tt>.
45900 </p>
45901 </blockquote>
45902 </blockquote>
45903 </li>
45904
45905 <li>
45906 <p>
45907 Change 20.9.9.2.3 [unique.ptr.single.asgn]/3+8 as indicated: <i>[The intent is to
45908 clarify that the moved-from source must contain a null pointer, there
45909 is no other choice left]</i>
45910 </p>
45911
45912 <blockquote><pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
45913 </pre>
45914 <blockquote>
45915 <p>[..]</p>
45916 <p>
45917 3 - <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer which <tt>u</tt>
45918 owned, and <tt>u</tt> no longer owns it<ins>, <tt>u.get() == nullptr</tt></ins>.
45919 [<i>Note:</i> If <tt>D</tt> is a reference type, then the referenced lvalue deleters
45920 are move assigned. \97 <i>end note</i>]
45921 </p>
45922 </blockquote>
45923
45924 <pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
45925 </pre>
45926
45927 <blockquote>
45928 <p>[..]</p>
45929
45930 <p>
45931 8 - <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer which
45932 <tt>u</tt> owned, and <tt>u</tt> no longer owns it<ins>, <tt>u.get() ==
45933 nullptr</tt></ins>.
45934 </p>
45935 </blockquote>
45936 </blockquote>
45937 </li>
45938
45939 <li>
45940 <p>
45941 Change 20.9.9.2.3 [unique.ptr.single.asgn]/6 as indicated: <i>[With the
45942 possibility of user-defined pointer-like types the implication does only exist,
45943 if those are built-in pointers. Note that this change should also be applied
45944 with the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>]</i>
45945 </p>
45946
45947 <blockquote><pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
45948 </pre>
45949 <blockquote>
45950 <p>[..]</p>
45951 <p>
45952 6 - <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
45953 <tt>D</tt> shall not throw an exception. <tt>unique_ptr&lt;U,
45954 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
45955 <del>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> are
45956 complete types. \97 <i>end note</i>]</del>
45957 </p>
45958 </blockquote>
45959 </blockquote>
45960 </li>
45961
45962 <li>
45963 <p>
45964 Change 20.9.9.2.3 [unique.ptr.single.asgn] before p. 11 and p. 12 as
45965 indicated: <i>[The first change is a simple typo fix]</i>
45966 </p>
45967
45968 <blockquote><pre>unique_ptr&amp; operator=(nullptr_t<del>}</del><ins>)</ins>;
45969 </pre>
45970
45971 <blockquote>
45972 <p>
45973 11 - <i>Effects:</i> <tt>reset()</tt>.
45974 </p>
45975
45976 <p>
45977 12 - <i>Postcondition:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>
45978 </p>
45979 </blockquote>
45980 </blockquote>
45981 </li>
45982
45983 <li>
45984 <p>
45985 Change 20.9.9.2.4 [unique.ptr.single.observers]/1+4+12 as indicated:
45986 </p>
45987
45988 <blockquote><pre>typename add_lvalue_reference&lt;T&gt;::type operator*() const;
45989 </pre>
45990 <blockquote>
45991 <p>
45992 1 - <i>Requires:</i> <tt>get() != <del>0</del> <ins>nullptr</ins></tt>. <ins>The
45993 variable definition <tt>add_lvalue_reference&lt;T&gt;::type t = *get()</tt>
45994 shall be well formed, shall have well-defined behavior, and shall not exit via
45995 an exception.</ins>
45996 </p>
45997 <p>
45998 [..]
45999 </p>
46000
46001 </blockquote>
46002
46003 <pre>pointer operator-&gt;() const;
46004 </pre>
46005
46006 <blockquote>
46007 <p>
46008 4 - <i>Requires:</i> <tt>get() != <del>0</del> <ins>nullptr</ins></tt>.
46009 </p>
46010
46011 <p>
46012 [..]
46013 </p>
46014
46015 </blockquote>
46016
46017 <pre>explicit operator bool() const;
46018 </pre>
46019
46020 <blockquote>
46021 12 - <i>Returns:</i> <tt>get() != <del>0</del><ins>nullptr</ins></tt>.
46022 </blockquote>
46023 </blockquote>
46024 </li>
46025
46026 <li>
46027 <p>
46028 Change 20.9.9.2.5 [unique.ptr.single.modifiers]/1 as indicated:
46029 </p>
46030
46031 <blockquote><pre>pointer release();
46032 </pre>
46033
46034 <blockquote>
46035 1 - <i>Postcondition:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>.
46036 </blockquote>
46037 </blockquote>
46038 </li>
46039
46040 <li>
46041 <p>
46042 Change 20.9.9.2.5 [unique.ptr.single.modifiers]/9 as indicated: <i>[The
46043 intent is to ensure that potentially user-defined swaps are used. A side-step
46044 fix and harmonization with the specification of the the deleter is realized.
46045 Please note the additional requirement in bullet 2 of this proposed resolution
46046 regarding the availability of the generic <tt>swap</tt> templates within the
46047 member <tt>swap</tt> function.]</i>
46048 </p>
46049
46050 <blockquote><pre>void swap(unique_ptr&amp; u);
46051 </pre>
46052
46053 <blockquote>
46054 <p>
46055 8 - <i>Requires:</i> The deleter <tt>D</tt> shall be <tt>Swappable</tt> and
46056 shall not throw an exception under <tt>swap</tt>.
46057 </p>
46058
46059 <p>
46060 9 - <i>Effects:</i> The stored pointers of <tt><ins>*</ins>this</tt> and
46061 <tt>u</tt> are exchanged <ins>by an unqualified call to non-member
46062 <tt>swap</tt></ins>. The stored deleters are <del><tt>swap</tt>'d
46063 (unqualified)</del> <ins>exchanged by an unqualified call to non-member
46064 <tt>swap</tt></ins>.
46065 </p>
46066 </blockquote>
46067 </blockquote>
46068 </li>
46069
46070 <li>
46071 <p>
46072 Change 20.9.9.3.2 [unique.ptr.runtime.observers]/1 as indicated:
46073 </p>
46074
46075 <blockquote><pre>T&amp; operator[](size_t i) const;
46076 </pre>
46077 <blockquote>
46078 <i>Requires:</i> <tt>i &lt;</tt> the size of the array to which the stored
46079 pointer points. <ins>The variable definition <tt>T&amp; t = get()[i]</tt> shall
46080 be well formed, shall have well-defined behavior, and shall not exit via an
46081 exception.</ins>
46082 </blockquote>
46083 </blockquote>
46084 </li>
46085
46086 <li>
46087 <p>
46088 Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]/1 as indicated:
46089 </p>
46090
46091 <blockquote><pre>void reset(pointer p = pointer());
46092 void reset(nullptr_t p);
46093 </pre>
46094
46095 <blockquote>
46096 1 - <i>Effects:</i> If <tt>get() == <del>0</del> <ins>nullptr</ins></tt> there
46097 are no effects. Otherwise <tt>get_deleter()(get())</tt>.
46098 </blockquote>
46099 </blockquote>
46100 </li>
46101
46102 <li>
46103 <p>
46104 Change 20.9.9.4 [unique.ptr.special] as indicated: <i>[We don't add the
46105 relational operators to the basic requirement set, therefore we need special
46106 handling here]</i>
46107 </p>
46108
46109 <blockquote>
46110 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46111   bool operator==(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46112 </pre>
46113
46114 <blockquote>
46115 <p>
46116 <ins><i>Requires:</i> The variable definition <tt>bool b = x.get() ==
46117 y.get();</tt> shall be well formed, shall have well-defined behavior, and shall
46118 not exit via an exception.</ins>
46119 </p>
46120
46121 <p>
46122 2 - <i>Returns:</i> <tt>x.get() == y.get()</tt>.
46123 </p>
46124
46125 <p><ins>
46126 <i>Throws:</i> nothing.
46127 </ins></p>
46128 </blockquote>
46129
46130 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46131   bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46132 </pre>
46133
46134 <blockquote>
46135 <p>
46136 <ins>Requires: The variable definition <tt>bool b = x.get() != y.get();</tt>
46137 shall be well formed, shall have well-defined behavior, and shall not exit via
46138 an exception.</ins>
46139 </p>
46140
46141 <p>
46142 3 - <i>Returns:</i> <tt>x.get() != y.get()</tt>.
46143 </p>
46144
46145 <p><ins>
46146 <i>Throws:</i> nothing.
46147 </ins></p>
46148 </blockquote>
46149
46150 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46151   bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46152 </pre>
46153
46154 <blockquote>
46155 <p>
46156 <ins>Requires: The variable definition <tt>bool b = x.get() &lt; y.get()</tt>;
46157 shall be well formed, shall have well-defined behavior, and shall not exit via
46158 an exception.</ins>
46159 </p>
46160
46161 <p>
46162 4 - <i>Returns:</i> <tt>x.get() &lt; y.get()</tt>.
46163 </p>
46164
46165 <p><ins>
46166 <i>Throws:</i> nothing.
46167 </ins></p>
46168 </blockquote>
46169
46170 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46171   bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46172 </pre>
46173
46174 <blockquote>
46175 <p>
46176 <ins>Requires: The variable definition <tt>bool b = x.get() &lt;= y.get();</tt>
46177 shall be well formed, shall have well-defined behavior, and shall not exit via
46178 an exception.</ins>
46179 </p>
46180
46181 <p>
46182 5 - <i>Returns:</i> <tt>x.get() &lt;= y.get()</tt>.
46183 </p>
46184
46185 <p><ins>
46186 <i>Throws:</i> nothing.
46187 </ins></p>
46188 </blockquote>
46189
46190 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46191   bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46192 </pre>
46193
46194 <blockquote>
46195 <p>
46196 <ins>Requires: The variable definition <tt>bool b = x.get() &gt; y.get();</tt>
46197 shall be well formed, shall have well-defined behavior, and shall not exit via
46198 an exception.</ins>
46199 </p>
46200
46201 <p>
46202 6 - <i>Returns:</i> <tt>x.get() &gt; y.get()</tt>.
46203 </p>
46204
46205 <p><ins>
46206 <i>Throws:</i> nothing.
46207 </ins></p>
46208 </blockquote>
46209
46210 <pre>template &lt;class T1, class D1, class T2, class D2&gt;
46211   bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
46212 </pre>
46213
46214 <blockquote>
46215 <p>
46216 <ins>Requires: The variable definition <tt>bool b = x.get() &gt;= y.get();</tt>
46217 shall be well formed, shall have well-defined behavior, and shall not exit via
46218 an exception.</ins>
46219 </p>
46220
46221 <p>
46222 7 - <i>Returns:</i> <tt>x.get() &gt;= y.get()</tt>.
46223 </p>
46224
46225 <p><ins>
46226 <i>Throws:</i> nothing.
46227 </ins></p>
46228 </blockquote>
46229
46230 </blockquote>
46231 </li>
46232
46233 </ol>
46234
46235
46236
46237
46238
46239
46240
46241 <hr>
46242 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
46243 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
46244  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
46245 <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>
46246 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
46247 <p><b>Discussion:</b></p>
46248        <p>
46249
46250 The fix for
46251 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
46252 now integrated into the working paper, overlooks a couple of minor
46253 problems.
46254
46255        </p>
46256        <p>
46257
46258 First, being an unformatted function once again, <code>flush()</code>
46259 is required to create a sentry object whose constructor must, among
46260 other things, flush the tied stream. When two streams are tied
46261 together, either directly or through another intermediate stream
46262 object, flushing one will also cause a call to <code>flush()</code> on
46263 the other tied stream(s) and vice versa, ad infinitum. The program
46264 below demonstrates the problem.
46265
46266        </p>
46267        <p>
46268
46269 Second, as Bo Persson notes in his
46270 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
46271 for streams with the <code>unitbuf</code> flag set such
46272 as <code>std::stderr</code>, the destructor of the sentry object will
46273 again call <code>flush()</code>. This seems to create an infinite
46274 recursion for <code>std::cerr &lt;&lt; std::flush;</code>
46275
46276        </p>
46277        <blockquote>
46278            <pre>#include &lt;iostream&gt;
46279
46280 int main ()
46281 {
46282    std::cout.tie (&amp;std::cerr);
46283    std::cerr.tie (&amp;std::cout);
46284    std::cout &lt;&lt; "cout\n";
46285    std::cerr &lt;&lt; "cerr\n";
46286
46287 </pre>
46288 </blockquote>
46289
46290 <p><i>[
46291 Batavia (2009-05):
46292 ]</i></p>
46293
46294 <blockquote>
46295 We agree with the proposed resolution.
46296 Move to Review.
46297 </blockquote>
46298
46299 <p><i>[
46300 2009-05-26 Daniel adds:
46301 ]</i></p>
46302
46303
46304 <blockquote>
46305 <p>
46306 I think that the most recently suggested change in
46307 27.7.2.4 [ostream::sentry] need some further word-smithing. As
46308 written, it would make the behavior undefined, if under
46309 conditions when <tt>pubsync()</tt> should be called, but when
46310 in this scenario <tt>os.rdbuf()</tt> returns 0.
46311 </p>
46312 <p>
46313 This case is explicitly handled in <tt>flush()</tt> and needs to be
46314 taken care of. My suggested fix is:
46315 </p>
46316
46317 <blockquote>
46318 If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()</tt>
46319 <ins><tt>&amp;&amp; os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
46320 <ins><tt>os.rdbuf()-&gt;pubsync()</tt></ins>.
46321 </blockquote>
46322
46323 <p>
46324 Two secondary questions are:
46325 </p>
46326
46327 <ol>
46328 <li>
46329 Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
46330 base requirement for this trial be that <tt>os.good() == true</tt>
46331 as required in the original <tt>flush()</tt> case?
46332 </li>
46333 <li>
46334 Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
46335 a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
46336 (which may throw <tt>ios_base::failure</tt>)?
46337 </li>
46338 </ol>
46339 </blockquote>
46340
46341 <p><i>[
46342 2009-07 Frankfurt:
46343 ]</i></p>
46344
46345
46346 <blockquote>
46347 <p>
46348 Daniel volunteered to modify the proposed resolution to address his two questions.
46349 </p>
46350 <p>
46351 Move back to Open.
46352 </p>
46353 </blockquote>
46354
46355 <p><i>[
46356 2009-07-26 Daniel provided wording.  Moved to Review.
46357 ]</i></p>
46358
46359
46360 <p><i>[
46361 2009-10-13 Daniel adds:
46362 ]</i></p>
46363
46364
46365 <blockquote>
46366 This proposed wording is written to match the outcome
46367 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>.
46368 </blockquote>
46369
46370 <p><i>[
46371 2009 Santa Cruz:
46372 ]</i></p>
46373
46374
46375 <blockquote>
46376 Move to Open. Martin to propose updated wording that will also resolve
46377 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a> consistently.
46378 </blockquote>
46379
46380 <p><i>[
46381 2010-02-15 Martin provided wording.
46382 ]</i></p>
46383
46384
46385 <p><i>[
46386 2010 Pittsburgh:
46387 ]</i></p>
46388
46389
46390 <blockquote>
46391 Moved to Ready for Pittsburgh.
46392 </blockquote>
46393
46394
46395
46396 <p><b>Proposed resolution:</b></p>
46397
46398 <ol>
46399 <li>
46400 <p>
46401 Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
46402 </p>
46403
46404 <blockquote>
46405 <ins><i>Requires:</i> If <tt>(tiestr != 0)</tt> is <tt>true</tt>,
46406 <tt>tiestr</tt> must not be reachable by traversing the linked list of tied
46407 stream objects starting from <tt>tiestr-&gt;tie()</tt>.</ins>
46408 </blockquote>
46409 </li>
46410
46411 <li>
46412 <p>
46413 Change 27.7.2.4 [ostream::sentry]/4 as indicated:
46414 </p>
46415
46416 <blockquote>
46417 If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()
46418 <ins>&amp;&amp; os.good()</ins>)</tt> is <tt>true</tt>, calls
46419 <del><tt>os.flush()</tt></del> <ins><tt>os.rdbuf()-&gt;pubsync()</tt>. If that
46420 function returns -1 sets <tt>badbit</tt> in <tt>os.rdstate()</tt> without
46421 propagating an exception</ins>.
46422 </blockquote>
46423 </li>
46424
46425 <li>
46426 <p>
46427 Add after 27.7.2.4 [ostream::sentry] p17, the following paragraph:
46428 </p>
46429
46430 <blockquote>
46431 <ins><i>Throws:</i> Nothing.</ins>
46432 </blockquote>
46433
46434 </li>
46435
46436 </ol>
46437
46438
46439    
46440
46441
46442
46443 <hr>
46444 <h3><a name="836"></a>836. 
46445        effects of <code>money_base::space</code> and
46446        <code>money_base::none</code> on <code>money_get</code>
46447    </h3>
46448 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
46449  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
46450 <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>
46451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
46452 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
46453 <p><b>Discussion:</b></p>
46454
46455        <p>
46456
46457 In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
46458
46459        </p>
46460        <blockquote>
46461
46462 Where <code>space</code> or <code>none</code> appears in the format
46463 pattern, except at the end, optional white space (as recognized
46464 by <code>ct.is</code>) is consumed after any required space.
46465
46466        </blockquote>
46467        <p>
46468
46469 This requirement can be (and has been) interpreted two mutually
46470 exclusive ways by different readers. One possible interpretation
46471 is that:
46472
46473        </p>
46474        <blockquote>
46475            <ol>
46476                <li>
46477
46478 where <code>money_base::space</code> appears in the format, at least
46479 one space is required, and
46480
46481                </li>
46482                <li>
46483
46484 where <code>money_base::none</code> appears in the format, space is
46485 allowed but not required.
46486
46487                </li>
46488            </ol>
46489        </blockquote>
46490        <p>
46491
46492 The other is that:
46493
46494        </p>
46495        <blockquote>
46496
46497 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
46498
46499        </blockquote>
46500
46501 <p><i>[
46502 San Francisco:
46503 ]</i></p>
46504
46505
46506 <blockquote>
46507 Martin will revise the proposed resolution.
46508 </blockquote>
46509
46510 <p><i>[
46511 2009-07 Frankfurt:
46512 ]</i></p>
46513
46514
46515 <blockquote>
46516 <p>
46517 There is a noun missing from the proposed resolution. It's not clear
46518 that the last sentence would be helpful, even if the word were not
46519 missing:
46520 </p>
46521 <blockquote>
46522 In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.
46523 </blockquote>
46524 <p>
46525 Strike this sentence and move to Review.
46526 </p>
46527
46528 <p><i>[
46529 Howard: done.
46530 ]</i></p>
46531
46532 </blockquote>
46533
46534 <p><i>[
46535 2009-10 Santa Cruz:
46536 ]</i></p>
46537
46538
46539 <blockquote>
46540 Move to Ready.
46541 </blockquote>
46542
46543    
46544
46545    <p><b>Proposed resolution:</b></p>
46546        <p>
46547
46548 I propose to change the text to make it clear that the first
46549 interpretation is intended, that is, to make following change to
46550 22.4.6.1.2 [locale.money.get.virtuals], p2:
46551
46552        </p>
46553
46554        <blockquote>
46555
46556 When <code><ins>money_base::</ins>space</code>
46557 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
46558 element </ins>in the format pattern, <del>except at the end, optional
46559 white space (as recognized by <code>ct.is</code>) is consumed after
46560 any required space.</del> <ins>no white space is consumed. Otherwise,
46561 where <code>money_base::space</code> appears in any of the initial
46562 elements of the format pattern, at least one white space character is
46563 required. Where <code>money_base::none</code> appears in any of the
46564 initial elements of the format pattern, white space is allowed but not
46565 required.</ins>
46566 If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
46567
46568        </blockquote>
46569    
46570
46571
46572
46573 <hr>
46574 <h3><a name="838"></a>838. 
46575    can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
46576  </h3>
46577 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
46578  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
46579 <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>
46580 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
46581 <p><b>Discussion:</b></p>
46582    <p>
46583
46584 From message c++std-lib-20003...
46585
46586    </p>
46587    <p>
46588
46589 The description of <code>istream_iterator</code> in
46590 24.6.1 [istream.iterator], p1 specifies that objects of the
46591 class become the <i>end-of-stream</i> (EOS) iterators under the
46592 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a> another problem
46593 with this paragraph):
46594
46595    </p>
46596    <blockquote>
46597
46598 If the end of stream is reached (<code>operator void*()</code> on the
46599 stream returns <code>false</code>), the iterator becomes equal to
46600 the <i>end-of-stream</i> iterator value.
46601
46602    </blockquote>
46603    <p>
46604
46605 One possible implementation approach that has been used in practice is
46606 for the iterator to set its <code>in_stream</code> pointer to 0 when
46607 it reaches the end of the stream, just like the default ctor does on
46608 initialization. The problem with this approach is that
46609 the <i>Effects</i> clause for <code>operator++()</code> says the
46610 iterator unconditionally extracts the next value from the stream by
46611 evaluating <code>*in_stream &gt;&gt; value</code>, without checking
46612 for <code>(in_stream == 0)</code>.
46613
46614    </p>
46615    <p>
46616
46617 Conformance to the requirement outlined in the <i>Effects</i> clause
46618 can easily be verified in programs by setting <code>eofbit</code>
46619 or <code>failbit</code> in <code>exceptions()</code> of the associated
46620 stream and attempting to iterate past the end of the stream: each
46621 past-the-end access should trigger an exception. This suggests that
46622 some other, more elaborate technique might be intended.
46623
46624    </p>
46625    <p>
46626
46627 Another approach, one that allows <code>operator++()</code> to attempt
46628 to extract the value even for EOS iterators (just as long
46629 as <code>in_stream</code> is non-0) is for the iterator to maintain a
46630 flag indicating whether it has reached the end of the stream. This
46631 technique would satisfy the presumed requirement implied by
46632 the <i>Effects</i> clause mentioned above, but it isn't supported by
46633 the exposition-only members of the class (no such flag is shown). This
46634 approach is also found in existing practice.
46635
46636    </p>
46637    <p>
46638
46639 The inconsistency between existing implementations raises the question
46640 of whether the intent of the specification is that a non-EOS iterator
46641 that has reached the EOS become a non-EOS one again after the
46642 stream's <code>eofbit</code> flag has been cleared? That is, are the
46643 assertions in the program below expected to pass?
46644
46645    </p>
46646    <blockquote>
46647      <pre>   sstream strm ("1 ");
46648    istream_iterator eos;
46649    istream_iterator it (strm);
46650    int i;
46651    i = *it++
46652    assert (it == eos);
46653    strm.clear ();
46654    strm &lt;&lt; "2 3 ";
46655    assert (it != eos);
46656    i = *++it;
46657    assert (3 == i);
46658      </pre>
46659    </blockquote>
46660    <p>
46661
46662 Or is it intended that once an iterator becomes EOS it stays EOS until
46663 the end of its lifetime?
46664
46665    </p>
46666  
46667  <p><i>[
46668 San Francisco:
46669 ]</i></p>
46670
46671
46672 <blockquote>
46673 <p>
46674 We like the direction of the proposed resolution. We're not sure about
46675 the wording, and we need more time to reflect on it,
46676 </p>
46677 <p>
46678 Move to Open. Detlef to rewrite the proposed resolution in such a way
46679 that no reference is made to exposition only members of
46680 <tt>istream_iterator</tt>.
46681 </p>
46682 </blockquote>
46683
46684 <p><i>[
46685 2009-07 Frankfurt:
46686 ]</i></p>
46687
46688
46689 <blockquote>
46690 Move to Ready.
46691 </blockquote>
46692
46693
46694
46695  <p><b>Proposed resolution:</b></p>
46696    <p>
46697
46698 The discussion of this issue on the reflector suggests that the intent
46699 of the standard is for an <code>istreambuf_iterator</code> that has
46700 reached the EOS to remain in the EOS state until the end of its
46701 lifetime. Implementations that permit EOS iterators to return to a
46702 non-EOS state may only do so as an extension, and only as a result of
46703 calling <code>istream_iterator</code> member functions on EOS
46704 iterators whose behavior is in this case undefined.
46705
46706    </p>
46707    <p>
46708
46709 To this end we propose to change 24.6.1 [istream.iterator], p1,
46710 as follows:
46711
46712    </p>
46713    <blockquote>
46714
46715 The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
46716 is not defined. For any other iterator value a <code>const T*</code>
46717 is returned.<ins> Invoking <code>operator++()</code> on
46718 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
46719 to store things into istream iterators...
46720
46721    </blockquote>
46722    <p>
46723
46724 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
46725
46726    </p>
46727    <blockquote>
46728
46729 <pre>istream_iterator();</pre>
46730
46731 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
46732 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
46733
46734 <pre>istream_iterator(istream_type &amp;s);</pre>
46735
46736 <i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
46737 may be initialized during construction or the first time it is
46738 referenced.<br>
46739 <ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
46740
46741 <pre>istream_iterator(const istream_iterator &amp;x);</pre>
46742
46743 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
46744 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
46745
46746 <pre>istream_iterator&amp; operator++();</pre>
46747
46748 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
46749 <i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
46750
46751 <pre>istream_iterator&amp; operator++(int);</pre>
46752
46753 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
46754 <i>Effects</i>:
46755    <blockquote><pre>istream_iterator tmp (*this);
46756 *in_stream &gt;&gt; value;
46757 return tmp;
46758      </pre>
46759      </blockquote>
46760    </blockquote>
46761  
46762
46763
46764
46765 <hr>
46766 <h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
46767 <p><b>Section:</b> 23.2 [container.requirements], 23.4.2 [vector.bool], 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
46768  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
46769 <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>
46770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
46771 <p><b>Discussion:</b></p>
46772 <p>
46773 23.2 [container.requirements]/p3 says:
46774 </p>
46775
46776 <blockquote>
46777 Objects stored in these components shall be constructed using
46778 <tt>construct_element</tt> (20.6.9). For each operation that inserts an
46779 element of type <tt>T</tt> into a container (<tt>insert</tt>,
46780 <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
46781 arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
46782 as described in table 88. [<i>Note:</i> If the component is instantiated
46783 with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
46784 <tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
46785 <tt>construct_element</tt> may pass an inner allocator argument to
46786 <tt>T</tt>'s constructor. <i>-- end note</i>]
46787 </blockquote>
46788
46789 <p>
46790 However <tt>vector&lt;bool, A&gt;</tt> (23.4.2 [vector.bool]) and <tt>bitset&lt;N&gt;</tt> 
46791 (20.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
46792 does not even have an allocator.  But these containers are governed by this clause.  Clearly this
46793 is not implementable.
46794 </p>
46795
46796
46797 <p><b>Proposed resolution:</b></p>
46798 <p>
46799 Change 23.2 [container.requirements]/p3:
46800 </p>
46801
46802 <blockquote>
46803 Objects stored in these components shall be constructed using
46804 <tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
46805 For each operation that inserts an
46806 element of type <tt>T</tt> into a container (<tt>insert</tt>,
46807 <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
46808 arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
46809 as described in table 88. [<i>Note:</i> If the component is instantiated
46810 with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
46811 <tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
46812 <tt>construct_element</tt> may pass an inner allocator argument to
46813 <tt>T</tt>'s constructor. <i>-- end note</i>]
46814 </blockquote>
46815
46816 <p>
46817 Change 23.4.2 [vector.bool]/p2:
46818 </p>
46819
46820 <blockquote>
46821 Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, 
46822 except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
46823 and <tt>construct_element</tt> (23.2 [container.requirements]) is not used to construct these values</ins>.
46824 </blockquote>
46825
46826 <p>
46827 Move 20.5 [template.bitset] to clause 20.
46828 </p>
46829
46830
46831
46832
46833
46834
46835 <hr>
46836 <h3><a name="843"></a>843.  Reference Closure</h3>
46837 <p><b>Section:</b> X [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
46838  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-02 <b>Last modified:</b> 2010-10-29</p>
46839 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
46840 <p><b>Discussion:</b></p>
46841 <p>
46842 The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
46843 under the theory that references cannot be assigned, and hence the
46844 assignment of its reference member must necessarily be ill-formed.
46845 </p>
46846 <p>
46847 However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
46848 provide for the "copying of references", and thus the current definition
46849 of <tt>std::reference_closure</tt> seems unnecessarily restrictive.  In particular,
46850 it should be possible to write generic functions using both <tt>std::function</tt>
46851 and <tt>std::reference_closure</tt>, but this generality is much harder when
46852 one such type does not support assignment.
46853 </p>
46854 <p>
46855 The definition of <tt>reference_closure</tt> does not necessarily imply direct
46856 implementation via reference types.  Indeed, the <tt>reference_closure</tt> is
46857 best implemented via a frame pointer, for which there is no standard
46858 type.
46859 </p>
46860 <p>
46861 The semantics of assignment are effectively obtained by use of the
46862 default destructor and default copy assignment operator via
46863 </p>
46864
46865 <blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
46866 </pre></blockquote>
46867
46868 <p>
46869 So the copy assignment operator generates no significant real burden
46870 to the implementation.
46871 </p>
46872
46873
46874 <p><b>Proposed resolution:</b></p>
46875 <p>
46876 In  [func.referenceclosure] Class template reference_closure,
46877 replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
46878 with <tt>=default</tt>.
46879 </p>
46880
46881 <blockquote><pre>template&lt;class R , class... ArgTypes &gt; 
46882   class reference_closure&lt;R (ArgTypes...)&gt; { 
46883   public:
46884      ...
46885      reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
46886      ...
46887 </pre></blockquote>
46888
46889 <p>
46890 In X [func.referenceclosure.cons] Construct, copy, destroy,
46891 add the member function description
46892 </p>
46893
46894 <blockquote>
46895 <pre>reference_closure&amp; operator=(const reference_closure&amp; f)
46896 </pre>
46897 <blockquote>
46898 <p>
46899 <i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
46900 </p>
46901 <p>
46902 <i>Returns:</i> <tt>*this</tt>.
46903 </p>
46904 </blockquote>
46905 </blockquote>
46906
46907
46908
46909
46910
46911
46912
46913 <hr>
46914 <h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
46915 <p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
46916  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
46917 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
46918 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
46919 <p><b>Discussion:</b></p>
46920 <p>
46921 The current working draft is in an inconsistent state.
46922 </p>
46923
46924 <p>
46925 26.4.8 [complex.transcendentals] says that:
46926 </p>
46927
46928 <blockquote>
46929 <tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
46930 </blockquote>
46931
46932 <p>
46933 26.4.9 [cmplx.over] says that:
46934 </p>
46935
46936 <blockquote>
46937 <tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
46938 </blockquote>
46939
46940 <p><i>[
46941 Sophia Antipolis:
46942 ]</i></p>
46943
46944
46945 <blockquote>
46946 <p>
46947 Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
46948 overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
46949 7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
46950 </p>
46951 <p>
46952 Special note: ask P.J. Plauger.
46953 </p>
46954 <blockquote>
46955 Looks fine.
46956 </blockquote>
46957 </blockquote>
46958
46959
46960 <p><b>Proposed resolution:</b></p>
46961 <p>
46962 Strike this <tt>pow</tt> overload in 26.4.1 [complex.syn] and in 26.4.8 [complex.transcendentals]:
46963 </p>
46964
46965 <blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
46966 </pre></blockquote>
46967
46968
46969
46970
46971
46972 <hr>
46973 <h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
46974 <p><b>Section:</b> X [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
46975  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
46976 <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>
46977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
46978 <p><b>Discussion:</b></p>
46979 <p>
46980 The atomic classes (and class templates) are required to support aggregate
46981 initialization (29.5.1 [atomics.types.integral]p2 / 29.5.2 [atomics.types.address]p1)
46982 yet also have user declared constructors, so cannot be aggregates.
46983 </p>
46984 <p>
46985 This problem might be solved with the introduction of the proposed
46986 initialization syntax at Antipolis, but the wording above should be altered.
46987 Either strike the sentence as redundant with new syntax, or refer to 'brace
46988 initialization'.
46989 </p>
46990
46991 <p><i>[
46992 Jens adds:
46993 ]</i></p>
46994
46995
46996 <blockquote>
46997 <p>
46998 Note that
46999 </p>
47000 <blockquote><pre>atomic_itype a1 = { 5 };
47001 </pre></blockquote>
47002 <p>
47003 would be aggregate-initialization syntax (now coming under the disguise
47004 of brace initialization), but would be ill-formed, because the corresponding
47005 constructor for atomic_itype is explicit.  This works, though:
47006 </p>
47007 <blockquote><pre>atomic_itype a2 { 6 };
47008 </pre></blockquote>
47009
47010 </blockquote>
47011
47012 <p><i>[
47013 San Francisco:
47014 ]</i></p>
47015
47016
47017 <blockquote>
47018 <p>
47019 The preferred approach to resolving this is to remove the explicit
47020 specifiers from the atomic integral type constructors.
47021 </p>
47022 <p>
47023 Lawrence will provide wording.
47024 </p>
47025 <p>
47026 This issue is addressed in
47027 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
47028 </p>
47029 </blockquote>
47030
47031
47032
47033 <p><b>Proposed resolution:</b></p>
47034 <p>
47035 within the synopsis in 29.5.1 [atomics.types.integral] edit as follows.
47036 </p>
47037
47038 <blockquote><pre><code>
47039 ....
47040 typedef struct atomic_bool {
47041 ....
47042   constexpr <del>explicit</del> atomic_bool(bool);
47043 ....
47044 typedef struct atomic_<var>itype</var> {
47045 ....
47046   constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>);
47047 ....
47048 </code></pre></blockquote>
47049
47050 <p>
47051 edit 29.5.1 [atomics.types.integral] paragraph 2 as follows.
47052 </p>
47053
47054 <blockquote>
47055 The atomic integral types shall have standard layout.
47056 They shall each have a trivial default constructor,
47057 a constexpr <del>explicit</del> value constructor,
47058 a deleted copy constructor,
47059 a deleted copy assignment operator,
47060 and a trivial destructor.
47061 They shall each support aggregate initialization syntax.
47062 </blockquote>
47063
47064 <p>
47065 within the synopsis of 29.5.2 [atomics.types.address] edit as follows.
47066 </p>
47067
47068 <blockquote><pre><code>
47069 ....
47070 typedef struct atomic_address {
47071 ....
47072   constexpr <del>explicit</del> atomic_address(void*);
47073 ....
47074 </code></pre></blockquote>
47075
47076 <p>
47077 edit 29.5.2 [atomics.types.address] paragraph 1 as follows.
47078 </p>
47079
47080 <blockquote>
47081 The type <code>atomic_address</code> shall have standard layout.
47082 It shall have a trivial default constructor,
47083 a constexpr <del>explicit</del> value constructor,
47084 a deleted copy constructor,
47085 a deleted copy assignment operator,
47086 and a trivial destructor.
47087 It shall support aggregate initialization syntax.
47088 </blockquote>
47089
47090 <p>
47091 within the synopsis of 29.5 [atomics.types.generic] edit as follows.
47092 </p>
47093
47094 <blockquote><pre><code>
47095 ....
47096 template &lt;class T&gt; struct atomic {
47097 ....
47098   constexpr <del>explicit</del> atomic(T);
47099 ....
47100 template &lt;&gt; struct atomic&lt;<var>integral</var>&gt; : atomic_<var>itype</var> {
47101 ....
47102   constexpr <del>explicit</del> atomic(<var>integral</var>);
47103 ....
47104 template &lt;&gt; struct atomic&lt;T*&gt; : atomic_address {
47105 ....
47106   constexpr <del>explicit</del> atomic(T*);
47107 ....
47108 </code></pre></blockquote>
47109
47110 <p>
47111 edit 29.5 [atomics.types.generic] paragraph 2 as follows.
47112 </p>
47113
47114 <blockquote>
47115 Specializations of the <code>atomic</code> template
47116 shall have a deleted copy constructor,
47117 a deleted copy assignment operator,
47118 and a constexpr <del>explicit</del> value constructor.
47119 </blockquote>
47120
47121
47122
47123
47124
47125
47126 <hr>
47127 <h3><a name="846"></a>846. No definition for constructor</h3>
47128 <p><b>Section:</b> X [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
47129  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
47130 <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>
47131 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
47132 <p><b>Discussion:</b></p>
47133 <p>
47134 The atomic classes and class templates (29.5.1 [atomics.types.integral] /
47135 29.5.2 [atomics.types.address]) have a constexpr
47136 constructor taking a value of the appropriate type for that atomic.
47137 However, neither clause provides semantics or a definition for this
47138 constructor.  I'm not sure if the initialization is implied by use of
47139 constexpr keyword (which restricts the form of a constructor) but even if
47140 that is the case, I think it is worth spelling out explicitly as the
47141 inference would be far too subtle in that case.
47142 </p>
47143
47144 <p><i>[
47145 San Francisco:
47146 ]</i></p>
47147
47148
47149 <blockquote>
47150 <p>
47151 Lawrence will provide wording.
47152 </p>
47153 <p>
47154 This issue is addressed in
47155 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
47156 </p>
47157 </blockquote>
47158
47159
47160 <p><b>Proposed resolution:</b></p>
47161
47162 <p>
47163 before the description of ...<code>is_lock_free</code>,
47164 that is before 29.6 [atomics.types.operations] paragraph 4,
47165 add the following description.
47166 </p>
47167
47168 <blockquote>
47169 <pre><code>
47170 constexpr <var>A</var>::<var>A</var>(<var>C</var> desired);
47171 </code></pre>
47172 <dl>
47173 <dt><i>Effects:</i></dt>
47174 <dd>
47175 Initializes the object with the value <code>desired</code>.
47176 [<i>Note:</i>
47177 Construction is not atomic.
47178 \97<i>end note</i>]
47179 </dd>
47180 </dl>
47181 </blockquote>
47182
47183
47184
47185
47186
47187 <hr>
47188 <h3><a name="847"></a>847. string exception safety guarantees</h3>
47189 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
47190  <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
47191 <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>
47192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
47193 <p><b>Discussion:</b></p>
47194 <p>
47195 In March, on comp.lang.c++.moderated, I asked what were the
47196 string exception safety guarantees are, because I cannot see
47197 *any* in the working paper, and any implementation I know offers
47198 the strong exception safety guarantee (string unchanged if a
47199 member throws exception). The closest the current draft comes to
47200 offering any guarantees is 21.4 [basic.string], para 3:
47201 </p>
47202
47203 <blockquote>
47204 The class template <tt>basic_string</tt> conforms to the requirements
47205 for a Sequence Container (23.1.1), for a Reversible Container (23.1),
47206 and for an Allocator-aware container (91). The iterators supported by
47207 <tt>basic_string</tt> are random access iterators (24.1.5).
47208 </blockquote>
47209
47210 <p>
47211 However, the chapter 23 only says, on the topic of exceptions:  23.2 [container.requirements],
47212 para 10:
47213 </p>
47214
47215 <blockquote>
47216 <p>
47217 Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following 
47218 additional requirements:
47219 </p>
47220
47221 <ul>
47222 <li>if an exception is thrown by...</li>
47223 </ul>
47224 </blockquote>
47225
47226 <p>
47227 I take it  as saying that this paragraph has *no* implication on
47228 <tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
47229 this paragraph does not define a *requirement* of Sequence
47230 nor Reversible Container, just of the models defined in Clause 23.
47231 In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
47232 </p>
47233
47234 <p>
47235 Finally, the fact that no operation on Traits should throw
47236 exceptions has no bearing, except to suggest (since the only
47237 other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
47238 that the strong exception guarantee can be achieved.
47239 </p>
47240
47241 <p>
47242 The reaction in that group by Niels Dekker, Martin Sebor, and
47243 Bo Persson, was all that this would be worth an LWG issue.
47244 </p>
47245
47246 <p>
47247 A related issue is that <tt>erase()</tt> does not throw.  This should be
47248 stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
47249 applies here).
47250 </p>
47251
47252 <p><i>[
47253 San Francisco:
47254 ]</i></p>
47255
47256
47257 <blockquote>
47258 Implementors will study this to confirm that it is actually possible.
47259 </blockquote>
47260
47261 <p><i>[
47262 Daniel adds 2009-02-14:
47263 ]</i></p>
47264
47265
47266 <blockquote>
47267 The proposed resolution of paper
47268 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
47269 interacts with this issue (the paper does not refer to this issue).
47270 </blockquote>
47271
47272 <p><i>[
47273 2009-07 Frankfurt:
47274 ]</i></p>
47275
47276
47277 <blockquote>
47278 Move to Ready.
47279 </blockquote>
47280
47281
47282
47283 <p><b>Proposed resolution:</b></p>
47284 <p>
47285 Add a blanket statement in 21.4.1 [string.require]:
47286 </p>
47287
47288 <blockquote>
47289 <p>
47290 - if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
47291 throws, that function or operator has no effect.
47292 </p>
47293 <p>
47294 - no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
47295 </p>
47296 </blockquote>
47297
47298 <p>
47299 As far as I can tell, this is achieved by any implementation.  If I made a
47300 mistake and it is not possible to offer this guarantee, then
47301 either state all the functions for which this is possible
47302 (certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
47303 or add paragraphs to Effects clauses wherever appropriate.
47304 </p>
47305
47306
47307
47308
47309
47310 <hr>
47311 <h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
47312 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
47313  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
47314 <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>
47315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
47316 <p><b>Discussion:</b></p>
47317 <p>
47318 In the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
47319 types and a few other types. Bitsets seems like one that is missing from
47320 the list, not because it cannot not be done by the user, but because it
47321 is hard or impossible to write an efficient implementation that works on
47322 32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
47323 encapsulated in this respect.
47324 </p>
47325
47326
47327 <p><b>Proposed resolution:</b></p>
47328 <p>
47329 Add the following to the synopsis in 20.8 [function.objects]/2:
47330 </p>
47331
47332 <blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
47333 template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
47334 </pre></blockquote>
47335
47336 <p>
47337 Modify the last sentence of 20.8.15 [unord.hash]/1 to end with:
47338 </p>
47339
47340 <blockquote>
47341 ... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
47342 <tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
47343 </blockquote>
47344
47345
47346
47347
47348
47349
47350 <hr>
47351 <h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
47352 <p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
47353  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
47354 <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>
47355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
47356 <p><b>Discussion:</b></p>
47357 <p>
47358 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
47359 It did not yet deal with <tt>std::deque</tt>, because of the fundamental
47360 difference between <tt>std::deque</tt> and the other two container types. The
47361 need for <tt>std::deque</tt> may seem less evident, because one might think that
47362 for this container, the overhead is a small map, and some number of
47363 blocks that's bounded by a small constant.
47364 </p>
47365 <p>
47366 The container overhead can in fact be arbitrarily large (i.e. is not
47367 necessarily O(N) where N is the number of elements currently held by the
47368 <tt>deque</tt>).  As Bill Plauger noted in a reflector message, unless the map of
47369 block pointers is shrunk, it must hold at least maxN/B pointers where
47370 maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
47371 creation.  This is independent of how the map is implemented
47372 (<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
47373 the number of elements it currently holds.
47374 </p>
47375 <p>
47376 Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
47377 large due to some temporary backup (the front request hanging), and the
47378 map of the <tt>deque</tt> grew quite large before getting back to normal.  Just
47379 to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
47380 steady regime, that held, at some point in its lifetime, maxN=10M
47381 pointers, with one block holding 128 elements, the spine must be at
47382 least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
47383 would allow to reuse about 100K which would otherwise never be reclaimed
47384 in the lifetime of the <tt>deque</tt>.
47385 </p>
47386 <p>
47387 An added bonus would be that it *allows* implementations to hang on to
47388 empty blocks at the end (but does not care if they do or not).  A
47389 <tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
47390 most O(B) space is used in addition to the storage to hold the N
47391 elements and the N/B block pointers.
47392 </p>
47393
47394
47395 <p><b>Proposed resolution:</b></p>
47396 <p>
47397 To Class template deque 23.3.2 [deque] synopsis, add:
47398 </p>
47399 <blockquote><pre>void shrink_to_fit();
47400 </pre></blockquote>
47401
47402 <p>
47403 To deque capacity 23.3.2.2 [deque.capacity], add:
47404 </p>
47405 <blockquote><pre>void shrink_to_fit();
47406 </pre>
47407
47408 <blockquote>
47409 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
47410 use. [<i>Note:</i> The request is non-binding to allow latitude for
47411 implementation-specific optimizations. -- <i>end note</i>]
47412 </blockquote>
47413 </blockquote>
47414
47415
47416
47417
47418
47419 <hr>
47420 <h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
47421 <p><b>Section:</b> 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
47422  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2010-10-29</p>
47423 <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>
47424 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
47425 <p><b>Discussion:</b></p>
47426 <p>
47427 In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
47428 </p>
47429
47430 <blockquote><pre>local_iterator begin(size_type n) const;
47431 </pre></blockquote>
47432
47433
47434 <p><b>Proposed resolution:</b></p>
47435 <p>
47436 Change the synopsis in 23.7.1 [unord.map], 23.7.2 [unord.multimap], and 23.7.4 [unord.multiset]:
47437 </p>
47438
47439 <blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
47440 </pre></blockquote>
47441
47442
47443
47444
47445
47446 <hr>
47447 <h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
47448 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
47449  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2010-10-29</p>
47450 <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>
47451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
47452 <p><b>Discussion:</b></p>
47453 <p>
47454 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
47455 the three newer <tt>to_string</tt> overloads.
47456 </p>
47457
47458 <p><i>[
47459 post San Francisco:
47460 ]</i></p>
47461
47462
47463 <blockquote>
47464 Daniel found problems with the wording and provided fixes.  Moved from Ready
47465 to Review.
47466 </blockquote>
47467
47468 <p><i>[
47469 Post Summit:
47470 ]</i></p>
47471
47472
47473 <blockquote>
47474 <p>
47475 Alisdair: suggest to not repeat the default arguments in B, C, D
47476 (definition of to_string members)
47477 </p>
47478 <p>
47479 Walter: This is not really a definition.
47480 </p>
47481 <p>
47482 Consensus: Add note to the editor: Please apply editor's judgement
47483 whether default arguments should be repeated for B, C, D changes.
47484 </p>
47485 <p>
47486 Recommend Tentatively Ready.
47487 </p>
47488 </blockquote>
47489
47490 <p><i>[
47491 2009-05-09:  See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>.
47492 ]</i></p>
47493
47494
47495
47496
47497 <p><b>Proposed resolution:</b></p>
47498 <ol type="A">
47499 <li>
47500 <p>replace in 20.5 [template.bitset]/1 (class <tt>bitset</tt>)
47501 </p>
47502 <blockquote><pre>template &lt;class charT, class traits&gt;
47503   basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
47504   to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
47505 template &lt;class charT&gt;
47506   basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
47507   to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
47508 basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
47509   to_string(<ins>char zero = '0', char one = '1'</ins>) const;
47510 </pre></blockquote>
47511 </li>
47512 <li>
47513 <p>
47514 replace in 20.5.2 [bitset.members]/37
47515 </p>
47516 <blockquote><pre>template &lt;class charT, class traits&gt;
47517   basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
47518   to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
47519 </pre>
47520 <blockquote>
47521 37 <i>Returns:</i> <tt>to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
47522 </blockquote>
47523 </blockquote>
47524 </li>
47525 <li>
47526 <p>
47527 replace in 20.5.2 [bitset.members]/38
47528 </p>
47529
47530 <blockquote><pre>template &lt;class charT&gt;
47531   basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
47532   to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
47533 </pre>
47534 <blockquote>
47535 38 <i>Returns:</i> <tt>to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
47536 </blockquote>
47537 </blockquote>
47538 </li>
47539
47540 <li>
47541 <p>
47542 replace in 20.5.2 [bitset.members]/39
47543 </p>
47544
47545 <blockquote><pre>basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
47546   to_string(<ins>char zero = '0', char one = '1'</ins>) const;
47547 </pre>
47548 <blockquote>
47549 39 <i>Returns:</i> <tt>to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;(<ins>zero, one</ins>)</tt>.
47550 </blockquote>
47551 </blockquote>
47552 </li>
47553
47554 </ol>
47555
47556
47557
47558
47559
47560
47561 <hr>
47562 <h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
47563 <p><b>Section:</b> 20.9.9.1.2 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
47564  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2010-10-29</p>
47565 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.dltr.dflt">issues</a> in [unique.ptr.dltr.dflt].</p>
47566 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
47567 <p><b>Discussion:</b></p>
47568 <p>
47569 No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
47570 </p>
47571 <p>
47572 Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
47573 the latter should also become a concept.
47574 </p>
47575 <p>
47576 Rules out cross-casting.
47577 </p>
47578 <p>
47579 The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
47580 </p>
47581
47582 <p><i>[
47583 Howard adds 2008-11-26:
47584 ]</i></p>
47585
47586
47587 <blockquote>
47588 <p>
47589 I believe we need to be careful to not outlaw the following use case, and
47590 I believe the current proposed wording
47591 (<tt>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>) does so:
47592 </p>
47593
47594 <blockquote><pre>#include &lt;memory&gt;
47595
47596 int main()
47597 {
47598     std::unique_ptr&lt;int&gt; p1(new int(1));
47599     std::unique_ptr&lt;const int&gt; p2(move(p1));
47600     int i = *p2;
47601 <font color="#C80000">//    *p2 = i;  // should not compile</font>
47602 }
47603 </pre></blockquote>
47604
47605 <p>
47606 I've removed "<tt>&amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>" from the
47607 <tt>requires</tt> clause in the proposed wording.
47608 </p>
47609
47610 </blockquote>
47611
47612 <p><i>[
47613 Post Summit:
47614 ]</i></p>
47615
47616
47617 <blockquote>
47618 <p>
47619 Alisdair: This issue has to stay in review pending a paper constraining
47620 <tt>unique_ptr</tt>.
47621 </p>
47622 <p>
47623 Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
47624 to be constrained, too.
47625 </p>
47626 <p>
47627 Recommend Keep in Review.
47628 </p>
47629 </blockquote>
47630
47631 <p><i>[
47632 Batavia (2009-05):
47633 ]</i></p>
47634
47635 <blockquote>
47636 Keep in Review status for the reasons cited.
47637 </blockquote>
47638
47639 <p><i>[
47640 2009-07 Frankfurt:
47641 ]</i></p>
47642
47643
47644 <blockquote>
47645 <p>
47646 The proposed resolution uses concepts. Howard needs to rewrite the
47647 proposed resolution.
47648 </p>
47649 <p>
47650 Move back to Open.
47651 </p>
47652 </blockquote>
47653
47654 <p><i>[
47655 2009-07-26 Howard provided rewritten proposed wording and moved to Review.
47656 ]</i></p>
47657
47658
47659 <p><i>[
47660 2009-10 Santa Cruz:
47661 ]</i></p>
47662
47663
47664 <blockquote>
47665 Move to Ready.
47666 </blockquote>
47667
47668
47669
47670 <p><b>Proposed resolution:</b></p>
47671 <p>
47672 Add after 20.9.9.1.2 [unique.ptr.dltr.dflt], p1:
47673 </p>
47674
47675 <blockquote><pre>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp; other);
47676 </pre>
47677 <blockquote>
47678 <p>
47679 -1- <i>Effects:</i> ...
47680 </p>
47681 <p><ins>
47682 <i>Remarks:</i> This constructor shall participate in overload resolution
47683 if and only if <tt>U*</tt> is implicitly convertible to <tt>T*</tt>.
47684 </ins></p>
47685 </blockquote>
47686 </blockquote>
47687
47688
47689
47690
47691
47692
47693 <hr>
47694 <h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
47695 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
47696  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2010-10-29</p>
47697 <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>
47698 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
47699 <p><b>Discussion:</b></p>
47700 <p>
47701 With the arrival of extended unions 
47702 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
47703 there is no
47704 known use of <tt>aligned_union</tt> that couldn't be handled by
47705 the "extended unions" core-language facility.
47706 </p>
47707
47708
47709 <p><b>Proposed resolution:</b></p>
47710 <p>
47711 Remove the following signature from 20.7.2 [meta.type.synop]:
47712 </p>
47713 <blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
47714 </pre></blockquote>
47715
47716 <p>
47717 Remove the second row from table 51 in 20.7.7.6 [meta.trans.other],
47718 starting with:
47719 </p>
47720
47721 <blockquote><pre>template &lt;std::size_t Len,
47722 class... Types&gt;
47723 struct aligned_union;
47724 </pre></blockquote>
47725
47726
47727
47728
47729
47730 <hr>
47731 <h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
47732 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
47733  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13 <b>Last modified:</b> 2010-10-29</p>
47734 <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>
47735 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
47736 <p><b>Discussion:</b></p>
47737 <p>
47738 The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
47739 obscure that even the class' designer can't deduce it correctly. Several
47740 people have independently stumbled on this issue.
47741 </p>
47742 <p>
47743 It might be simpler to change the return type to a scoped enum:
47744 </p>
47745 <blockquote><pre>enum class timeout { not_reached, reached };
47746 </pre></blockquote>
47747
47748 <p>
47749 That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
47750 </p>
47751
47752 <blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
47753   throw time_out();
47754 </pre></blockquote>
47755
47756 <p><i>[
47757 Beman to supply exact wording.
47758 ]</i></p>
47759
47760
47761 <p><i>[
47762 San Francisco:
47763 ]</i></p>
47764
47765
47766 <blockquote>
47767 <p>
47768 There is concern that the enumeration names are just as confusing, if
47769 not more so, as the bool. You might have awoken because of a signal or a
47770 spurious wakeup, for example.
47771 </p>
47772 <p>
47773 Group feels that this is a defect that needs fixing.
47774 </p>
47775 <p>
47776 Group prefers returning an enum over a void return.
47777 </p>
47778 <p>
47779 Howard to provide wording.
47780 </p>
47781 </blockquote>
47782
47783 <p><i>[
47784 2009-06-14 Beman provided wording.
47785 ]</i></p>
47786
47787
47788 <p><i>[
47789 2009-07 Frankfurt:
47790 ]</i></p>
47791
47792
47793 <blockquote>
47794 Move to Ready.
47795 </blockquote>
47796
47797
47798
47799 <p><b>Proposed resolution:</b></p>
47800 <p>
47801 Change Condition variables 30.5 [thread.condition], Header
47802 condition_variable synopsis, as indicated:
47803 </p>
47804
47805 <blockquote><pre>namespace std {
47806   class condition_variable;
47807   class condition_variable_any;
47808
47809   <ins>enum class cv_status { no_timeout, timeout };</ins>
47810 }
47811 </pre></blockquote>
47812
47813 <p>
47814 Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
47815 </p>
47816
47817 <blockquote><pre>class condition_variable { 
47818 public:
47819   ...
47820   template &lt;class Clock, class Duration&gt;
47821     <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
47822                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
47823   template &lt;class Clock, class Duration, class Predicate&gt;
47824     bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
47825                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
47826                     Predicate pred);
47827
47828   template &lt;class Rep, class Period&gt;
47829     <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
47830                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
47831   template &lt;class Rep, class Period, class Predicate&gt;
47832     bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
47833                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
47834                   Predicate pred);
47835   ...
47836 };
47837
47838 ...
47839
47840 template &lt;class Clock, class Duration&gt;
47841   <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
47842                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
47843 </pre>
47844 <blockquote>
47845 <p>
47846 -15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
47847 </p>
47848 <ul>
47849 <li>
47850 no other thread is waiting on this <tt>condition_variable</tt> object or
47851 </li>
47852 <li>
47853 <tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
47854 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
47855 <tt>wait_for</tt> or <tt>wait_until</tt>.).
47856 </li>
47857 </ul>
47858
47859 <p>
47860 -16- <i>Effects:</i>
47861 </p>
47862
47863 <ul>
47864 <li>
47865 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
47866 </li>
47867 <li>
47868 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
47869 </li>
47870 <li>
47871 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
47872 a call to <tt>notify_all()</tt>, <del>by 
47873 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
47874 or spuriously.
47875 </li>
47876 <li>
47877 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
47878 to exiting the function scope.
47879 </li>
47880 </ul>
47881
47882 <p>
47883 -17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
47884 </p>
47885
47886 <p>
47887 -18- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
47888 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
47889 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
47890 </p>
47891
47892 <p>
47893 -19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
47894 cannot be achieved.
47895 </p>
47896
47897 <p>
47898 -20- <i>Error conditions:</i>
47899 </p>
47900
47901 <ul>
47902 <li>
47903 <tt>operation_not_permitted</tt> \97 if the thread does not own the lock.
47904 </li>
47905 <li>
47906 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
47907 </li>
47908 </ul>
47909 </blockquote>
47910
47911 <pre>template &lt;class Rep, class Period&gt;
47912   <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
47913                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
47914
47915 </pre>
47916 <blockquote>
47917 <p>
47918 -21- <i><del>Effects</del> <ins>Returns</ins>:</i>
47919 </p>
47920 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
47921 </pre></blockquote>
47922 <p>
47923 <del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
47924 duration specified by <tt>rel_time</tt> has elapsed, 
47925 otherwise <tt>true</tt>.</del>
47926 </p>
47927
47928 <p><i>[
47929 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
47930 not do so in spirit.  If both issues are accepted, there is a logical merge.
47931 ]</i></p>
47932
47933 </blockquote>
47934
47935 <pre>template &lt;class Clock, class Duration, class Predicate&gt; 
47936   bool wait_until(unique_lock&lt;mutex&gt;&amp; lock, 
47937                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time, 
47938                   Predicate pred);
47939 </pre>
47940
47941 <blockquote>
47942 <p>
47943 -23- <i>Effects:</i>
47944 </p>
47945 <blockquote><pre>while (!pred()) 
47946   if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
47947     return pred(); 
47948 return true;
47949 </pre></blockquote>
47950
47951 <p>
47952 -24- <i>Returns:</i> <tt>pred()</tt>.
47953 </p>
47954
47955 <p>
47956 -25- [<i>Note:</i>
47957 The returned value indicates whether the predicate evaluates to
47958 <tt>true</tt> regardless of whether the timeout was triggered.
47959 \97 <i>end note</i>].
47960 </p>
47961 </blockquote>
47962 </blockquote>
47963
47964 <p>
47965 Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
47966 </p>
47967
47968 <blockquote><pre>class condition_variable_any {
47969 public:
47970   ...
47971   template &lt;class Lock, class Clock, class Duration&gt;
47972     <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
47973                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
47974   template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
47975     bool wait_until(Lock&amp; lock,
47976                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
47977                     Predicate pred);
47978
47979   template &lt;class Lock, class Rep, class Period&gt;
47980     <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
47981                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
47982   template &lt;class Lock, class Rep, class Period, class Predicate&gt;
47983     bool wait_for(Lock&amp; lock,
47984                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
47985                   Predicate pred);
47986   ...
47987 };
47988
47989 ...
47990
47991 template &lt;class Lock, class Clock, class Duration&gt;
47992   <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
47993                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
47994 </pre>
47995
47996 <blockquote>
47997
47998 <p>
47999 -13- <i>Effects:</i>
48000 </p>
48001
48002 <ul>
48003 <li>
48004 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
48005 </li>
48006 <li>
48007 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
48008 </li>
48009 <li>
48010 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
48011 a call to <tt>notify_all()</tt>, <del>by 
48012 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
48013 or spuriously.
48014 </li>
48015 <li>
48016 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
48017 to exiting the function scope.
48018 </li>
48019 </ul>
48020
48021 <p>
48022 -14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
48023 </p>
48024
48025 <p>
48026 -15- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
48027 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
48028 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
48029 </p>
48030
48031 <p>
48032 -16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
48033 cannot be achieved.
48034 </p>
48035
48036 <p>
48037 -17- <i>Error conditions:</i>
48038 </p>
48039
48040 <ul>
48041 <li>
48042 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
48043 </li>
48044 </ul>
48045 </blockquote>
48046
48047 <pre>template &lt;class Lock, class Rep, class Period&gt;
48048   <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
48049                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
48050
48051 </pre>
48052
48053 <blockquote>
48054 <p>
48055 -18- <i><del>Effects</del> <ins>Returns</ins>:</i>
48056 </p>
48057 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
48058 </pre></blockquote>
48059
48060 <p>
48061 <del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
48062 duration specified by <tt>rel_time</tt> has elapsed, 
48063 otherwise <tt>true</tt>.</del>
48064 </p>
48065
48066 <p><i>[
48067 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
48068 not do so in spirit.  If both issues are accepted, there is a logical merge.
48069 ]</i></p>
48070
48071
48072 </blockquote>
48073
48074 <pre>template &lt;class Lock, class Clock, class Duration, class Predicate&gt; 
48075   bool wait_until(Lock&amp; lock, 
48076                   const chrono::time_point&lt;Clock, Duration&gt;&amp; <del>rel_time</del> <ins>abs_time</ins>, 
48077                   Predicate pred);
48078 </pre>
48079
48080 <blockquote>
48081 <p>
48082 -20- <i>Effects:</i>
48083 </p>
48084 <blockquote><pre>while (!pred()) 
48085   if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
48086     return pred(); 
48087 return true;
48088 </pre></blockquote>
48089
48090 <p>
48091 -21- <i>Returns:</i> <tt>pred()</tt>.
48092 </p>
48093
48094 <p>
48095 -22- [<i>Note:</i>
48096 The returned value indicates whether the predicate evaluates to
48097 <tt>true</tt> regardless of whether the timeout was triggered.
48098 \97 <i>end note</i>].
48099 </p>
48100 </blockquote>
48101
48102 </blockquote>
48103
48104
48105
48106
48107
48108
48109 <hr>
48110 <h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
48111 <p><b>Section:</b> 20.9.11 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
48112  <b>Submitter:</b> Pete Becker  <b>Opened:</b> 2008-06-21 <b>Last modified:</b> 2010-10-29</p>
48113 <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>
48114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
48115 <p><b>Discussion:</b></p>
48116 <p>
48117 The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
48118 to be missing some words. I can't parse
48119 </p>
48120 <blockquote>
48121 ... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
48122 </blockquote>
48123 <p>
48124 I take it the intent is that <tt>undeclare_reachable</tt> should be called only
48125 when there has been a corresponding call to <tt>declare_reachable</tt>. In
48126 particular, although the wording seems to allow it, I assume that code
48127 shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
48128 twice.
48129 </p>
48130 <p>
48131 I don't know what "shall be live" in the Requires clause means.
48132 </p>
48133 <p>
48134 In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
48135 deallocated" mean? Is this different from "will not be able to collect"?
48136 </p>
48137
48138 <p>
48139 For the wording on nesting of <tt>declare_reachable</tt> and
48140 <tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
48141 mutexes probably are a good model.
48142 </p>
48143
48144 <p><i>[
48145 San Francisco:
48146 ]</i></p>
48147
48148
48149 <blockquote>
48150 <p>
48151 Nick: what does "shall be live" mean?
48152 </p>
48153 <p>
48154 Hans: I can provide an appropriate cross-reference to the Project Editor
48155 to clarify the intent.
48156 </p>
48157 </blockquote>
48158
48159
48160 <p><b>Proposed resolution:</b></p>
48161 <p>
48162 In 20.9.11 [util.dynamic.safety]
48163 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm">N2670</a>,
48164 Minimal Support for Garbage Collection)
48165 </p>
48166 <p>
48167 Add at the beginning, before paragraph 39
48168 </p>
48169
48170 <blockquote>
48171 A complete object is <i>declared reachable</i> while the number of calls
48172 to <tt>declare_reachable</tt> with an argument referencing the object exceeds the
48173 number of <tt>undeclare_reachable</tt> calls with pointers to the same complete
48174 object.
48175 </blockquote>
48176
48177 <p>
48178 Change paragraph 42 (Requires clause for <tt>undeclare_reachable</tt>)
48179 </p>
48180
48181 <blockquote>
48182 If <tt>p</tt> is not null, <del><tt>declare_reachable(p)</tt> was previously called</del>
48183 <ins>the complete object referenced by <tt>p</tt> shall have
48184 been previously declared reachable</ins>, and shall
48185 be live <ins>(3.8 [basic.life])</ins> from the time of the call until the last <tt>undeclare_reachable(p)</tt>
48186 call on the object.
48187 </blockquote>
48188
48189 <p>
48190 Change the first sentence in paragraph 44 (Effects clause for
48191 <tt>undeclare_reachable</tt>):
48192 </p>
48193
48194 <blockquote>
48195 <i>Effects:</i> 
48196 <del>Once the number of calls to
48197 <tt>undeclare_reachable(p)</tt> equals the number of calls to
48198 <tt>declare_reachable(p)</tt>
48199 for all non-null <tt>p</tt> referencing
48200 the argument is no longer declared reachable.  When this happens,
48201 pointers to the object referenced by p may not be subsequently
48202 dereferenced.</del>
48203 <ins>
48204 After a call to <tt>undeclare_reachable(p)</tt>, if <tt>p</tt> is not null and the object <tt>q</tt>
48205 referenced by <tt>p</tt> is no longer declared reachable, then
48206 dereferencing any pointer to <tt>q</tt> that is not safely derived
48207 results in undefined behavior.
48208 </ins> ...
48209 </blockquote>
48210
48211 <p>
48212 Change the final note:
48213 </p>
48214 <p>
48215 [<i>Note:</i> It is expected that calls to <tt>declare_reachable(p)</tt>
48216 will consume a small amount of memory<ins>, in addition to that occupied
48217 by the referenced object, </ins> until the matching call to
48218 <tt>undeclare_reachable(p)</tt> is encountered. <del>In addition, the
48219 referenced object cannot be deallocated during this period, and garbage
48220 collecting implementations will not be able to collect the object while
48221 it is declared reachable.</del> Long running programs should arrange
48222 that calls <ins>for short-lived objects</ins> are matched. <i>--end
48223 note</i>]
48224 </p>
48225
48226
48227
48228
48229
48230
48231 <hr>
48232 <h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
48233 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
48234  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2010-10-29</p>
48235 <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>
48236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
48237 <p><b>Discussion:</b></p>
48238
48239 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>.</p>
48240
48241 <p>
48242 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
48243 says that there is a class named <tt>monotonic_clock</tt>. It also says that this
48244 name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
48245 supported. So the actual requirement is that it can be monotonic or not,
48246 and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
48247 all (since it's conditionally supported). Okay, maybe too much
48248 flexibility, but so be it.
48249 </p>
48250 <p>
48251 A problem comes up in the threading specification, where several
48252 variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
48253 meaning of an effects clause that says
48254 </p>
48255
48256 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
48257 </pre></blockquote>
48258
48259 <p>
48260 when <tt>monotonic_clock</tt> is not required to exist?
48261 </p>
48262
48263 <p><i>[
48264 San Francisco:
48265 ]</i></p>
48266
48267
48268 <blockquote>
48269 <p>
48270 Nick: maybe instead of saying that chrono::monotonic_clock is
48271 conditionally supported, we could say that it's always there, but not
48272 necessarily supported..
48273 </p>
48274 <p>
48275 Beman: I'd prefer a typedef that identifies the best clock to use for
48276 wait_for locks.
48277 </p>
48278 <p>
48279 Tom: combine the two concepts; create a duration clock type, but keep
48280 the is_monotonic test.
48281 </p>
48282 <p>
48283 Howard: if we create a duration_clock type, is it a typedef or an
48284 entirely true type?
48285 </p>
48286 <p>
48287 There was broad preference for a typedef.
48288 </p>
48289 <p>
48290 Move to Open. Howard to provide wording to add a typedef for
48291 duration_clock and to replace all uses of monotonic_clock in function
48292 calls and signatures with duration_clock.
48293 </p>
48294 </blockquote>
48295
48296 <p><i>[
48297 Howard notes post-San Francisco:
48298 ]</i></p>
48299
48300
48301 <blockquote>
48302 <p>
48303 After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
48304 is the best way to proceed.  An implementation may not need to use a
48305 <tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
48306 </p>
48307
48308 <p>
48309 For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
48310 <tt>nanosleep</tt> which takes only a duration in terms of nanoseconds.  The current
48311 working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
48312 And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
48313 implementations to use monotonic clocks for <tt>sleep_for</tt>:
48314 </p>
48315
48316 <blockquote>
48317 2 The member functions whose names end in <tt>_for</tt> take an argument that
48318 specifies a relative time. Implementations should use a monotonic clock to
48319 measure time for these functions.
48320 </blockquote>
48321
48322 <p>
48323 I believe the approach taken in describing the effects of <tt>sleep_for</tt>
48324 and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>.  I.e. these
48325 are not described in terms of their <tt>_until</tt> variants.
48326 </p>
48327
48328 </blockquote>
48329
48330 <p><i>[
48331 2009-07 Frankfurt:
48332 ]</i></p>
48333
48334
48335 <blockquote>
48336 <p>
48337 Beman will send some suggested wording changes to Howard.
48338 </p>
48339 <p>
48340 Move to Ready.
48341 </p>
48342 </blockquote>
48343
48344 <p><i>[
48345 2009-07-21 Beman added the requested wording changes to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>.
48346 ]</i></p>
48347
48348
48349
48350
48351 <p><b>Proposed resolution:</b></p>
48352 <p>
48353 Change 30.5.1 [thread.condition.condvar], p21-22:
48354 </p>
48355
48356 <blockquote>
48357 <pre>template &lt;class Rep, class Period&gt; 
48358   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
48359                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
48360 </pre>
48361 <blockquote>
48362 <p><ins>
48363 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
48364 </ins></p>
48365 <ul>
48366 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
48367 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
48368 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
48369 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
48370 </ul>
48371 <p>
48372 21 <i>Effects:</i>
48373 </p>
48374 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
48375 </pre></blockquote>
48376 <ul>
48377 <li><ins>
48378 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
48379 </ins></li>
48380
48381 <li><ins>
48382 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
48383 </ins></li>
48384
48385 <li><ins>
48386 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
48387 to <tt>notify_all()</tt>, by 
48388 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
48389 or spuriously.
48390 </ins></li>
48391
48392 <li><ins>
48393 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called 
48394 prior to exiting the function scope.
48395 </ins></li>
48396 </ul>
48397
48398 <p><ins>
48399 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
48400 </ins></p>
48401
48402
48403 <p>
48404 22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
48405 duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
48406 </p>
48407
48408 <p><i>[
48409 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a> in detail, but does
48410 not do so in spirit.  If both issues are accepted, there is a logical merge.
48411 ]</i></p>
48412
48413
48414 <p><ins>
48415 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
48416 </ins></p>
48417
48418 <p><ins>
48419 <i>Error conditions:</i>
48420 </ins></p>
48421
48422 <ul>
48423 <li><ins>
48424 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
48425 </ins></li>
48426 <li><ins>
48427 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
48428 </ins></li>
48429 </ul>
48430
48431 </blockquote>
48432 </blockquote>
48433
48434 <p>
48435 Change 30.5.1 [thread.condition.condvar], p26-p29:
48436 </p>
48437
48438 <blockquote>
48439 <pre>template &lt;class Rep, class Period, class Predicate&gt; 
48440   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
48441                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
48442                 Predicate pred);
48443 </pre>
48444 <blockquote>
48445 <p><ins>
48446 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
48447 </ins></p>
48448 <ul>
48449 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
48450 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
48451 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
48452 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
48453 </ul>
48454 <p>
48455 <i>26 Effects:</i>
48456 </p>
48457 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
48458 </pre>
48459 <ul>
48460 <li><ins>
48461 Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
48462 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
48463 </ins></li>
48464 <li><ins>
48465 Atomically calls <tt>lock.unlock()</tt>
48466 and blocks on <tt>*this</tt>.
48467 </ins></li>
48468 <li><ins>
48469 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
48470 </ins></li>
48471 <li><ins>
48472 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
48473 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
48474 [thread.req.timing]), or spuriously.
48475 </ins></li>
48476 <li><ins>
48477 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
48478 prior to exiting the function scope.
48479 </ins></li>
48480 <li><ins>
48481 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
48482 duration specified by <tt>rel_time</tt> has elapsed.
48483 </ins></li>
48484 </ul>
48485 </blockquote>
48486
48487 <p>
48488 27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
48489 even if the timeout has already expired. <i>-- end note</i>]
48490 </p>
48491
48492 <p><ins>
48493 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
48494 </ins></p>
48495
48496 <p>
48497 28 <i>Returns:</i> <tt>pred()</tt>
48498 </p>
48499
48500 <p>
48501 29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
48502 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
48503 </p>
48504
48505 <p><ins>
48506 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
48507 </ins></p>
48508
48509 <p><ins>
48510 <i>Error conditions:</i>
48511 </ins></p>
48512
48513 <ul>
48514 <li><ins>
48515 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
48516 </ins></li>
48517 <li><ins>
48518 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
48519 </ins></li>
48520 </ul>
48521
48522 </blockquote>
48523 </blockquote>
48524
48525 <p>
48526 Change 30.5.2 [thread.condition.condvarany], p18-19:
48527 </p>
48528
48529 <blockquote>
48530 <pre>template &lt;class Lock, class Rep, class Period&gt; 
48531   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
48532 </pre>
48533 <blockquote>
48534 <p>
48535 18 <i>Effects:</i>
48536 </p>
48537 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
48538 </pre></blockquote>
48539
48540 <ul>
48541 <li><ins>
48542 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
48543 </ins></li>
48544
48545 <li><ins>
48546 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
48547 </ins></li>
48548
48549 <li><ins>
48550 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
48551 <tt>notify_all()</tt>, by
48552 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
48553 or spuriously.
48554 </ins></li>
48555
48556 <li><ins>
48557 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
48558 prior to exiting the function scope.
48559 </ins></li>
48560 </ul>
48561
48562 <p><ins>
48563 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
48564 </ins></p>
48565
48566 <p>
48567 19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
48568 specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
48569 </p>
48570
48571 <p><ins>
48572 <i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
48573 or postcondition cannot be achieved.
48574 </ins></p>
48575
48576 <p><ins>
48577 <i>Error conditions:</i>
48578 </ins></p>
48579
48580 <ul>
48581 <li><ins>
48582 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
48583 </ins></li>
48584 </ul>
48585 </blockquote>
48586 </blockquote>
48587
48588 <p>
48589 Change 30.5.2 [thread.condition.condvarany], p23-p26:
48590 </p>
48591
48592 <blockquote>
48593 <pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
48594   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
48595 </pre>
48596 <blockquote>
48597 <p><ins>
48598 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
48599 </ins></p>
48600 <ul>
48601 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
48602 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
48603 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
48604 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
48605 </ul>
48606 <p>
48607 <i>23 Effects:</i>
48608 </p>
48609 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
48610 </pre>
48611 <ul>
48612 <li><ins>
48613 Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
48614 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
48615 </ins></li>
48616 <li><ins>
48617 Atomically calls <tt>lock.unlock()</tt>
48618 and blocks on <tt>*this</tt>.
48619 </ins></li>
48620 <li><ins>
48621 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
48622 </ins></li>
48623 <li><ins>
48624 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
48625 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
48626 [thread.req.timing]), or spuriously.
48627 </ins></li>
48628 <li><ins>
48629 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
48630 prior to exiting the function scope.
48631 </ins></li>
48632 <li><ins>
48633 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
48634 duration specified by <tt>rel_time</tt> has elapsed.
48635 </ins></li>
48636 </ul>
48637 </blockquote>
48638
48639 <p>
48640 24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
48641 even if the timeout has already expired. <i>-- end note</i>]
48642 </p>
48643
48644 <p><ins>
48645 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
48646 </ins></p>
48647
48648 <p>
48649 25 <i>Returns:</i> <tt>pred()</tt>
48650 </p>
48651
48652 <p>
48653 26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
48654 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
48655 </p>
48656
48657 <p><ins>
48658 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
48659 </ins></p>
48660
48661 <p><ins>
48662 <i>Error conditions:</i>
48663 </ins></p>
48664
48665 <ul>
48666 <li><ins>
48667 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
48668 </ins></li>
48669 <li><ins>
48670 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
48671 </ins></li>
48672 </ul>
48673
48674 </blockquote>
48675 </blockquote>
48676
48677
48678
48679
48680
48681
48682
48683 <hr>
48684 <h3><a name="860"></a>860. Floating-Point State</h3>
48685 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
48686  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2010-10-29</p>
48687 <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>
48688 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
48689 <p><b>Discussion:</b></p>
48690 <p>
48691 There are a number of functions that affect the floating point state.
48692 These function need to be thread-safe, but I'm unsure of the right
48693 approach in the standard, as we inherit them from C.
48694 </p>
48695
48696 <p><i>[
48697 San Francisco:
48698 ]</i></p>
48699
48700
48701 <blockquote>
48702 <p>
48703 Nick: I think we already say that these functions do not introduce data
48704 races; see 17.6.5.6/20
48705 </p>
48706 <p>
48707 Pete: there's more to it than not introducing data races; are these
48708 states maintained per thread?
48709 </p>
48710 <p>
48711 Howard: 21.5/14 says that strtok and strerror are not required to avoid
48712 data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
48713 gmtime.
48714 </p>
48715 <p>
48716 Nick: POSIX has a list of not-safe functions. All other functions are
48717 implicitly thread safe.
48718 </p>
48719 <p>
48720 Lawrence is to form a group between meetings to attack this issue. Nick
48721 and Tom volunteered to work with Lawrence.
48722 </p>
48723 <p>
48724 Move to Open.
48725 </p>
48726 </blockquote>
48727
48728 <p><i>[
48729 Post Summit:
48730 ]</i></p>
48731
48732
48733 <blockquote>
48734 <p>
48735 Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
48736 </p>
48737 <p>
48738 Nick: Default wording seems to cover this? Hole in POSIX, these
48739 functions need to be added to list of thread-unsafe functions.
48740 </p>
48741 <p>
48742 Lawrence: Not sufficient, not "thread-safe" per our definition, but
48743 think of state as a thread-local variable. Need something like "these
48744 functions only affect state in the current thread."
48745 </p>
48746 <p>
48747 Hans: Suggest the following wording: "The floating point environment is
48748 maintained per-thread."
48749 </p>
48750 <p>
48751 Walter: Any other examples of state being thread safe that are not
48752 already covered elsewhere?
48753 </p>
48754 <p>
48755 Have thread unsafe functions paper which needs to be updated. Should
48756 just fold in 26.3 [cfenv] functions.
48757 </p>
48758 <p>
48759 Recommend Open. Lawrence instead suggests leaving it open until we have
48760 suitable wording that may or may not include the thread local
48761 commentary.
48762 </p>
48763 </blockquote>
48764
48765 <p><i>[
48766 2009-09-23 Hans provided wording.
48767 ]</i></p>
48768
48769
48770 <blockquote>
48771 If I understand the history correctly, Nick, as the Posix liaison,
48772 should probably get a veto on this, since I think it came from Posix (?)
48773 via WG14 and should probably really be addressed there (?).  But I think
48774 we are basically in agreement that there is no other sane way to do
48775 this, and hence we don't have to worry too much about stepping on toes. 
48776 As far as I can tell, this same issue also exists in the latest Posix
48777 standard (?).
48778 </blockquote>
48779
48780 <p><i>[
48781 2009-10 Santa Cruz:
48782 ]</i></p>
48783
48784
48785 <blockquote>
48786 Moved to Ready.
48787 </blockquote>
48788
48789
48790
48791 <p><b>Proposed resolution:</b></p>
48792 <p>
48793 Add at the end of 26.3.1 [cfenv.syn]:
48794 </p>
48795
48796 <blockquote>
48797 <p>
48798 2 The header defines all functions, types, and macros the same as C99 7.6.
48799 </p>
48800
48801 <p><ins>
48802 A separate floating point environment shall be maintained for each
48803 thread.  Each function accesses the environment corresponding to its
48804 calling thread.
48805 </ins></p>
48806 </blockquote>
48807
48808
48809
48810
48811
48812 <hr>
48813 <h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
48814 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
48815  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24 <b>Last modified:</b> 2010-10-29</p>
48816 <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>
48817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
48818 <p><b>Discussion:</b></p>
48819 <p>
48820 Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
48821 member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
48822 </p>
48823
48824 <blockquote>
48825 <tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
48826 equal(a.begin(), a.end(), b.begin()</tt>
48827 </blockquote>
48828
48829 <p>
48830 The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
48831 by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
48832 </p>
48833 <p>
48834 Other parts of the (sequence) container requirements do also depend on
48835 <tt>size()</tt>, e.g. <tt>empty()</tt>
48836 or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
48837 <tt>EqualityComparable</tt> specification,
48838 because of the special design choices of <tt>forward_list</tt>.
48839 </p>
48840 <p>
48841 I propose to apply one of the following resolutions, which are described as:
48842 </p>
48843
48844 <ol type="A">
48845 <li>
48846 Provide a definition, which is optimal for this special container without
48847 previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
48848 with the corresponding container ranges and instead uses a special
48849 <tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
48850 </li>
48851 <li>
48852 The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
48853 by <tt>distance</tt> with corresponding performance disadvantages.
48854 </li>
48855 </ol>
48856 <p>
48857 Both proposal choices are discussed, the preferred choice of the author is
48858 to apply (A).
48859 </p>
48860
48861 <p><i>[
48862 San Francisco:
48863 ]</i></p>
48864
48865
48866 <blockquote>
48867 <p>
48868 There's an Option C: change the requirements table to use distance().
48869 </p>
48870 <p>
48871 LWG found Option C acceptable.
48872 </p>
48873 <p>
48874 Martin will draft the wording for Option C.
48875 </p>
48876 </blockquote>
48877
48878 <p><i>[
48879 post San Francisco:
48880 ]</i></p>
48881
48882
48883 <blockquote>
48884 Martin provided wording for Option C.
48885 </blockquote>
48886
48887 <p><i>[
48888 2009-07 Frankfurt
48889 ]</i></p>
48890
48891
48892 <blockquote>
48893 <p>
48894 Other operational semantics (see, for example, Tables 82 and 83) are
48895 written in terms of a container's size() member. Daniel to update
48896 proposed resolution C.
48897 </p>
48898 <p><i>[
48899 Howard: Commented out options A and B.
48900 ]</i></p>
48901
48902 </blockquote>
48903
48904 <p><i>[
48905 2009-07-26 Daniel updated proposed resolution C.
48906 ]</i></p>
48907
48908
48909 <p><i>[
48910 2009-10 Santa Cruz:
48911 ]</i></p>
48912
48913
48914 <blockquote>
48915 Mark NAD Editorial. Addressed by
48916 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
48917 </blockquote>
48918
48919 <p><i>[
48920 2009-10 Santa Cruz:
48921 ]</i></p>
48922
48923
48924 <blockquote>
48925 Reopened.
48926 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>
48927 was rejected in full committee on procedural grounds.
48928 </blockquote>
48929
48930 <p><i>[
48931 2010-01-30 Howard updated Table numbers.
48932 ]</i></p>
48933
48934
48935 <p><i>[
48936 2010 Pittsburgh:
48937 ]</i></p>
48938
48939
48940 <blockquote>
48941 Moved to Ready for Pittsburgh.
48942 </blockquote>
48943
48944
48945
48946 <p><b>Proposed resolution:</b></p>
48947
48948
48949 <p>
48950 Option (C):
48951 </p>
48952 <blockquote>
48953
48954 <ol>
48955 <li>
48956 <p>
48957 In 23.2.1 [container.requirements.general] change Table 90 -- Container requirements as indicated:
48958 </p>
48959
48960 <ol type="a">
48961 <li>
48962 <p>
48963 Change the text in the Assertion/note column in the row for "<tt>X u</tt>;"
48964 as follows:
48965 </p>
48966
48967 <blockquote>
48968 post: <tt>u.<del>size() == 0</del><ins>empty() == true</ins></tt>
48969 </blockquote>
48970 </li>
48971
48972 <li>
48973 <p>
48974 Change the text in the Assertion/note column in the row for "<tt>X();</tt>"
48975 as follows:
48976 </p>
48977
48978 <blockquote>
48979 <tt>X().<del>size() == 0</del><ins>empty() == true</ins></tt>
48980 </blockquote>
48981 </li>
48982
48983 <li>
48984 <p>
48985 Change the text in the Operational Semantics column in the row for
48986 "<tt>a == b</tt>" as follows:
48987 </p>
48988 <blockquote>
48989 <tt>==</tt> is an equivalence relation.
48990 <tt><del>a.size()</del><ins>distance(a.begin(), a.end())</ins> ==
48991    <del>b.size()</del><ins>distance(b.begin(), b.end())</ins> &amp;&amp;
48992 equal(a.begin(), a.end(), b.begin())</tt>
48993 </blockquote>
48994 </li>
48995
48996 <li>
48997 <p>
48998 Add text in the Ass./Note/pre-/post-condition column in the row for
48999 "<tt>a == b</tt>" as follows:
49000 </p>
49001 <blockquote><ins>
49002 <i>Requires:</i> <tt>T</tt> is <tt>EqualityComparable</tt>
49003 </ins></blockquote>
49004 </li>
49005
49006 <li>
49007 <p>
49008 Change the text in the Operational Semantics column in the row for
49009 "<tt>a.size()</tt>" as follows:
49010 </p>
49011
49012 <blockquote>
49013 <tt><del>a.end() - a.begin()</del><ins>distance(a.begin(), a.end())</ins></tt>
49014 </blockquote>
49015 </li>
49016
49017 <li>
49018 <p>
49019 Change the text in the Operational Semantics column in the row for
49020 "<tt>a.max_size()</tt>" as follows:
49021 </p>
49022
49023 <blockquote>
49024 <tt><del>size()</del><ins>distance(begin(), end())</ins></tt> of the largest
49025 possible container
49026 </blockquote>
49027 </li>
49028
49029 <li>
49030 <p>
49031 Change the text in the Operational Semantics column in the row for
49032 "<tt>a.empty()</tt>" as follows:
49033 </p>
49034
49035 <blockquote>
49036 <tt><del>a.size() == 0</del><ins>a.begin() == a.end()</ins></tt>
49037 </blockquote>
49038 </li>
49039 </ol>
49040 </li>
49041
49042 <li>
49043 <p>
49044 In 23.2.1 [container.requirements.general] change Table 93 -- Allocator-aware container requirements as indicated:
49045 </p>
49046
49047 <ol type="a">
49048 <li>
49049 <p>
49050 Change the text in the Assertion/note column in the row for "<tt>X() /
49051 X u;</tt>" as follows:
49052 </p>
49053
49054 <blockquote>
49055 <i>Requires:</i> <tt>A</tt> is <tt>DefaultConstructible</tt> post: <tt><del>u.size() ==
49056 0</del><ins>u.empty() == true</ins></tt>, <tt>get_allocator() == A()</tt>
49057 </blockquote>
49058 </li>
49059
49060 <li>
49061 <p>
49062 Change the text in the Assertion/note column in the row for "<tt>X(m) /
49063 X u(m);</tt>" as follows:
49064 </p>
49065
49066 <blockquote>
49067 post: <tt><del>u.size() == 0</del><ins>u.empty() == true</ins>,
49068 get_allocator() == m</tt>
49069 </blockquote>
49070 </li>
49071 </ol>
49072 </li>
49073
49074 <li>
49075 <p>
49076 In 23.2.3 [sequence.reqmts] change Table 94 -- Sequence container requirements as indicated:
49077 </p>
49078
49079 <ol type="a">
49080 <li>
49081 <p>
49082 Change the text in the Assertion/note column in the row for "<tt>X(n,
49083 t) / X a(n, t)</tt>" as follows:
49084 </p>
49085
49086 <blockquote>
49087 post: <tt><del>size()</del><ins>distance(begin(), end())</ins> == n [..]</tt>
49088 </blockquote>
49089 </li>
49090
49091 <li>
49092 <p>
49093 Change the text in the Assertion/note column in the row for "<tt>X(i,
49094 j) / X a(i, j)</tt>" as follows:
49095 </p>
49096
49097 <blockquote>
49098 [..] post: <del><tt>size() ==</tt> distance between <tt>i</tt> and
49099 <tt>j</tt></del><ins><tt>distance(begin(), end()) == distance(i, j)</tt></ins> [..]
49100 </blockquote>
49101 </li>
49102
49103 <li>
49104 <p>
49105 Change the text in the Assertion/note column in the row for
49106 "<tt>a.clear()</tt>" as follows:
49107 </p>
49108 <blockquote>
49109 <tt><ins>a.</ins>erase(<ins>a.</ins>begin(), <ins>a.</ins>end())</tt> post:
49110 <tt><del>size() == 0</del><ins>a.empty() == true</ins></tt>
49111 </blockquote>
49112 </li>
49113 </ol>
49114 </li>
49115
49116 <li>
49117 <p>
49118 In 23.2.4 [associative.reqmts] change Table 96 -- Associative container requirements as indicated:
49119 </p>
49120
49121 <p><i>[
49122 Not every occurrence of <tt>size()</tt> was replaced, because all current
49123 associative containers
49124 have a <tt>size</tt>. The following changes ensure consistency regarding the
49125 semantics of "<tt>erase</tt>"
49126 for all tables and adds some missing objects
49127 ]</i></p>
49128
49129
49130 <ol type="a">
49131
49132 <li>
49133 <p>
49134 Change the text in the Complexity column in the row for <tt>X(i,j,c)/X
49135 a(i,j,c);</tt> as follows:
49136 </p>
49137
49138 <blockquote>
49139 <tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> <ins><tt> == distance(i,
49140 j)</tt></ins><del>is the distance from <tt>i</tt> to <tt>j</tt></del>); ...
49141 </blockquote>
49142
49143 </li>
49144
49145 <li>
49146 <p>
49147 Change the text in the Complexity column in the row for
49148 "<tt>a.insert(i, j)</tt>" as follows:
49149 </p>
49150 <blockquote>
49151 <tt>N log(<ins>a.</ins>size() + N)</tt> <del>(<tt>N</tt> is the distance from <tt>i</tt> to
49152 <tt>j</tt>)</del><ins> where <tt>N == distance(i, j)</tt></ins>
49153 </blockquote>
49154 </li>
49155
49156 <li>
49157 <p>
49158 Change the text in the Complexity column in the row for
49159 "<tt>a.erase(k)</tt>" as follows:
49160 </p>
49161 <blockquote>
49162 <tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
49163 </blockquote>
49164 </li>
49165
49166 <li>
49167 <p>
49168 Change the text in the Complexity column in the row for
49169 "<tt>a.erase(q1, q2)</tt>" as follows:
49170 </p>
49171
49172 <blockquote>
49173 <tt>log(<ins>a.</ins>size()) + N</tt> where <tt>N</tt> <del>is the distance from <tt>q1</tt>
49174 to <tt>q2</tt></del>
49175    <ins><tt>== distance(q1, q2)</tt></ins>.
49176 </blockquote>
49177 </li>
49178
49179 <li>
49180 <p>
49181 Change the text in the Assertion/note column in the row for
49182 "<tt>a.clear()</tt>" as follows:
49183 </p>
49184
49185 <blockquote>
49186 <tt><ins>a.</ins>erase(a.begin(),a.end())</tt> post: <tt><del>size() ==
49187 0</del><ins>a.empty() == true</ins></tt>
49188 </blockquote>
49189 </li>
49190
49191 <li>
49192 <p>
49193 Change the text in the Complexity column in the row for "<tt>a.clear()</tt>"
49194 as follows:
49195 </p>
49196
49197 <blockquote>
49198 linear in <tt><ins>a.</ins>size()</tt>
49199 </blockquote>
49200 </li>
49201
49202 <li>
49203 <p>
49204 Change the text in the Complexity column in the row for
49205 "<tt>a.count(k)</tt>" as follows:
49206 </p>
49207
49208 <blockquote>
49209 <tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
49210 </blockquote>
49211 </li>
49212 </ol>
49213 </li>
49214
49215 <li>
49216 <p>
49217 In 23.2.5 [unord.req] change Table 98 -- Unordered associative container requirements as indicated:
49218 </p>
49219 <p><i>[
49220 The same rational as for Table 96 applies here
49221 ]</i></p>
49222
49223
49224 <ol type="a">
49225 <li>
49226 <p>
49227 Change the text in the Assertion/note column in the row for
49228 "<tt>a.clear()</tt>" as follows:
49229 </p>
49230
49231 <blockquote>
49232 [..] Post: <tt>a.<del>size() == 0</del><ins>empty() == true</ins></tt>
49233 </blockquote>
49234 </li>
49235 </ol>
49236 </li>
49237 </ol>
49238
49239
49240 </blockquote>
49241
49242
49243
49244
49245
49246 <hr>
49247 <h3><a name="865"></a>865. More algorithms that throw away information</h3>
49248 <p><b>Section:</b> 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
49249  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13 <b>Last modified:</b> 2010-10-29</p>
49250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
49251 <p><b>Discussion:</b></p>
49252 <p>
49253 In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
49254 unnecessarily throw away information. These are typically algorithms,
49255 which sequentially write into an <tt>OutputIterator</tt>, but do not return the
49256 final value of this output iterator. These cases are:
49257 </p>
49258
49259 <ol>
49260 <li>
49261 <pre>template&lt;class OutputIterator, class Size, class T&gt;
49262 void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
49263
49264 <li>
49265 <pre>template&lt;class OutputIterator, class Size, class Generator&gt;
49266 void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
49267 </ol>
49268 <p>
49269 In both cases the minimum requirements on the iterator are
49270 <tt>OutputIterator</tt>, which means according to the requirements of
49271 24.2.4 [output.iterators]/2 that only single-pass iterations are guaranteed.
49272 So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
49273 available, they have no chance to continue pushing further values
49274 into it, which seems to be a severe limitation to me.
49275 </p>
49276
49277 <p><i>[
49278 Post Summit Daniel "conceptualized" the wording.
49279 ]</i></p>
49280
49281
49282 <p><i>[
49283 Batavia (2009-05):
49284 ]</i></p>
49285
49286 <blockquote>
49287 <p>
49288 Alisdair likes the idea, but has concerns about the specific wording
49289 about the returns clauses.
49290 </p>
49291 <p>
49292 Alan notes this is a feature request.
49293 </p>
49294 <p>
49295 Bill notes we have made similar changes to other algorithms.
49296 </p>
49297 <p>
49298 Move to Open.
49299 </p>
49300 </blockquote>
49301
49302 <p><i>[
49303 2009-07 Frankfurt
49304 ]</i></p>
49305
49306
49307 <blockquote>
49308 We have a consensus for moving forward on this issue, but Daniel needs
49309 to deconceptify it.
49310 </blockquote>
49311
49312 <p><i>[
49313 2009-07-25 Daniel provided non-concepts wording.
49314 ]</i></p>
49315
49316
49317 <p><i>[
49318 2009-10 Santa Cruz:
49319 ]</i></p>
49320
49321
49322 <blockquote>
49323 Moved to Ready.
49324 </blockquote>
49325
49326
49327
49328 <p><b>Proposed resolution:</b></p>
49329
49330 <ol>
49331 <li>
49332 <p>
49333 Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
49334 <tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.6 [alg.fill] by
49335 </p>
49336
49337 <blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
49338   <del>void</del><ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
49339 </pre></blockquote>
49340
49341 <p>
49342 Just after the effects clause add a new returns clause saying:
49343 </p>
49344
49345 <blockquote>
49346 <ins><i>Returns:</i> For <tt>fill_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
49347 returns <tt>first</tt> for <tt>fill_n</tt>.</ins>
49348 </blockquote>
49349 </li>
49350
49351 <li>
49352 <p>
49353 Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2,
49354 header <tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.7 [alg.generate] by
49355 </p>
49356
49357 <blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
49358   <del>void</del><ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
49359 </pre></blockquote>
49360
49361 <p>
49362 Just after the effects clause add a new returns clause saying:
49363 </p>
49364
49365 <blockquote>
49366 <ins>For <tt>generate_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
49367 returns <tt>first</tt> for <tt>generate_n</tt>.</ins>
49368 </blockquote>
49369 </li>
49370 </ol>
49371
49372
49373
49374
49375
49376
49377
49378 <hr>
49379 <h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
49380 <p><b>Section:</b> 20.9.8 [specialized.algorithms], 20.9.10.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
49381  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-14 <b>Last modified:</b> 2010-10-29</p>
49382 <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>
49383 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
49384 <p><b>Discussion:</b></p>
49385 <p>
49386 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
49387 new-expression in 20.9.5.1 [allocator.members]. I believe the rationale
49388 given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
49389 </p>
49390 <ul>
49391 <li>
49392 <p>
49393 in 20.9.8 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
49394 <tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
49395 the unqualified placement new-expression in some variation of the form:
49396 </p>
49397 <blockquote><pre>new  (static_cast&lt;void*&gt;(&amp;*result)) typename  iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
49398 </pre></blockquote>
49399 </li>
49400 <li>
49401 <p>
49402 in 20.9.10.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
49403 </p>
49404 <blockquote><pre>new  (pv)  T(std::forward&lt;Args&gt;(args)...),
49405 </pre></blockquote>
49406 </li>
49407 </ul>
49408 <p>
49409 I suggest to add qualification in all those places. As far as I know,
49410 these are all the remaining places in the whole library that explicitly
49411 use a placement new-expression. Should other uses come out, they should
49412 be qualified as well.
49413 </p>
49414 <p>
49415 As an aside, a qualified placement new-expression does not need
49416 additional requirements to be compiled in a constrained context. By
49417 adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
49418 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
49419 would no longer be needed by library and
49420 should therefore be removed.
49421 </p>
49422
49423 <p><i>[
49424 San Francisco:
49425 ]</i></p>
49426
49427
49428 <blockquote>
49429 Detlef: If we move this to Ready, it's likely that we'll forget about
49430 the side comment about the <tt>HasPlacementNew</tt> concept.
49431 </blockquote>
49432
49433 <p><i>[
49434 post San Francisco:
49435 ]</i></p>
49436
49437
49438 <blockquote>
49439 Daniel:  <tt>HasPlacementNew</tt> has been removed from
49440 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774 (Foundational Concepts)</a>.
49441 </blockquote>
49442
49443
49444
49445 <p><b>Proposed resolution:</b></p>
49446 <p>
49447 Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
49448 </p>
49449 <ul>
49450 <li>
49451 20.9.8.2 [uninitialized.copy], paragraphs 1 and 3
49452 </li>
49453 <li>
49454 20.9.8.3 [uninitialized.fill]  paragraph 1
49455 </li>
49456 <li>
49457 20.9.8.4 [uninitialized.fill.n] paragraph 1
49458 </li>
49459 <li>
49460 20.9.10.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
49461 </li>
49462 </ul>
49463
49464
49465
49466
49467
49468
49469 <hr>
49470 <h3><a name="868"></a>868. default construction and value-initialization</h3>
49471 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
49472  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2010-11-24</p>
49473 <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>
49474 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
49475 <p><b>Discussion:</b></p>
49476 <p>
49477 The term "default constructed" is often used in wording that predates
49478 the introduction of the concept of value-initialization. In a few such
49479 places the concept of value-initialization is more correct than the
49480 current wording (for example when the type involved can be a built-in)
49481 so a replacement is in order. Two of such places are already covered by
49482 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>. This issue deliberately addresses the hopefully
49483 non-controversial changes in the attempt of being approved more quickly.
49484 A few other occurrences (for example in <tt>std::tuple</tt>,
49485 <tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
49486 issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>. This issue is
49487 related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>.
49488 </p>
49489
49490 <p><i>[
49491 San Francisco:
49492 ]</i></p>
49493
49494
49495 <blockquote>
49496 <p>
49497 The list provided in the proposed resolution is not complete. James
49498 Dennett will review the library and provide a complete list and will
49499 double-check the vocabulary.
49500 </p>
49501 <p>
49502 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a> tuple construction
49503 </p>
49504 </blockquote>
49505
49506 <p><i>[
49507 2009-07 Frankfurt
49508 ]</i></p>
49509
49510
49511 <blockquote>
49512 <p>
49513 The proposed resolution is incomplete.
49514 </p>
49515 <p>
49516 Move to Tentatively NAD Future. Howard will contact Ganesh for wording.
49517 If wording is forthcoming, Howard will move it back to Review.
49518 </p>
49519 </blockquote>
49520
49521 <p><i>[
49522 2009-07-18 Ganesh updated the proposed wording.
49523 ]</i></p>
49524
49525
49526 <blockquote>
49527 <p>
49528 Howard:  Moved back to Review.  Note that 20.2.1 [utility.arg.requirements]
49529 refers to a section that is not in the current working paper, but does refer to
49530 a section that we expect to reappear after the de-concepts merge.  This was a
49531 point of confusion we did not recognize when we reviewed this issue in Frankfurt.
49532 </p>
49533 <p>
49534 Howard:  Ganesh also includes a survey of places in the WP surveyed for changes
49535 of this nature and purposefully <em>not</em> treated:
49536 </p>
49537
49538 <blockquote>
49539 <p>
49540 Places where changes are <u>not</u> being
49541 proposed
49542 </p>
49543 <p>
49544 In the following paragraphs, we are not proposing changes because
49545 it's not clear whether we actually prefer value-initialization over
49546 default-initialization (now partially covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>):
49547 </p>
49548 <ul>
49549     <li><p>20.9.9.2.1 [unique.ptr.single.ctor] para 3 e 7</p></li>
49550     <li><p>24.5.1.3.1 [reverse.iter.cons] para 1</p></li>
49551     <li><p>24.5.3.3.1 [move.iter.op.const] para 1</p></li>
49552 </ul>
49553 <p>In the following paragraphs, the expression "default
49554 constructed" need not be changed, because the relevant type does
49555 not depend on a template parameter and has a user-provided
49556 constructor:</p>
49557 <ul>
49558     <li><p> [func.referenceclosure.invoke] para 12, type:
49559     reference_closure</p></li>
49560     <li><p>30.3.1.2 [thread.thread.constr] para 30, type: thread</p></li>
49561     <li><p>30.3.1.5 [thread.thread.member] para 52, type: thread_id</p></li>
49562     <li><p>30.3.2 [thread.thread.this], para 1, type: thread_id</p></li>
49563 </ul>
49564 </blockquote>
49565
49566 </blockquote>
49567
49568 <p><i>[
49569 2009-08-18 Daniel adds:
49570 ]</i></p>
49571
49572
49573 <blockquote>
49574 <p>
49575 I have no objections against the currently suggested changes, but I
49576 also cross-checked
49577 with the list regarding intentionally excluded changes, and from this
49578 I miss the discussion
49579 of
49580 </p>
49581
49582 <ol>
49583 <li>
49584 <p>
49585 21.4.1 [string.require]/2:
49586 </p>
49587
49588 <blockquote>
49589 "[..] The <tt>Allocator</tt> object used shall be a copy of the <tt>Allocator&gt;</tt>
49590 object passed to the <tt>basic_string</tt> object's
49591 constructor or, if the constructor does not take an <tt>Allocator</tt>
49592 argument, a copy of a default-constructed
49593 <tt>Allocator</tt> object."
49594 </blockquote>
49595 </li>
49596
49597 <li>
49598 <p>
49599 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
49600 26.5.1.4 [rand.req.eng], Table 109, expression "<tt>T()</tt>":
49601 </p>
49602 <blockquote>
49603 Pre-/post-condition: "Creates an engine with the same initial state as
49604 all other default-constructed engines of type <tt>X</tt>."
49605 </blockquote>
49606
49607 <p>
49608 as well as in 26.5.5 [rand.predef]/1-9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 26.5.7.1 [rand.util.seedseq]/3, 27.7.1.1.1 [istream.cons]/3, 27.7.2.2 [ostream.cons]/9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 28.13 [re.grammar]/2, 30.3.1.4 [thread.thread.assign]/1 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>),
49609 </p>
49610 <p><i>[
49611 Candidates for the "the expression "default constructed" need not be
49612 changed" list
49613 ]</i></p>
49614
49615
49616 <p>
49617 I'm fine, if these would be added to the intentionally exclusion list,
49618 but mentioning them makes it
49619 easier for other potential reviewers to decide on the relevance or
49620 not-relevance of them for this issue.
49621 </p>
49622 </li>
49623
49624 <li>
49625 <p>
49626 I suggest to remove the reference of  [func.referenceclosure.invoke]
49627 in the "it's not clear" list, because
49628 this component does no longer exist.
49629 </p>
49630 </li>
49631
49632 <li>
49633 <p>
49634 I also suggest to add a short comment that all paragraphs in the
49635 resolution whether they refer to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> or to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a> numbering, because e.g. "Change 23.3.2.1 [deque.cons] para 5" is an <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> coordinate, while "Change 23.3.2.2 [deque.capacity] para 1" is an <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a> coordinate. Even better would be to use one default document
49636 for the numbering (probably <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>) and mention special cases (e.g. "Change 20.2.1 [utility.arg.requirements] para 2" as referring to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> numbering).
49637 </p>
49638 </li>
49639 </ol>
49640
49641 </blockquote>
49642
49643 <p><i>[
49644 2009-08-18 Alisdair adds:
49645 ]</i></p>
49646
49647
49648 <blockquote>
49649 <p>
49650 I strongly believe the term "default constructed" should not appear in
49651 the library clauses unless we very clearly define a meaning for it, and
49652 I am not sure what that would be.
49653 </p>
49654
49655 <p>
49656 In those cases where we do not want to replace "default constructed"
49657 with "vale initialized" we should be using "default initialized".  If we
49658 have a term that could mean either, we reduce portability of programs.
49659 </p>
49660
49661 <p>
49662 I have not done an exhaustive review to clarify if that is a vendor
49663 freedom we have reason to support (e.g. value-init in debug,
49664 default-init in release) so I may yet be convinced that LWG has reason
49665 to define this new term of art, but generally C++ initialization is
49666 confusing enough without supporting further ill-defined terms.
49667 </p>
49668 </blockquote>
49669
49670 <p><i>[
49671 2009-10 Santa Cruz:
49672 ]</i></p>
49673
49674
49675 <blockquote>
49676 Move to Ready.
49677 </blockquote>
49678
49679 <p><i>[
49680 2010 Pittsburgh:
49681 ]</i></p>
49682
49683
49684 <blockquote>
49685 Moved to review in order to enable conflict resolution with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>.
49686 </blockquote>
49687
49688 <p><i>[
49689 2010-03-26 Daniel harmonized the wording with the upcoming FCD.
49690 ]</i></p>
49691
49692
49693
49694 <p><i>[
49695 2010 Rapperswil:
49696 ]</i></p>
49697
49698
49699 <blockquote>
49700 Move to Ready.
49701 </blockquote>
49702
49703 <p><i>[
49704 Adopted at 2010-11 Batavia
49705 ]</i></p>
49706
49707
49708
49709
49710 <p><b>Proposed resolution:</b></p>
49711 <p>
49712 Change 20.2.1 [utility.arg.requirements] para 2:
49713 </p>
49714
49715 <blockquote>
49716 2 In general, a default constructor is
49717 not required. Certain container class member function signatures
49718 specify <del>the default constructor</del><ins>T()</ins>
49719 as a default argument. T() shall be a well-defined expression (8.5)
49720 if one of those signatures is called using the default argument
49721 (8.3.6).
49722 </blockquote>
49723
49724 <p>
49725 Change 23.3.2.1 [deque.cons] para 3:
49726 </p>
49727
49728 <blockquote>
49729 3 <i>Effects:</i> Constructs a deque with n
49730 <del>default constructed</del><ins>value-initialized</ins>
49731 elements. 
49732 </blockquote>
49733
49734 <p>
49735 Change 23.3.2.2 [deque.capacity] para 1:
49736 </p>
49737
49738 <blockquote>
49739 1 <i>Effects:</i> If sz &lt; size(), equivalent
49740 to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
49741 size() <del>default
49742 constructed</del><ins>value-initialized</ins>
49743 elements to the sequence.
49744 </blockquote>
49745
49746 <p>
49747 Change 23.3.3.1 [forwardlist.cons] para 3:
49748 </p>
49749
49750 <blockquote>
49751 3 <i>Effects:</i> Constructs a forward_list object with n <del>default
49752 constructed</del><ins>value-initialized</ins>
49753 elements.
49754 </blockquote>
49755
49756 <p>
49757 Change 23.3.3.4 [forwardlist.modifiers] para 22:
49758 </p>
49759
49760 <blockquote>
49761 22 <i>Effects:</i> [...] For the first signature
49762 the inserted elements are <del>default
49763 constructed</del><ins>value-initialized</ins>,
49764 and for the second signature they are copies of c.
49765 </blockquote>
49766
49767 <p>
49768 Change 23.3.4.1 [list.cons] para 3:
49769 </p>
49770
49771 <blockquote>
49772 3 <i>Effects:</i> Constructs a list with n <del>default
49773 constructed</del><ins>value-initialized</ins>
49774 elements. 
49775 </blockquote>
49776
49777 <p>
49778 Change 23.3.4.2 [list.capacity] para 1:
49779 </p>
49780
49781 <blockquote>
49782 1 <i>Effects:</i> If sz &lt; size(), equivalent
49783 to list&lt;T&gt;::iterator it = begin(); advance(it, sz); erase(it,
49784 end());. If size() &lt; sz, appends sz - size() <del>default
49785 constructed</del><ins>value-initialized</ins>
49786 elements to the sequence.
49787 </blockquote>
49788
49789 <p>
49790 Change 23.4.1.1 [vector.cons] para 3:
49791 </p>
49792
49793 <blockquote>
49794 3 <i>Effects:</i> Constructs a vector with n
49795 <del>default constructed</del><ins>value-initialized</ins>
49796 elements. 
49797 </blockquote>
49798
49799 <p>
49800 Change 23.4.1.2 [vector.capacity] para 9:
49801 </p>
49802
49803 <blockquote>
49804 9 <i>Effects:</i> If sz &lt; size(), equivalent
49805 to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
49806 size() <del>default
49807 constructed</del><ins>value-initialized</ins>
49808 elements to the sequence.
49809 </blockquote>
49810
49811
49812
49813
49814
49815
49816 <hr>
49817 <h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
49818 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
49819  <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2010-10-29</p>
49820 <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>
49821 <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>
49822 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
49823 <p><b>Discussion:</b></p>
49824 <p>
49825 Is there any language in the current draft specifying the behaviour of the following snippet?
49826 </p>
49827
49828 <blockquote><pre>unordered_set&lt;int&gt; s;
49829 unordered_set&lt;int&gt;::local_iterator it = s.end(0);
49830
49831 // Iterate past end - the unspecified part
49832 it++;
49833 </pre></blockquote>
49834
49835 <p>
49836 I don't think there is anything about <tt>s.end(n)</tt> being considered an
49837 iterator for the past-the-end value though (I think) it should be.
49838 </p>
49839
49840 <p><i>[
49841 San Francisco:
49842 ]</i></p>
49843
49844
49845 <blockquote>
49846 We believe that this is not a substantive change, but the proposed
49847 change to the wording is clearer than what we have now.
49848 </blockquote>
49849
49850 <p><i>[
49851 Post Summit:
49852 ]</i></p>
49853
49854
49855 <blockquote>
49856 Recommend Tentatively Ready.
49857 </blockquote>
49858
49859
49860
49861 <p><b>Proposed resolution:</b></p>
49862 <p>
49863 Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
49864 </p>
49865
49866 <blockquote>
49867 <table border="1">
49868 <caption>Table 97: Unordered associative container requirements</caption>
49869 <tbody><tr>
49870 <th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
49871 </tr>
49872 <tr>
49873 <td><tt>b.begin(n)</tt></td>
49874 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
49875 <td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
49876 valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
49877 <ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
49878 If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
49879 <td>Constant</td>
49880 </tr>
49881 <tr>
49882 <td><tt>b.end(n)</tt></td>
49883 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
49884 <td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
49885 <ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
49886 <td>Constant</td>
49887 </tr>
49888 </tbody></table>
49889 </blockquote>
49890
49891
49892
49893
49894
49895
49896 <hr>
49897 <h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
49898 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
49899  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17 <b>Last modified:</b> 2010-10-29</p>
49900 <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>
49901 <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>
49902 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
49903 <p><b>Discussion:</b></p>
49904 <p>
49905 Good ol' associative containers allow both function pointers and
49906 function objects as feasible
49907 comparators, as described in 23.2.4 [associative.reqmts]/2:
49908 </p>
49909
49910 <blockquote>
49911 Each associative container is parameterized on <tt>Key</tt> and an ordering
49912 relation <tt>Compare</tt> that
49913 induces a strict weak ordering (25.3) on elements of Key. [..]. The
49914 object of type <tt>Compare</tt> is
49915 called the comparison object of a container. This comparison object
49916 may be a pointer to
49917 function or an object of a type with an appropriate function call operator.[..]
49918 </blockquote>
49919
49920 <p>
49921 The corresponding wording for unordered containers is not so clear,
49922 but I read it to disallow
49923 function pointers for the hasher and I miss a clear statement for the
49924 equality predicate, see
49925 23.2.5 [unord.req]/3+4+5:
49926 </p>
49927
49928 <blockquote>
49929 <p>
49930 Each unordered associative container is parameterized by <tt>Key</tt>, by a
49931 function object <tt>Hash</tt> that
49932 acts as a hash function for values of type <tt>Key</tt>, and by a binary
49933 predicate <tt>Pred</tt> that induces an
49934 equivalence relation on values of type <tt>Key</tt>.[..]
49935 </p>
49936 <p>
49937 A hash function is a function object that takes a single argument of
49938 type <tt>Key</tt> and returns a
49939 value of type <tt>std::size_t</tt>.
49940 </p>
49941 <p>
49942 Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
49943 container's equality function object
49944 returns <tt>true</tt> when passed those values.[..]
49945 </p>
49946 </blockquote>
49947
49948 <p>
49949 and table 97 says in the column "assertion...post-condition" for the
49950 expression X::hasher:
49951 </p>
49952
49953 <blockquote>
49954 <tt>Hash</tt> shall be a unary function object type such that the expression
49955 <tt>hf(k)</tt> has type <tt>std::size_t</tt>.
49956 </blockquote>
49957
49958 <p>
49959 Note that 20.8 [function.objects]/1 defines as "Function objects are
49960 objects with an <tt>operator()</tt> defined.[..]"
49961 </p>
49962 <p>
49963 Does this restriction exist by design or is it an oversight? If an
49964 oversight, I suggest that to apply
49965 the following
49966 </p>
49967
49968 <p><i>[
49969 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
49970 ]</i></p>
49971
49972
49973 <p><i>[
49974 2009-10 Santa Cruz:
49975 ]</i></p>
49976
49977
49978 <blockquote>
49979 Ask Daniel to provide proposed wording that: makes it explicit that
49980 function pointers are function objects at the beginning of 20.8 [function.objects]; fixes the "requirements" for typedefs in
49981 20.8.4 [refwrap] to instead state that the function objects
49982 defined in that clause have these typedefs, but not that these typedefs
49983 are requirements on function objects; remove the wording that explicitly
49984 calls out that associative container comparators may be function
49985 pointers.
49986 </blockquote>
49987
49988 <p><i>[
49989 2009-12-19 Daniel updates wording and rationale.
49990 ]</i></p>
49991
49992
49993 <p><i>[
49994 2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
49995 ]</i></p>
49996
49997
49998
49999
50000 <p><b>Rationale:</b></p>
50001
50002 <p>
50003 The below provided wording also affects some part of the library which is
50004 involved with <em>callable types</em> (20.8.1 [func.def]/3). Reason for
50005 this is that <em>callable objects</em> do have a lot in common with <em>function
50006 objects</em>. A simple formula seems to be:
50007 </p>
50008
50009 <blockquote>
50010 callable objects = function objects + pointers to member
50011 </blockquote>
50012
50013 <p>
50014 The latter group is excluded from function objects because of the
50015 expression-based usage of <em>function objects</em> in the algorithm clause,
50016 which is incompatible with the notation to dereference pointers to member
50017 without a concept map available in the language.
50018 </p>
50019
50020 <p>
50021 This analysis showed some currently existing normative definition differences
50022 between the above subset of callable objects and function objects which seem to
50023 be unintended: Backed by the Santa Cruz outcome function objects should include
50024 both function pointers and "object[s] with an operator() defined". This clearly
50025 excludes class types with a conversion function to a function pointer or all
50026 similar conversion function situations described in 13.3 [over.match]/2
50027 b. 2. In contrast to this, the wording for callable types seems to be less
50028 constrained (20.8.1 [func.def]/3):
50029 </p>
50030
50031 <blockquote>
50032 A callable type is a [..] class type whose objects can appear immediately to the
50033 left of a function call operator.
50034 </blockquote>
50035
50036 <p>
50037 The rationale given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#fn2">N1673</a>
50038 and a recent private communication with Peter Dimov revealed that the intention
50039 of this wording was to cover the above mentioned class types with conversion
50040 functions as well. To me the current wording of callable types can be read
50041 either way and I suggest to make the intention more explicit by replacing
50042 </p>
50043
50044 <blockquote>
50045 [..] class type whose objects can appear immediately to the left of a function
50046 call operator
50047 </blockquote>
50048
50049 by
50050
50051 <blockquote>
50052 [..] class type whose objects can appear as the leftmost subexpression of a
50053 function call expression 5.2.2 [expr.call].
50054 </blockquote>
50055
50056 <p>
50057 and to use the same definition for the class type part of <em>function
50058 objects</em>, because there is no reason to exclude class types with a
50059 conversion function to e.g. pointer to function from being used in algorithms.
50060 </p>
50061
50062 <p>
50063 Now this last term "function objects" itself brings us to a third unsatisfactory
50064 state: The term is used both for objects (e.g. "Function objects are
50065 objects[..]" in 20.8 [function.objects]/1) and for types (e.g. "Each
50066 unordered associative container is parameterized [..] by a function object Hash
50067 that acts as a hash function [..]" in 23.2.5 [unord.req]/3). This
50068 impreciseness should be fixed and I suggest to introduce the term <em>function
50069 object type</em> as the counter part to <em>callable type</em>. This word seems
50070 to be a quite natural choice, because the library already uses it here and there
50071 (e.g. "Hash shall be a unary function object type such that the expression
50072 <tt>hf(k)</tt> has type <tt>std::size_t</tt>." in Table 98, "<tt>X::hasher</tt>"
50073 or "Requires: <tt>T</tt> shall be a function object type [..]" in 20.8.14.2.5 [func.wrap.func.targ]/3).
50074 </p>
50075
50076 <p>
50077 Finally I would like to add that part of the issue 870 discussion related to the
50078 requirements for typedefs in 20.8.4 [refwrap] during the Santa Cruz
50079 meeting is now handled by the new issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>.
50080 </p>
50081
50082 <p>
50083 Obsolete rationale:
50084 </p>
50085
50086 <blockquote>
50087 <p><i>[
50088 San Francisco:
50089 ]</i></p>
50090
50091
50092 <blockquote>
50093 This is fixed by
50094 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
50095 </blockquote>
50096
50097 </blockquote>
50098
50099
50100
50101 <p><b>Proposed resolution:</b></p>
50102
50103 <ol>
50104
50105 <li>
50106 <p>
50107 Change 20.8 [function.objects]/1 as indicated:
50108 </p>
50109
50110 <blockquote>
50111 <p>
50112 1 <del>Function objects are objects with an <tt>operator()</tt>
50113 defined.</del> <ins>An object type (3.9 [basic.types]) that can be the
50114 type of the <em>postfix-expression</em> in a function call (5.2.2 [expr.call], 13.3.1.1 [over.match.call]) is called a <em>function
50115 object type</em><sup>*</sup>. A <em>function object</em> is an object of a
50116 <em>function object type</em>.</ins> In the places where one would expect to
50117 pass a pointer to a function to an algorithmic template (Clause 25 [algorithms]), the interface is specified to accept <del>an object with
50118 an <tt>operator()</tt> defined</del><ins>a function object</ins>. This not only
50119 makes algorithmic templates work with pointers to functions, but also enables
50120 them to work with arbitrary function objects.
50121 </p>
50122 <blockquote><ins>
50123 * Such a type is either a function pointer or a class type which often has a
50124 member <tt>operator()</tt>, but in some cases it can omit that member and
50125 provide a conversion to a pointer to function.
50126 </ins></blockquote>
50127 </blockquote>
50128 </li>
50129
50130 <li>
50131 <p>
50132 Change 20.8.1 [func.def]/3 as indicated: <i>[The intent is to make the
50133 commonality of callable types and function object
50134 types more explicit and to get rid of wording redundancies]</i>
50135 </p>
50136
50137 <blockquote>
50138 3 A <i>callable type</i> is <del>a pointer to function,</del> a pointer to
50139 member <del>function, a pointer to member data,</del> or a <del>class type whose
50140 objects can appear immediately to the left of a function call operator</del>
50141 <ins><em>function object type</em> (20.8 [function.objects])</ins>.
50142 </blockquote>
50143 </li>
50144
50145 <li>
50146 <p>
50147 Change 20.8.10 [bind]/1 as indicated:
50148 </p>
50149
50150 <blockquote>
50151 1 The function template <tt>bind</tt> returns an object that binds a
50152 <del>function</del> <ins>callable</ins> object passed as an argument to
50153 additional arguments.
50154 </blockquote>
50155 </li>
50156
50157 <li>
50158 <p>
50159 Change 20.8.10.1 [func.bind]/1 as indicated:
50160 </p>
50161
50162 <blockquote>
50163 1 This subclause describes a uniform mechanism for binding arguments of
50164 <del>function</del> <ins>callable</ins> objects.
50165 </blockquote>
50166 </li>
50167
50168 <li>
50169 <p>
50170 Change 20.8.14 [func.wrap]/1 as indicated:
50171 </p>
50172
50173 <blockquote>
50174 1 This subclause describes a polymorphic wrapper class that encapsulates
50175 arbitrary <del>function</del> <ins>callable</ins> objects.
50176 </blockquote>
50177 </li>
50178
50179 <li>
50180 <p>
50181 Change 20.8.14.2 [func.wrap.func]/2 as indicated <i>[The reason for this
50182 change is that 20.8.14.2 [func.wrap.func]/1 clearly says that all callable
50183 types may be wrapped by <tt>std::function</tt> and current implementations
50184 indeed do provide support for pointer to members as well. One further suggested
50185 improvement is to set the below definition of Callable in italics]</i>:
50186 </p>
50187
50188 <blockquote>
50189 2 A <del>function</del><ins>callable</ins> object <tt>f</tt> of type <tt>F</tt>
50190 is <del>Callable</del> <ins><em>Callable</em></ins> for argument types
50191 <del><tt>T1, T2, ..., TN</tt> in</del> <tt>ArgTypes</tt> and <del>a</del> return
50192 type <tt>R</tt><del>,</del> if<del>, given lvalues <tt>t1, t2, ..., tN</tt> of
50193 types <tt>T1, T2, ..., TN</tt>, respectively,</del> <ins>the expression</ins>
50194 <tt><i>INVOKE</i>(f, <ins>declval&lt;ArgTypes&gt;()..., R</ins><del>t1, t2, ...,
50195 tN</del>)</tt><ins>, considered as an unevaluated operand (5 [expr]),</ins> is well formed (20.7.2)<del> and, if <tt>R</tt> is not
50196 <tt>void</tt>, convertible to <tt>R</tt></del>.
50197 </blockquote>
50198 </li>
50199
50200
50201
50202 <li>
50203 <p>
50204 Change 20.8.14.2.1 [func.wrap.func.con]/7 as indicated:
50205 </p>
50206
50207 <blockquote><pre>function(const function&amp; f);
50208 template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, const function&amp; f);
50209 </pre>
50210 <blockquote>
50211 <p>...</p>
50212 <p>
50213 7 <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
50214 pointer or a <del>function</del> <ins>callable</ins> object passed via
50215 <tt>reference_wrapper</tt>. Otherwise, may throw <tt>bad_alloc</tt> or any
50216 exception thrown by the copy constructor of the stored <del>function</del>
50217 <ins>callable</ins> object. [<i>Note:</i> Implementations are encouraged to
50218 avoid the use of dynamically allocated memory for small <del>function</del>
50219 <ins>callable</ins> objects, e.g., where <tt>f</tt>'s target is an object
50220 holding only a pointer or reference to an object and a member function pointer.
50221 \97 <i>end note</i>]
50222 </p>
50223 </blockquote>
50224 </blockquote>
50225 </li>
50226
50227 <li>
50228 <p>
50229 Change 20.8.14.2.1 [func.wrap.func.con]/11 as indicated:
50230 </p>
50231
50232 <blockquote><pre>template&lt;class F&gt; function(F f);
50233 template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
50234 </pre>
50235 <blockquote>
50236 <p>...</p>
50237 <p>
50238 11 [..] [<i>Note:</i> implementations are encouraged to avoid the use of dynamically
50239 allocated memory for small <del>function</del> <ins>callable</ins> objects, for
50240 example, where <tt>f</tt>'s target is an object holding only a pointer or
50241 reference to an object and a member function pointer. \97 <i>end note</i>]
50242 </p>
50243 </blockquote>
50244 </blockquote>
50245 </li>
50246
50247 <li>
50248 <p>
50249 Change 20.8.14.2.4 [func.wrap.func.inv]/3 as indicated:
50250 </p>
50251
50252 <blockquote><pre>R operator()(ArgTypes... args) const
50253 </pre>
50254 <blockquote>
50255 <p>...</p>
50256 <p>
50257 3 <i>Throws:</i> <tt>bad_function_call</tt> if <tt>!*this</tt>; otherwise, any
50258 exception thrown by the wrapped <del>function</del> <ins>callable</ins> object.
50259 </p>
50260 </blockquote>
50261 </blockquote>
50262 </li>
50263
50264 <li>
50265 <p>
50266 Change 20.8.14.2.5 [func.wrap.func.targ]/3 as indicated:
50267 </p>
50268
50269 <blockquote><pre>template&lt;typename T&gt;       T* target();
50270 template&lt;typename T&gt; const T* target() const;
50271 </pre>
50272 <blockquote>
50273 <p>...</p>
50274 <p>
50275 3 <i>Requires:</i> <tt>T</tt> shall be a <del>function object</del> type that is
50276 Callable (20.8.14.2 [func.wrap.func]) for parameter types <tt>ArgTypes</tt>
50277 and return type <tt>R</tt>.
50278 </p>
50279 </blockquote>
50280 </blockquote>
50281 </li>
50282
50283 <li>
50284 <p>
50285 Change 23.2.4 [associative.reqmts]/2 as indicated: <i>[The suggested
50286 removal seems harmless, because 25.4 [alg.sorting]1 already clarifies
50287 that <tt>Compare</tt> is a function object type. Nevertheless it is recommended,
50288 because the explicit naming of "pointer to function" is misleading]</i>
50289 </p>
50290
50291 <blockquote>
50292 2 Each associative container is parameterized on <tt>Key</tt> and an ordering
50293 relation <tt>Compare</tt> that induces a strict weak ordering (25.4 [alg.sorting]) on elements of <tt>Key</tt>. In addition, <tt>map</tt>
50294 and <tt>multimap</tt> associate an arbitrary type <tt>T</tt> with the
50295 <tt>Key</tt>. The object of type <tt>Compare</tt> is called the comparison
50296 object of a container. <del>This comparison object may be a pointer to function
50297 or an object of a type with an appropriate function call operator.</del>
50298 </blockquote>
50299 </li>
50300
50301 <li>
50302 <p>
50303 Change 23.2.5 [unord.req]/3 as indicated:
50304 </p>
50305
50306 <blockquote>
50307 3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
50308 function object <ins>type</ins> <tt>Hash</tt> that acts as a hash function for
50309 values of type <tt>Key</tt>, and by a binary predicate <tt>Pred</tt> that
50310 induces an equivalence relation on values of type Key. [..]
50311 </blockquote>
50312 </li>
50313
50314 <li>
50315 <p>
50316 Change 25.1 [algorithms.general]/7 as indicated: <i>[The intent is to
50317 bring this part in sync with 20.8 [function.objects]]</i>
50318 </p>
50319
50320 <blockquote>
50321 7 The <tt>Predicate</tt> parameter is used whenever an algorithm expects a
50322 function object <ins>(20.8 [function.objects])</ins> that when applied
50323 to the result of dereferencing the corresponding iterator returns a value
50324 testable as <tt>true</tt>. In other words, if an algorithm takes <tt>Predicate
50325 pred</tt> as its argument and <tt>first</tt> as its iterator argument, it should
50326 work correctly in the construct <tt>if (pred(*first)){...}</tt>. The function
50327 object <tt>pred</tt> shall not apply any nonconstant function through the
50328 dereferenced iterator. <del>This function object may be a pointer to function,
50329 or an object of a type with an appropriate function call operator.</del>
50330 </blockquote>
50331 </li>
50332
50333 <li>
50334 <p>
50335 Change 20.9.9.2 [unique.ptr.single]/1 as indicated:
50336 </p>
50337
50338 <blockquote>
50339 1 The default type for the template parameter <tt>D</tt> is
50340 <tt>default_delete</tt>. A client-supplied template argument <tt>D</tt> shall be
50341 a function <del>pointer or functor</del> <ins>object type</ins> for which, given
50342 a value <tt>d</tt> of type <tt>D</tt> and a pointer <tt>ptr</tt> of type
50343 <tt>T*</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of
50344 deallocating the pointer as appropriate for that deleter. <tt>D</tt> may also be
50345 an lvalue-reference to a deleter.
50346 </blockquote>
50347 </li>
50348
50349 </ol>
50350
50351
50352
50353
50354
50355
50356
50357
50358 <hr>
50359 <h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
50360 <p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
50361  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20 <b>Last modified:</b> 2010-10-29</p>
50362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
50363 <p><b>Discussion:</b></p>
50364 <p>
50365 According to the recent WP
50366 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
50367 26.7.5 [numeric.iota]/1, the requires clause
50368 of <tt>std::iota</tt> says:
50369 </p>
50370
50371 <blockquote>
50372 <tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
50373 shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
50374 </blockquote>
50375
50376 <p>
50377 Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
50378 seems to be the correct choice. I guess the current wording resulted as an
50379 artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
50380 </p>
50381
50382 <p>
50383 Note: If this function will be conceptualized, the here proposed
50384 <tt>MoveConstructible</tt>
50385 requirement can be removed, because this is an implied requirement of
50386 function arguments, see
50387 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
50388 </p>
50389
50390 <p><i>[
50391 post San Francisco:
50392 ]</i></p>
50393
50394
50395 <blockquote>
50396 Issue pulled by author prior to review.
50397 </blockquote>
50398
50399 <p><i>[
50400 2009-07-30 Daniel reopened:
50401 ]</i></p>
50402
50403
50404 <blockquote>
50405 with the absence of concepts, this issue (closed) is valid again and I
50406 suggest to reopen it.
50407 I also revised by proposed resolution based on N2723 wording:
50408 </blockquote>
50409
50410 <p><i>[
50411 2009-10 Santa Cruz:
50412 ]</i></p>
50413
50414
50415 <blockquote>
50416 Change 'convertible' to 'assignable', Move To Ready.
50417 </blockquote>
50418
50419
50420
50421 <p><b>Proposed resolution:</b></p>
50422 <p>
50423 Change the first sentence of 26.7.5 [numeric.iota]/1:
50424 </p>
50425
50426 <blockquote>
50427 <i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of <tt>CopyConstructible</tt> and
50428 <tt>Assignable</tt> types, and shall</del> be
50429 assignable to <tt>ForwardIterator</tt>'s value type. [..]
50430 </blockquote>
50431
50432
50433
50434
50435
50436
50437
50438
50439 <hr>
50440 <h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
50441 <p><b>Section:</b> 24.5.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
50442  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21 <b>Last modified:</b> 2010-10-29</p>
50443 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
50444 <p><b>Discussion:</b></p>
50445 <p>
50446 <tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
50447 </p>
50448
50449 <blockquote><pre>reference operator[](difference_type n) const;
50450 </pre></blockquote>
50451
50452 <p>
50453 This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
50454 have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
50455 implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
50456 that has already been destroyed. This is essentially the same issue that
50457 we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
50458 </p>
50459
50460 <p><i>[
50461 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
50462 ]</i></p>
50463
50464
50465 <p><i>[
50466 2009-08-15 Howard adds:
50467 ]</i></p>
50468
50469
50470 <blockquote>
50471 I recommend closing this as  a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> which addresses
50472 this issue for both <tt>move_iterator</tt> and <tt>reverse_iterator</tt>.
50473 </blockquote>
50474
50475 <p><i>[
50476 2009-10 Santa Cruz:
50477 ]</i></p>
50478
50479
50480 <blockquote>
50481 Move to Ready. Note that if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is reopened, it may yield a
50482 better resolution, but <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is currently marked NAD.
50483 </blockquote>
50484
50485
50486
50487 <p><b>Proposed resolution:</b></p>
50488 <p>
50489 In 24.5.3.1 [move.iterator] and 24.5.3.3.12 [move.iter.op.index], change the declaration of
50490 <tt>move_iterator</tt>'s <tt>operator[]</tt> to:
50491 </p>
50492
50493 <blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
50494 </pre></blockquote>
50495
50496
50497
50498 <p><b>Rationale:</b></p>
50499 <p><i>[
50500 San Francisco:
50501 ]</i></p>
50502
50503
50504 <blockquote>
50505 NAD Editorial, see
50506 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
50507 </blockquote>
50508
50509
50510
50511
50512 <hr>
50513 <h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
50514 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
50515  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2010-10-29</p>
50516 <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>
50517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
50518 <p><b>Discussion:</b></p>
50519 <p>
50520 During the Sophia Antipolis meeting it was decided to split-off some
50521 parts of the
50522 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
50523 ("Concurrency modifications for <tt>basic_string</tt>")
50524 proposal into a separate issue, because these weren't actually
50525 concurrency-related. The here proposed changes refer to the recent
50526 update document
50527 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
50528 and attempt to take advantage of the
50529 stricter structural requirements.
50530 </p>
50531 <p>
50532 Indeed there exists some leeway for more guarantees that would be
50533 very useful for programmers, especially if interaction with transactionary
50534 or exception-unaware C API code is important. This would also allow
50535 compilers to take advantage of more performance optimizations, because
50536 more functions can have throw() specifications. This proposal uses the
50537 form of "Throws: Nothing" clauses to reach the same effect, because
50538 there already exists a different issue in progress to clean-up the current
50539 existing "schizophrenia" of the standard in this regard.
50540 </p>
50541 <p>
50542 Due to earlier support for copy-on-write, we find the following
50543 unnecessary limitations for C++0x:
50544 </p>
50545
50546 <ol>
50547 <li>
50548 Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
50549 a pointer to their guts, which is a non-failure operation. This should
50550 be spelled out. It is also noteworthy to mention that the same
50551 guarantees should also be given by the size query functions,
50552 because the combination of pointer to content and the length is
50553 typically needed during interaction with low-level API.
50554 </li>
50555 <li>
50556 Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
50557 a pointer to their guts, which is guaranteed O(1). This should be
50558 spelled out.
50559 </li>
50560 <li>
50561 Missing reading access to the terminating character: Only the
50562 const overload of <tt>operator[]</tt> allows reading access to the terminator
50563 char. For more intuitive usage of strings, reading access to this
50564 position should be extended to the non-const case. In contrast
50565 to C++03 this reading access should now be homogeneously
50566 an lvalue access.
50567 </li>
50568 </ol>
50569
50570 <p>
50571 The proposed resolution is split into a main part (A) and a
50572 secondary part (B) (earlier called "Adjunct Adjunct Proposal").
50573 (B) extends (A) by also making access to index position
50574 size() of the at() overloads a no-throw operation. This was
50575 separated, because this part is theoretically observable in
50576 specifically designed test programs.
50577 </p>
50578
50579 <p><i>[
50580 San Francisco:
50581 ]</i></p>
50582
50583
50584 <blockquote>
50585 <p>
50586 We oppose part 1 of the issue but hope to address <tt>size()</tt> in
50587 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.
50588 </p>
50589 <p>
50590 We do not support part B. 4 of the issue because of the breaking API change.
50591 </p>
50592 <p>
50593 We support part A. 2 of the issue.
50594 </p>
50595 <p>
50596 On support part A. 3 of the issue:
50597 </p>
50598 <blockquote>
50599 Pete's broader comment: now that we know that basic_string will be a
50600 block of contiguous memory, we should just rewrite its specification
50601 with that in mind. The expression of the specification will be simpler
50602 and probably more correct as a result.
50603 </blockquote>
50604 </blockquote>
50605
50606 <p><i>[
50607 2009-07 Frankfurt
50608 ]</i></p>
50609
50610
50611 <blockquote>
50612 <p>
50613 Move proposed resolution A to Ready.
50614 </p>
50615 <p><i>[
50616 Howard: Commented out part B.
50617 ]</i></p>
50618
50619 </blockquote>
50620
50621
50622
50623 <p><b>Proposed resolution:</b></p>
50624 <ol type="A">
50625 <li>
50626 <ol>
50627 <li>
50628 <p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
50629 </p>
50630 <blockquote>
50631 <i>Throws:</i> Nothing.
50632 </blockquote>
50633
50634 </li>
50635 <li>
50636 <p>
50637 In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
50638 </p>
50639
50640 <blockquote>
50641 <p>
50642 <i>Requires:</i> <tt>pos &#8804; size()</tt>.
50643 </p>
50644 <p>
50645 <i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
50646 a reference to a <tt>charT()</tt> that shall not be modified.
50647 </p>
50648 <p>
50649 <i>Throws:</i> Nothing.
50650 </p>
50651 <p>
50652 <i>Complexity:</i> Constant time.
50653 </p>
50654 </blockquote>
50655
50656 </li>
50657 <li>
50658 <p>
50659 In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
50660 clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
50661 </p>
50662 <blockquote>
50663 <p>
50664 <i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
50665 in <tt>[0, size()]</tt>.
50666 </p>
50667 <p>
50668 <i>Throws:</i> Nothing.
50669 </p>
50670 <p>
50671 <i>Complexity:</i> Constant time.
50672 </p>
50673 </blockquote>
50674 </li>
50675 </ol>
50676 </li>
50677
50678 </ol>
50679
50680
50681
50682
50683
50684
50685 <hr>
50686 <h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
50687 <p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
50688  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2010-10-29</p>
50689 <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>
50690 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
50691 <p><b>Discussion:</b></p>
50692        <p>
50693
50694 <tt>forward_list</tt> member functions that take
50695 a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
50696 function signatures) argument have the following precondition:
50697
50698        </p>
50699        <blockquote>
50700
50701 <i>Requires:</i> <tt>position</tt> is dereferenceable or equal
50702 to <tt>before_begin()</tt>.
50703
50704        </blockquote>
50705        <p>
50706
50707 I believe what's actually intended is this:
50708
50709        </p>
50710        <blockquote>
50711
50712 <i>Requires:</i> <tt>position</tt> is in the range
50713 [<tt>before_begin()</tt>, <tt>end()</tt>).
50714
50715        </blockquote>
50716        <p>
50717
50718 That is, when it's dereferenceable, <tt>position</tt> must point
50719 into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
50720
50721        </p>
50722
50723 <p><i>[
50724 San Francisco:
50725 ]</i></p>
50726
50727
50728 <blockquote>
50729 Robert suggested alternate proposed wording which had large support.
50730 </blockquote>
50731
50732 <p><i>[
50733 Post Summit:
50734 ]</i></p>
50735
50736
50737 <blockquote>
50738 <p>
50739 Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
50740 </p>
50741 <p>
50742 With that minor update, Recommend Tentatively Ready.
50743 </p>
50744 </blockquote>
50745
50746
50747
50748 <p><b>Proposed resolution:</b></p>
50749        <p>
50750
50751 Change the <i>Requires</i> clauses
50752  [forwardlist] , p21, p24, p26, p29, and,
50753 23.3.3.5 [forwardlist.ops], p39, p43, p47
50754 as follows:
50755
50756        </p>
50757        <blockquote>
50758
50759 <i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins>
50760 dereferenceable
50761 <ins>iterator in the range <tt>[begin(), end())</tt></ins>
50762 <del>or equal to <tt>before_begin()</tt></del>. ...
50763
50764        </blockquote>
50765    
50766
50767
50768
50769 <hr>
50770 <h3><a name="881"></a>881. shared_ptr conversion issue</h3>
50771 <p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
50772  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30 <b>Last modified:</b> 2010-10-29</p>
50773 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
50774 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
50775 <p><b>Discussion:</b></p>
50776 <p>
50777 We've changed <tt>shared_ptr&lt;Y&gt;</tt> to not convert to <tt>shared_ptr&lt;T&gt;</tt> when <tt>Y*</tt>
50778 doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
50779 converting copy constructor though.
50780 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
50781 later added move support, and
50782 the converting move constructor is not constrained.
50783 </p>
50784
50785 <p><i>[
50786 San Francisco:
50787 ]</i></p>
50788
50789
50790 <blockquote>
50791 We might be able to move this to NAD, Editorial once shared_ptr is
50792 conceptualized, but we want to revisit this issue to make sure.
50793 </blockquote>
50794
50795 <p><i>[
50796 2009-07 Frankfurt
50797 ]</i></p>
50798
50799
50800 <blockquote>
50801 <p>
50802 Moved to Ready.
50803 </p>
50804 <p>
50805 This issue now represents the favored format for specifying constrained templates.
50806 </p>
50807 </blockquote>
50808
50809
50810
50811 <p><b>Proposed resolution:</b></p>
50812 <p>
50813 We need to change the Requires clause of the move constructor:
50814 </p>
50815
50816 <blockquote><pre>shared_ptr(shared_ptr&amp;&amp; r); 
50817 template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r); 
50818 </pre>
50819 <blockquote>
50820 <i><del>Requires</del> <ins>Remarks</ins>:</i> <del>For the second constructor <tt>Y*</tt> shall be
50821 convertible to <tt>T*</tt>.</del>
50822 <ins>
50823 The second constructor shall not participate in overload resolution
50824 unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
50825 </ins>
50826 </blockquote>
50827 </blockquote>
50828
50829 <p>
50830 in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
50831 (it now resolves to the move constructor).
50832 </p>
50833
50834
50835
50836
50837
50838
50839 <hr>
50840 <h3><a name="882"></a>882. <tt>duration</tt> non-member arithmetic requirements</h3>
50841 <p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
50842  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2010-10-29</p>
50843 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
50844 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
50845 <p><b>Discussion:</b></p>
50846 <p>
50847 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
50848 specified the following requirements for the non-member <tt>duration</tt>
50849 arithmetic:
50850 </p>
50851
50852 <blockquote>
50853
50854 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
50855   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
50856   operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
50857 </pre>
50858 <blockquote>
50859 <i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of <tt>Rep1</tt> and
50860 <tt>Rep2</tt>.  Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
50861 to CR, diagnostic required.
50862 </blockquote>
50863
50864 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
50865   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
50866   operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
50867 </pre>
50868
50869 <blockquote>
50870 <i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
50871 <tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt>
50872 shall be implicitly convertible to <tt>CR</tt>, diagnostic required.
50873 </blockquote>
50874
50875 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
50876   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
50877   operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
50878 </pre>
50879
50880 <blockquote>
50881 <i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
50882 <tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be
50883 implicitly convertible to <tt>CR</tt>, and <tt>Rep2</tt> shall not be an
50884 instantiation of <tt>duration</tt>, diagnostic required.
50885 </blockquote>
50886
50887 </blockquote>
50888
50889 <p>
50890 During transcription into the working paper, the requirements clauses on these
50891 three functions was changed to:
50892 </p>
50893
50894 <blockquote>
50895 <i>Requires:</i> <tt>CR(Rep1, Rep2)</tt> shall exist. Diagnostic required.
50896 </blockquote>
50897
50898 <p>
50899 This is a non editorial change with respect to
50900 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
50901 as user written representations which are used in <tt>duration</tt> need not be
50902 implicitly convertible to or from arithmetic types in order to interoperate with
50903 <tt>duration</tt>s based on arithmetic types.  An explicit conversion will do
50904 fine for most expressions as long as there exists a <tt>common_type</tt> specialization
50905 relating the user written representation and the arithmetic type.  For example:
50906 </p>
50907
50908 <blockquote><pre>class saturate
50909 {
50910 public:
50911   explicit saturate(long long i);
50912   ...
50913 };
50914
50915 namespace std {
50916
50917 template &lt;&gt;
50918 struct common_type&lt;saturate, long long&gt;
50919 {
50920     typedef saturate type;
50921 };
50922
50923 template &lt;&gt;
50924 struct common_type&lt;long long, saturate&gt;
50925 {
50926     typedef saturate type;
50927 };
50928
50929 }  // std
50930
50931 millisecond ms(3);  // integral-based duration
50932 duration&lt;saturate, milli&gt; my_ms = ms;  // ok, even with explicit conversions
50933 my_ms = my_ms + ms;                    // ok, even with explicit conversions
50934 </pre></blockquote>
50935
50936 <p>
50937 However, when dealing with multiplication of a duration and its representation,
50938 implicit convertibility is required between the rhs and the lhs's representation
50939 for the member <tt>*=</tt> operator:
50940 </p>
50941
50942 <blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt; 
50943 class duration { 
50944 public: 
50945    ...
50946    duration&amp; operator*=(const rep&amp; rhs);
50947    ...
50948 };
50949 ...
50950 ms *= 2;               // ok, 2 is implicitly convertible to long long
50951 my_ms *= saturate(2);  // ok, rhs is lhs's representation
50952 my_ms *= 2;            // error, 2 is not implicitly convertible to saturate
50953 </pre></blockquote>
50954
50955 <p>
50956 The last line does not (and should not) compile.  And we want non-member multiplication
50957 to have the same behavior as member arithmetic:
50958 </p>
50959
50960 <blockquote><pre>my_ms = my_ms * saturate(2);  // ok, rhs is lhs's representation
50961 my_ms = my_ms * 2;            // <em>should be</em> error, 2 is not implicitly convertible to saturate
50962 </pre></blockquote>
50963
50964 <p>
50965 The requirements clauses of
50966 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
50967 make the last line an error as expected.  However the latest working draft at
50968 this time
50969 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
50970 allows the last line to compile.
50971 </p>
50972
50973 <p>
50974 All that being said, there does appear to be an error in these requirements clauses
50975 as specified by 
50976 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>.
50977 </p>
50978
50979 <blockquote>
50980 <i>Requires:</i> ... <em>Both</em> <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
50981 to CR, diagnostic required.
50982 </blockquote>
50983
50984 <p>
50985 It is not necessary for both <tt>Rep</tt>s to be <i>implicitly</i> convertible to
50986 the <tt>CR</tt>.  It is only necessary for the rhs <tt>Rep</tt> to be implicitly
50987 convertible to the <tt>CR</tt>.  The <tt>Rep</tt> within the <tt>duration</tt>
50988 should be allowed to only be explicitly convertible to the <tt>CR</tt>.  The
50989 explicit-conversion-requirement is covered under 20.11.3.7 [time.duration.cast].
50990 </p>
50991
50992
50993
50994 <p><b>Proposed resolution:</b></p>
50995 <p>
50996 Change the requirements clauses under 20.11.3.5 [time.duration.nonmember]:
50997 </p>
50998
50999 <blockquote>
51000
51001 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
51002   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
51003   operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
51004 </pre>
51005
51006 <blockquote>
51007 <i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
51008 <ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
51009 Diagnostic required.
51010 </blockquote>
51011
51012 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
51013   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
51014   operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
51015 </pre>
51016
51017 <blockquote>
51018 <i>Require<ins>s</ins><del>d behavior</del>:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
51019 <ins><tt>Rep1</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
51020 Diagnostic required.
51021 </blockquote>
51022
51023 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
51024   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
51025   operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
51026 </pre>
51027
51028 <blockquote>
51029 <i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist</del>
51030 <ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt></ins>
51031 and <tt>Rep2</tt> shall not
51032 be an instantiation of <tt>duration</tt>. Diagnostic required.
51033 </blockquote>
51034
51035 </blockquote>
51036
51037
51038
51039
51040
51041 <hr>
51042 <h3><a name="883"></a>883. swap circular definition</h3>
51043 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51044  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2010-10-29</p>
51045 <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>
51046 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51047 <p><b>Discussion:</b></p>
51048
51049 <p>
51050 Note in particular that Table 90 "Container Requirements" gives
51051 semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
51052 containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
51053 circular definition.
51054 </p>
51055
51056 <p><i>[
51057 San Francisco:
51058 ]</i></p>
51059
51060
51061 <blockquote>
51062 Robert to propose a resolution along the lines of "Postcondition: "a =
51063 b, b = a" This will be a little tricky for the hash containers, since
51064 they don't have <tt>operator==</tt>.
51065 </blockquote>
51066
51067 <p><i>[
51068 Post Summit Anthony Williams provided proposed wording.
51069 ]</i></p>
51070
51071
51072 <p><i>[
51073 2009-07 Frankfurt
51074 ]</i></p>
51075
51076
51077 <blockquote>
51078 Moved to Ready with minor edits (which have been made).
51079 </blockquote>
51080
51081
51082
51083 <p><b>Proposed resolution:</b></p>
51084 <p>
51085 In table 80 in section 23.2.1 [container.requirements.general],
51086 replace the postcondition of <tt>a.swap(b)</tt> with the following:
51087 </p>
51088
51089 <blockquote>
51090 <table border="1">
51091 <caption>Table 80 -- Container requirements</caption>
51092 <tbody><tr>
51093 <th>Expression</th>
51094 <th>Return type</th>
51095 <th>Operational semantics</th>
51096 <th>Assertion/note pre-/post-conidtion</th>
51097 <th>Complexity</th>
51098 </tr>
51099 <tr>
51100 <td>...</td>
51101 <td>...</td>
51102 <td>...</td>
51103 <td>...</td>
51104 <td>...</td>
51105 </tr>
51106 <tr>
51107 <td><tt>a.swap(b);</tt></td>
51108 <td><tt>void</tt></td>
51109 <td>&nbsp;</td>
51110 <td><del><tt>swap(a,b)</tt></del>
51111 <ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></td>
51112 <td>(Note A)</td>
51113 </tr>
51114 </tbody></table>
51115 </blockquote>
51116
51117 <p>
51118 Remove the reference to swap from the paragraph following the table.
51119 </p>
51120
51121 <blockquote>
51122 Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
51123 <tt>lexicographical_compare()</tt> are defined in Clause 25. ...
51124 </blockquote>
51125
51126
51127
51128
51129
51130 <hr>
51131 <h3><a name="884"></a>884. shared_ptr swap</h3>
51132 <p><b>Section:</b> 20.9.10.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
51133  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-11-20</p>
51134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
51135 <p><b>Discussion:</b></p>
51136 <blockquote><pre>#include &lt;memory&gt;
51137 #include &lt;cassert&gt;
51138
51139 struct A { };
51140 struct B : A { };
51141
51142 int main()
51143 {
51144     std::shared_ptr&lt;A&gt; pa(new A);
51145     std::shared_ptr&lt;B&gt; pb(new B);
51146     std::swap&lt;A&gt;(pa, pb);  // N.B. no argument deduction
51147     assert( pa.get() == pb.get() );
51148     return 0;
51149 }
51150 </pre></blockquote>
51151
51152 <p>
51153 Is this behaviour correct (I believe it is) and if so, is it
51154 unavoidable, or not worth worrying about?
51155 </p>
51156
51157 <p>
51158 This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>:
51159 </p>
51160
51161 <blockquote><pre>template&lt;class T&gt; void swap( shared_ptr&lt;T&gt; &amp; a, shared_ptr&lt;T&gt; &amp;&amp; b );
51162 </pre></blockquote>
51163
51164 <p>
51165 silently converting the second argument from <tt>shared_ptr&lt;B&gt;</tt> to
51166 <tt>shared_ptr&lt;A&gt;</tt> and binding the rvalue ref to the produced temporary.
51167 </p>
51168
51169 <p>
51170 This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue
51171 with the rvalue swap overloads. Do we want to prevent this code from
51172 compiling? If so, how?
51173 </p>
51174
51175 <p>
51176 Perhaps we should limit rvalue args to swap to those types that would
51177 benefit from the "swap trick".  Or, since we now have <tt>shrink_to_fit()</tt>, just
51178 eliminate the rvalue swap overloads altogether.  The original motivation
51179 was:
51180 </p>
51181
51182 <blockquote><pre>vector&lt;A&gt; v = ...;
51183 ...
51184 swap(v, vector&lt;A&gt;(v));
51185 </pre></blockquote>
51186
51187 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>.
51188
51189 <p><i>[
51190 Batavia (2009-05):
51191 ]</i></p>
51192
51193 <blockquote>
51194 We agree with the proposed resolution.
51195 Move to <del>NAD Editorial</del><ins>Resolved</ins>.
51196 </blockquote>
51197
51198
51199 <p><b>Proposed resolution:</b></p>
51200 <p>
51201 Recommend <del>NAD Editorial</del><ins>Resolved</ins>, fixed by
51202 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
51203 </p>
51204
51205
51206
51207
51208
51209 <hr>
51210 <h3><a name="885"></a>885. pair assignment</h3>
51211 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51212  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
51213 <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>
51214 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51215 <p><b>Discussion:</b></p>
51216 <blockquote><pre>20.2.3 pairs
51217 Missing assignemnt operator:
51218 template&lt;class U , class V&gt;
51219   requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
51220     pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
51221 </pre></blockquote>
51222
51223 <p>
51224 Well, that's interesting. This assignment operator isn't in the
51225 current working paper, either. Perhaps we deemed it acceptable to
51226 build a temporary of type <tt>pair</tt> from <tt>pair&lt;U, V&gt;</tt>, then move-assign
51227 from that temporary?
51228 </p>
51229 <p>
51230 It sounds more like an issue waiting to be opened, unless you want to plug
51231 it now.  As written we risk moving from lvalues.
51232 </p>
51233
51234 <p><i>[
51235 San Francisco:
51236 ]</i></p>
51237
51238
51239 <blockquote>
51240 <p>
51241 Would be NAD if better ctors fixed it.
51242 </p>
51243 <p>
51244 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>.
51245 </p>
51246 </blockquote>
51247
51248 <p><i>[
51249 post San Francisco:
51250 ]</i></p>
51251
51252
51253 <blockquote>
51254 Possibly NAD Editorial, solved by
51255 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
51256 </blockquote>
51257
51258 <p><i>[
51259 2009-05-25 Alisdair adds:
51260 ]</i></p>
51261
51262
51263 <blockquote>
51264 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a> was something I reported while reviewing the library concepts
51265 documents ahead of San Francisco.  The missing operator was added as part of
51266 the paper adopted at that meeting
51267 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
51268 and I can confirm this operator is
51269 present in the current working paper.  I recommend NAD.
51270 </blockquote>
51271
51272 <p><i>[
51273 2009-07 Frankfurt
51274 ]</i></p>
51275
51276
51277 <blockquote>
51278 We agree with the intent, but we need to wait for the dust to settle on concepts.
51279 </blockquote>
51280
51281 <p><i>[
51282 2010-03-11 Stefanus provided wording.
51283 ]</i></p>
51284
51285
51286 <p><i>[
51287 2010 Pittsburgh:  Moved to Ready for Pittsburgh.
51288 ]</i></p>
51289
51290
51291
51292
51293 <p><b>Proposed resolution:</b></p>
51294 <p>
51295 Add the following declaration 20.3.5.2 [pairs.pair], before the
51296 declaration of <tt>pair&amp; operator=(pair&amp;&amp; p);</tt>:
51297 </p>
51298  
51299 <blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(const pair&lt;U, V&gt;&amp; p);
51300 </pre></blockquote>
51301
51302 <p>
51303 Add the following description to 20.3.5.2 [pairs.pair] after paragraph 11 (before
51304 the description of <tt>pair&amp; operator=(pair&amp;&amp; p);)</tt>:
51305 </p>
51306  
51307 <blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(const pair&lt;U, V&gt;&amp; p);
51308 </pre>
51309 <blockquote>
51310 <p>
51311 <i>Requires:</i> <tt>T1</tt> shall satisfy the requirements of
51312 <tt>CopyAssignable</tt> from <tt>U</tt>. <tt>T2</tt> shall
51313 satisfy the requirements of <tt>CopyAssignable</tt> from <tt>V</tt>.
51314 </p>
51315 <p>
51316 <i>Effects:</i> Assigns <tt>p.first</tt> to <tt>first</tt> and 
51317 <tt>p.second</tt> to <tt>second</tt>.
51318 </p>
51319 <p>
51320 <i>Returns:</i> <tt>*this</tt>.
51321 </p>
51322 </blockquote>
51323 </blockquote>
51324
51325
51326
51327
51328
51329
51330 <hr>
51331 <h3><a name="886"></a>886. tuple construction</h3>
51332 <p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51333  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
51334 <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>
51335 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51336 <p><b>Discussion:</b></p>
51337 <p>
51338 20.4.2.1 [tuple.cnstr]:
51339 </p>
51340 <blockquote>
51341 <i>Effects:</i> Default initializes each element.
51342 </blockquote>
51343
51344 <p>
51345 Could be clarified to state each "non-trivial" element.  Otherwise
51346 we have a conflict with Core deinfition of default initialization -
51347 trivial types do not get initialized (rather than initialization
51348 having no effect)
51349 </p>
51350
51351 <p>
51352 I'm going to punt on this one, because it's not an issue that's
51353 related to concepts. I suggest bringing it to Howard's attention on
51354 the reflector.
51355 </p>
51356
51357 <p><i>[
51358 San Francisco:
51359 ]</i></p>
51360
51361
51362 <blockquote>
51363 <p>
51364 Text in draft doesn't mean anything, changing to "non-trivial" makes it
51365 meaningful.
51366 </p>
51367 <p>
51368 We prefer "value initializes". Present implementations use
51369 value-initialization. Users who don't want value initialization have
51370 alternatives.
51371 </p>
51372 <p>
51373 Request resolution text from Alisdair.
51374 </p>
51375
51376 <p>
51377 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a> default construction and value-initialization.
51378 </p>
51379 </blockquote>
51380
51381 <p><i>[
51382 2009-05-04 Alisdair provided wording and adds:
51383 ]</i></p>
51384
51385
51386 <blockquote>
51387 <p>
51388 Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
51389 with during the discussion.  To preserve TR1 semantics, this would have been
51390 worded:
51391 </p>
51392 <blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
51393 </pre>
51394 <blockquote>
51395 -2-   <i>Effects:</i> Default-initializes each non-trivial element.
51396 </blockquote>
51397 </blockquote>
51398
51399
51400 </blockquote>
51401
51402 <p><i>[
51403 2009-07 Frankfurt
51404 ]</i></p>
51405
51406
51407 <blockquote>
51408 Move to Ready.
51409 </blockquote>
51410
51411
51412
51413 <p><b>Proposed resolution:</b></p>
51414 <p>
51415 Change p2 in Construction 20.4.2.1 [tuple.cnstr]:
51416 </p>
51417
51418 <blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
51419 </pre>
51420 <blockquote>
51421 <p>
51422 -2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
51423 </p>
51424 </blockquote>
51425 </blockquote>
51426
51427
51428
51429
51430
51431
51432 <hr>
51433 <h3><a name="888"></a>888. this_thread::yield too strong</h3>
51434 <p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51435  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
51436 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.this">active issues</a> in [thread.thread.this].</p>
51437 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.this">issues</a> in [thread.thread.this].</p>
51438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51439 <p><b>Discussion:</b></p>
51440 <p>
51441 I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too
51442 strong in specification.  The issue is that some systems distinguish
51443 between yielding to another thread in the same process and yielding
51444 to another process.  Given that the C++ standard only talks about
51445 a single program, one can infer that the specification allows yielding
51446 only to another thread within the same program.  Posix has no
51447 facility for that behavior.  Can you please file an issue to weaken
51448 the wording.  Perhaps "Offers the operating system the opportunity
51449 to reschedule."
51450 </p>
51451
51452 <p><i>[
51453 Post Summit:
51454 ]</i></p>
51455
51456
51457 <blockquote>
51458 Recommend move to Tentatively Ready.
51459 </blockquote>
51460
51461
51462
51463 <p><b>Proposed resolution:</b></p>
51464 <p>
51465 Change 30.3.2 [thread.thread.this]/3:
51466 </p>
51467
51468 <blockquote>
51469 <pre>void this_thread::yield();
51470 </pre>
51471 <blockquote>
51472 <i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins>
51473 the opportunity to <ins>re</ins>schedule.
51474 <del>another thread.</del>
51475 </blockquote>
51476 </blockquote>
51477
51478
51479
51480
51481
51482 <hr>
51483 <h3><a name="890"></a>890. Improving <tt>&lt;system_error&gt;</tt> initialization</h3>
51484 <p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51485  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14 <b>Last modified:</b> 2010-10-29</p>
51486 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51487 <p><b>Discussion:</b></p>
51488 <p>
51489 The <tt>static const error_category</tt> objects <tt>generic_category</tt> and
51490 <tt>system_category</tt> in header <tt>&lt;system_error&gt;</tt> are currently declared:
51491 </p>
51492
51493 <blockquote><pre>const error_category&amp; get_generic_category();
51494 const error_category&amp; get_system_category();
51495
51496 static const error_category&amp; generic_category = get_generic_category();
51497 static const error_category&amp; system_category = get_system_category();
51498 </pre></blockquote>
51499
51500 <p>
51501 This formulation has several problems:
51502 </p>
51503
51504 <ul>
51505 <li>
51506 Implementation details are exposed, since initialization is specified in
51507 the interface. This over-constrains implementations without offsetting
51508 user benefits. The form of initialization specified may be less than
51509 maximally efficient on some platforms.
51510 </li>
51511 <li>
51512 Use of the objects is more expensive in terms of number of machine level
51513 instructions. See <i>Implementation experience</i> below.
51514 </li>
51515 <li>
51516 Depending on the compiler, some cost may be incurred by each translation unit
51517 that includes the header, even if the objects are not used. This is a
51518 common scenario in user code, since the header is included by other
51519 standard library headers. It should be mentioned that at least one
51520 compilers is able to optimize this cost away, however.
51521 </li>
51522 </ul>
51523
51524 <p>
51525 IO streams uses a somewhat different formulation for iostream_category, but 
51526 still suffer much the same problems.
51527 </p>
51528
51529 <p>
51530 The original plan was to eliminate these problems by applying the C++0x
51531 <tt>constexpr</tt> feature. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>. However, that approach turned out
51532 to be unimplementable, since it would require a <tt>constexpr</tt> object of a
51533 class with virtual functions, and that is not allowed by the core
51534 language.
51535 </p>
51536
51537 <p>
51538 The proposed resolution was developed as an alternative. It mitigates the above 
51539 problems by removing initialization from the visible interface, allowing 
51540 implementations flexibility.
51541 </p>
51542
51543 <p>
51544 <b>Implementation experience:</b>
51545 </p>
51546
51547 <p>
51548 Prototype implementations of the current WP interface and proposed
51549 resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft 
51550 compilers on Windows. The code generated by the Microsoft compiler was studied 
51551 at length; the WP and proposal versions generated very similar code. For both versions 
51552 the compiler did make use of static
51553 initialization; apparently the compiler applied an implicit <tt>constexpr</tt>
51554 where useful, even in cases where <tt>constexpr</tt> would not be permitted by
51555 the language!
51556 </p>
51557
51558 <p>
51559 <b>Acknowledgements:</b>
51560 </p>
51561
51562 <p>
51563 Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
51564 </p>
51565
51566 <p><i>[
51567 San Francisco:
51568 ]</i></p>
51569
51570
51571 <blockquote>
51572 <p>
51573 Martin: prefers not to create more file-scope static objects, and would
51574 like to see <tt>get_*</tt> functions instead.
51575 </p>
51576 </blockquote>
51577
51578
51579 <p><i>[Pre-Summit:]</i></p>
51580
51581 <blockquote>
51582
51583
51584 <p>
51585 Beman: The proposed resolution has been reworked to remove the file-scope 
51586 static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been 
51587 eliminated from the function names as no longer necessary and to conform with 
51588 standard library naming practice.
51589 </p>
51590
51591 </blockquote>
51592
51593 <p><i>[
51594 Post Summit:
51595 ]</i></p>
51596
51597
51598 <blockquote>
51599 Agreement that this is wise and essential, text provided works and has
51600 been implemented. Seems to be widespread consensus. Move to Tentative Ready.
51601 </blockquote>
51602
51603
51604
51605 <p><b>Proposed resolution:</b></p>
51606
51607 <p>Change 17.6.4.14 [value.error.codes] Value of error codes as indicated:</p>
51608 <blockquote>
51609  <p>Certain functions in the C++ standard library report errors via a 
51610  <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall 
51611  return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the 
51612  operating system, or a reference to an implementation-defined error_category 
51613  object for errors originating elsewhere. The implementation shall define the 
51614  possible values of value() for each of these error categories. [<i>Example:</i> For 
51615  operating systems that are based on POSIX, implementations are encouraged to 
51616  define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values, 
51617  with additional values as defined by the operating system's documentation. 
51618  Implementations for operating systems that are not based on POSIX are 
51619  encouraged to define values identical to the operating system's values. For 
51620  errors that do not originate from the operating system, the implementation may 
51621  provide enums for the associated values --<i>end example</i>]</p>
51622 </blockquote>
51623
51624 <p>
51625 Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview
51626 <tt>error_category</tt> synopsis as indicated:
51627 </p>
51628
51629 <blockquote>
51630 <pre>const error_category&amp; <del>get_</del>generic_category();
51631 const error_category&amp; <del>get_</del>system_category();
51632
51633 <del>static storage-class-specifier const error_category&amp; generic_category = get_generic_category();
51634 static storage-class-specifier const error_category&amp; system_category = get_system_category();</del>
51635 </pre>
51636 </blockquote>
51637
51638 <p>
51639 Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
51640 </p>
51641
51642 <blockquote>
51643 <pre>const error_category&amp; <del>get_</del>generic_category();
51644 </pre>
51645
51646 <blockquote>
51647
51648 <p>
51649 <i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
51650 </p>
51651
51652 <p>
51653 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
51654 functions shall behave as specified for the class <tt>error_category</tt>. The
51655 object's <tt>name</tt> virtual function shall return a pointer to the string
51656 <tt>"GENERIC"</tt>.
51657 </p>
51658 </blockquote>
51659
51660 <pre>const error_category&amp; <del>get_</del>system_category();
51661 </pre>
51662
51663 <blockquote>
51664 <p>
51665 <i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
51666 </p>
51667
51668 <p>
51669 <i>Remarks:</i> The object's <tt>equivalent</tt> virtual functions shall behave as
51670 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
51671 shall return a pointer to the string <tt>"system"</tt>. The object's
51672 <tt>default_error_condition</tt> virtual function shall behave as follows:
51673 </p>
51674 <blockquote>
51675 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
51676 shall return <tt>error_condition(posv, generic_category<ins>()</ins>)</tt>. Otherwise, the
51677 function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</tt>. What
51678 constitutes correspondence for any given operating system is
51679 unspecified. [<i>Note:</i> The number of potential system error codes is large
51680 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
51681 Thus implementations are given latitude in determining correspondence.
51682 <i>-- end note</i>]
51683 </blockquote>
51684 </blockquote>
51685
51686 </blockquote>
51687
51688 <p>Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors 
51689 as indicated:</p>
51690 <blockquote>
51691  <pre>error_code();</pre>
51692  <blockquote>
51693  <p><i>Effects:</i> Constructs an object of type error_code.</p>
51694  <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &amp;system_category</code><tt><ins>()</ins></tt>.</p>
51695  </blockquote>
51696 </blockquote>
51697 <p>Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as 
51698 indicated:</p>
51699 <blockquote>
51700  <pre>void clear();</pre>
51701  <blockquote>
51702  <p>Postconditions: <code>value() == 0</code> and <code>category() == 
51703  system_category</code><tt><ins>()</ins></tt>.</p>
51704  </blockquote>
51705 </blockquote>
51706 <p>Change 19.5.2.5 [syserr.errcode.nonmembers] Class error_code non-member 
51707 functions as indicated:</p>
51708 <blockquote>
51709  <pre>error_code make_error_code(errc e);</pre>
51710  <blockquote>
51711  <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p>
51712  </blockquote>
51713 </blockquote>
51714 <p>Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition 
51715 constructors as indicated:</p>
51716 <blockquote>
51717  <pre>error_condition();</pre>
51718  <blockquote>
51719  <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p>
51720  <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &amp;generic_category</code><tt><ins>()</ins></tt>.</p>
51721  </blockquote>
51722 </blockquote>
51723 <p>Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition 
51724 modifiers as indicated:</p>
51725 <blockquote>
51726  <pre>void clear();</pre>
51727  <blockquote>
51728  <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() == 
51729  generic_category</code><tt><ins>()</ins></tt>.</p>
51730  </blockquote>
51731 </blockquote>
51732 <p>Change 19.5.3.5 [syserr.errcondition.nonmembers] Class error_condition 
51733 non-member functions as indicated:</p>
51734 <blockquote>
51735  <pre>error_condition make_error_condition(errc e);</pre>
51736  <blockquote>
51737  <p><i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e), generic_category<ins>()</ins>)</tt>.</p>
51738  </blockquote>
51739 </blockquote>
51740  <p>Change 27.5 [iostreams.base] Iostreams base classes, Header &lt;ios&gt; 
51741  synopsis as indicated:</p>
51742 <blockquote>
51743  <pre>concept_map ErrorCodeEnum&lt;io_errc&gt; { };
51744 error_code make_error_code(io_errc e);
51745 error_condition make_error_condition(io_errc e);
51746 <del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
51747 </blockquote>
51748 <p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as 
51749 indicated:</p>
51750 <blockquote>
51751 <p>When throwing ios_base::failure exceptions, implementations should provide 
51752 values of ec that identify the specific reason for the failure. [ Note: Errors 
51753 arising from the operating system would typically be reported as <tt>
51754 system_category</tt><tt><ins>()</ins></tt> errors with an error value of the 
51755 error number reported by the operating system. Errors arising from within the 
51756 stream library would typically be reported as <tt>error_code(io_errc::stream, 
51757 iostream_category<ins>()</ins>)</tt>. --end note ]</p>
51758 </blockquote>
51759 <p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p>
51760 <blockquote>
51761  <pre>error_code make_error_code(io_errc e);</pre>
51762  <blockquote>
51763  <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), iostream_category</code><ins>()</ins><code>)</code>.</p>
51764  </blockquote>
51765  <pre>error_condition make_error_condition(io_errc e);</pre>
51766  <blockquote>
51767  <p><i>Returns:</i> <code>error_condition(static_cast&lt;int&gt;(e), 
51768  iostream_category</code><ins>()</ins><code>)</code>.</p>
51769  </blockquote>
51770  <pre><del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
51771  <blockquote>
51772  <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier 
51773  may be static or extern. It is unspecified whether initialization is static 
51774  or dynamic (3.6.2). If initialization is dynamic, it shall occur before 
51775  completion of the dynamic initialization of the first translation unit 
51776  dynamically initialized that includes header &lt;system_error&gt;.</p></del>
51777 <p>
51778 <ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins>
51779 </p>
51780 <p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall 
51781 behave as specified for the class error_category. The object's name virtual 
51782 function shall return a pointer to the string "iostream".</p>
51783  </blockquote>
51784 </blockquote>
51785
51786
51787
51788
51789
51790
51791
51792 <hr>
51793 <h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
51794 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.4.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51795  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
51796 <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>
51797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51798 <p><b>Discussion:</b></p>
51799 <p>
51800 I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
51801 (N2723 30.3.1.2 [thread.thread.constr] and 30.4.4.2 [thread.once.callonce]) are no longer specified in terms of
51802 <tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
51803 the specification.
51804 </p>
51805 <p>
51806 There are two problems with this.
51807 </p>
51808 <p>
51809 First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
51810 </p>
51811
51812 <blockquote><pre>std::thread th( f, 1, std::bind( g ) );
51813 </pre></blockquote>
51814
51815 <p>
51816 which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
51817 "inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
51818 </p>
51819 <p>
51820 Second, assuming that we don't want the above, the specification has copied the wording
51821 </p>
51822
51823 <blockquote>
51824 <tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
51825 expression for some values <tt>w1, w2, ..., wN</tt>
51826 </blockquote>
51827
51828 <p>
51829 but this is not needed since we know that our argument list is args; it should simply be
51830 </p>
51831
51832 <blockquote>
51833 <tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
51834 </blockquote>
51835
51836 <p><i>[
51837 Summit:
51838 ]</i></p>
51839
51840
51841 <blockquote>
51842 Move to open.
51843 </blockquote>
51844
51845 <p><i>[
51846 Post Summit Anthony provided proposed wording.
51847 ]</i></p>
51848
51849
51850 <p><i>[
51851 2009-07 Frankfurt
51852 ]</i></p>
51853
51854
51855 <blockquote>
51856 Leave Open. Await decision for thread variadic constructor.
51857 </blockquote>
51858
51859 <p><i>[
51860 2009-10 Santa Cruz:
51861 ]</i></p>
51862
51863
51864 <blockquote>
51865 See proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> for this, for the formulation
51866 on how to solve this.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> modifies the thread constructor to
51867 have "pass by value" behavior with pass by reference efficiency through the use
51868 of the <tt>decay</tt> trait.  This same formula would be useful for <tt>call_once</tt>.
51869 </blockquote>
51870
51871 <p><i>[
51872 2010-02-11 Anthony updates wording.
51873 ]</i></p>
51874
51875
51876 <p><i>[
51877 2010-02-12 Moved to Tentatively Ready after 5 postive votes on c++std-lib.
51878 ]</i></p>
51879
51880
51881
51882 <p><b>Proposed resolution:</b></p>
51883 <p>
51884 Modify 30.4.4.2 [thread.once.callonce] p1-p2 with the following:
51885 </p>
51886
51887 <blockquote>
51888 <pre>template&lt;class Callable, class ...Args&gt;
51889   void call_once(once_flag&amp; flag, Callable<ins>&amp;&amp;</ins> func, Args&amp;&amp;... args);</pre>
51890 <blockquote>
51891
51892 <p><ins>
51893 Given a function as follows:
51894 </ins></p>
51895
51896 <blockquote><pre><ins>
51897 template&lt;typename T&gt; typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v)
51898    { return std::forward&lt;T&gt;(v); }
51899 </ins></pre></blockquote>
51900
51901 <p>
51902 1 <i>Requires:</i> <del>The template parameters</del> <tt>Callable</tt> and each
51903 <tt>Ti</tt> in <tt>Args</tt> shall <del>be <tt>CopyConstructible</tt> if an
51904 lvalue and otherwise</del> <ins>satisfy the</ins>
51905 <tt>MoveConstructible</tt> <ins>requirements</ins>.
51906 <tt><i>INVOKE</i>(<ins>decay_copy(std::forward&lt;Callable&gt;(</ins>func<ins>)</ins>,
51907 <del>w1, w2, ..., wN</del>
51908 <ins>decay_copy(std::forward&lt;Args&gt;(args))...</ins>)</tt> (20.8.2 [func.require]) shall be a valid expression<del> for some values <tt>w1,
51909 w2, ..., wN</tt>, where <tt>N == sizeof...(Args)</tt></del>.
51910 </p>
51911
51912 <p>
51913 2 <i>Effects:</i> Calls to <tt>call_once</tt> on the same <tt>once_flag</tt>
51914 object are serialized. If there has been a prior effective call to
51915 <tt>call_once</tt> on the same <tt>once_flag</tt> object, the call to
51916 <tt>call_once</tt> returns without invoking <tt>func</tt>. If there has been no
51917 prior effective call to <tt>call_once</tt> on the same <tt>once_flag</tt>
51918 object, <del>the argument <tt>func</tt> (or a copy thereof) is called as if by
51919 invoking <tt>func(args)</tt></del>
51920 <ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;Callable&gt;(func)),
51921 decay_copy(std::forward&lt;Args&gt;(args))...)</tt> is executed</ins>. The call
51922 to <tt>call_once</tt> is effective if and only if <del><tt>func(args)</tt></del>
51923 <ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;Callable&gt;(func)),
51924 decay_copy(std::forward&lt;Args&gt;(args))...)</tt></ins> returns without
51925 throwing an exception. If an exception is thrown it is propagated to the caller.
51926 </p>
51927
51928 </blockquote>
51929
51930 </blockquote>
51931
51932
51933
51934
51935
51936
51937
51938 <hr>
51939 <h3><a name="893"></a>893. std::mutex issue</h3>
51940 <p><b>Section:</b> 30.4.1.2.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
51941  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
51942 <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>
51943 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
51944 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
51945 <p><b>Discussion:</b></p>
51946 <p>
51947 30.4.1.2.1 [thread.mutex.class]/27 (in
51948 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
51949 says that the behavior is undefined if:
51950 </p>
51951 <ul>
51952 <li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
51953 <tt>try_lock()</tt> on that object</li>
51954 </ul>
51955 <p>
51956 I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
51957 locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
51958 to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
51959 exception (and is allowed to do so if it detects deadlock) or to block
51960 until the <tt>mutex</tt> is free. These general requirements apply regardless of
51961 the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
51962 the current thread.
51963 </p>
51964 <p>
51965 Making double <tt>lock()</tt> undefined behavior probably can be justified (even
51966 though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
51967 locked <tt>mutex</tt> must fail.
51968 </p>
51969
51970 <p><i>[
51971 Summit:
51972 ]</i></p>
51973
51974 <blockquote>
51975 <p>
51976 Move to open. Proposed resolution:
51977 </p>
51978 <ul>
51979 <li>
51980 In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
51981 condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
51982 detects that a deadlock would occur"
51983 </li>
51984 <li>
51985 Strike 30.4.1.2.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
51986 calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
51987 </li>
51988 </ul>
51989 </blockquote>
51990
51991 <p><i>[
51992 2009-07 Frankfurt
51993 ]</i></p>
51994
51995
51996 <blockquote>
51997 Move to Review. Alisdair to provide note.
51998 </blockquote>
51999
52000 <p><i>[
52001 2009-07-31 Alisdair provided note.
52002 ]</i></p>
52003
52004
52005 <p><i>[
52006 2009-10 Santa Cruz:
52007 ]</i></p>
52008
52009
52010 <blockquote>
52011 Moved to Ready.
52012 </blockquote>
52013
52014 <p><i>[
52015 2009-11-18 Peter Opens:
52016 ]</i></p>
52017
52018
52019 <blockquote>
52020 <p>
52021 I don't believe that the proposed note:
52022 </p>
52023
52024 <blockquote>
52025 [<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
52026 object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object. If the program can
52027 detect the deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may
52028 be observed. \97 <i>end note</i>]
52029 </blockquote>
52030
52031 <p>
52032 is entirely correct. "or <tt>try_lock()</tt>" should be removed, because
52033 <tt>try_lock</tt> is non-blocking and doesn't deadlock; it just returns
52034 <tt>false</tt> when it fails to lock the mutex.
52035 </p>
52036
52037 <p><i>[
52038 Howard: I've set to Open and updated the wording per Peter's suggestion.
52039 ]</i></p>
52040
52041
52042 </blockquote>
52043
52044 <p><i>[
52045 2009-11-18 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
52046 ]</i></p>
52047
52048
52049
52050
52051 <p><b>Proposed resolution:</b></p>
52052 <p>
52053 In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
52054 </p>
52055
52056 <blockquote>
52057 <ul>
52058 <li>...</li>
52059 <li>
52060 <tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able 
52061 to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
52062 </li>
52063 <li>...</li>
52064 </ul>
52065 </blockquote>
52066
52067 <p>
52068 Strike 30.4.1.2.1 [thread.mutex.class] paragraph 3 bullet 2:
52069 </p>
52070 <blockquote>
52071 <p>
52072 -3- The behavior of a program is undefined if:
52073 </p>
52074 <ul>
52075 <li>...</li>
52076 <li>
52077 <del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
52078 </li>
52079 <li>...</li>
52080 </ul>
52081 </blockquote>
52082
52083 <p>
52084 Add the following note after p3 30.4.1.2.1 [thread.mutex.class]
52085 </p>
52086
52087 <blockquote>
52088 [<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
52089 object calls <tt>lock()</tt> on that object. If the implementation can detect the
52090 deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may be
52091 observed. \97 <i>end note</i>]
52092 </blockquote>
52093
52094
52095
52096
52097
52098
52099 <hr>
52100 <h3><a name="894"></a>894. longjmp and destructors</h3>
52101 <p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52102  <b>Submitter:</b> Lawrence Crowl, Alisdair Meredith <b>Opened:</b> 2008-09-17 <b>Last modified:</b> 2010-10-29</p>
52103 <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>
52104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52105 <p><b>Discussion:</b></p>
52106 <p>
52107 The interaction between <tt>longjmp</tt> and exceptions seems unnecessarily
52108 restrictive and not in keeping with existing practice.
52109 </p>
52110
52111
52112 <p><b>Proposed resolution:</b></p>
52113 <p>
52114 Edit paragraph 4 of 18.10 [support.runtime] as follows:
52115 </p>
52116
52117 <blockquote>
52118 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
52119 restricted behavior in this International Standard. A
52120 <tt>setjmp/longjmp</tt> call pair has undefined behavior if replacing the
52121 <tt>setjmp</tt> and <tt>longjmp</tt> by <tt>catch</tt> and
52122 <tt>throw</tt> would <del>destroy</del>
52123 <ins>invoke any non-trivial destructors for</ins>
52124 any automatic objects.
52125 </blockquote>
52126
52127
52128
52129
52130
52131 <hr>
52132 <h3><a name="896"></a>896. Library thread safety issue</h3>
52133 <p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52134  <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2010-10-29</p>
52135 <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>
52136 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52137 <p><b>Discussion:</b></p>
52138 <p>
52139 It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
52140 multiple threads may simultaneously copy a <tt>shared_ptr</tt>.  However this
52141 is a critical piece of information for the client, and it has significant
52142 impact on usability for many applications.  (Detlef Vollman thinks it
52143 is currently clear that it is not thread-safe.  Hans Boehm thinks
52144 it currently requires thread safety, since the <tt>use_count</tt> is not an
52145 explicit field, and constructors and assignment take a const reference
52146 to an existing <tt>shared_ptr</tt>.)
52147 </p>
52148
52149 <p>
52150 Pro thread-safety:
52151 </p>
52152 <p>
52153 Many multi-threaded usages are impossible.  A thread-safe version can
52154 be used to destroy an object when the last thread drops it, something
52155 that is often required, and for which we have no other easy mechanism.
52156 </p>
52157 <p>
52158 Against thread-safety:
52159 </p>
52160 <p>
52161 The thread-safe version is well-known to be far more expensive, even
52162 if used by a single thread.  Many applications, including all single-threaded
52163 ones, do not care.
52164 </p>
52165
52166 <p><i>[
52167 San Francisco:
52168 ]</i></p>
52169
52170
52171 <blockquote>
52172 <p>
52173 Beman: this is a complicated issue, and would like to move this to Open
52174 and await comment from Peter Dimov; we need very careful and complete
52175 rationale for any decision we make; let's go slow
52176 </p>
52177 <p>
52178 Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
52179 </p>
52180 <p>
52181 Hans: When you create a thread with a lambda, it in some cases makes it
52182 very difficult for the lambda to reference anything in the heap. It's
52183 currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
52184 object.
52185 </p>
52186 <p>
52187 Leave in Open. Detlef will submit an alternative proposed resolution
52188 that makes <tt>shared_ptr</tt> explicitly unsafe.
52189 </p>
52190 <p>
52191 A third option is to support both threadsafe and non-safe share_ptrs,
52192 and to let the programmer decide which behavior they want.
52193 </p>
52194
52195 <p>
52196 Beman:  Peter, do you support the PR?
52197 </p>
52198
52199 <p>
52200 Peter:
52201 </p>
52202 <blockquote>
52203 <p>
52204 Yes, I support the proposed resolution, and I certainly oppose any
52205 attempts to <tt>make shared_ptr</tt> thread-unsafe.
52206 </p>
52207 <p>
52208 I'd mildly prefer if
52209 </p>
52210 <blockquote>
52211 [<i>Note:</i> This is true in spite of that fact that such functions often
52212 modify <tt>use_count()</tt> <i>--end note</i>]
52213 </blockquote>
52214 <p>
52215 is changed to
52216 </p>
52217 <blockquote>
52218 [<i>Note:</i> This is true in spite of that fact that such functions often
52219 cause a change in <tt>use_count()</tt> <i>--end note</i>]
52220 </blockquote>
52221 <p>
52222 (or something along these lines) to emphasise that <tt>use_count()</tt> is not,
52223 conceptually, a variable, but a return value.
52224 </p>
52225 </blockquote>
52226
52227 </blockquote>
52228
52229 <p><i>[
52230 2009-07 Frankfurt
52231 ]</i></p>
52232
52233
52234 <blockquote>
52235 <p>
52236 Vote: Do we want one thread-safe shared pointer or two? If two, one
52237 would allow concurrent construction and destruction of shared pointers,
52238 and one would not be thread-safe. If one, then it would be thread-safe.
52239 </p>
52240 <p>
52241 No concensus on that vote.
52242 </p>
52243 <p>
52244 Hans to improve wording in consultation with Pete. Leave Open.
52245 </p>
52246 </blockquote>
52247
52248 <p><i>[
52249 2009-10 Santa Cruz:
52250 ]</i></p>
52251
52252
52253 <blockquote>
52254 Move to Ready. Ask Editor to clear up wording a little when integrating to
52255 make it clear that the portion after the first comma only applies for
52256 the presence of data races.
52257 </blockquote>
52258
52259 <p><i>[
52260 2009-10-24 Hans adds:
52261 ]</i></p>
52262
52263
52264 <blockquote>
52265 <p>
52266 I think we need to pull 896 back from ready, unfortunately.  My wording
52267 doesn't say the right thing.
52268 </p>
52269
52270 <p>
52271 I suspect we really want to say something along the lines of:
52272 </p>
52273
52274 <blockquote>
52275 For purposes of determining the presence of a data race, member
52276 functions access and modify only the <tt>shared_ptr</tt> and
52277 <tt>weak_ptr</tt> objects themselves and not objects they refer to.
52278 Changes in <tt>use_count()</tt> do not reflect modifications that can
52279 introduce data races.
52280 </blockquote>
52281
52282 <p>
52283 But I think this needs further discussion by experts to make sure this
52284 is right.
52285 </p>
52286
52287 <p>
52288 Detlef and I agree continue to disagree on the resolution, but I think
52289 we agree that it would be good to try to expedite this so that it can be
52290 in CD2, since it's likely to generate NB comments no matter what we do.
52291 And lack of clarity of intent is probably the worst option.  I think it
52292 would be good to look at this between meetings.
52293 </p>
52294 </blockquote>
52295
52296 <p><i>[
52297 2010-01-20 Howard:
52298 ]</i></p>
52299
52300
52301 <blockquote>
52302 <p>
52303 I've moved Hans' suggested wording above into the proposed resolution section
52304 and preserved the previous wording here:
52305 </p>
52306
52307 <blockquote>
52308 <p>
52309 Make it explicitly thread-safe, in this weak sense, as I believe was intended:
52310 </p>
52311 <p>
52312 Insert in 20.9.10.2 [util.smartptr.shared], before p5:
52313 </p>
52314 <blockquote>
52315 <p>
52316 For purposes of determining the presence of a data race,
52317 member functions do not modify <tt>const shared_ptr</tt> and
52318 const <tt>weak_ptr</tt> arguments, nor any objects they
52319 refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
52320 cause a change in <tt>use_count()</tt> <i>--end note</i>]
52321 </p>
52322 </blockquote>
52323 <p>
52324 On looking at the text, I'm not sure we need a similar disclaimer
52325 anywhere else, since nothing else has the problem with the modified
52326 <tt>use_count()</tt>.  I think Howard arrived at a similar conclusion.
52327 </p>
52328 </blockquote>
52329 </blockquote>
52330
52331 <p><i>[
52332 2010 Pittsburgh:  Moved to Ready for Pittsburgh
52333 ]</i></p>
52334
52335
52336
52337
52338 <p><b>Proposed resolution:</b></p>
52339
52340 <p>
52341 Insert a new paragraph at the end of 20.9.10.2 [util.smartptr.shared]:
52342 </p>
52343
52344 <blockquote>
52345 For purposes of determining the presence of a data race, member functions access
52346 and modify only the <tt>shared_ptr</tt> and <tt>weak_ptr</tt> objects themselves
52347 and not objects they refer to. Changes in <tt>use_count()</tt> do not reflect
52348 modifications that can introduce data races.
52349 </blockquote>
52350
52351
52352
52353
52354
52355 <hr>
52356 <h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3>
52357 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52358  <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2010-10-29</p>
52359 <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>
52360 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52361 <p><b>Discussion:</b></p>
52362 <p>
52363 I ran across a small contradiction in working draft n2723. 
52364 </p>
52365 <blockquote>
52366 <p>
52367 23.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the
52368 requirements of a container (table 90), except that the <tt>size()</tt> member
52369 function is not provided.
52370 </p>
52371 <p>
52372 23.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt>
52373 comparisons.
52374 </p>
52375 </blockquote>
52376 <p>
52377 Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
52378 <tt>size()</tt>, or note that it is used there only for sake of notational convenience. 
52379 </p>
52380
52381 <p><i>[
52382 2009-03-29 Beman provided proposed wording.
52383 ]</i></p>
52384
52385
52386 <p><i>[
52387 Batavia (2009-05):
52388 ]</i></p>
52389
52390 <blockquote>
52391 <p>
52392 We agree with the proposed resolution.
52393 </p>
52394 <p>
52395 Move to Tentatively Ready.
52396 </p>
52397 </blockquote>
52398
52399
52400 <p><b>Proposed resolution:</b></p>
52401 <p><i>Change 23.3.3.5 [forwardlist.ops],
52402 forward_list operations, paragraph 19, merge complexity as indicated:
52403 </i></p>
52404 <blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del>
52405 <ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt>
52406 comparisons.
52407 </blockquote>
52408
52409
52410
52411
52412
52413 <hr>
52414 <h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3>
52415 <p><b>Section:</b> 20.9.10.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52416  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2010-10-29</p>
52417 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
52418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52419 <p><b>Discussion:</b></p>
52420 <p>
52421 James Dennett, message c++std-lib-22442:
52422 </p>
52423 <blockquote>
52424 The wording below addresses one case of this, but opening an
52425 issue to address the need to sanity check uses of the term "pointer"
52426 in 20.9.10.2 [util.smartptr.shared] would be a good thing.
52427 </blockquote>
52428 <p>
52429 There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is:
52430 </p>
52431 <p>
52432 Change 20.9.10.2.2 [util.smartptr.shared.dest]/1 second bullet from:
52433 </p>
52434 <blockquote>
52435 Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
52436 </blockquote>
52437 <p>
52438 to:
52439 </p>
52440 <blockquote>
52441 Otherwise, if *this owns an object p and a deleter d, d(p) is called.
52442 </blockquote>
52443
52444 <p><i>[
52445 Post Summit:
52446 ]</i></p>
52447
52448
52449 <blockquote>
52450 Recommend Review.
52451 </blockquote>
52452
52453 <p><i>[
52454 Batavia (2009-05):
52455 ]</i></p>
52456
52457 <blockquote>
52458 <p>
52459 Peter Dimov notes the analogous change has already been made
52460 to "the new nullptr_t taking constructors
52461 in 20.9.10.2.1 [util.smartptr.shared.const] p9-13."
52462 </p>
52463 <p>
52464 We agree with the proposed resolution.
52465 Move to Tentatively Ready.
52466 </p>
52467 </blockquote>
52468
52469
52470 <p><b>Proposed resolution:</b></p>
52471 <p>
52472 Change 20.9.10.2.2 [util.smartptr.shared.dest]/1 second bullet:
52473 </p>
52474 <blockquote>
52475 <ul>
52476 <li>...</li>
52477 <li>
52478 Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del>
52479 <ins>an object</ins> <tt>p</tt> and a
52480 deleter <tt>d</tt>, <tt>d(p)</tt> is called.
52481 </li>
52482 </ul>
52483 </blockquote>
52484
52485
52486
52487
52488
52489 <hr>
52490 <h3><a name="900"></a>900. stream move-assignment</h3>
52491 <p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52492  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20 <b>Last modified:</b> 2010-10-29</p>
52493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52494 <p><b>Discussion:</b></p>
52495 <p>
52496 It
52497 appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
52498 stream types. For example, when assigning to an <tt>std::ifstream</tt>,
52499 <tt>ifstream1</tt>, it seems preferable to close the file originally held by
52500 <tt>ifstream1</tt>:
52501 </p>
52502
52503 <blockquote><pre>ifstream1 = std::move(ifstream2); 
52504 </pre></blockquote>
52505
52506 <p>
52507 The current Draft
52508 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
52509 specifies that the move-assignment of
52510 stream types like <tt>ifstream</tt> has the same effect as a swap:
52511 </p>
52512
52513 <blockquote>
52514 <p>
52515 Assign and swap 27.9.1.8 [ifstream.assign]
52516 </p>
52517 <pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs); 
52518 </pre>
52519 <blockquote>
52520 <i>Effects:</i> <tt>swap(rhs)</tt>.
52521 </blockquote>
52522 </blockquote>
52523
52524 <p><i>[
52525 Batavia (2009-05):
52526 ]</i></p>
52527
52528 <blockquote>
52529 <p>
52530 Howard agrees with the analysis and the direction proposed.
52531 </p>
52532 <p>
52533 Move to Open pending specific wording to be supplied by Howard.
52534 </p>
52535 </blockquote>
52536
52537 <p><i>[
52538 2009-07 Frankfurt:
52539 ]</i></p>
52540
52541
52542 <blockquote>
52543 Howard is going to write wording.
52544 </blockquote>
52545
52546 <p><i>[
52547 2009-07-26 Howard provided wording.
52548 ]</i></p>
52549
52550
52551 <p><i>[
52552 2009-09-13 Niels adds:
52553 ]</i></p>
52554
52555
52556 <blockquote>
52557 Note: The proposed change of 27.9.1.3 [filebuf.assign]/1 depends on the
52558 resolution of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, which allows implementations to assume that
52559 <tt>*this</tt> and <tt>rhs</tt> refer to different objects.
52560 </blockquote>
52561
52562 <p><i>[
52563 2009 Santa Cruz:
52564 ]</i></p>
52565
52566
52567 <blockquote>
52568 Leave as Open.  Too closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a> to move on at this time.
52569 </blockquote>
52570
52571 <p><i>[
52572 2010 Pittsburgh:
52573 ]</i></p>
52574
52575
52576 <blockquote>
52577 Moved to Ready for Pittsburgh.
52578 </blockquote>
52579
52580
52581
52582 <p><b>Proposed resolution:</b></p>
52583
52584 <p>
52585 Change 27.8.1.2 [stringbuf.assign]/1:
52586 </p>
52587
52588 <blockquote><pre>basic_stringbuf&amp; operator=(basic_stringbuf&amp;&amp; rhs);
52589 </pre>
52590 <blockquote>
52591 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52592 <ins>After the move assignment <tt>*this</tt> reflects the same observable
52593 state it would have if it had been move constructed from <tt>rhs</tt>
52594 (27.8.1.1 [stringbuf.cons]).
52595 </ins>
52596 </blockquote>
52597 </blockquote>
52598
52599 <p>
52600 Change 27.8.2.2 [istringstream.assign]/1:
52601 </p>
52602
52603 <blockquote><pre>basic_istringstream&amp; operator=(basic_istringstream&amp;&amp; rhs);
52604 </pre>
52605 <blockquote>
52606 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52607 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52608 base and members of <tt>rhs</tt>.
52609 </ins>
52610 </blockquote>
52611 </blockquote>
52612
52613 <p>
52614 Change 27.8.3.2 [ostringstream.assign]/1:
52615 </p>
52616
52617 <blockquote><pre>basic_ostringstream&amp; operator=(basic_ostringstream&amp;&amp; rhs);
52618 </pre>
52619 <blockquote>
52620 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52621 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52622 base and members of <tt>rhs</tt>.
52623 </ins>
52624 </blockquote>
52625 </blockquote>
52626
52627 <p>
52628 Change 27.8.5.1 [stringstream.assign]/1:
52629 </p>
52630
52631 <blockquote><pre>basic_stringstream&amp; operator=(basic_stringstream&amp;&amp; rhs);
52632 </pre>
52633 <blockquote>
52634 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52635 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52636 base and members of <tt>rhs</tt>.
52637 </ins>
52638 </blockquote>
52639 </blockquote>
52640
52641 <p>
52642 Change 27.9.1.3 [filebuf.assign]/1:
52643 </p>
52644
52645 <blockquote><pre>basic_filebuf&amp; operator=(basic_filebuf&amp;&amp; rhs);
52646 </pre>
52647 <blockquote>
52648 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52649 <ins>Begins by calling <tt>this-&gt;close()</tt>.
52650 After the move assignment <tt>*this</tt> reflects the same observable
52651 state it would have if it had been move constructed from <tt>rhs</tt>
52652 (27.9.1.2 [filebuf.cons]).
52653 </ins>
52654 </blockquote>
52655 </blockquote>
52656
52657 <p>
52658 Change 27.9.1.8 [ifstream.assign]/1:
52659 </p>
52660
52661 <blockquote><pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
52662 </pre>
52663 <blockquote>
52664 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52665 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52666 base and members of <tt>rhs</tt>.</ins>
52667 </blockquote>
52668 </blockquote>
52669
52670 <p>
52671 Change 27.9.1.12 [ofstream.assign]/1:
52672 </p>
52673
52674 <blockquote><pre>basic_ofstream&amp; operator=(basic_ofstream&amp;&amp; rhs);
52675 </pre>
52676 <blockquote>
52677 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52678 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52679 base and members of <tt>rhs</tt>.</ins>
52680 </blockquote>
52681 </blockquote>
52682
52683 <p>
52684 Change 27.9.1.16 [fstream.assign]/1:
52685 </p>
52686
52687 <blockquote><pre>basic_fstream&amp; operator=(basic_fstream&amp;&amp; rhs);
52688 </pre>
52689 <blockquote>
52690 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
52691 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
52692 base and members of <tt>rhs</tt>.</ins>
52693 </blockquote>
52694 </blockquote>
52695
52696
52697
52698
52699
52700
52701 <hr>
52702 <h3><a name="904"></a>904. result_of argument types</h3>
52703 <p><b>Section:</b> X [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52704  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2010-10-29</p>
52705 <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>
52706 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52707 <p><b>Discussion:</b></p>
52708 <p>
52709 The WP and TR1 have the same text regarding the argument types of a
52710 <tt>result_of</tt> expression:
52711 </p>
52712 <blockquote>
52713 The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a
52714 reference type, and rvalues otherwise.
52715 </blockquote>
52716 <p>
52717 I read this to mean that this compiles:
52718 </p>
52719 <blockquote><pre>typedef int (*func)(int&amp;);
52720 result_of&lt;func(int&amp;&amp;)&gt;::type i = 0;
52721 </pre></blockquote>
52722 <p>
52723 even though this doesn't:
52724 </p>
52725 <blockquote><pre>int f(int&amp;);
52726 f( std::move(0) );
52727 </pre></blockquote>
52728 <p>
52729 Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference
52730 type" or am I missing something?
52731 </p>
52732 <p>
52733 I later came up with this self-contained example which won't compile,
52734 but I think it should:
52735 </p>
52736 <blockquote><pre>struct X {
52737   void operator()(int&amp;);
52738   int operator()(int&amp;&amp;);
52739 } x;
52740
52741 std::result_of&lt; X(int&amp;&amp;) &gt;::type i = x(std::move(0));
52742 </pre></blockquote>
52743
52744 <p><i>[
52745 Post Summit:
52746 ]</i></p>
52747
52748
52749 <blockquote>
52750 Recommend Tentatively Ready.
52751 </blockquote>
52752
52753
52754
52755 <p><b>Proposed resolution:</b></p>
52756 <p>
52757 Change X [func.ret], p1:
52758 </p>
52759
52760 <blockquote>
52761 ... The values <tt>ti</tt> are lvalues 
52762 when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type,
52763 and rvalues otherwise. 
52764 </blockquote>
52765
52766
52767
52768
52769
52770 <hr>
52771 <h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3>
52772 <p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52773  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
52774 <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>
52775 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52776 <p><b>Discussion:</b></p>
52777 <p>
52778 The current standard 14882::2003(E) as well as the current draft
52779 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
52780 have in common a contradiction of the operational semantics
52781 of member function test 20.5.2 [bitset.members]/56-58 and the immutable
52782 member <tt>operator[]</tt> overload 20.5.2 [bitset.members]/64-66 (all references
52783 are defined in terms of
52784 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>):
52785 </p>
52786
52787 <ol>
52788 <li><pre>bool test(size_t pos) const;
52789 </pre>
52790 <blockquote>
52791 <p>
52792 <i>Requires:</i> <tt>pos</tt> is valid
52793 </p>
52794 <p>
52795 <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond
52796 to a valid bit position.
52797 </p>
52798 <p>
52799 <i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
52800 has the value one.
52801 </p>
52802 </blockquote>
52803 </li>
52804 <li><pre>constexpr bool operator[](size_t pos) const;
52805 </pre>
52806 <blockquote>
52807 <p>
52808 <i>Requires:</i> <tt>pos</tt> shall be valid.
52809 </p>
52810 <p>
52811 <i>Throws:</i> nothing.
52812 </p>
52813 <p>
52814 <i>Returns:</i> <tt>test(pos)</tt>.
52815 </p>
52816 </blockquote>
52817 </li>
52818 </ol>
52819
52820 <p>
52821 Three interpretations:
52822 </p>
52823
52824 <ol type="A">
52825 <li>
52826 The <tt>operator[]</tt> overload is indeed allowed to throw an exception
52827 (via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does
52828 not leave the call frame. In this case this function cannot be a
52829 <tt>constexpr</tt> function, because <tt>test()</tt> is not, due to
52830 5.19 [expr.const]/2, last bullet.
52831 </li>
52832 <li>
52833 The intend was not to throw an exception in <tt>test</tt> in case of an
52834 invalid bit position. There is only little evidence for this interpretation.
52835 </li>
52836 <li>
52837 The intend was that <tt>operator[]</tt> should not throw any exception,
52838 but that <tt>test</tt> has the contract to do so, if the provided bit position
52839 is invalid.
52840 </li>
52841 </ol>
52842
52843 <p>
52844 The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
52845 recently voted into WP argued that member <tt>test</tt> logically must be
52846 a <tt>constexpr</tt> function, because it was used to define the semantics
52847 of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload).
52848 </p>
52849
52850 <p>
52851 Three alternatives are proposed, corresponding to the three bullets
52852 (A), (B), and (C), the author suggests to follow proposal (C).
52853 </p>
52854
52855 <b>
52856 Proposed alternatives:
52857 </b>
52858
52859 <ol type="A">
52860 <li>
52861 <p>
52862 Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and
52863 undo that of member <tt>test</tt> (assuming <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> is accepted) in both the
52864 class declaration 20.5 [template.bitset]/1 and in the member description
52865 before 20.5.2 [bitset.members]/56 and before /64 to read:
52866 </p>
52867 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
52868 ..
52869 <del>constexpr</del> bool operator[](size_t pos) const;
52870 </pre></blockquote>
52871
52872 <p>
52873 Change the throws clause of p. 65 to read:
52874 </p>
52875
52876 <blockquote>
52877 <i>Throws:</i> <del>nothing</del>
52878 <ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
52879 position</ins>.
52880 </blockquote>
52881 </li>
52882 <li>
52883 <p>
52884 Replace the throws clause p. 57 to read:
52885 </p>
52886
52887 <blockquote>
52888 <i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
52889 position</del> <ins>nothing</ins>.
52890 </blockquote>
52891 </li>
52892 <li>
52893 <p>
52894 Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
52895 function in both class declaration 20.5 [template.bitset]/1 and in the
52896 member description before 20.5.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
52897 was applied.
52898 </p>
52899
52900 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
52901 </pre></blockquote>
52902
52903 <p>
52904 Change the returns clause p. 66 to read:
52905 </p>
52906
52907 <blockquote>
52908 <i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
52909 has the value one, otherwise <tt>false</tt></ins>.
52910 </blockquote>
52911 </li>
52912 </ol>
52913
52914 <p><i>[
52915 Post Summit:
52916 ]</i></p>
52917
52918
52919 <blockquote>
52920 <p>
52921 Lawrence: proposed resolutions A, B, C are mutually exclusive.
52922 </p>
52923 <p>
52924 Recommend Review with option C.
52925 </p>
52926 </blockquote>
52927
52928 <p><i>[
52929 Batavia (2009-05):
52930 ]</i></p>
52931
52932 <blockquote>
52933 We agree with the proposed resolution.
52934 Move to Tentatively Ready.
52935 </blockquote>
52936
52937
52938 <p><b>Proposed resolution:</b></p>
52939
52940 <ol type="A" ,="" start="3">
52941 <li>
52942 <p>
52943 Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
52944 function in both class declaration 20.5 [template.bitset]/1 and in the
52945 member description before 20.5.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
52946 was applied.
52947 </p>
52948
52949 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
52950 </pre></blockquote>
52951
52952 <p>
52953 Change the returns clause p. 66 to read:
52954 </p>
52955
52956 <blockquote>
52957 <i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
52958 has the value one, otherwise <tt>false</tt></ins>.
52959 </blockquote>
52960 </li>
52961 </ol>
52962
52963
52964
52965
52966
52967
52968 <hr>
52969 <h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3>
52970 <p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
52971  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
52972 <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>
52973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
52974 <p><b>Discussion:</b></p>
52975
52976 <p><b>Addresses UK 319</b></p>
52977 <p>
52978 Construction of a <tt>regex_token_iterator</tt> (28.12.2 [re.tokiter]/6+) usually
52979 requires the provision of a sequence of integer values, which
52980 can currently be done via a <tt>std::vector&lt;int&gt;</tt> or
52981 a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the
52982 standard it seems much more reasonable to provide a
52983 corresponding constructor that accepts an <tt>initializer_list&lt;int&gt;</tt>
52984 instead. This could be done as a pure addition or one could
52985 even consider replacement. The author suggests the
52986 replacement strategy (A), but provides an alternative additive
52987 proposal (B) as a fall-back, because of the handiness of this
52988 range type:
52989 </p>
52990
52991 <p><i>[
52992 Batavia (2009-05):
52993 ]</i></p>
52994
52995 <blockquote>
52996 We strongly recommend alternative B of the proposed resolution
52997 in order that existing code not be broken.
52998 With that understanding, move to Tentatively Ready.
52999 </blockquote>
53000
53001 <p><b>Original proposed wording:</b></p>
53002
53003 <ol type="A">
53004 <li><br>
53005 <ol>
53006 <li>
53007 <p>
53008 In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 change the
53009 constructor declaration:
53010 </p>
53011
53012 <blockquote><pre><del>template &lt;std::size_t N&gt;</del>
53013 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
53014                      const regex_type&amp; re,
53015                      <del>const int (&amp;submatches)[N]</del> <ins>initializer_list&lt;int&gt; submatches</ins>,
53016                      regex_constants::match_flag_type m =
53017                        regex_constants::match_default);
53018 </pre></blockquote>
53019 </li>
53020
53021 <li>
53022 <p>
53023 In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
53024 </p>
53025
53026 <blockquote>
53027 The third constructor initializes the member <tt>subs</tt> to hold
53028 a copy of the sequence of integer values pointed to by the
53029 iterator range <tt>[<del>&amp;</del>submatches<ins>.begin()</ins>,
53030 <del>&amp;</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>.
53031 </blockquote>
53032 </li>
53033 </ol>
53034 </li>
53035
53036 <li><br>
53037 <ol>
53038 <li>
53039 <p>
53040 In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
53041 following constructor declaration between the already existing ones
53042 accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
53043 </p>
53044
53045 <blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
53046                      const regex_type&amp; re,
53047                      initializer_list&lt;int&gt; submatches,
53048                      regex_constants::match_flag_type m =
53049                        regex_constants::match_default);
53050 </pre></blockquote>
53051 </li>
53052 <li>
53053 <p>
53054 In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
53055 </p>
53056
53057 <blockquote>
53058 The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
53059 to hold a copy of the sequence of integer values pointed to
53060 by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
53061 <ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
53062 </blockquote>
53063 </li>
53064 </ol>
53065 </li>
53066
53067 </ol>
53068
53069
53070
53071 <p><b>Proposed resolution:</b></p>
53072
53073 <ol type="A" start="2">
53074
53075 <li><br>
53076 <ol>
53077 <li>
53078 <p>
53079 In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
53080 following constructor declaration between the already existing ones
53081 accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
53082 </p>
53083
53084 <blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
53085                      const regex_type&amp; re,
53086                      initializer_list&lt;int&gt; submatches,
53087                      regex_constants::match_flag_type m =
53088                        regex_constants::match_default);
53089 </pre></blockquote>
53090 </li>
53091 <li>
53092 <p>
53093 In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
53094 </p>
53095
53096 <blockquote>
53097 The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
53098 to hold a copy of the sequence of integer values pointed to
53099 by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
53100 <ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
53101 </blockquote>
53102 </li>
53103 </ol>
53104 </li>
53105
53106 </ol>
53107
53108
53109
53110
53111
53112
53113 <hr>
53114 <h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
53115 <p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53116  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2010-10-29</p>
53117 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53118 <p><b>Discussion:</b></p>
53119 <p>
53120 Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
53121 implements public move constructors, move assignment operators and <tt>swap</tt>
53122 method and free functions. This might induce both the user and the
53123 compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
53124 and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
53125 expectations. For example:
53126 </p>
53127
53128 <blockquote><pre>std::ostream os(std::ofstream("file.txt"));
53129 assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
53130
53131 std::vector&lt;std::ostream&gt; v;
53132 v.push_back(std::ofstream("file.txt"));
53133 v.reserve(100); // causes reallocation
53134 assert(v[0].rdbuf() == 0); // file.txt has been closed!
53135
53136 std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
53137 os1 = std::ofstream("file2.txt");
53138 os1 &lt;&lt; "hello, world"; // still writes to file1.txt, not to file2.txt!
53139
53140 std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
53141 std::ostream&amp;&amp; os2 = std::ofstream("file2.txt");
53142 std::swap(os1, os2);
53143 os1 &lt;&lt; "hello, world"; // writes to file1.txt, not to file2.txt!
53144 </pre></blockquote>
53145
53146 <p>
53147 This is because the move constructor, the move assignment operator and
53148 <tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
53149 functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
53150 stream buffers. That can't happen because the stream buffers may have
53151 different types.
53152 </p>
53153
53154 <p>
53155 Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
53156 protected. I believe that is correct and all of <tt>basic_istream</tt>,
53157 <tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
53158 assignment operator and swap member function are needed by the derived
53159 <tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
53160 <tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
53161 </p>
53162
53163 <p><i>[
53164 Batavia (2009-05):
53165 ]</i></p>
53166
53167 <blockquote>
53168 <p>
53169 We note that the rvalue swap functions have already been removed.
53170 </p>
53171 <p>
53172 Bill is unsure about making the affected functions protected;
53173 he believes they may need to be public.
53174 </p>
53175 <p>
53176 We are also unsure about removing the lvalue swap functions as proposed.
53177 </p>
53178 <p>
53179 Move to Open.
53180 </p>
53181 </blockquote>
53182
53183 <p><i>[
53184 2009-07 Frankfurt:
53185 ]</i></p>
53186
53187
53188 <blockquote>
53189 <p>
53190 It's not clear that the use case is compelling.
53191 </p>
53192 <p>
53193 Howard: This needs to be implemented and tested.
53194 </p>
53195 </blockquote>
53196
53197 <p><i>[
53198 2009-07-26 Howard adds:
53199 ]</i></p>
53200
53201
53202 <blockquote>
53203 <p>
53204 I started out thinking I would recommend NAD for this one.  I've turned around
53205 to agree with the proposed resolution (which I've updated to the current draft).
53206 I did not fully understand Ganesh's rationale, and attempt to describe my
53207 improved understanding below.
53208 </p>
53209
53210 <p>
53211 The move constructor, move assignment operator, and swap function are different
53212 for <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
53213 than other classes.  A timely conversation with Daniel reminded me of this long
53214 forgotten fact.  These members are sufficiently different that they would be
53215 extremely confusing to use in general, but they are very much needed for derived
53216 clients.
53217 </p>
53218
53219 <ul>
53220 <li>
53221 The move constructor moves everything but the <tt>rdbuf</tt> pointer.
53222 </li>
53223 <li>
53224 The move assignment operator moves everything but the <tt>rdbuf</tt> pointer.
53225 </li>
53226 <li>
53227 The swap function swaps everything but the <tt>rdbuf</tt> pointer.
53228 </li>
53229 </ul>
53230
53231 <p>
53232 The reason for this behavior is that for the std-derived classes (stringstreams,
53233 filestreams), the <tt>rdbuf</tt> pointer points back into the class itself
53234 (self referencing).  It can't be swapped or moved.  But this fact isn't born out
53235 at the <tt>stream</tt> level.  Rather it is born out at the <tt>fstream</tt>/<tt>sstream</tt>
53236 level.  And the lower levels just need to deal with that fact by not messing around
53237 with the <tt>rdbuf</tt> pointer which is stored down at the lower levels.
53238 </p>
53239
53240 <p>
53241 In a nutshell, it is very confusing for all of those who are not so intimately
53242 related with streams that they've implemented them.  And it is even fairly
53243 confusing for some of those who have (including myself).  I do not think it is
53244 safe to swap or move <tt>istreams</tt> or <tt>ostreams</tt> because this will
53245 (by necessary design) separate stream state from streambuffer state.  Derived
53246 classes (such as <tt>fstream</tt> and <tt>stringstream</tt> must be used to
53247 keep the stream state and stream buffer consistently packaged as one unit during
53248 a move or swap.
53249 </p>
53250
53251 <p>
53252 I've implemented this proposal and am living with it day to day.
53253 </p>
53254
53255 </blockquote>
53256
53257 <p><i>[
53258 2009 Santa Cruz:
53259 ]</i></p>
53260
53261
53262 <blockquote>
53263 Leave Open.  Pablo expected to propose alternative wording which would rename
53264 move construction, move assignment and swap, and may or may not make them
53265 protected.  This will impact issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>.
53266 </blockquote>
53267
53268 <p><i>[
53269 2010 Pittsburgh:
53270 ]</i></p>
53271
53272
53273 <blockquote>
53274 Moved to Ready for Pittsburgh.
53275 </blockquote>
53276
53277
53278
53279 <p><b>Proposed resolution:</b></p>
53280 <p>
53281 27.7.1.1 [istream]: make the following member functions protected:
53282 </p>
53283
53284 <blockquote><pre>basic_istream(basic_istream&amp;&amp;  rhs);
53285 basic_istream&amp;  operator=(basic_istream&amp;&amp;  rhs);
53286 void  swap(basic_istream&amp;  rhs);
53287 </pre></blockquote>
53288
53289 <p>
53290 Ditto: remove the swap free function signature
53291 </p>
53292
53293 <blockquote><pre><del>// swap: 
53294 template &lt;class charT, class traits&gt; 
53295   void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
53296 </pre></blockquote>
53297
53298 <p>
53299 27.7.1.1.2 [istream.assign]: remove paragraph 4
53300 </p>
53301
53302 <blockquote><pre><del>template &lt;class charT, class traits&gt; 
53303   void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
53304 </pre>
53305 <blockquote>
53306 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
53307 </blockquote>
53308 </blockquote>
53309
53310 <p>
53311 27.7.1.5 [iostreamclass]: make the following member function protected:
53312 </p>
53313
53314 <blockquote><pre>basic_iostream(basic_iostream&amp;&amp;  rhs);
53315 basic_iostream&amp;  operator=(basic_iostream&amp;&amp;  rhs);
53316 void  swap(basic_iostream&amp;  rhs);
53317 </pre></blockquote>
53318
53319 <p>
53320 Ditto: remove the swap free function signature
53321 </p>
53322
53323 <blockquote><pre><del>template &lt;class charT, class traits&gt; 
53324   void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
53325 </pre></blockquote>
53326
53327 <p>
53328 27.7.1.5.3 [iostream.assign]: remove paragraph 3
53329 </p>
53330
53331 <blockquote><pre><del>template &lt;class charT, class traits&gt; 
53332   void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
53333 </pre>
53334 <blockquote>
53335 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
53336 </blockquote>
53337 </blockquote>
53338
53339 <p>
53340 27.7.2.1 [ostream]: make the following member function protected:
53341 </p>
53342
53343 <blockquote><pre>basic_ostream(basic_ostream&amp;&amp;  rhs);
53344 basic_ostream&amp;  operator=(basic_ostream&amp;&amp;  rhs);
53345 void  swap(basic_ostream&amp;  rhs);
53346 </pre></blockquote>
53347
53348 <p>
53349 Ditto: remove the swap free function signature
53350 </p>
53351
53352 <blockquote><pre><del>// swap: 
53353 template &lt;class charT, class traits&gt; 
53354   void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
53355 </pre></blockquote>
53356
53357 <p>
53358 27.7.2.3 [ostream.assign]: remove paragraph 4 
53359 </p>
53360
53361 <blockquote><pre><del>template &lt;class charT, class traits&gt; 
53362   void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
53363 </pre>
53364 <blockquote>
53365 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
53366 </blockquote>
53367 </blockquote>
53368
53369
53370
53371
53372
53373
53374 <hr>
53375 <h3><a name="920"></a>920. Ref-qualification support in the library</h3>
53376 <p><b>Section:</b> 20.8.13 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53377  <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2010-10-29</p>
53378 <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>
53379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53380 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a></p>
53381 <p><b>Discussion:</b></p>
53382 <p>
53383 Daniel Krügler wrote:
53384 </p>
53385
53386 <blockquote>
53387 <p>
53388 Shouldn't above list be completed for &amp;- and &amp;&amp;-qualified
53389 member functions This would cause to add:
53390 </p>
53391 <blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53392 unspecified mem_fn(R (T::* pm)(Args...) &amp;);
53393 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53394 unspecified mem_fn(R (T::* pm)(Args...) const &amp;);
53395 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53396 unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;);
53397 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53398 unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;);
53399 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53400 unspecified mem_fn(R (T::* pm)(Args...) &amp;&amp;);
53401 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53402 unspecified mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
53403 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53404 unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
53405 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
53406 unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
53407 </pre></blockquote>
53408
53409 </blockquote>
53410
53411 <p>
53412 yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
53413 cannot be initialized from pointer to ref-qualified member function. I
53414 believe semantics of such function pointer is well defined.
53415 </p>
53416
53417 <p><i>[
53418 Post Summit Daniel provided wording.
53419 ]</i></p>
53420
53421
53422 <p><i>[
53423 Batavia (2009-05):
53424 ]</i></p>
53425
53426 <blockquote>
53427 <p>
53428 We need to think about whether we really want to go down the proposed path
53429 of combinatorial explosion.
53430 Perhaps a Note would suffice.
53431 </p>
53432 <p>
53433 We would really like to have an implementation before proceeding.
53434 </p>
53435 <p>
53436 Move to Open, and recommend this be deferred until after the next
53437 Committee Draft has been issued.
53438 </p>
53439 </blockquote>
53440
53441 <p><i>[
53442 2009-10-10 Daniel updated wording to post-concepts.
53443 ]</i></p>
53444
53445
53446 <blockquote>
53447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a> has a similar proposed resolution
53448 </blockquote>
53449
53450 <p><i>[
53451 2009-10 Santa Cruz:
53452 ]</i></p>
53453
53454
53455 <blockquote>
53456 Move to Ready.
53457 </blockquote>
53458
53459
53460
53461 <p><b>Proposed resolution:</b></p>
53462 <ol>
53463 <li>
53464 <p>
53465 Change 20.8 [function.objects]/2, header
53466 <tt>&lt;functional&gt;</tt> synopsis as follows:
53467 </p>
53468
53469 <blockquote><pre>// 20.7.14, member function adaptors:
53470 template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);
53471
53472 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...));</ins>
53473 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const);</ins>
53474 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);</ins>
53475 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);</ins>
53476
53477 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);</ins>
53478 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);</ins>
53479 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);</ins>
53480 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);</ins>
53481
53482 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);</ins>
53483 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);</ins>
53484 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);</ins>
53485 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</ins>
53486 </pre></blockquote>
53487 </li>
53488
53489 <li>
53490 <p>
53491 Change the prototype list of 20.8.13 [func.memfn] as follows [NB: The
53492 following text, most notably p.2 and p.3 which
53493 discuss influence of the cv-qualification on the definition of the
53494 base class's first template parameter remains
53495 unchanged. ]:
53496 </p>
53497
53498 <blockquote><pre>template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm);
53499
53500 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
53501 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
53502 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
53503 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>
53504
53505 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);</ins>
53506 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);</ins>
53507 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);</ins>
53508 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);</ins>
53509
53510 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);</ins>
53511 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);</ins>
53512 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);</ins>
53513 <ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);</ins>
53514 </pre></blockquote>
53515 </li>
53516
53517 <li>
53518 <p>
53519 Remove 20.8.13 [func.memfn]/5:
53520 </p>
53521
53522 <blockquote>
53523 <del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set of
53524 overloaded function templates.</del>
53525 </blockquote>
53526 </li>
53527 </ol>
53528
53529
53530
53531
53532
53533
53534 <hr>
53535 <h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
53536 <p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53537  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07 <b>Last modified:</b> 2010-10-29</p>
53538 <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>
53539 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53540 <p><b>Discussion:</b></p>
53541 <p>
53542 The compile-time functions that operate on <tt>ratio&lt;N,D&gt;</tt> require the
53543 cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
53544 meta-programming style that predates the invention of template aliases.
53545 Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
53546 </p>
53547
53548 <blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;::type&gt;::type
53549 </pre></blockquote>
53550
53551 <p>
53552 The simpler expression:
53553 </p>
53554
53555 <blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;&gt;
53556 </pre></blockquote>
53557
53558 <p>
53559 Could be used by if template aliases were employed in the definitions.
53560 </p>
53561
53562 <p><i>[
53563 Post Summit:
53564 ]</i></p>
53565
53566
53567 <blockquote>
53568 <p>
53569 Jens: not a complete proposed resolution: "would need to make similar change"
53570 </p>
53571 <p>
53572 Consensus: We agree with the direction of the issue.
53573 </p>
53574 <p>
53575 Recommend Open.
53576 </p>
53577 </blockquote>
53578
53579 <p><i>[
53580 2009-05-11 Daniel adds:
53581 ]</i></p>
53582
53583
53584 <blockquote>
53585 <p>
53586 Personally I'm <em>not</em> in favor for the addition of:
53587 </p>
53588 <blockquote><pre>typedef ratio type;
53589 </pre></blockquote>
53590 <p>
53591 For a reader of the
53592 standard it's usage or purpose is unclear. I haven't seen similar examples
53593 of attempts to satisfy non-feature complete compilers.
53594 </p>
53595 </blockquote>
53596
53597 <p><i>[
53598 2009-05-11 Pablo adds:
53599 ]</i></p>
53600
53601
53602 <blockquote>
53603 <p>
53604 The addition of type to the <tt>ratio</tt> template allows the previous style
53605 (i.e., in the prototype implementations) to remain valid and permits the
53606 use of transitional library implementations for C++03 compilers.  I do
53607 not feel strongly about its inclusion, however, and leave it up to the
53608 reviewers to decide.
53609 </p>
53610 </blockquote>
53611
53612 <p><i>[
53613 Batavia (2009-05):
53614 ]</i></p>
53615
53616 <blockquote>
53617 Bill asks for additional discussion in the issue
53618 that spells out more details of the implementation.
53619 Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>
53620 which has at least most of the requested details.
53621 Tom is strongly in favor of overflow-checking at compile time.
53622 Pete points out that there is no change of functionality implied.
53623 We agree with the proposed resolution,
53624 but recommend moving the issue to Review
53625 to allow time to improve the discussion if needed.
53626 </blockquote>
53627
53628 <p><i>[
53629 2009-07-21 Alisdair adds:
53630 ]</i></p>
53631
53632
53633 <blockquote>
53634 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a> for a potentially incompatible proposal.
53635 </blockquote>
53636
53637 <p><i>[
53638 2009-10 Santa Cruz:
53639 ]</i></p>
53640
53641
53642 <blockquote>
53643 Move to Ready.
53644 </blockquote>
53645
53646
53647
53648 <p><b>Proposed resolution:</b></p>
53649
53650  
53651  <ol start="0">
53652 <li>
53653 <p>
53654 In 20.6 [ratio]/3 change as indicated:
53655 </p>
53656
53657 <blockquote><pre>// ratio arithmetic
53658 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
53659 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
53660 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
53661 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
53662 </pre></blockquote>
53663 </li>
53664 <li>
53665 <p>
53666 In 20.6.1 [ratio.ratio], change as indicated:
53667 </p>
53668 <blockquote><pre>namespace std {
53669   template &lt;intmax_t N, intmax_t D = 1&gt;
53670   class ratio {
53671   public:
53672     <ins>typedef ratio type;</ins>
53673     static const intmax_t num;
53674     static const intmax_t den;
53675   };
53676 }
53677 </pre></blockquote>
53678 </li>
53679 <li>
53680 <p>
53681 In 20.6.2 [ratio.arithmetic] change as indicated:
53682 </p>
53683
53684 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
53685   typedef <em>see below</em> type;
53686 }</del>;
53687 </pre>
53688
53689 <blockquote>
53690 <p>
53691 1 The <del>nested typedef</del> type <tt><ins>ratio_add&lt;R1, R2&gt;</ins></tt>
53692 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
53693 where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt>
53694 has the value <tt>R1::den * R2::den</tt>.
53695 </p>
53696 </blockquote>
53697 </blockquote>
53698 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
53699   typedef <em>see below</em> type;
53700 }</del>;
53701 </pre>
53702 <blockquote>
53703 <p>
53704 2 The <del>nested typedef</del> type <tt><ins>ratio_subtract&lt;R1, R2&gt;</ins></tt>
53705 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
53706 where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt>
53707 has the value <tt>R1::den * R2::den</tt>.
53708 </p>
53709 </blockquote>
53710 </blockquote>
53711 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
53712   typedef <em>see below</em> type;
53713 }</del>;
53714 </pre>
53715 <blockquote>
53716 <p>
53717 3 The <del>nested typedef</del> type <tt><ins>ratio_multiply&lt;R1, R2&gt;</ins></tt>
53718 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
53719 where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
53720 </p>
53721 </blockquote>
53722 </blockquote>
53723 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
53724   typedef <em>see below</em> type;
53725 }</del>;
53726 </pre>
53727 <blockquote>
53728 <p>
53729 4 The <del>nested typedef</del> type <tt><ins>ratio_divide&lt;R1, R2&gt;</ins></tt>
53730 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
53731 where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
53732 </p>
53733 </blockquote>
53734 </blockquote>
53735 </li>
53736 <li>
53737 <p>
53738 In 20.11.3.1 [time.duration.cons]/4 change as indicated:
53739 </p>
53740 <blockquote>
53741 <p>
53742 <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be true or
53743 <tt>ratio_divide&lt;Period2, period&gt;::<del>type::</del>den</tt> shall be 1.[..]
53744 </p>
53745 </blockquote>
53746 </li>
53747 <li>
53748 <p>
53749 In 20.11.3.7 [time.duration.cast]/2 change as indicated:
53750 </p>
53751 <blockquote>
53752 <p>
53753 <i>Returns:</i> Let CF be <tt>ratio_divide&lt;Period, typename
53754 ToDuration::period&gt;<del>::type</del></tt>, and [..]
53755 </p>
53756 </blockquote>
53757 </li>
53758 </ol>
53759
53760
53761
53762
53763
53764 <hr>
53765 <h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3>
53766 <p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53767  <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11 <b>Last modified:</b> 2010-10-29</p>
53768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53769 <p><b>Discussion:</b></p>
53770 <p><b>Addresses DE 24</b></p>
53771
53772 <p>
53773 With respect to the section 20.8.10.1.3 [func.bind.place]:
53774 </p>
53775 <p>
53776 TR1 dropped some suggested implementation quantities for the number of
53777 placeholders. The purpose of this defect is to put these back for C++0x.
53778 </p>
53779
53780 <p><i>[
53781 Post Summit:
53782 ]</i></p>
53783
53784
53785 <blockquote>
53786 <p>
53787 see DE 24
53788 </p>
53789 <p>
53790 Recommend applying the proposed resolution from DE 24, with that
53791 Tentatively Ready.
53792 </p>
53793 </blockquote>
53794
53795 <b>Original proposed resolution:</b>
53796
53797 <p>
53798 Add 20.8.10.1.3 [func.bind.place]/2:
53799 </p>
53800
53801 <blockquote>
53802 While the exact number of placeholders (<tt>_M</tt>) is implementation defined,
53803 this number shall be at least 10.
53804 </blockquote>
53805
53806
53807
53808 <p><b>Proposed resolution:</b></p>
53809
53810 <p>
53811 Add to B [implimits]:
53812 </p>
53813
53814 <ul>
53815 <li>
53816 Number of placeholders (20.8.10.1.3 [func.bind.place]) [10].
53817 </li>
53818 </ul>
53819
53820
53821
53822
53823
53824
53825 <hr>
53826 <h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3>
53827 <p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53828  <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12 <b>Last modified:</b> 2010-10-29</p>
53829 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
53830 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53831 <p><b>Discussion:</b></p>
53832 <p>
53833 The current working draft
53834 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
53835 section 20.9.10.2.1 [util.smartptr.shared.const] declares
53836 <tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and
53837 <tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use
53838 cases that would take advantage of this conversion being implicit, for
53839 example:
53840 </p>
53841
53842 <blockquote><pre>class A;
53843 std::unique_ptr&lt;A&gt; create();
53844 void process(std::shared_ptr&lt;A&gt; obj);
53845
53846 int main()
53847 {
53848    process(create());                  // use case #1
53849    std::unique_ptr&lt;A&gt; uobj = create();
53850    process(std::move(uobj));           // use case #2
53851    return 0;
53852 }
53853 </pre></blockquote>
53854
53855 <p>
53856 If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines
53857 should be written:
53858 </p>
53859
53860 <blockquote><pre>process(std::shared_ptr&lt;A&gt;(create()));        // use case #1
53861 process(std::shared_ptr&lt;A&gt;(std::move(uobj))); // use case #2
53862 </pre></blockquote>
53863
53864 <p>
53865 The extra cast required doesn't seems to give any benefits to the user,
53866 nor protects him of any unintended conversions, this being the raison
53867 d'etre of explicit constructors.
53868 </p>
53869
53870 <p>
53871 It seems that this constructor was made explicit to mimic the conversion
53872 from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and
53873 rvalue references. Although this decision was valid back then, C++0x
53874 allows the user to express in a clear and non verbose manner when he wants
53875 move semantics to be employed, be it implicitly (use case 1) or explicitly
53876 (use case 2).
53877 </p>
53878
53879 <p><i>[
53880 Batavia (2009-05):
53881 ]</i></p>
53882
53883 <blockquote>
53884 <p>
53885 Howard and Alisdair like the motivating use cases
53886 and the proposed resolution.
53887 </p>
53888 <p>
53889 Move to Tentatively Ready.
53890 </p>
53891 </blockquote>
53892
53893
53894 <p><b>Proposed resolution:</b></p>
53895 <p>
53896 In both 20.9.10.2 [util.smartptr.shared] paragraph 1 and 
53897 20.9.10.2.1 [util.smartptr.shared.const] change:
53898 </p>
53899
53900 <blockquote><pre>template &lt;class Y&gt; <del>explicit</del> shared_ptr(auto_ptr&lt;Y&gt; &amp;&amp;r);
53901 template &lt;class Y, class D&gt; <del>explicit</del> shared_ptr(unique_ptr&lt;Y, D&gt; &amp;&amp;r);
53902 </pre></blockquote>
53903
53904
53905
53906
53907
53908
53909 <hr>
53910 <h3><a name="929"></a>929. Thread constructor</h3>
53911 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
53912  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2010-10-29</p>
53913 <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>
53914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
53915 <p><b>Discussion:</b></p>
53916
53917 <p><b>Addresses UK 323</b></p>
53918
53919 <p>
53920 The <tt>thread</tt> constructor for starting a new thread with a function and
53921 arguments is overly constrained by the signature requiring rvalue
53922 references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
53923 for the elements of <tt>args</tt>. The use of an rvalue reference for the
53924 function restricts the potential use of a plain function name, since
53925 the type of the bound parameter will be deduced to be a function
53926 reference and decay to pointer-to-function will not happen. This
53927 therefore complicates the implementation in order to handle a simple
53928 case. Furthermore, the use of rvalue references for args prevents the
53929 array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
53930 <tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
53931 parameters. In particular it prevents the passing of string literals.
53932 Consequently a simple case such as
53933 </p>
53934
53935 <blockquote><pre>void f(const char*);
53936 std::thread t(f,"hello");
53937 </pre></blockquote>
53938
53939 <p>
53940 is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
53941 </p>
53942
53943 <p>
53944 By changing the signature to take all parameters by value we can
53945 eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
53946 arrays, as the parameter passing semantics will cause the necessary
53947 array-to-pointer decay. They will also cause the function name to
53948 decay to a pointer to function and allow the implementation to handle
53949 functions and function objects identically.
53950 </p>
53951
53952 <p>
53953 The new signature of the <tt>thread</tt> constructor for a function and
53954 arguments is thus:
53955 </p>
53956
53957 <blockquote><pre>template&lt;typename F,typename... Args&gt;
53958 thread(F,Args... args);
53959 </pre></blockquote>
53960
53961 <p>
53962 Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
53963 constructor that takes just a function by value is now redundant.
53964 </p>
53965
53966 <p><i>[
53967 Howard adds:
53968 ]</i></p>
53969
53970
53971 <blockquote>
53972 <p>
53973 I agree with everything Anthony says in this issue.  However I believe we
53974 can optimize in such a way as to get the pass-by-value behavior with the
53975 pass-by-rvalue-ref performance.  The performance difference is that the latter
53976 removes a <tt>move</tt> when passing in an lvalue.
53977 </p>
53978
53979 <p>
53980 This circumstance is very analogous to <tt>make_pair</tt> (20.3.5 [pairs])
53981 where we started with passing by const reference, changed to pass by value to
53982 get pointer decay, and then changed to pass by rvalue reference, but modified with
53983 <tt>decay&lt;T&gt;</tt> to retain the pass-by-value behavior.  If we were to
53984 apply the same solution here it would look like:
53985 </p>
53986
53987 <blockquote><pre><del>template &lt;class F&gt; explicit thread(F f);</del>
53988 template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
53989 </pre>
53990 <blockquote>
53991 <p>
53992 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
53993 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
53994 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for
53995 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
53996 </p>
53997 <p>
53998 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
53999 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
54000 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
54001 <ins>Constructs
54002 the following objects in memory which is accessible to a new thread of execution
54003 as if:</ins>
54004 </p>
54005 <blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
54006 <ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
54007 </pre></blockquote>
54008 <p>
54009 <ins>The new thread of
54010 execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
54011 to the elements stored in the <tt>tuple w</tt>.</ins>
54012 Any return value from <tt>g</tt> is ignored.
54013 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
54014 <ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
54015 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
54016 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
54017 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
54018 catchable in the calling thread.</ins>
54019 </p>
54020 </blockquote>
54021 </blockquote>
54022
54023 <p>
54024 Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
54025 </p>
54026
54027 </blockquote>
54028
54029 <p><i>[
54030 Batavia (2009-05):
54031 ]</i></p>
54032
54033 <blockquote>
54034 We agree with the proposed resolution,
54035 but would like the final sentence to be reworded
54036 since "catchable" is not a term of art (and is used nowhere else).
54037 </blockquote>
54038
54039 <p><i>[
54040 2009-07 Frankfurt:
54041 ]</i></p>
54042
54043
54044 <blockquote>
54045 <p>
54046 This is linked to
54047 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
54048 </p>
54049 <p>
54050 Howard to open a separate issue to remove (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>).
54051 </p>
54052 <p>
54053 In Frankfurt there is no consensus for removing the variadic constructor.
54054 </p>
54055 </blockquote>
54056
54057 <p><i>[
54058 2009-10 Santa Cruz:
54059 ]</i></p>
54060
54061
54062 <blockquote>
54063 We want to move forward with this issue.  If we later take it out via <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>
54064 then that's ok too.  Needs small group to improve wording.
54065 </blockquote>
54066
54067 <p><i>[
54068 2009-10 Santa Cruz:
54069 ]</i></p>
54070
54071
54072 <blockquote>
54073 <p>
54074 Stefanus provided revised wording.  Moved to Review  Here is the original wording:
54075 </p>
54076 <blockquote>
54077 <p>
54078 Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
54079 following signature:
54080 </p>
54081
54082 <blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
54083 template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
54084 </pre></blockquote>
54085
54086 <p>
54087 Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
54088 the single constructor as above. Replace paragraph 4 - 6 with the
54089 following:
54090 </p>
54091
54092 <blockquote>
54093 <p>
54094 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
54095 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
54096 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for
54097 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
54098 </p>
54099 <p>
54100 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
54101 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
54102 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
54103 <ins>Constructs
54104 the following objects:</ins>
54105 </p>
54106 <blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
54107 <ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
54108 </pre></blockquote>
54109 <p>
54110 <ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
54111 These objects shall be destroyed when the new thread of execution completes.</ins>
54112 Any return value from <tt>g</tt> is ignored.
54113 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
54114 <ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
54115 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
54116 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
54117 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
54118 catchable in the calling thread.</ins>
54119 </p>
54120 <p>
54121 -6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
54122 invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
54123 </p>
54124 </blockquote>
54125
54126 </blockquote>
54127 </blockquote>
54128
54129 <p><i>[
54130 2010-01-19 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
54131 ]</i></p>
54132
54133
54134
54135 <p><b>Proposed resolution:</b></p>
54136 <p>
54137 Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
54138 following signature:
54139 </p>
54140
54141 <blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
54142 template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
54143 </pre></blockquote>
54144
54145 <p>
54146 Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
54147 the single constructor as above. Replace paragraph 4 - 6 with the
54148 following:
54149 </p>
54150
54151 <blockquote>
54152 <p>
54153 <ins>Given a function as follows:</ins>
54154 </p>
54155
54156 <blockquote><pre><ins>
54157 template&lt;typename T&gt; typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v)
54158     { return std::forward&lt;T&gt;(v); }
54159 </ins></pre></blockquote>
54160
54161 <p>
54162 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall
54163 <del>be <tt>CopyConstructible</tt> if an lvalue and otherwise</del> <ins>satisfy
54164 the</ins> <tt>MoveConstructible</tt> <ins>requirements</ins>.
54165 <del><tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require])
54166 shall be a valid expression for some values <tt>w1, w2, ... , wN,</tt> where
54167 <tt>N == sizeof...(Args)</tt>.</del>
54168 <ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;F&gt;(f)), decay_copy(std::forward&lt;Args&gt;(args))...)</tt> (20.8.2 [func.require]) shall be a valid expression.</ins>
54169 </p>
54170
54171 <p>
54172 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt> <del>and executes
54173 <tt>INVOKE(f, t1, t2, ..., tN)</tt> in a new thread of execution, where
54174 <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt>. 
54175 Any return
54176 value from <tt>f</tt> is ignored. If <tt>f</tt> terminates with an
54177 uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
54178 <ins>The new thread of execution executes <tt>INVOKE(decay_copy(std::forward&lt;F&gt;(f)),
54179 decay_copy(std::forward&lt;Args&gt;(args))...)</tt> with the calls to <tt>decay_copy()</tt> being evaluated in
54180 the constructing thread. Any return value from this invocation is
54181 ignored. [<i>Note:</i> this implies any exceptions not thrown from the
54182 invocation of the copy of <tt>f</tt> will be thrown in the constructing thread,
54183 not the new thread. \97 <i>end note</i>].
54184 If the invocation of <tt><i>INVOKE</i>(decay_copy(std::forward&lt;F&gt;(f)),
54185 decay_copy(std::forward&lt;Args&gt;(args))...)</tt> terminates with an uncaught
54186 exception, <tt>std::terminate</tt> shall be called.
54187 </ins></p>
54188
54189 <p>
54190 -6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
54191 invocation of <ins>the copy of</ins> <tt>f</tt>.
54192 </p>
54193 </blockquote>
54194
54195
54196
54197
54198
54199
54200 <hr>
54201 <h3><a name="931"></a>931. type trait <tt>extent&lt;T, I&gt;</tt></h3>
54202 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
54203  <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04 <b>Last modified:</b> 2010-10-29</p>
54204 <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>
54205 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
54206 <p><b>Discussion:</b></p>
54207 <p>
54208 The draft (N2798) says in 20.7.4.3 [meta.unary.prop] Table 44: 
54209 </p>
54210 <blockquote>
54211 <table border="1">
54212 <caption>Table 44 -- Type property queries</caption>
54213 <tbody><tr><th>Template</th><th>Value</th></tr>
54214 <tr>
54215 <td>
54216 <tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
54217 </td>
54218 <td>
54219 If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than
54220 <tt>I</tt>, or if <tt>I</tt> is 0
54221 and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
54222 size of the <tt>I</tt>'th dimension of <tt>T</tt>
54223 </td>
54224 </tr>
54225 </tbody></table>
54226 </blockquote>
54227
54228 <p>
54229 Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based 
54230 ("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following 
54231 example it is clear that the intent is 0-based, in which case it 
54232 should say "or if it has rank less than or equal to <tt>I</tt>".
54233 </p>
54234 <p>
54235 Sanity check:
54236 </p>
54237 <p>
54238 The example says <tt>assert((extent&lt;int[2], 1&gt;::value) == 0);</tt>
54239 </p>
54240 <p>
54241 Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0.
54242 </p>
54243
54244 <p><i>[
54245 Post Summit:
54246 ]</i></p>
54247
54248
54249 <blockquote>
54250 <p>
54251 Do not use "size" or "value", use "bound". Also, move the
54252 cross-reference to 8.3.4 to just after "bound".
54253 </p>
54254 <p>
54255 Recommend Tentatively Ready.
54256 </p>
54257 </blockquote>
54258
54259
54260
54261 <p><b>Proposed resolution:</b></p>
54262 <p>
54263 In Table 44 of 20.7.4.3 [meta.unary.prop], third row, column "Value",
54264 change the cell content:
54265 </p>
54266
54267 <blockquote>
54268 <table border="1">
54269 <caption>Table 44 -- Type property queries</caption>
54270 <tbody><tr><th>Template</th><th>Value</th></tr>
54271 <tr>
54272 <td>
54273 <tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
54274 </td>
54275 <td>
54276 If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than
54277 <ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0
54278 and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
54279 <del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>,
54280 where indexing of <tt>I</tt> is zero-based.</ins>
54281 </td>
54282 </tr>
54283 </tbody></table>
54284 </blockquote>
54285
54286 <p><i>[
54287 Wording supplied by Daniel.
54288 ]</i></p>
54289
54290
54291
54292
54293
54294
54295
54296 <hr>
54297 <h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
54298 <p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
54299  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26 <b>Last modified:</b> 2010-11-19</p>
54300 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
54301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
54302 <p><b>Discussion:</b></p>
54303
54304 <p><b>Addresses US 79</b></p>
54305
54306 <p>
54307 20.9.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
54308 not to be a pointer type.  I believe this restriction was accidently removed
54309 when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
54310 needs to be put back in.  Otherwise we have a run time failure that could
54311 have been caught at compile time:
54312 </p>
54313
54314 <blockquote><pre>{
54315 unique_ptr&lt;int, void(*)(void*)&gt; p1(malloc(sizeof(int)));  <font color="#C80000">// should not compile</font>
54316 }  <font color="#C80000">// p1.~unique_ptr() dereferences a null function pointer</font>
54317 unique_ptr&lt;int, void(*)(void*)&gt; p2(malloc(sizeof(int)), free);  <font color="#C80000">// ok</font>
54318 </pre></blockquote>
54319
54320 <p><i>[
54321 Post Summit:
54322 ]</i></p>
54323
54324
54325 <blockquote>
54326 Recommend Tentatively Ready.
54327 </blockquote>
54328
54329 <p><i>[
54330 2009-07 Frankfurt
54331 ]</i></p>
54332
54333
54334 <blockquote>
54335 Moved from Tentatively Ready to Open only because the wording needs to be
54336 improved for enable_if type constraining, possibly following Robert's
54337 formula.
54338 </blockquote>
54339
54340 <p><i>[
54341 2009-07 Frankfurt:
54342 ]</i></p>
54343
54344
54345 <blockquote>
54346 <p>
54347 We need to consider whether some requirements in the Requires paragraphs
54348 of [unique.ptr] should instead be Remarks.
54349 </p>
54350 <p>
54351 Leave Open. Howard to provide wording, and possibly demonstrate how this
54352 can be implemented using enable_if.
54353 </p>
54354 </blockquote>
54355
54356 <p><i>[
54357 2009-07-27 Howard adds:
54358 ]</i></p>
54359
54360
54361 <blockquote>
54362 <p>
54363 The two constructors to which this issue applies are not easily constrained
54364 with <tt>enable_if</tt> as they are not templated:
54365 </p>
54366
54367 <blockquote><pre>unique_ptr();
54368 explicit unique_ptr(pointer p);
54369 </pre></blockquote>
54370
54371 <p>
54372 To "SFINAE" these constructors away would take heroic effort such as specializing
54373 the entire <tt>unique_ptr</tt> class template on pointer deleter types.  There
54374 is insufficient motivation for such heroics.  Here is the expected and
54375 reasonable implementation for these constructors:
54376 </p>
54377
54378 <blockquote><pre>unique_ptr()
54379     : ptr_(pointer())
54380     {
54381         static_assert(!is_pointer&lt;deleter_type&gt;::value,
54382             "unique_ptr constructed with null function pointer deleter");
54383     }
54384 explicit unique_ptr(pointer p)
54385     : ptr_(p)
54386     {
54387         static_assert(!is_pointer&lt;deleter_type&gt;::value,
54388             "unique_ptr constructed with null function pointer deleter");
54389     }
54390 </pre></blockquote>
54391
54392 <p>
54393 I.e. just use <tt>static_assert</tt> to verify that the constructor is not
54394 instantiated with a function pointer for a deleter.  The compiler will automatically
54395 take care of issuing a diagnostic if the deleter is a reference type (uninitialized
54396 reference error).
54397 </p>
54398
54399 <p>
54400 In keeping with our discussions in Frankfurt, I'm moving this requirement on
54401 the implementation from the Requires paragraph to a Remarks paragraph.
54402 </p>
54403
54404 </blockquote>
54405
54406 <p><i>[
54407 2009-08-17 Daniel adds:
54408 ]</i></p>
54409
54410
54411 <blockquote>
54412 <p>
54413 It is insufficient to require a diagnostic. This doesn't imply an
54414 ill-formed program
54415 as of 1.3.6 [defns.diagnostic] (a typical alternative would be a compiler
54416 warning), but
54417 exactly that seems to be the intend. I suggest to use the following
54418 remark instead:
54419 </p>
54420
54421 <blockquote>
54422 <i>Remarks:</i> The program shall be ill-formed if this constructor is
54423 instantiated when <tt>D</tt> is a pointer type or reference type.
54424 </blockquote>
54425
54426 <p>
54427 Via the general standard rules of 1.4 [intro.compliance] the "diagnostic
54428 required" is implied.
54429 </p>
54430
54431 </blockquote>
54432
54433 <p><i>[
54434 2009-10 Santa Cruz:
54435 ]</i></p>
54436
54437
54438 <blockquote>
54439 Moved to Ready.
54440 </blockquote>
54441
54442 <p><i>[
54443 2010-03-14 Howard adds:
54444 ]</i></p>
54445
54446
54447 <blockquote>
54448 We moved
54449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
54450 to the formal motions page in Pittsburgh which should obsolete this issue.  I've
54451 moved this issue to NAD Editorial, solved by N3073.
54452 </blockquote>
54453
54454
54455
54456 <p><b>Rationale:</b></p>
54457 <p>
54458 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
54459 </p>
54460
54461
54462 <p><b>Proposed resolution:</b></p>
54463 <p>
54464 Change the description of the default constructor in 20.9.9.2.1 [unique.ptr.single.ctor]:
54465 </p>
54466
54467 <blockquote><pre>unique_ptr();
54468 </pre>
54469 <blockquote>
54470 <p>
54471 -1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that construction
54472 shall not throw an exception. <del><tt>D</tt> shall 
54473 not be a reference type or pointer type (diagnostic required).</del>
54474 </p>
54475 <p>...</p>
54476 <p><ins>
54477 <i>Remarks:</i> The program shall be ill-formed if this constructor is
54478 instantiated when <tt>D</tt> is a pointer type or reference type.
54479
54480 </ins></p>
54481 </blockquote>
54482 </blockquote>
54483
54484 <p>
54485 Add  after 20.9.9.2.1 [unique.ptr.single.ctor]/8:
54486 </p>
54487
54488 <blockquote><pre>unique_ptr(pointer p);
54489 </pre>
54490 <blockquote>
54491 <p>...</p>
54492 <p><ins>
54493 <i>Remarks:</i> The program shall be ill-formed if this constructor is
54494 instantiated when <tt>D</tt> is a pointer type or reference type.
54495
54496 </ins></p>
54497 </blockquote>
54498 </blockquote>
54499
54500
54501
54502
54503
54504 <hr>
54505 <h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
54506 <p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
54507  <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30 <b>Last modified:</b> 2010-10-29</p>
54508 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
54509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
54510 <p><b>Discussion:</b></p>
54511
54512 <p><b>Addresses US 81</b></p>
54513
54514 <p>
54515 <tt>duration</tt> is missing <tt>operator%</tt>.  This operator is convenient
54516 for computing where in a time frame a given <tt>duration</tt> lies.  A
54517 motivating example is converting a <tt>duration</tt> into a "broken-down"
54518 time duration such as hours::minutes::seconds:
54519 </p>
54520
54521 <blockquote><pre>class ClockTime
54522 {
54523     typedef std::chrono::hours hours;
54524     typedef std::chrono::minutes minutes;
54525     typedef std::chrono::seconds seconds;
54526 public:
54527     hours hours_;
54528     minutes minutes_;
54529     seconds seconds_;
54530
54531     template &lt;class Rep, class Period&gt;
54532       explicit ClockTime(const std::chrono::duration&lt;Rep, Period&gt;&amp; d)
54533         : hours_  (std::chrono::duration_cast&lt;hours&gt;  (d)),
54534           minutes_(std::chrono::duration_cast&lt;minutes&gt;(d % hours(1))),
54535           seconds_(std::chrono::duration_cast&lt;seconds&gt;(d % minutes(1)))
54536           {}
54537 };
54538 </pre></blockquote>
54539
54540 <p><i>[
54541 Summit:
54542 ]</i></p>
54543
54544
54545 <blockquote>
54546 Agree except that there is a typo in the proposed resolution. The member
54547 operators should be operator%=.
54548 </blockquote>
54549
54550 <p><i>[
54551 Batavia (2009-05):
54552 ]</i></p>
54553
54554 <blockquote>
54555 We agree with the proposed resolution.
54556 Move to Tentatively Ready.
54557 </blockquote>
54558
54559 <p><i>[
54560 2009-07 Frankfurt
54561 ]</i></p>
54562
54563
54564 <blockquote>
54565 Moved from Tentatively Ready to Open only because the wording needs to be
54566 improved for enable_if type constraining, possibly following Robert's
54567 formula.
54568 </blockquote>
54569
54570 <p><i>[
54571 2009-07 Frankfurt:
54572 ]</i></p>
54573
54574
54575 <blockquote>
54576 <p>
54577 Howard to open a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>) to handle the removal of member
54578 functions from overload sets, provide wording, and possibly demonstrate
54579 how this can be implemented using enable_if (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>).
54580 </p>
54581 <p>
54582 Move to Ready.
54583 </p>
54584 </blockquote>
54585
54586
54587
54588 <p><b>Proposed resolution:</b></p>
54589 <p>
54590 Add to the synopsis in 20.11 [time]:
54591 </p>
54592
54593 <blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
54594   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
54595   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
54596 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
54597   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
54598   operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
54599 </pre></blockquote>
54600
54601 <p>
54602 Add to the synopsis of <tt>duration</tt> in 20.11.3 [time.duration]:
54603 </p>
54604
54605 <blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
54606 class duration {
54607 public:
54608   ...
54609   <ins>duration&amp; operator%=(const rep&amp; rhs);</ins>
54610   <ins>duration&amp; operator%=(const duration&amp; d);</ins>
54611   ...
54612 };
54613 </pre></blockquote>
54614
54615 <p>
54616 Add to 20.11.3.3 [time.duration.arithmetic]:
54617 </p>
54618
54619 <blockquote>
54620 <pre>duration&amp; operator%=(const rep&amp; rhs);
54621 </pre>
54622 <blockquote>
54623 <p>
54624 <i>Effects:</i> <tt>rep_ %= rhs</tt>.
54625 </p>
54626 <p>
54627 <i>Returns:</i> <tt>*this</tt>.
54628 </p>
54629 </blockquote>
54630
54631 <pre>duration&amp; operator%=(const duration&amp; d);
54632 </pre>
54633 <blockquote>
54634 <p>
54635 <i>Effects:</i> <tt>rep_ %= d.count()</tt>.
54636 </p>
54637 <p>
54638 <i>Returns:</i> <tt>*this</tt>.
54639 </p>
54640 </blockquote>
54641 </blockquote>
54642
54643 <p>
54644 Add to 20.11.3.5 [time.duration.nonmember]:
54645 </p>
54646
54647 <blockquote>
54648
54649 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
54650   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
54651   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
54652 </pre>
54653 <blockquote>
54654 <p>
54655 <i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
54656 <tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
54657 </p>
54658 <p>
54659 <i>Returns:</i> <tt>duration&lt;CR, Period&gt;(d) %= s</tt>.
54660 </p>
54661 </blockquote>
54662
54663 <pre>template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
54664   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
54665   operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
54666 </pre>
54667 <blockquote>
54668 <p>
54669 <i>Returns:</i> <tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type(lhs) %= rhs</tt>.
54670 </p>
54671 </blockquote>
54672
54673 </blockquote>
54674
54675
54676
54677
54678
54679
54680 <hr>
54681 <h3><a name="938"></a>938. <tt>default_delete&lt;T[]&gt;::operator()</tt> should only accept <tt>T*</tt></h3>
54682 <p><b>Section:</b> 20.9.9.1.3 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
54683  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07 <b>Last modified:</b> 2010-10-29</p>
54684 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
54685 <p><b>Discussion:</b></p>
54686 <p>
54687 Consider:
54688 </p>
54689
54690 <blockquote><pre>derived* p = new derived[3];
54691 std::default_delete&lt;base[]&gt; d;
54692 d(p);  <font color="#C80000">// should fail</font>
54693 </pre></blockquote>
54694
54695 <p>
54696 Currently the marked line is a run time failure.  We can make it a compile
54697 time failure by "poisoning" <tt>op(U*)</tt>.
54698 </p>
54699
54700 <p><i>[
54701 Post Summit:
54702 ]</i></p>
54703
54704
54705 <blockquote>
54706 Recommend Review.
54707 </blockquote>
54708
54709 <p><i>[
54710 Batavia (2009-05):
54711 ]</i></p>
54712
54713 <blockquote>
54714 We agree with the proposed resolution.
54715 Move to Tentatively Ready.
54716 </blockquote>
54717
54718
54719 <p><b>Proposed resolution:</b></p>
54720 <p>
54721 Add to 20.9.9.1.3 [unique.ptr.dltr.dflt1]:
54722 </p>
54723
54724 <blockquote><pre>namespace std {
54725   template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
54726     void operator()(T*) const;
54727   <ins>template &lt;class U&gt; void operator()(U*) const = delete;</ins>
54728 };
54729 }
54730 </pre></blockquote>
54731
54732
54733
54734
54735
54736 <hr>
54737 <h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
54738 <p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
54739  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11 <b>Last modified:</b> 2010-10-29</p>
54740 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
54741 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
54742 <p><b>Discussion:</b></p>
54743 <p>
54744 <tt>std::identity</tt> takes an argument of type <tt>T const &amp;</tt>
54745 and returns a result of <tt>T const &amp;</tt>.
54746 </p>
54747 <p>
54748 Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
54749 is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary.  The
54750 constraint in the concepts version simply protects against returning
54751 reference-to-<tt>void</tt>.
54752 </p>
54753 <p>
54754 Solutions:
54755 </p>
54756 <blockquote>
54757 <p>
54758 i/  Return-by-value, potentially slicing bases and rejecting non-copyable
54759 types
54760 </p>
54761 <p>
54762 ii/ Provide an additional overload:
54763 </p>
54764 <blockquote><pre>template&lt; typename T &gt;
54765 template operator( U &amp; ) = delete;
54766 </pre></blockquote>
54767 <p>
54768 This seems closer on intent, but moves beyond the original motivation for
54769 the operator, which is compatibility with existing (non-standard)
54770 implementations.
54771 </p>
54772 <p>
54773 iii/ Remove the <tt>operator()</tt> overload.  This restores the original definition
54774 of the <tt>identity</tt>, although now effectively a type_trait rather than part of
54775 the perfect forwarding protocol.
54776 </p>
54777 <p>
54778 iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
54779 replaced with the <tt>IdentityOf</tt> concept.
54780 </p>
54781 </blockquote>
54782 <p>
54783 My own preference is somewhere between (ii) and (iii) - although I stumbled
54784 over the issue with a specific application hoping for resolution (i)!
54785 </p>
54786
54787 <p><i>[
54788 Batavia (2009-05):
54789 ]</i></p>
54790
54791 <blockquote>
54792 <p>
54793 We dislike options i and iii, and option ii seems like overkill.
54794 If we remove it (option iv), implementers can still provide it under a
54795 different name.
54796 </p>
54797 <p>
54798 Move to Open pending wording (from Alisdair) for option iv.
54799 </p>
54800 </blockquote>
54801
54802 <p><i>[
54803 2009-05-23 Alisdair provided wording for option iv.
54804 ]</i></p>
54805
54806
54807 <p><i>[
54808 2009-07-20 Alisdair adds:
54809 ]</i></p>
54810
54811
54812 <blockquote>
54813 <p>
54814 I'm not sure why this issue was not discussed at Frankfurt (or I missed
54815 the discussion) but the rationale is now fundamentally flawed.  With the
54816 removal of concepts, <tt>std::identity</tt> again becomes an important library
54817 type so we cannot simply remove it.
54818 </p>
54819 <p>
54820 At that point, we need to pick one of the other suggested resolutions,
54821 but have no guidance at the moment.
54822 </p>
54823 </blockquote>
54824
54825 <p><i>[
54826 2009-07-20 Howard adds:
54827 ]</i></p>
54828
54829
54830 <blockquote>
54831 <p>
54832 I believe the rationale for not addressing this issue in Frankfurt was that it did
54833 not address a national body comment.
54834 </p>
54835 <p>
54836 I also believe that removal of <tt>identity</tt> is still a practical option as
54837 my latest reformulation of <tt>forward</tt>, which is due to comments suggested
54838 at Summit, no longer uses <tt>identity</tt>. :-)
54839 </p>
54840
54841 <blockquote><pre>template &lt;class T, class U,
54842     class = typename enable_if
54843             &lt;
54844                 !is_lvalue_reference&lt;T&gt;::value || 
54845                  is_lvalue_reference&lt;T&gt;::value &amp;&amp;
54846                  is_lvalue_reference&lt;U&gt;::value
54847             &gt;::type,
54848     class = typename enable_if
54849             &lt;
54850                 is_same&lt;typename remove_all&lt;T&gt;::type,
54851                         typename remove_all&lt;U&gt;::type&gt;::value
54852             &gt;::type&gt;
54853 inline
54854 T&amp;&amp;
54855 forward(U&amp;&amp; t)
54856 {
54857     return static_cast&lt;T&amp;&amp;&gt;(t);
54858
54859 }
54860 </pre>
54861
54862 <p><i>[
54863 The above code assumes acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a> for the definition of
54864 <tt>remove_all</tt>.  This is just to make the syntax a little more palatable.
54865 Without this trait the above is still very implementable.
54866 ]</i></p>
54867
54868
54869 </blockquote>
54870
54871 <p>
54872 Paper with rationale is on the way ... <i>really</i>, I promise this time! ;-)
54873 </p>
54874 </blockquote>
54875
54876 <p><i>[
54877 2009-07-30 Daniel adds:  See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a> for an alternative resolution.
54878 ]</i></p>
54879
54880
54881 <p><i>[
54882 2009-10 Santa Cruz:
54883 ]</i></p>
54884
54885
54886 <blockquote>
54887 Move to Ready. Howard will update proposed wording to reflect current draft.
54888 </blockquote>
54889
54890
54891
54892 <p><b>Proposed resolution:</b></p>
54893 <p>
54894 Strike from 20.3 [utility]:
54895 </p>
54896
54897 <blockquote><pre><del>template &lt;class T&gt; struct identity;</del>
54898 </pre></blockquote>
54899
54900 <p>
54901 Remove from 20.3.3 [forward]:
54902 </p>
54903
54904 <blockquote>
54905 <pre><del>template &lt;class T&gt; struct identity {
54906   typedef T type;
54907
54908   const T&amp; operator()(const T&amp; x) const;
54909 };</del>
54910
54911 <del>const T&amp; operator()(const T&amp; x) const;</del>
54912 </pre>
54913 <blockquote>
54914 <del>-2-  <i>Returns:</i> <tt>x</tt></del>
54915 </blockquote>
54916 </blockquote>
54917
54918
54919
54920
54921
54922
54923 <hr>
54924 <h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3>
54925 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
54926  <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2010-10-29</p>
54927 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
54928 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
54929 <p><b>Discussion:</b></p>
54930 <p>
54931 There is a row in "Table 122 - Atomics for standard typedef types"
54932 in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt>
54933 and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt>
54934 is not defined by the standard.
54935 </p>
54936
54937 <p><i>[
54938 Summit:
54939 ]</i></p>
54940
54941
54942 <blockquote>
54943 Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
54944 is a POSIX type.
54945 </blockquote>
54946
54947 <p><i>[
54948 Batavia (2009-05):
54949 ]</i></p>
54950
54951 <blockquote>
54952 We agree with the proposed resolution.
54953 Move to Tentatively Ready.
54954 </blockquote>
54955
54956
54957 <p><b>Proposed resolution:</b></p>
54958 <p>
54959 Remove the row containing <tt>ssize_t</tt> from Table 119
54960 "Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
54961 </p>
54962
54963
54964
54965
54966
54967 <hr>
54968 <h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
54969 <p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
54970  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2010-11-20</p>
54971 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
54972 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
54973 <p><b>Discussion:</b></p>
54974 <p>
54975 In 20.11.3.5 [time.duration.nonmember], paragraph 8 says that calling
54976 <tt>dur / rep</tt>
54977 when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
54978 That's followed by an <tt>operator/</tt> that takes two durations.
54979 So <tt>dur1 / dur2</tt> is legal under the second version,
54980 but requires a diagnostic under the first.
54981 </p>
54982
54983 <p><i>[
54984 Howard adds:
54985 ]</i></p>
54986
54987
54988 <blockquote>
54989 Please see the thread starting with c++std-lib-22980 for more information.
54990 </blockquote>
54991
54992 <p><i>[
54993 Batavia (2009-05):
54994 ]</i></p>
54995
54996 <blockquote>
54997 Move to Open, pending proposed wording (and preferably an implementation).
54998 </blockquote>
54999
55000 <p><i>[
55001 2009-07-27 Howard adds:
55002 ]</i></p>
55003
55004
55005 <blockquote>
55006 <p>
55007 I've addressed this issue under the proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a> which
55008 cleans up several places under 20.11.3 [time.duration] which used the
55009 phrase "diagnostic required".
55010 </p>
55011 <p>
55012 For clarity's sake, here is an example implementation of the constrained <tt>operator/</tt>:
55013 </p>
55014
55015 <blockquote><pre>template &lt;class _Duration, class _Rep, bool = __is_duration&lt;_Rep&gt;::value&gt;
55016 struct __duration_divide_result
55017 {
55018 };
55019
55020 template &lt;class _Duration, class _Rep2,
55021     bool = is_convertible&lt;_Rep2,
55022                           typename common_type&lt;typename _Duration::rep, _Rep2&gt;::type&gt;::value&gt;
55023 struct __duration_divide_imp
55024 {
55025 };
55026
55027 template &lt;class _Rep1, class _Period, class _Rep2&gt;
55028 struct __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, true&gt;
55029 {
55030     typedef duration&lt;typename common_type&lt;_Rep1, _Rep2&gt;::type, _Period&gt; type;
55031 };
55032
55033 template &lt;class _Rep1, class _Period, class _Rep2&gt;
55034 struct __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, false&gt;
55035     : __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;
55036 {
55037 };
55038
55039 template &lt;class _Rep1, class _Period, class _Rep2&gt;
55040 inline
55041 typename __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;::type
55042 operator/(const duration&lt;_Rep1, _Period&gt;&amp; __d, const _Rep2&amp; __s)
55043 {
55044     typedef typename common_type&lt;_Rep1, _Rep2&gt;::type _Cr;
55045     duration&lt;_Cr, _Period&gt; __r = __d;
55046     __r /= static_cast&lt;_Cr&gt;(__s);
55047     return __r;
55048 }
55049 </pre></blockquote>
55050
55051 <p>
55052 <tt>__duration_divide_result</tt> is basically a custom-built <tt>enable_if</tt>
55053 that will contain <tt>type</tt> only if <tt>Rep2</tt> is not a <tt>duration</tt>
55054 and if <tt>Rep2</tt> is implicitly convertible to
55055 <tt>common_type&lt;typename Duration::rep, Rep2&gt;::type</tt>. <tt>__is_duration</tt>
55056 is simply a private trait that answers <tt>false</tt>, but is specialized for
55057 <tt>duration</tt> to answer <tt>true</tt>.
55058 </p>
55059
55060 <p>
55061 The constrained <tt>operator%</tt> works identically.
55062 </p>
55063 </blockquote>
55064
55065 <p><i>[
55066 2009-10 Santa Cruz:
55067 ]</i></p>
55068
55069
55070 <blockquote>
55071 Mark <del>NAD Editorial</del><ins>Resolved</ins>, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.
55072 </blockquote>
55073
55074
55075
55076 <p><b>Proposed resolution:</b></p>
55077 <p>
55078 </p>
55079
55080
55081
55082
55083
55084 <hr>
55085 <h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3>
55086 <p><b>Section:</b> 20.6.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
55087  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26 <b>Last modified:</b> 2010-10-29</p>
55088 <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>
55089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
55090 <p><b>Discussion:</b></p>
55091 <p>
55092 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
55093 20.6.2 [ratio.arithmetic] lacks a paragraph from the proposal
55094 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>:
55095 </p>
55096
55097 <blockquote>
55098 <p><b>ratio arithmetic [ratio.arithmetic]</b></p>
55099
55100 <p>
55101 ... If the implementation is unable to form the indicated <tt>ratio</tt> due to
55102 overflow, a diagnostic shall be issued.
55103 </p>
55104 </blockquote>
55105
55106 <p>
55107 The lack of a diagnostic on compile-time overflow is a significant lack of
55108 functionality.  This paragraph could be put back into the WP simply editorially.
55109 However in forming this issue I realized that we can do better than that.  This
55110 paragraph should also allow alternative formulations which go to extra lengths
55111 to avoid overflow when possible.  I.e. we should not mandate overflow when the
55112 implementation can avoid it.
55113 </p>
55114
55115 <p>
55116 For example:
55117 </p>
55118
55119 <blockquote>
55120 <pre>template &lt;class R1, class R2&gt; struct ratio_multiply {
55121   typedef <i>see below</i>} type; 
55122 </pre>
55123
55124 <blockquote>
55125 The nested typedef type shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt> where
55126 <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the
55127 value <tt>R1::den * R2::den</tt>.
55128 </blockquote>
55129
55130 </blockquote>
55131
55132 <p>
55133 Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer,
55134 and we have:
55135 </p>
55136
55137 <blockquote><pre>typedef std::ratio&lt;0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0&gt; R1;
55138 typedef std::ratio&lt;8, 7&gt; R2;
55139 typedef std::ratio_multiply&lt;R1, R2&gt;::type RT;
55140 </pre></blockquote>
55141
55142 <p>
55143 According to the present formulation the implementaiton will multiply
55144 <tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently
55145 require a diagnostic.
55146 </p>
55147
55148 <p>
55149 However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt>
55150 by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide
55151 <tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>,
55152 then the exact result can then be computed without overflow:
55153 </p>
55154
55155 <blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
55156 </pre></blockquote>
55157
55158 <p>
55159 Example implmentation which accomplishes this:
55160 </p>
55161
55162 <blockquote><pre>template &lt;class R1, class R2&gt;
55163 struct ratio_multiply
55164 {
55165 private:
55166     typedef ratio&lt;R1::num, R2::den&gt; _R3;
55167     typedef ratio&lt;R2::num, R1::den&gt; _R4;
55168 public:
55169     typedef ratio&lt;__ll_mul&lt;_R3::num, _R4::num&gt;::value,
55170                   __ll_mul&lt;_R3::den, _R4::den&gt;::value&gt; type;
55171 };
55172 </pre></blockquote>
55173
55174 <p><i>[
55175 Post Summit:
55176 ]</i></p>
55177
55178
55179 <blockquote>
55180 Recommend Tentatively Ready.
55181 </blockquote>
55182
55183
55184
55185
55186 <p><b>Proposed resolution:</b></p>
55187 <p>
55188 Add a paragraph prior to p1 in 20.6.2 [ratio.arithmetic]:
55189 </p>
55190
55191 <blockquote>
55192 Implementations may use other algorithms to compute the indicated ratios to avoid overflow. 
55193 If overflow occurs, a diagnostic shall be issued.
55194 </blockquote>
55195
55196
55197
55198
55199
55200 <hr>
55201 <h3><a name="949"></a>949. <tt>owner_less</tt></h3>
55202 <p><b>Section:</b> 20.9.10.3.7 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
55203  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30 <b>Last modified:</b> 2010-10-29</p>
55204 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
55205 <p><b>Discussion:</b></p>
55206 <p>
55207 20.9.10.3.7 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that 
55208 <tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>.
55209 </p>
55210 <p>
55211 However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a
55212 <tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>.
55213 </p>
55214 <p>
55215 Being that the class is named  <tt>owner_less</tt> , I'm guessing that
55216 "<tt>before()</tt>" should be "<tt>owner_before()</tt>", right?
55217 </p>
55218
55219 <p><i>[
55220 Herve adds:
55221 ]</i></p>
55222
55223
55224 <blockquote>
55225 Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>".
55226 </blockquote>
55227
55228 <p><i>[
55229 Post Summit:
55230 ]</i></p>
55231
55232
55233 <blockquote>
55234 Recommend Tentatively Ready.
55235 </blockquote>
55236
55237
55238
55239 <p><b>Proposed resolution:</b></p>
55240 <p>
55241 Change 20.9.10.3.7 [util.smartptr.ownerless] p2:
55242 </p>
55243
55244 <blockquote>
55245 -2- <tt>operator()(x,y)</tt> shall return
55246 <tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ...
55247 </blockquote>
55248
55249
55250
55251
55252
55253 <hr>
55254 <h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
55255 <p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
55256  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-19</p>
55257 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
55258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
55259 <p><b>Discussion:</b></p>
55260 <p>
55261 <tt>unique_ptr</tt>'s of array type should not convert to
55262 <tt>unique_ptr</tt>'s which do not have an array type.
55263 </p>
55264
55265 <blockquote><pre>struct Deleter
55266 {
55267    void operator()(void*) {}
55268 };
55269
55270 int main()
55271 {
55272    unique_ptr&lt;int[], Deleter&gt; s;
55273    unique_ptr&lt;int, Deleter&gt; s2(std::move(s));  <font color="#C80000">// should not compile</font>
55274 }
55275 </pre></blockquote>
55276
55277 <p><i>[
55278 Post Summit:
55279 ]</i></p>
55280
55281
55282 <blockquote>
55283 <p>
55284 Walter: Does the "diagnostic required" apply to both arms of the "and"?
55285 </p>
55286 <p>
55287 Tom Plum: suggest to break into several sentences
55288 </p>
55289 <p>
55290 Walter: suggest "comma" before the "and" in both places
55291 </p>
55292 <p>
55293 Recommend Review.
55294 </p>
55295 </blockquote>
55296
55297 <p><i>[
55298 Batavia (2009-05):
55299 ]</i></p>
55300
55301 <blockquote>
55302 The post-Summit comments have been applied to the proposed resolution.
55303 We now agree with the proposed resolution.
55304 Move to Tentatively Ready.
55305 </blockquote>
55306
55307 <p><i>[
55308 2009-07 Frankfurt
55309 ]</i></p>
55310
55311
55312 <blockquote>
55313 Moved from Tentatively Ready to Open only because the wording needs to be
55314 improved for enable_if type constraining, possibly following Robert's
55315 formula.
55316 </blockquote>
55317
55318 <p><i>[
55319 2009-08-01 Howard updates wording and sets to Review.
55320 ]</i></p>
55321
55322
55323 <p><i>[
55324 2009-10 Santa Cruz:
55325 ]</i></p>
55326
55327
55328 <blockquote>
55329 Move to Ready.
55330 </blockquote>
55331
55332 <p><i>[
55333 2010-02-27 Pete Opens:
55334 ]</i></p>
55335
55336
55337 <blockquote>
55338 <p>
55339 The proposed replacement text doesn't make sense.
55340 </p>
55341
55342 <blockquote>
55343 If <tt>D</tt> is a reference type, then <tt>E</tt> shall be the same type as
55344 <tt>D</tt>, else this constructor shall not participate in overload resolution.
55345 </blockquote>
55346
55347 <p>
55348 This imposes two requirements. 1. If <tt>D</tt> is a reference type, <tt>E</tt>
55349 has to be <tt>D</tt>. 2. If <tt>D</tt> is not a reference type, the constructor
55350 shall not participate in overload resolution. If the latter apples, the language
55351 in the preceding paragraph that this constructor shall not throw an exception if
55352 <tt>D</tt> is not a reference type is superfluous. I suspect that's not the
55353 intention, but I can't parse this text any other way.
55354 </p>
55355
55356 <blockquote>
55357 <tt>U</tt> shall not be an array type, else this constructor shall not
55358 participate in overload resolution.
55359 </blockquote>
55360
55361 <p>
55362 I don't know what this means.
55363 </p>
55364 </blockquote>
55365
55366 <p><i>[
55367 2010-02-27 Peter adds:
55368 ]</i></p>
55369
55370
55371 <blockquote>
55372 <p>
55373 I think that the intent is (proposed text):
55374 </p>
55375
55376 <blockquote>
55377 <p>
55378 <i>Remarks:</i> this constructor shall only participate in overload resolution
55379 if:
55380 </p>
55381
55382 <ul>
55383 <li>
55384 <tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to
55385 <tt>pointer</tt>,
55386 </li>
55387
55388 <li>
55389 <tt>U</tt> is not an array type, and
55390 </li>
55391
55392 <li>
55393 if <tt>D</tt> is a reference type, <tt>E</tt> is the same type as <tt>D</tt>.
55394 </li>
55395 </ul>
55396
55397 </blockquote>
55398
55399 </blockquote>
55400
55401 <p><i>[
55402 2010-02-28 Howard adds:
55403 ]</i></p>
55404
55405
55406 <blockquote>
55407 <p>
55408 I like Peter's proposal.  Here is a tweak of it made after looking at my
55409 implementation.  I believe this fixes a further defect not addressed by the
55410 current proposed wording:
55411 </p>
55412
55413 <blockquote>
55414 <p>
55415 <i>Remarks:</i> this constructor shall only participate in overload resolution
55416 if:
55417 </p>
55418
55419 <ul>
55420 <li>
55421 <tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to
55422 <tt>pointer</tt>, and
55423 </li>
55424
55425 <li>
55426 <tt>U</tt> is not an array type, and
55427 </li>
55428
55429 <li>
55430 if <tt>D</tt> is a reference type, <tt>E</tt> is the same type as <tt>D</tt>,
55431 else <tt>E</tt> shall be implicitly convertible to <tt>D</tt>.
55432 </li>
55433 </ul>
55434
55435 </blockquote>
55436
55437 </blockquote>
55438
55439 <p><i>[
55440 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
55441 ]</i></p>
55442
55443
55444
55445
55446 <p><b>Rationale:</b></p>
55447 <p>
55448 Solved by
55449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
55450 </p>
55451
55452
55453 <p><b>Proposed resolution:</b></p>
55454 <p>
55455 Change 20.9.9.2.1 [unique.ptr.single.ctor]:
55456 </p>
55457
55458 <blockquote>
55459 <pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
55460 </pre>
55461 <blockquote>
55462 <p>
55463 -20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
55464 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
55465 shall be well formed and shall not throw an exception. <del>If <tt>D</tt> is
55466 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
55467 (diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
55468 implicitly convertible to <tt>pointer</tt>. [<i>Note:</i> These requirements
55469 imply that <tt>T</tt> and <tt>U</tt> are complete types. \97 <i>end note</i>]</del>
55470 </p>
55471
55472 <p><ins>
55473 <i>Remarks:</i> If <tt>D</tt> is
55474 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>, else this
55475 constructor shall not participate in overload resolution. <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
55476 implicitly convertible to <tt>pointer</tt>, else this
55477 constructor shall not participate in overload resolution. <tt>U</tt> shall not be
55478 an array type, else this
55479 constructor shall not participate in overload resolution. [<i>Note:</i> These requirements
55480 imply that <tt>T</tt> and <tt>U</tt> are complete types. \97 <i>end note</i>]
55481 </ins></p>
55482
55483 </blockquote>
55484 </blockquote>
55485
55486 <p>
55487 Change 20.9.9.2.3 [unique.ptr.single.asgn]:
55488 </p>
55489
55490 <blockquote>
55491 <pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
55492 </pre>
55493 <blockquote>
55494 <p>
55495 -6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
55496 <tt>D</tt> shall not throw an exception. <del><tt>unique_ptr&lt;U,
55497 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
55498 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
55499 are complete types. \97 <i>end note</i>]</del>
55500 </p>
55501
55502 <p><ins>
55503 <i>Remarks:</i> <tt>unique_ptr&lt;U,
55504 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>, else this
55505 operator shall not participate in overload resolution.
55506 <tt>U</tt> shall not be an array type, else this
55507 operator shall not participate in overload resolution.
55508 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
55509 are complete types. \97 <i>end note</i>]
55510 </ins></p>
55511
55512 </blockquote>
55513 </blockquote>
55514
55515
55516
55517
55518
55519
55520 <hr>
55521 <h3><a name="951"></a>951. Various threading bugs #1</h3>
55522 <p><b>Section:</b> 20.11.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
55523  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-24</p>
55524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
55525 <p><b>Discussion:</b></p>
55526
55527 <p>
55528 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>.
55529 </p>
55530
55531 <p>
55532 20.11.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
55533 assumed to be ... a class emulating an integral type." What are the
55534 requirements for such a type?
55535 </p>
55536 <p><i>[
55537 2009-05-10 Howard adds:
55538 ]</i></p>
55539
55540
55541 <blockquote>
55542 <tt>IntegralLike</tt>.
55543 </blockquote>
55544
55545 <p><i>[
55546 Batavia (2009-05):
55547 ]</i></p>
55548
55549 <blockquote>
55550 <p>
55551 As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>,
55552 we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
55553 </p>
55554 <p>
55555 We look forward to proposed wording.
55556 </p>
55557 <p>
55558 Move to Open.
55559 </p>
55560 </blockquote>
55561
55562 <p><i>[
55563 2009-08-01 Howard adds:
55564 ]</i></p>
55565
55566
55567 <blockquote>
55568 <p>
55569 I have surveyed all clauses of 20.11.2.2 [time.traits.duration_values],
55570 20.11.2.3 [time.traits.specializations] and 20.11.3 [time.duration].
55571 I can not find any clause which involves the use of a <tt>duration::rep</tt> type
55572 where the requirements on the <tt>rep</tt> type are not clearly spelled out.
55573 These requirements were carefully crafted to allow any arithmetic type, or
55574 any user-defined type emulating an arithmetic type.
55575 </p>
55576
55577 <p>
55578 Indeed, <tt>treat_as_floating_point</tt>
55579 becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
55580 </p>
55581
55582 <p>
55583 There will be some <tt>Rep</tt> types which will not meet the requirements of
55584 <em>every</em> <tt>duration</tt> operation.  This is no different than the fact
55585 that <tt>vector&lt;T&gt;</tt> can easily be used for types <tt>T</tt> which are
55586 not <tt>DefaultConstructible</tt>, even though some members of <tt>vector&lt;T&gt;</tt>
55587 require <tt>T</tt> to be <tt>DefaultConstructible</tt>.  This is why the requirements
55588 on <tt>Rep</tt> are specified for each operation individually.
55589 </p>
55590
55591 <p>
55592 In 20.11.2.1 [time.traits.is_fp] p1:
55593 </p>
55594
55595 <blockquote><pre>template &lt;class Rep&gt; struct treat_as_floating_point 
55596   : is_floating_point&lt;Rep&gt; { };
55597 </pre>
55598
55599 <blockquote>
55600 The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait to help
55601 determine if a <tt>duration</tt> object can be converted to another <tt>duration</tt>
55602 with a different tick period. If <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is
55603 <tt>true</tt>, then <tt>Rep</tt> is a floating-point type and implicit conversions are
55604 allowed among <tt>duration</tt>s. Otherwise, the implicit convertibility depends
55605 on the tick periods of the <tt>duration</tt>s. If <tt>Rep</tt> is <u>a class type which
55606 emulates a floating-point type</u>, the author of <tt>Rep</tt> can specialize
55607 <tt>treat_as_floating_point</tt> so that <tt>duration</tt> will treat this <tt>Rep</tt> as if it
55608 were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an integral
55609 type or <u>a class emulating an integral type</u>.
55610 </blockquote>
55611 </blockquote>
55612
55613 <p>
55614 The phrases "a class type which emulates a floating-point type" and
55615 "a class emulating an integral type" are clarifying phrases which refer to
55616 the summation of all the requirements on the <tt>Rep</tt> type specified in
55617 detail elsewhere (and <em>should not</em> be repeated here).
55618 </p>
55619
55620 <p>
55621 This specification has been implemented, now multiple times, and the experience
55622 has been favorable.  The current specification clearly specifies the requirements
55623 at each point of use (though I'd be happy to fix any place I may have missed,
55624 but none has been pointed out).
55625 </p>
55626
55627 <p>
55628 I am amenable to improved wording of this paragraph (and any others), but do not have any
55629 suggestions for improved wording at this time.  I am <em>strongly</em> opposed to
55630 changes which would significantly alter the semantics of the
55631 specification under 20.11 [time] without firmly grounded and
55632 documented rationale, example implementation, testing, and user
55633 experience which relates a positive experience.
55634 </p>
55635
55636 <p>
55637 I recommend NAD unless someone wants to produce some clarifying wording.
55638 </p>
55639 </blockquote>
55640
55641 <p><i>[
55642 2009-10 Santa Cruz:
55643 ]</i></p>
55644
55645
55646 <blockquote>
55647 Stefanus to provide wording to turn this into a note.
55648 </blockquote>
55649
55650 <p><i>[
55651 2010-02-11 Stefanus provided wording.
55652 ]</i></p>
55653
55654
55655
55656 <p><i>[
55657 2010 Rapperswil:
55658 ]</i></p>
55659
55660
55661 <blockquote>
55662 Move to Ready.
55663 </blockquote>
55664
55665 <p><i>[
55666 Adopted at 2010-11 Batavia
55667 ]</i></p>
55668
55669
55670
55671
55672 <p><b>Proposed resolution:</b></p>
55673 <p>
55674 Change 20.11.2.1 [time.traits.is_fp]/1:
55675 </p>
55676
55677 <blockquote>
55678 1 The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait
55679 to help determine if a <tt>duration</tt> object can be converted to another
55680 <tt>duration</tt> with a different tick period. If
55681 <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>true</tt>, then
55682 <del><tt>Rep</tt> is a floating-point type and</del> implicit conversions are allowed among
55683 <tt>duration</tt>s. Otherwise, the implicit convertibility depends on the tick
55684 periods of the <tt>duration</tt>s. <del>If <tt>Rep</tt> is a class type which
55685 emulates a floating-point type, the author of <tt>Rep</tt> can specialize
55686 <tt>treat_as_floating_point</tt> so that duration will treat this <tt>Rep</tt>
55687 as if it were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an
55688 integral type or a class emulating an integral type.</del>
55689 <ins>[<i>Note:</i> The intention of this trait is to indicate whether a given
55690 class behaves like a floating point type, and thus allows division of one value
55691 by another with acceptable loss of precision. If
55692 <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>false</tt>,
55693 <tt>Rep</tt> will be treated as if it behaved like an integral type for the
55694 purpose of these conversions. \97 <i>end note</i>]</ins>
55695 </blockquote>
55696
55697
55698
55699
55700
55701
55702 <hr>
55703 <h3><a name="953"></a>953. Various threading bugs #3</h3>
55704 <p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
55705  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-20</p>
55706 <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>
55707 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
55708 <p><b>Discussion:</b></p>
55709
55710 <p>
55711 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
55712 </p>
55713
55714 <p>
55715 20.11.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
55716 arithmetic type or a class emulating an arithmetic type." What are the
55717 requirements for such a type?
55718 </p>
55719
55720 <p><i>[
55721 2009-05-10 Howard adds:
55722 ]</i></p>
55723
55724
55725 <blockquote>
55726 This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
55727 </blockquote>
55728
55729 <p><i>[
55730 Batavia (2009-05):
55731 ]</i></p>
55732
55733 <blockquote>
55734 <p>
55735 We recommend this issue be addressed in the context of providing concepts
55736 for the entire <tt>thread</tt> header.
55737 </p>
55738 <p>
55739 May resolve for now by specifying arithmetic types,
55740 and in future change to <tt>ArithmeticLike</tt>.
55741 However, Alisdair believes this is not feasible.
55742 </p>
55743 <p>
55744 Bill disagrees.
55745 </p>
55746 <p>
55747 We look forward to proposed wording.  Move to Open.
55748 </p>
55749 </blockquote>
55750
55751 <p><i>[
55752 2009-08-01 Howard adds:
55753 ]</i></p>
55754
55755
55756 <blockquote>
55757 See commented dated 2009-08-01 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
55758 </blockquote>
55759
55760 <p><i>[
55761 2009-10 Santa Cruz:
55762 ]</i></p>
55763
55764
55765 <blockquote>
55766 Stefanus to provide wording to turn this into a note.
55767 </blockquote>
55768
55769 <p><i>[
55770 2010-02-11 Stephanus provided wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a> which addresses
55771 this issue as well.
55772 ]</i></p>
55773
55774
55775
55776 <p><i>[
55777 2010 Rapperswil:
55778 ]</i></p>
55779
55780
55781 <blockquote>
55782 Move to <del>NAD Editorial</del><ins>Resolved</ins>, resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
55783 </blockquote>
55784
55785
55786
55787
55788 <p><b>Proposed resolution:</b></p>
55789 <p>
55790 </p>
55791
55792
55793
55794
55795
55796 <hr>
55797 <h3><a name="954"></a>954. Various threading bugs #4</h3>
55798 <p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
55799  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
55800 <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>
55801 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
55802 <p><b>Discussion:</b></p>
55803 <p>
55804 Table 55 -- Clock Requirements (in 20.11.1 [time.clock.req])
55805 </p>
55806
55807 <ol type="a">
55808 <li>
55809 the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
55810 to "refer to the same epoch", but "epoch" is not defined.
55811 </li>
55812 <li>
55813 "Different clocks may share a <tt>time_point</tt> definition if it is
55814 valid to compare their <tt>time_point</tt>s by comparing their
55815 respective <tt>duration</tt>s." What does "valid" mean here? And, since
55816 <tt>C1::rep</tt> is "**THE** representation type of the native
55817 <tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
55818 doesn't seem to be much room for some other representation.
55819 </li>
55820 <li>
55821 <tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
55822 "<tt>const</tt>" should be removed.
55823 </li>
55824 <li>
55825 <tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type, 
55826 it's a template. What is the required type?
55827 </li>
55828 </ol>
55829
55830 <p><i>[
55831 2009-05-10 Howard adds:
55832 ]</i></p>
55833
55834
55835 <ol type="a">
55836 <li>
55837 <p>
55838 "epoch" is purposefully not defined beyond the common English
55839 <a href="http://www.dictionary.net/epoch">definition</a>.  The C standard
55840 also chose not to define epoch, though POSIX did.  I believe it is a strength
55841 of the C standard that epoch is not defined.  When it is known that two <tt>time_point</tt>s
55842 refer to the same epoch, then a definition of the epoch is not needed to compare
55843 the two <tt>time_point</tt>s, or subtract them.
55844 </p>
55845 <p>
55846 A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
55847 The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
55848 </p>
55849 </li>
55850 <li>
55851 <p>
55852 The sentence:
55853 </p>
55854 <blockquote>
55855 Different clocks 
55856 may share a <tt>time_point</tt>
55857 definition if it is valid to 
55858 compare their <tt>time_point</tt>s by 
55859 comparing their respective 
55860 <tt>duration</tt>s.
55861 </blockquote>
55862
55863 <p>
55864 is redundant and could be removed.  I believe the sentence which follows the above:
55865 </p>
55866
55867 <blockquote>
55868 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
55869 </blockquote>
55870
55871 <p>
55872 is sufficient.  If two clocks share the same epoch, then by definition, comparing
55873 their <tt>time_point</tt>s is valid.
55874 </p>
55875 </li>
55876 <li>
55877 <tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>).  It is also
55878 desired that this value be usable in compile-time computation and branching.
55879 </li>
55880 <li>
55881 <p>
55882 This should probably instead be worded:
55883 </p>
55884 <blockquote>
55885 An instantiation of <tt>ratio</tt>.
55886 </blockquote>
55887 </li>
55888 </ol>
55889
55890 <p><i>[
55891 Batavia (2009-05):
55892 ]</i></p>
55893
55894 <blockquote>
55895 <p>
55896 Re (a): It is not clear to us whether "epoch" is a term of art.
55897 </p>
55898 <p>
55899 Re (b), (c), and (d):  We agree with Howard's comments,
55900 and would consider adding to (c) a <tt>static constexpr</tt> requirement.
55901 </p>
55902 <p>
55903 Move to Open pending proposed wording.
55904 </p>
55905 </blockquote>
55906
55907 <p><i>[
55908 2009-05-25 Daniel adds:
55909 ]</i></p>
55910
55911
55912 <blockquote>
55913 In regards to (d) I suggest to say "a specialization of ratio" instead of
55914 "An instantiation of ratio". This seems to be the better matching standard
55915 core language term for this kind of entity.
55916 </blockquote>
55917
55918 <p><i>[
55919 2009-05-25 Ganesh adds:
55920 ]</i></p>
55921
55922
55923 <blockquote>
55924 <p>
55925 Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
55926 </p>
55927
55928 <p>
55929 <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
55930 </p>
55931 <p>
55932 which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
55933 </p>
55934 </blockquote>
55935
55936 <p><i>[
55937 2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided.
55938 ]</i></p>
55939
55940
55941 <p><i>[
55942 2009-10 Santa Cruz:
55943 ]</i></p>
55944
55945
55946 <blockquote>
55947 Move to Ready.
55948 </blockquote>
55949
55950
55951
55952 <p><b>Proposed resolution:</b></p>
55953 <ol type="a">
55954 <li>
55955 <p>
55956 Change 20.11.1 [time.clock.req] p1:
55957 </p>
55958 <blockquote>
55959 -1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the 
55960 current <tt>time_point</tt>.  <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in 
55961 section 6.3 of ISO/IEC 18026.</ins>
55962 A clock shall meet the requirements in Table 45.
55963 </blockquote>
55964 </li>
55965 <li>
55966 <p>
55967 Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
55968 </p>
55969 <table border="1">
55970 <caption>Clock requirements</caption>
55971 <tbody><tr>
55972 <td>
55973 <tt>C1::time_point</tt>
55974 </td>
55975 <td>
55976 <tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration&gt;</tt>
55977 </td>
55978 <td>
55979 The native <tt>time_point</tt> type of the clock.
55980 <del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
55981 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
55982 </td>
55983 </tr>
55984 </tbody></table>
55985 </li>
55986 </ol>
55987 <ol type="a" start="4">
55988 <li>
55989 <p>
55990 Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
55991 </p>
55992 <table border="1">
55993 <caption>Clock requirements</caption>
55994 <tbody><tr>
55995 <td>
55996 <tt>C1::period</tt>
55997 </td>
55998 <td>
55999 <ins>a specialization of</ins> <tt>ratio</tt>
56000 </td>
56001 <td>
56002 The tick period of the clock in seconds.
56003 </td>
56004 </tr>
56005 </tbody></table>
56006
56007 </li>
56008 </ol>
56009
56010
56011
56012
56013
56014 <hr>
56015 <h3><a name="956"></a>956. Various threading bugs #6</h3>
56016 <p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56017  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-24</p>
56018 <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>
56019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56020 <p><b>Discussion:</b></p>
56021 <p>
56022 20.11.1 [time.clock.req] uses the word "native" in several places,
56023 but doesn't define it. What is a "native <tt>duration</tt>"?
56024 </p>
56025
56026 <p><i>[
56027 2009-05-10 Howard adds:
56028 ]</i></p>
56029
56030
56031 <blockquote>
56032 The standard uses "native" in several places without defining it (e.g.
56033 2.14.3 [lex.ccon]).  It is meant to mean "that which is defined
56034 by the facility", or something along those lines.  In this case it refers
56035 to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
56036 Better wording is welcome.
56037 </blockquote>
56038
56039 <p><i>[
56040 Batavia (2009-05):
56041 ]</i></p>
56042
56043 <blockquote>
56044 Move to Open pending proposed wording from Pete.
56045 </blockquote>
56046
56047 <p><i>[
56048 2009-10-23 Pete provides wording:
56049 ]</i></p>
56050
56051
56052 <p><i>[
56053 2009-11-18 Daniel adds:
56054 ]</i></p>
56055
56056
56057 <blockquote>
56058 <p>
56059 I see that 30.4.1.3 [thread.timedmutex.requirements]/3 says:
56060 </p>
56061
56062 <blockquote>
56063 <i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
56064 exactly convertible to the native tick <tt>period</tt>, the <tt>duration</tt>
56065 shall be rounded up to the nearest native tick <tt>period</tt>.
56066 </blockquote>
56067
56068 <p>
56069 I would prefer to see that adapted as well. Following the same style as
56070 the proposed resolution I come up with
56071 </p>
56072
56073 <blockquote>
56074 <i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
56075 exactly convertible to the <del>native</del> tick <tt>period</tt> <ins>of the
56076 execution environment</ins>, the <tt>duration</tt> shall be rounded up to the
56077 nearest <del>native</del> tick <tt>period</tt> <ins>of the execution
56078 environment</ins>.
56079 </blockquote>
56080
56081 </blockquote>
56082
56083 <p><i>[
56084 2010-03-28 Daniel synced wording with N3092
56085 ]</i></p>
56086
56087
56088 <p><i>[
56089 Post-Rapperswil, Howard provides wording:
56090 ]</i></p>
56091
56092
56093 <blockquote>
56094 Moved to Tentatively Ready with revised wording from Howard Hinnant after 5 positive votes on c++std-lib.
56095 </blockquote>
56096
56097 <p><i>[
56098 Adopted at 2010-11 Batavia
56099 ]</i></p>
56100
56101
56102
56103
56104 <p><b>Proposed resolution:</b></p>
56105
56106 <p>
56107 Change 20.11.1 [time.clock.req]:
56108 </p>
56109
56110 <blockquote>
56111 <p>
56112 1 A clock is a bundle consisting of a <del>native</del> <tt>duration</tt>, a
56113 <del>native</del> <tt>time_point</tt>, and a function <tt>now()</tt> to get the
56114 current <tt>time_point</tt>. The origin of the clock's <tt>time_point</tt> is
56115 referred to as the clock's <i>epoch</i>. A clock shall meet the requirements in
56116 Table 56.
56117 </p>
56118
56119 <p>
56120 2 ...
56121 </p>
56122
56123 <table border="1">
56124 <caption>Table 56 \97 Clock requirements</caption>
56125 <tbody><tr><th>Expression</th> <th>Return type</th> <th>Operational semantics</th></tr>
56126
56127 <tr>
56128 <td><tt>C1::rep</tt></td>
56129 <td>An arithmetic type or a class emulating an arithmetic type</td>
56130 <td>The representation type of <del>the native</del>
56131 <tt><ins>C1::</ins>duration</tt><ins>.</ins> <del>and
56132 <tt>time_point</tt>.</del></td>
56133 </tr>
56134
56135 <tr>
56136 <td><tt>C1::period</tt></td>
56137 <td align="center">...</td>
56138 <td align="center">...</td>
56139 </tr>
56140
56141 <tr>
56142 <td><tt>C1::duration</tt></td>
56143 <td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
56144 <td>The <del>native</del> <tt>duration</tt> type of the clock.</td>
56145 </tr>
56146
56147 <tr>
56148 <td><tt>C1::time_point</tt></td>
56149 <td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2,
56150 C1::duration&gt;</tt></td>
56151 <td>The <del>native</del> <tt>time_point</tt> type of the clock. <tt>C1</tt> and
56152 <tt>C2</tt> shall refer to the same epoch.</td>
56153 </tr>
56154
56155 <tr>
56156 <td colspan="3" align="center">...</td>
56157 </tr>
56158
56159 </tbody></table>
56160 </blockquote>
56161
56162
56163
56164
56165
56166
56167 <hr>
56168 <h3><a name="957"></a>957. Various threading bugs #7</h3>
56169 <p><b>Section:</b> 20.11.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56170  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56171 <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>
56172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56173 <p><b>Discussion:</b></p>
56174 <p>
56175 20.11.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
56176 requires truncation, but should allow rounding. For example, suppose a
56177 system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
56178 those times to the nearest second. Then <tt>system_clock</tt> can't use any
56179 resolution finer than one second, because if it did, truncating times
56180 between half a second and a full second would produce the wrong <tt>time_t</tt>
56181 value.
56182 </p>
56183
56184 <p><i>[
56185 Post Summit Anthony Williams provided proposed wording.
56186 ]</i></p>
56187
56188
56189 <p><i>[
56190 Batavia (2009-05):
56191 ]</i></p>
56192
56193 <blockquote>
56194 Move to Review pending input from Howard. and other stakeholders.
56195 </blockquote>
56196
56197 <p><i>[
56198 2009-05-23 Howard adds:
56199 ]</i></p>
56200
56201
56202 <blockquote>
56203 I am in favor of the wording provided by Anthony.
56204 </blockquote>
56205
56206 <p><i>[
56207 2009-10 Santa Cruz:
56208 ]</i></p>
56209
56210
56211 <blockquote>
56212 Move to Ready.
56213 </blockquote>
56214
56215
56216
56217 <p><b>Proposed resolution:</b></p>
56218 <p>
56219 In 20.11.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
56220 </p>
56221
56222 <blockquote>
56223 <pre>time_t to_time_t(const time_point&amp; t);
56224 </pre>
56225 <blockquote>
56226 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
56227 point in time as <tt>t</tt> when both values are <del>truncated</del>
56228 <ins>restricted</ins> to the coarser of the precisions of
56229 <tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
56230 defined whether values are rounded or truncated to the required
56231 precision.</ins>
56232 </blockquote>
56233
56234 <pre>time_point from_time_t(time_t t);
56235 </pre>
56236 <blockquote>
56237 -4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
56238 same point in time as <tt>t</tt> when both values are <del>truncated</del>
56239 <ins>restricted</ins> to the
56240 coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
56241 <ins>It is implementation defined whether values are
56242 rounded or truncated to the required precision.</ins>
56243 </blockquote>
56244 </blockquote>
56245
56246
56247
56248
56249
56250 <hr>
56251 <h3><a name="960"></a>960. Various threading bugs #10</h3>
56252 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56253  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56254 <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>
56255 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56256 <p><b>Discussion:</b></p>
56257 <p>
56258 30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
56259 "Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
56260 conditions:" specifies "the error conditions for error codes reported by
56261 the function." It's not clear what this should mean when there is no
56262 function in sight.
56263 </p>
56264
56265 <p><i>[
56266 Summit:
56267 ]</i></p>
56268
56269
56270 <blockquote>
56271 Move to open.
56272 </blockquote>
56273
56274 <p><i>[
56275 Beman provided proposed wording.
56276 ]</i></p>
56277
56278
56279 <p><i>[
56280 2009-10 Santa Cruz:
56281 ]</i></p>
56282
56283
56284 <blockquote>
56285 Move to Ready. Fix the proposed wording with "functions of type Mutex"
56286 -&gt; "functions of Mutex type"
56287 </blockquote>
56288
56289
56290
56291 <p><b>Proposed resolution:</b></p>
56292 <p>
56293 Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
56294 paragraph 4 as indicated:
56295 </p>
56296
56297 <blockquote>
56298 <p>
56299 -4- <del><i>Error conditions:</i></del>
56300 <ins>The error conditions for error codes, if any, reported by member
56301 functions of Mutex type shall be:</ins>
56302 </p>
56303 <ul>
56304 <li>
56305 <tt>not_enough_memory</tt> -- if there is not enough memory to construct
56306 the mutex object.
56307 </li>
56308 <li>
56309 <tt>resource_unavailable_try_again</tt> -- if any native handle type
56310 manipulated is not available.
56311 </li>
56312 <li>
56313 <tt>operation_not_permitted</tt> -- if the thread does not have the
56314 necessary permission to change the state of the mutex object.
56315 </li>
56316 <li>
56317 <tt>device_or_resource_busy</tt> -- if any native handle type
56318 manipulated is already locked.
56319 </li>
56320 <li>
56321 <tt>invalid_argument</tt> -- if any native handle type manipulated as
56322 part of mutex construction is incorrect.
56323 </li>
56324 </ul>
56325 </blockquote>
56326
56327
56328
56329
56330
56331 <hr>
56332 <h3><a name="962"></a>962. Various threading bugs #12</h3>
56333 <p><b>Section:</b> 30.4.2.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56334  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56335 <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>
56336 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56337 <p><b>Discussion:</b></p>
56338 <p>
56339 30.4.2.2.2 [thread.lock.unique.locking]:  <tt>unique_lock::lock</tt> is
56340 required to throw an object of type <tt>std::system_error</tt> "when the
56341 postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
56342 and this is trivial to achieve. Presumably, the requirement is intended
56343 to mean something more than that.
56344 </p>
56345
56346 <p><i>[
56347 Summit:
56348 ]</i></p>
56349
56350 <blockquote>
56351 Move to open.
56352 </blockquote>
56353
56354 <p><i>[
56355 Beman has volunteered to provide proposed wording.
56356 ]</i></p>
56357
56358
56359 <p><i>[
56360 2009-07-21 Beman added wording to address 30.2.2 [thread.req.exception]
56361 in response to the Frankfurt notes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>.
56362 ]</i></p>
56363
56364
56365 <p><i>[
56366 2009-09-25 Beman: minor update to wording.
56367 ]</i></p>
56368
56369
56370 <p><i>[
56371 2009-10 Santa Cruz:
56372 ]</i></p>
56373
56374
56375 <blockquote>
56376 Move to Ready.
56377 </blockquote>
56378
56379
56380
56381 <p><b>Proposed resolution:</b></p>
56382
56383 <p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
56384 <blockquote>
56385 <p>Some functions described in this Clause are specified to throw exceptions of 
56386 type <code>system_error</code> (19.5.5). Such exceptions shall be thrown if <ins>
56387 any of the <i>Error conditions</i> are detected or</ins> a call to an operating 
56388 system or other underlying API results in an error that prevents the library 
56389 function from <del>satisfying its postconditions or from returning a meaningful 
56390 value</del> <ins>meeting its specifications</ins>. <ins>Failure to
56391 allocate storage shall be reported as described in
56392 17.6.4.12 [res.on.exception.handling].</ins></p>
56393 </blockquote>
56394
56395 <p><i>Change thread assignment 30.3.1.5 [thread.thread.member], join(), 
56396 paragraph 8 as indicated:</i></p>
56397 <blockquote>
56398 <p><i>Throws:</i> <code>std::system_error</code> when <del>the postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56399
56400 </blockquote>
56401
56402 <p><i>Change thread assignment 30.3.1.5 [thread.thread.member], detach(), paragraph 
56403 13 as indicated:</i></p>
56404 <blockquote>
56405
56406 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56407 postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56408
56409 </blockquote>
56410
56411 <p><i>Change Mutex requirements 30.4.1 [thread.mutex.requirements], paragraph 
56412 11, as indicated:</i></p>
56413 <blockquote>
56414
56415 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56416 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56417 </blockquote>
56418 <p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
56419 paragraph 3, as indicated:</i></p>
56420 <blockquote>
56421
56422 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56423 </blockquote>
56424 <p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
56425 paragraph 8, as indicated:</i></p>
56426 <blockquote>
56427
56428 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56429 </blockquote>
56430 <p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
56431 paragraph 13, as indicated:</i></p>
56432 <blockquote>
56433
56434 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56435 </blockquote>
56436 <p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
56437 paragraph 18, as indicated:</i></p>
56438 <blockquote>
56439
56440 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56441 </blockquote>
56442 <p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
56443 paragraph 22, as indicated:</i></p>
56444 <blockquote>
56445
56446 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56447 </blockquote>
56448 <p><i>Change Function call_once 30.4.4.2 [thread.once.callonce], paragraph 4, as 
56449 indicated</i></p>
56450 <blockquote>
56451   <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>, 
56452   or any exception thrown by <code>func</code>.</p>
56453 </blockquote>
56454 <p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
56455 paragraph 12, as indicated:</i></p>
56456 <blockquote>
56457
56458 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56459 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56460 </blockquote>
56461 <p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
56462 paragraph 19, as indicated:</i></p>
56463 <blockquote>
56464
56465 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56466 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56467 </blockquote>
56468 <p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
56469 paragraph 10, as indicated:</i></p>
56470 <blockquote>
56471
56472 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56473 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56474 </blockquote>
56475 <p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
56476 paragraph 16, as indicated:</i></p>
56477 <blockquote>
56478
56479 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects, or 
56480 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56481 </blockquote>
56482
56483 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
56484 applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
56485 indicated:</i></p>
56486 <blockquote>
56487 <pre>template &lt;class Rep, class Period&gt; 
56488 bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
56489               const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
56490 <pre>...</pre>
56491
56492 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56493 postcondition cannot be achieved</del> <ins>an exception is required ([thread.req.exception])</ins>.</p>
56494 </blockquote>
56495
56496 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
56497 applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
56498 indicated:</i></p>
56499 <blockquote>
56500 <pre>template &lt;class Rep, class Period, class Predicate&gt; 
56501   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
56502                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
56503                 Predicate pred);</pre>
56504   <pre>...</pre>
56505
56506 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
56507 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56508 </blockquote>
56509
56510 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
56511 applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
56512 indicated:</i></p>
56513 <blockquote>
56514 <pre>template &lt;class Lock, class Rep, class Period&gt; 
56515   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
56516   <pre>...</pre>
56517
56518 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
56519 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56520 </blockquote>
56521
56522 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
56523 applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
56524 indicated:</i></p>
56525 <blockquote>
56526 <pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
56527   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);</pre>
56528   <pre>...</pre>
56529
56530 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
56531 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56532 </blockquote>
56533
56534
56535
56536
56537
56538
56539 <hr>
56540 <h3><a name="963"></a>963. Various threading bugs #13</h3>
56541 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56542  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56543 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
56544 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56545 <p><b>Discussion:</b></p>
56546 <p>
56547 30.3.1.5 [thread.thread.member]:  <tt>thread::detach</tt> is required to
56548 throw an exception if the thread is "not a detachable thread".
56549 "Detachable" is never defined.
56550 </p>
56551
56552 <p><i>[
56553 Howard adds:
56554 ]</i></p>
56555
56556
56557 <blockquote>
56558 Due to a mistake on my part, 3 proposed resolutions appeared at approximately
56559 the same time.  They are all three noted below in the discussion.
56560 </blockquote>
56561
56562 <p><i>[
56563 Summit, proposed resolution:
56564 ]</i></p>
56565
56566
56567 <blockquote>
56568 <p>
56569 In 30.3.1.5 [thread.thread.member] change:
56570 </p>
56571
56572 <blockquote><pre>void detach();
56573 </pre>
56574 <blockquote>
56575 <p>...</p>
56576 <p>-14- <i>Error conditions:</i></p>
56577 <ul>
56578 <li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
56579 <li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
56580 </ul>
56581 </blockquote>
56582
56583 </blockquote>
56584
56585 </blockquote>
56586
56587 <p><i>[
56588 Post Summit, Jonathan Wakely adds:
56589 ]</i></p>
56590
56591
56592 <blockquote>
56593 <p>
56594 A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
56595 we can just use that.
56596 </p>
56597 <p>
56598 This corresponds to the pthreads specification, where pthread_detach
56599 fails if the thread is not joinable:
56600 </p>
56601 <blockquote>
56602 EINVAL: The  implementation  has  detected  that  the value specified by
56603 thread does not refer to a joinable thread.
56604 </blockquote>
56605 <p>
56606 Jonathan recommends this proposed wording:
56607 </p>
56608 <blockquote>
56609 <p>
56610 In 30.3.1.5 [thread.thread.member] change:
56611 </p>
56612
56613 <blockquote><pre>void detach();
56614 </pre>
56615 <blockquote>
56616 <p>...</p>
56617 <p>-14- <i>Error conditions:</i></p>
56618 <ul>
56619 <li>...</li>
56620 <li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
56621 </ul>
56622 </blockquote>
56623
56624 </blockquote>
56625 </blockquote>
56626 </blockquote>
56627
56628 <p><i>[
56629 Post Summit, Anthony Williams adds:
56630 ]</i></p>
56631
56632
56633 <blockquote>
56634 <p>
56635 This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
56636 </p>
56637 <p>
56638 Anthony recommends this proposed wording:
56639 </p>
56640
56641 <blockquote>
56642 <p>
56643 In 30.3.1.5 [thread.thread.member] change:
56644 </p>
56645
56646 <blockquote><pre>void detach();
56647 </pre>
56648 <blockquote>
56649 <p>...</p>
56650 <p>-14- <i>Error conditions:</i></p>
56651 <ul>
56652 <li>...</li>
56653 <li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
56654 </ul>
56655 </blockquote>
56656
56657 </blockquote>
56658
56659 </blockquote>
56660
56661 </blockquote>
56662
56663 <p><i>[
56664 2009-10 Santa Cruz:
56665 ]</i></p>
56666
56667
56668 <blockquote>
56669 Mark as Ready with proposed resolution from Summit.
56670 </blockquote>
56671
56672
56673
56674 <p><b>Proposed resolution:</b></p>
56675
56676 <p>
56677 In 30.3.1.5 [thread.thread.member] change:
56678 </p>
56679
56680 <blockquote><pre>void detach();
56681 </pre>
56682 <blockquote>
56683 <p>...</p>
56684 <p>-14- <i>Error conditions:</i></p>
56685 <ul>
56686 <li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
56687 <li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
56688 </ul>
56689 </blockquote>
56690
56691 </blockquote>
56692
56693
56694
56695
56696
56697
56698 <hr>
56699 <h3><a name="965"></a>965. Various threading bugs #15</h3>
56700 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56701  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56702 <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>
56703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56704 <p><b>Discussion:</b></p>
56705 <p>
56706 30.5.1 [thread.condition.condvar]: the constructor for
56707 <tt>condition_variable</tt> throws an exception with error code
56708 <tt>device_or_resource_busy</tt> "if attempting to initialize a
56709 previously-initialized but as of yet undestroyed <tt>condition_variable</tt>."
56710 How can this occur?
56711 </p>
56712
56713 <p><i>[
56714 Summit:
56715 ]</i></p>
56716
56717 <blockquote>
56718 <p>
56719 Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt>
56720 error condition from the constructor of <tt>condition_variable</tt>.
56721 </p>
56722 <ul>
56723 <li>
56724 This is a POSIX error that cannot occur in this interface because the
56725 C++ interface does not separate declaration from initialization.
56726 </li>
56727 </ul>
56728 </blockquote>
56729
56730 <p><i>[
56731 Batavia (2009-05):
56732 ]</i></p>
56733
56734 <blockquote>
56735 We agree with the proposed resolution.
56736 Move to Tentatively Ready.
56737 </blockquote>
56738
56739
56740 <p><b>Proposed resolution:</b></p>
56741 <p>
56742 Change 30.5.1 [thread.condition.condvar] p3:
56743 </p>
56744
56745 <blockquote>
56746 <ul>
56747 <li>...</li>
56748 <li>
56749 <del><tt>device_or_resource_busy</tt> -- if attempting to initialize a
56750 previously-initialized but as of yet undestroyed
56751 <tt>condition_variable</tt>.</del>
56752 </li>
56753 </ul>
56754 </blockquote>
56755
56756
56757
56758
56759
56760 <hr>
56761 <h3><a name="967"></a>967. Various threading bugs #17</h3>
56762 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56763  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56764 <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>
56765 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56766 <p><b>Discussion:</b></p>
56767 <p>
56768 the error handling for the constructor for <tt>condition_variable</tt>
56769 distinguishes lack of memory from lack of other resources, but the error
56770 handling for the thread constructor does not. Is this difference
56771 intentional?
56772 </p>
56773
56774 <p><i>[
56775 Beman has volunteered to provide proposed wording.
56776 ]</i></p>
56777
56778
56779 <p><i>[
56780 2009-09-25 Beman provided proposed wording.
56781 ]</i></p>
56782
56783
56784 <blockquote>
56785 The proposed resolution assumes <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a> has been accepted and
56786 its proposed resolution applied to the working paper.
56787 </blockquote>
56788
56789 <p><i>[
56790 2009-10 Santa Cruz:
56791 ]</i></p>
56792
56793
56794 <blockquote>
56795 Move to Ready.
56796 </blockquote>
56797
56798
56799
56800 <p><b>Proposed resolution:</b></p>
56801
56802
56803 <p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
56804 paragraph 4, as indicated:</span></p>
56805 <blockquote>
56806
56807 <p><i>Error conditions:</i></p>
56808   <blockquote>
56809
56810 <ul>
56811 <li><del> <code>not_enough_memory</code> \97 if there is not enough memory to construct 
56812 the mutex object.</del></li>
56813
56814 <li><code>resource_unavailable_try_again</code> \97 if any native handle type 
56815 manipulated is not available.</li>
56816
56817 <li><code>operation_not_permitted</code> \97 if the thread does not have the 
56818 necessary permission to change the state of the mutex object.</li>
56819
56820 <li><code>device_or_resource_busy</code> \97 if any native handle type 
56821 manipulated is already locked.</li>
56822
56823 <li><code>invalid_argument</code> \97 if any native handle type manipulated as 
56824 part of mutex construction is incorrect.</li>
56825 </ul>
56826   </blockquote>
56827 </blockquote>
56828
56829 <p><span style="font-style: italic">Change Class condition_variable 30.5.1 [thread.condition.condvar], 
56830 default constructor, as indicated:</span></p>
56831 <blockquote>
56832   <p><code>condition_variable();</code></p>
56833   <blockquote>
56834     <p><i>Effects:</i> Constructs an object of type <code>condition_variable</code>.</p>
56835     <p><ins><i>Throws:</i> <code>std::system_error</code> when an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
56836     <p><i>Error conditions:</i></p>
56837     <blockquote>
56838     <ul>
56839       <li><del><code>not_enough_memory</code> \97 if a memory limitation prevents 
56840       initialization.</del></li>
56841       <li> <code>resource_unavailable_try_again</code> \97 if some non-memory 
56842       resource limitation prevents initialization.</li>
56843       <li> <code>device_or_resource_busy</code> \97 if attempting to initialize a 
56844       previously-initialized but as of yet undestroyed <code>condition_variable</code>.</li>
56845     </ul>
56846     </blockquote>
56847   </blockquote>
56848 </blockquote>
56849
56850
56851
56852
56853
56854 <hr>
56855 <h3><a name="968"></a>968. Various threading bugs #18</h3>
56856 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56857  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
56858 <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>
56859 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56860 <p><b>Discussion:</b></p>
56861 <p>
56862 30.4.1 [thread.mutex.requirements]: several functions are
56863 required to throw exceptions "if the thread does not have the necessary
56864 permission ...". "The necessary permission" is not defined.
56865 </p>
56866
56867 <p><i>[
56868 Summit:
56869 ]</i></p>
56870
56871 <blockquote>
56872 Move to open.
56873 </blockquote>
56874
56875
56876 <p><i>[
56877 Beman has volunteered to provide proposed wording.
56878 ]</i></p>
56879
56880
56881 <p><i>[
56882 2009-10 Santa Cruz:
56883 ]</i></p>
56884
56885
56886 <blockquote>
56887 Moved to Ready with minor word-smithing in the example.
56888 </blockquote>
56889
56890
56891
56892 <p><b>Proposed resolution:</b></p>
56893
56894
56895 <p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
56896 <blockquote>
56897 <p>Some functions described in this Clause are 
56898 specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions 
56899 shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API 
56900 results in an error that prevents the library function from meeting its specifications.
56901 <i>[Note:</i> See 17.6.4.12 [res.on.exception.handling] for exceptions thrown to report 
56902 storage allocation failures. <i>\97end 
56903 note]</i></p>
56904
56905 <p><ins><i>[Example:</i></ins></p>
56906
56907 <blockquote>
56908
56909 <p><ins>Consider a function in this clause that is specified to throw exceptions of type <code>
56910 system_error</code> and specifies <i>Error conditions</i> that include <code>
56911 operation_not_permitted</code> for a thread that does not have the privilege to 
56912 perform the operation. Assume that, during the execution of this function, an <code>errno</code> 
56913 of <code>EPERM</code> is reported by a POSIX API call used by the 
56914 implementation. Since POSIX specifies an <code>errno</code> of <code>EPERM</code> 
56915 when "the caller does not have the privilege to perform the operation", 
56916 the implementation maps <code>EPERM</code>&nbsp; to an <code>error_condition</code> 
56917 of <code>operation_not_permitted</code> (19.5 [syserr]) and an exception of type <code>
56918 system_error</code> is thrown. </ins></p>
56919
56920 </blockquote>
56921
56922 <p><ins><i>\97end example]</i></ins></p>
56923
56924 <p><span style="font-style: italic">Editorial note: For the sake of exposition, 
56925 the existing text above is shown with the changes proposed in issues 962 and 967. The 
56926 proposed additional example is independent of whether or not the 962 and 967 
56927 proposed resolutions are accepted.</span></p>
56928
56929 </blockquote>
56930
56931 <p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
56932 paragraph 4, as indicated:</span></p>
56933
56934 <blockquote>
56935
56936 <p>\97 <code>operation_not_permitted</code> \97 if the thread does not have the 
56937 <del>necessary permission to change the state of the mutex object</del> <ins>privilege to perform the operation</ins>.</p>
56938
56939 </blockquote>
56940
56941 <p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
56942 paragraph 12, as indicated:</span></p>
56943
56944 <blockquote>
56945
56946 <p>\97 <code>operation_not_permitted</code> \97 if the thread does not have the 
56947 <del>necessary permission to change the state of the mutex</del> <ins>privilege to perform the operation</ins>.</p>
56948
56949 </blockquote>
56950
56951
56952
56953
56954
56955
56956 <hr>
56957 <h3><a name="970"></a>970. addressof overload unneeded</h3>
56958 <p><b>Section:</b> 20.9.8.1 [specialized.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
56959  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16 <b>Last modified:</b> 2010-10-29</p>
56960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
56961 <p><b>Discussion:</b></p>
56962 <p>
56963 20.9.8.1 [specialized.addressof] specifies:
56964 </p>
56965
56966 <blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
56967 template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);
56968 </pre></blockquote>
56969
56970 <p>
56971 The two signatures are ambiguous when the argument is an lvalue.  The
56972 second signature seems not useful:  what does it mean to take the
56973 address of an rvalue?
56974 </p>
56975
56976 <p><i>[
56977 Post Summit:
56978 ]</i></p>
56979
56980
56981 <blockquote>
56982 Recommend Review.
56983 </blockquote>
56984
56985 <p><i>[
56986 Batavia (2009-05):
56987 ]</i></p>
56988
56989 <blockquote>
56990 We agree with the proposed resolution.
56991 Move to Tentatively Ready.
56992 </blockquote>
56993
56994 <p><i>[
56995 2009-11-18 Moved from Pending WP to WP.  Confirmed in
56996 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>.
56997 ]</i></p>
56998
56999
57000
57001 <p><b>Proposed resolution:</b></p>
57002 <p>
57003 Change 20.9.8.1 [specialized.addressof]:
57004 </p>
57005
57006 <blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
57007 <del>template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);</del>
57008 </pre></blockquote>
57009
57010
57011
57012
57013
57014
57015 <hr>
57016 <h3><a name="974"></a>974. <tt>duration&lt;double&gt;</tt> should not implicitly convert to <tt>duration&lt;int&gt;</tt></h3>
57017 <p><b>Section:</b> 20.11.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57018  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2010-10-29</p>
57019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57020 <p><b>Discussion:</b></p>
57021 <p>
57022 The following code should not compile because it involves implicit truncation
57023 errors (against the design philosophy of the <tt>duration</tt> library).
57024 </p>
57025
57026 <blockquote><pre>duration&lt;double&gt; d(3.5);
57027 duration&lt;int&gt; i = d;  <font color="#C80000">// implicit truncation, should not compile</font>
57028 </pre></blockquote>
57029
57030 <p>
57031 This intent was codified in the example implementation which drove this proposal
57032 but I failed to accurately translate the code into the specification in this
57033 regard.
57034 </p>
57035
57036 <p><i>[
57037 Batavia (2009-05):
57038 ]</i></p>
57039
57040 <blockquote>
57041 <p>
57042 We agree with the proposed resolution.
57043 </p>
57044 <p>
57045 Move to Tentatively Ready.
57046 </p>
57047 </blockquote>
57048
57049 <p><i>[
57050 2009-07 Frankfurt
57051 ]</i></p>
57052
57053
57054 <blockquote>
57055 Moved from Tentatively Ready to Open only because the wording needs to be
57056 improved for enable_if type constraining, possibly following Robert's
57057 formula.
57058 </blockquote>
57059
57060 <p><i>[
57061 2009-08-01 Howard adds:
57062 ]</i></p>
57063
57064
57065 <blockquote>
57066 Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.
57067 </blockquote>
57068
57069 <p><i>[
57070 2009-10 Santa Cruz:
57071 ]</i></p>
57072
57073
57074 <blockquote>
57075 Not completely addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.  Move to Ready.
57076 </blockquote>
57077
57078
57079
57080 <p><b>Proposed resolution:</b></p>
57081 <p>
57082 Change 20.11.3.1 [time.duration.cons], p4:
57083 </p>
57084
57085 <blockquote>
57086 <pre>template &lt;class Rep2, class Period2&gt; 
57087   duration(const duration&lt;Rep2, Period2&gt;&amp; d);
57088 </pre>
57089 <blockquote>
57090 -4- <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt>
57091 shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide&lt;Period2,
57092 period&gt;::type::den</tt> shall be 1
57093 <ins>and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt>
57094 shall be <tt>false</tt></ins>.
57095 Diagnostic required.
57096 [<i>Note:</i> This requirement prevents implicit truncation error when
57097 converting between integral-based <tt>duration</tt> types. Such a
57098 construction could easily lead to confusion about the value of the
57099 <tt>duration</tt>. -- <i>end note</i>]
57100 </blockquote>
57101 </blockquote>
57102
57103
57104
57105
57106
57107 <hr>
57108 <h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for  non-convertible types</h3>
57109 <p><b>Section:</b> 20.7.6 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57110  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-01-25 <b>Last modified:</b> 2010-10-29</p>
57111 <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>
57112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57113 <p><b>Discussion:</b></p>
57114
57115 <b>Addresses UK 206</b>
57116
57117 <p>
57118 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.
57119 </p>
57120
57121 <p>
57122 The current specification of <tt>std::is_convertible</tt> (reference is draft
57123 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
57124 is basically defined by 20.7.6 [meta.rel]/4:
57125 </p>
57126
57127 <blockquote>
57128 <p>
57129 In order to instantiate the template <tt>is_convertible&lt;From,
57130 To&gt;</tt>, the following code shall be well formed:
57131 </p>
57132
57133 <blockquote><pre>template &lt;class T&gt;
57134   typename add_rvalue_reference&lt;T&gt;::type create();
57135
57136 To test() {
57137   return create&lt;From&gt;();
57138 }
57139 </pre></blockquote>
57140
57141 <p>
57142 [<i>Note:</i> This requirement gives well defined results for reference
57143 types, void types, array types, and function types. --<i>end note</i>]
57144 </p>
57145 </blockquote>
57146
57147 <p>
57148 The first sentence can be interpreted, that e.g. the expression
57149 </p>
57150
57151 <blockquote><pre>std::is_convertible&lt;double, int*&gt;::value
57152 </pre></blockquote>
57153
57154 <p>
57155 is ill-formed because <tt>std::is_convertible&lt;double, int*&gt;</tt> could not be
57156 instantiated, or in more general terms: The wording requires that
57157 <tt>std::is_convertible&lt;X, Y&gt;</tt> cannot be instantiated for otherwise valid
57158 argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>.
57159 </p>
57160
57161 <p>
57162 This semantic is both unpractical and in contradiction to what the last type
57163 traits paper
57164 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a>
57165 proposed:
57166 </p>
57167
57168 <blockquote>
57169 <p>
57170 If the following <tt>test</tt> function is well formed code <tt>b</tt>
57171 is <tt>true</tt>, else it is <tt>false</tt>.
57172 </p>
57173
57174 <blockquote><pre>template &lt;class T&gt;
57175   typename add_rvalue_reference&lt;T&gt;::type create();
57176
57177 To test() {
57178   return create&lt;From&gt;();
57179 }
57180 </pre></blockquote>
57181
57182 <p>
57183 [<i>Note:</i> This definition gives well defined results for <tt>reference</tt>
57184 types, <tt>void</tt> types, array types, and function types. --<i>end note</i>]
57185 </p>
57186 </blockquote>
57187
57188 <p><i>[
57189 Post Summit:
57190 ]</i></p>
57191
57192
57193 <blockquote>
57194 <p>
57195 Jens: Checking that code is well-formed and then returning true/false
57196 sounds like speculative compilation. John Spicer would really dislike
57197 this. Please find another wording suggesting speculative compilation.
57198 </p>
57199 <p>
57200 Recommend Open.
57201 </p>
57202 </blockquote>
57203
57204 <p><i>[
57205 Post Summit, Howard adds:
57206 ]</i></p>
57207
57208
57209 <blockquote>
57210 <p>
57211 John finds the following wording clearer:
57212 </p>
57213 <blockquote>
57214
57215 <table border="1">
57216 <tbody><tr>
57217 <th>Template</th><th>Condition</th><th>Comments</th>
57218 </tr>
57219 <tr>
57220 <td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
57221 <td><i>see below</i></td>
57222 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
57223 or (possibly cv-qualified) <tt>void</tt> types.</td>
57224 </tr>
57225 </tbody></table>
57226
57227 <p>
57228 Given the following function prototype:
57229 </p>
57230
57231 <blockquote><pre>template &lt;class T&gt;
57232   typename add_rvalue_reference&lt;T&gt;::type create();
57233 </pre></blockquote>
57234
57235 <p>
57236 <tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>true</tt> if the
57237 return expression in the following code would be well-formed, including
57238 any implicit conversions to the return type of the function, else
57239 <tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>false</tt>.
57240 </p>
57241
57242 <blockquote><pre>To test() {
57243   return create&lt;From&gt;();
57244 }
57245 </pre></blockquote>
57246
57247 </blockquote>
57248
57249 </blockquote>
57250
57251 <b>Original proposed wording:</b>
57252
57253 <p>
57254 In 20.7.6 [meta.rel]/4 change:
57255 </p>
57256
57257 <blockquote>
57258 <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
57259 following code shall be well formed</del> <ins>If the following code
57260 is well formed <tt>is_convertible&lt;From, To&gt;::value</tt> is <tt>true</tt>, otherwise
57261 <tt>false</tt></ins>:[..]
57262 </blockquote>
57263
57264 <p><b>Revision 2</b></p>
57265
57266 <blockquote>
57267
57268 <p>
57269 In 20.7.6 [meta.rel] change:
57270 </p>
57271
57272 <blockquote>
57273
57274 <table border="1">
57275 <tbody><tr>
57276 <th>Template</th><th>Condition</th><th>Comments</th>
57277 </tr>
57278 <tr>
57279 </tr><tr><td>...</td><td>...</td><td>...</td></tr>
57280 <tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
57281 <td>
57282 <del>The code set out below shall be well formed.</del>
57283 <ins><i>see below</i></ins></td>
57284 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
57285 or (possibly cv-qualified) <tt>void</tt> types.</td>
57286 </tr>
57287 </tbody></table>
57288
57289 <p>
57290 -4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
57291 following code shall be well formed:</del>
57292 <ins>Given the following function prototype:</ins>
57293 </p>
57294
57295 <blockquote><pre>template &lt;class T&gt; 
57296   typename add_rvalue_reference&lt;T&gt;::type create();
57297 </pre></blockquote>
57298
57299 <p>
57300 <ins><tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
57301 indirectly from <tt>true_type</tt> if the
57302 return expression in the following code would be well-formed, including
57303 any implicit conversions to the return type of the function, else
57304 <tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
57305 indirectly from <tt>false_type</tt>.</ins>
57306 </p>
57307
57308 <blockquote><pre>To test() { 
57309   return create&lt;From&gt;(); 
57310 }
57311 </pre></blockquote>
57312
57313 <p>
57314 [<i>Note:</i> This requirement gives well defined results for reference types,
57315 void types, array types, and function types. <i>-- end note</i>]
57316 </p>
57317
57318 </blockquote>
57319 </blockquote>
57320
57321 <p><i>[
57322 Batavia (2009-05):
57323 ]</i></p>
57324
57325 <blockquote>
57326 We agree with the proposed resolution.
57327 Move to Tentatively Ready.
57328 </blockquote>
57329
57330
57331 <p><b>Proposed resolution:</b></p>
57332
57333 <p>
57334 In 20.7.6 [meta.rel] change:
57335 </p>
57336
57337 <blockquote>
57338
57339 <table border="1">
57340 <tbody><tr>
57341 <th>Template</th><th>Condition</th><th>Comments</th>
57342 </tr>
57343 <tr>
57344 </tr><tr><td>...</td><td>...</td><td>...</td></tr>
57345 <tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
57346 <td>
57347 <del>The code set out below shall be well formed.</del>
57348 <ins><i>see below</i></ins></td>
57349 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
57350 or (possibly cv-qualified) <tt>void</tt> types.</td>
57351 </tr>
57352 </tbody></table>
57353
57354 <p>
57355 -4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
57356 following code shall be well formed:</del>
57357 <ins>Given the following function prototype:</ins>
57358 </p>
57359
57360 <blockquote><pre>template &lt;class T&gt; 
57361   typename add_rvalue_reference&lt;T&gt;::type create();
57362 </pre></blockquote>
57363
57364 <p>
57365 <ins>the predicate condition for a template specialization
57366 <tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied, if and only
57367 if the return expression in the following code would be well-formed,
57368 including any implicit conversions to the return type of the
57369 function.</ins>
57370 </p>
57371
57372 <blockquote><pre>To test() { 
57373   return create&lt;From&gt;(); 
57374 }
57375 </pre></blockquote>
57376
57377 <p>
57378 [<i>Note:</i> This requirement gives well defined results for reference types,
57379 void types, array types, and function types. <i>\97 end note</i>]
57380 </p>
57381
57382 </blockquote>
57383
57384
57385
57386
57387
57388 <hr>
57389 <h3><a name="978"></a>978. Hashing smart pointers</h3>
57390 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57391  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2010-10-29</p>
57392 <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>
57393 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57394 <p><b>Discussion:</b></p>
57395 <p><b>Addresses UK 208</b></p>
57396 <p>
57397 I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
57398 (<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
57399 </p>
57400 <p>
57401 It seems reasonable to at least expect support for the smart
57402 pointers, especially as they support comparison for use in ordered
57403 associative containers.
57404 </p>
57405
57406 <p><i>[
57407 Batavia (2009-05):
57408 ]</i></p>
57409
57410 <blockquote>
57411 <p>
57412 Howard points out that the client can always supply a custom hash function.
57413 </p>
57414 <p>
57415 Alisdair replies that the smart pointer classes are highly likely
57416 to be frequently used as hash keys.
57417 </p>
57418 <p>
57419 Bill would prefer to be conservative.
57420 </p>
57421 <p>
57422 Alisdair mentions that this issue may also be viewed as a subissue or
57423 duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
57424 </p>
57425 <p>
57426 Move to Open, and recommend the issue be deferred until after the next
57427 Committee Draft is issued.
57428 </p>
57429 </blockquote>
57430
57431 <p><i>[
57432 2009-05-31 Peter adds:
57433 ]</i></p>
57434
57435
57436 <blockquote>
57437 <blockquote>
57438 Howard points out that the client can always supply a custom hash function.
57439 </blockquote>
57440 <p>
57441 Not entirely true. The client cannot supply the function that hashes the
57442 address of the control block (the equivalent of the old <tt>operator&lt;</tt>, now
57443 proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
57444 implementation can do that, not necessarily via specializing <tt>hash&lt;&gt;</tt>, of
57445 course.
57446 </p>
57447 <p>
57448 This hash function makes sense in certain situations for <tt>shared_ptr</tt>
57449 (when one needs to switch from <tt>set/map</tt> using ownership ordering to
57450 <tt>unordered_set/map</tt>) and is the only hash function that makes sense for
57451 <tt>weak_ptr</tt>.
57452 </p>
57453 </blockquote>
57454
57455 <p><i>[
57456 2009-07-28 Alisdair provides wording.
57457 ]</i></p>
57458
57459
57460 <p><i>[
57461 2009-10 Santa Cruz:
57462 ]</i></p>
57463
57464
57465 <blockquote>
57466 Move to Ready.
57467 </blockquote>
57468
57469 <p><i>[
57470 2009-11-16 Moved from Ready to Open:
57471 ]</i></p>
57472
57473
57474 <blockquote>
57475 <p>
57476 Pete writes:
57477 </p>
57478 <blockquote>
57479 <p>
57480 As far as I can see, "...suitable for using this type as key in unordered
57481 associative containers..." doesn't define any semantics. It's advice to the
57482 reader, and if it's present at all it should be in a note. But we have far too
57483 much of this sort of editorial commentary as it is.
57484 </p>
57485 <p>
57486 And in the resolution of 978 it's clearly wrong: it says that if there is no
57487 hash specialization available for <tt>D::pointer</tt>, the implementation may provide
57488 <tt>hash&lt;unique_ptr&lt;T,D&gt;&gt;</tt> if the result is not suitable for use in unordered
57489 containers.
57490 </p>
57491 </blockquote>
57492
57493 <p>
57494 Howard writes:
57495 </p>
57496
57497 <blockquote>
57498 Is this a request to pull 978 from Ready?
57499 </blockquote>
57500
57501 <p>
57502 Barry writes:
57503 </p>
57504 <blockquote>
57505 <p>
57506 I read this as more than a request. The PE says it's wrong, so it can't be
57507 Ready.
57508 </p>
57509 </blockquote>
57510
57511 </blockquote>
57512
57513 <p><i>[
57514 2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
57515 ]</i></p>
57516
57517
57518 <p><i>[
57519 2010-02-08 Beman updates wording.
57520 ]</i></p>
57521
57522
57523 <p><i>[
57524 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
57525 ]</i></p>
57526
57527
57528
57529
57530 <p><b>Proposed resolution:</b></p>
57531
57532 <p><i>Add the following declarations to the synopsis of <tt>&lt;memory&gt;</tt> in 
57533 20.9 [memory] </i></p>
57534
57535 <blockquote>
57536 <pre><ins>// [util.smartptr.hash] hash support
57537 template &lt;class T&gt; struct hash;
57538 template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
57539 template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;</ins></pre>
57540 </blockquote>
57541
57542 <p><i>Add a new subclause under 20.9.10 [util.smartptr] called hash support </i></p>
57543
57544 <blockquote>
57545 <h3><ins>hash support [util.smartptr.hash]</ins></h3>
57546
57547 <pre><ins>template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;</ins></pre>
57548
57549 <blockquote>
57550 <p><ins>
57551 Specialization meeting the requirements of class template <tt>hash</tt> (20.8.15 [unord.hash]). For an object <tt>p</tt> of type <tt>UP</tt>, where
57552 <tt>UP</tt> is a type <tt>unique_ptr&lt;T,D&gt;</tt>,
57553 <tt>hash&lt;UP&gt;()(p)</tt> shall evaluate to the same value as
57554 <tt>hash&lt;typename UP::pointer&gt;()(p.get())</tt>. The specialization
57555 <tt>hash&lt;typename UP::pointer&gt;</tt> is required to be well-formed.
57556 </ins></p>
57557 </blockquote>
57558
57559 <pre><ins>template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;</ins></pre>
57560
57561 <blockquote>
57562 <p><ins>
57563 Specialization meeting the requirements of class template <tt>hash</tt> (20.8.15 [unord.hash]). For an object <tt>p</tt> of type
57564 <tt>shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;shared_ptr&lt;T&gt;&gt;()(p)</tt>
57565 shall evaluate to the same value as <tt> hash&lt;T*&gt;()(p.get())</tt>.
57566 </ins></p>
57567 </blockquote>
57568 </blockquote>
57569
57570
57571
57572
57573
57574
57575 <hr>
57576 <h3><a name="981"></a>981. Unordered container requirements should add  <tt>initializer_list</tt> support</h3>
57577 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57578  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2010-10-29</p>
57579 <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>
57580 <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>
57581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57582 <p><b>Discussion:</b></p>
57583 <p>
57584 Refering to
57585 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
57586 all container requirements tables (including those for
57587 associative containers) provide useful member function overloads
57588 accepting <tt>std::initializer_list</tt> as argument, the only exception is
57589 Table 87. There seems to be no reason for not providing them, because 23.7 [unord]
57590 is already <tt>initializer_list</tt>-aware. For the sake of 
57591 library interface consistency and user-expectations corresponding 
57592 overloads should be added to the table requirements of unordered 
57593 containers as well.
57594 </p>
57595
57596 <p><i>[
57597 Batavia (2009-05):
57598 ]</i></p>
57599
57600 <blockquote>
57601 <p>
57602 We agree with the proposed resolution.
57603 </p>
57604 <p>
57605 Move to Tentatively Ready.
57606 </p>
57607 </blockquote>
57608
57609
57610 <p><b>Proposed resolution:</b></p>
57611
57612 <p>
57613 In 23.2.5 [unord.req]/9 insert:
57614 </p>
57615
57616 <blockquote>
57617 ... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt>
57618 designates an object of type <tt>initializer_list&lt;value_type&gt;</tt>, </ins><tt>t</tt> is a value of type
57619 <tt>X::value_type</tt>, ...
57620 </blockquote>
57621
57622 <p>
57623 In 23.2.5 [unord.req], Table 87 insert:
57624 </p>
57625
57626 <blockquote>
57627 <table border="1">
57628 <caption>Table 87 - Unordered associative container requirements (in addition to container)</caption>
57629 <tbody><tr>
57630 <th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
57631 </tr>
57632 <tr>
57633 <td><tt>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
57634 </tr>
57635 <tr>
57636 <td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td> 
57637 <td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td> 
57638 <td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
57639 </tr>
57640 <tr>
57641 <td>...</td> <td>...</td> <td>...</td> <td>...</td>
57642 </tr>
57643 <tr>
57644 <td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
57645 </tr>
57646 <tr>
57647 <td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&amp;</tt></ins></td> 
57648 <td><ins><tt>a = X(il); return *this;</tt></ins></td> 
57649 <td><ins>Same as <tt>a = X(il)</tt>.</ins></td>
57650 </tr>
57651 <tr>
57652 <td>...</td> <td>...</td> <td>...</td> <td>...</td>
57653 </tr>
57654 <tr>
57655 <td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td>
57656 </tr>
57657 <tr>
57658 <td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td> 
57659 <td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td> 
57660 <td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
57661 </tr>
57662 </tbody></table>
57663 </blockquote>
57664
57665
57666
57667
57668
57669
57670 <hr>
57671 <h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in  Table 85</h3>
57672 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57673  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2010-10-29</p>
57674 <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>
57675 <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>
57676 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57677 <p><b>Discussion:</b></p>
57678 <p>
57679 According to
57680 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
57681 the associative container requirements table 85 says
57682     that assigning an <tt>initializer_list</tt> to such a container is of
57683     constant complexity, which is obviously wrong.
57684 </p>
57685
57686 <p><i>[
57687 Batavia (2009-05):
57688 ]</i></p>
57689
57690 <blockquote>
57691 <p>
57692 We agree with the proposed resolution.
57693 </p>
57694 <p>
57695 Move to Tentatively Ready.
57696 </p>
57697 </blockquote>
57698
57699
57700 <p><b>Proposed resolution:</b></p>
57701
57702 <p>
57703 In 23.2.4 [associative.reqmts], Table 85 change:
57704 </p>
57705
57706 <blockquote>
57707 <table border="1">
57708 <caption>Table 85 - Associative container requirements (in addition to container)</caption>
57709 <tbody><tr>
57710 <th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
57711 </tr>
57712 <tr>
57713 <td><tt>a = il</tt></td> <td><tt>X&amp;</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td> 
57714 <td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td>
57715 </tr>
57716 </tbody></table>
57717 </blockquote>
57718
57719
57720
57721
57722
57723
57724 <hr>
57725 <h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
57726 <p><b>Section:</b> 20.9.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
57727  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10 <b>Last modified:</b> 2010-11-19</p>
57728 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
57729 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
57730 <p><b>Discussion:</b></p>
57731 <p>
57732 Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
57733 type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
57734 the reference is an rvalue, could have surprising results:
57735 </p>
57736
57737 <blockquote><pre>D d(some-state);
57738 unique_ptr&lt;A, D&amp;&gt; p(new A, d);
57739 unique_ptr&lt;A, D&gt; p2 = std::move(p);
57740 <font color="#C80000">// has d's state changed here?</font>
57741 </pre></blockquote>
57742
57743 <p>
57744 I agree with him.  It is the <tt>unique_ptr</tt> that is the rvalue, not the
57745 deleter.  When the deleter is a reference type, the <tt>unique_ptr</tt> should
57746 respect the "lvalueness" of the deleter.
57747 </p>
57748
57749 <p>
57750 Thanks Dave.
57751 </p>
57752
57753 <p><i>[
57754 Batavia (2009-05):
57755 ]</i></p>
57756
57757 <blockquote>
57758 Seems correct, but complicated enough that we recommend moving to Review.
57759 </blockquote>
57760
57761 <p><i>[
57762 2009-10 Santa Cruz:
57763 ]</i></p>
57764
57765
57766 <blockquote>
57767 Move to Ready.
57768 </blockquote>
57769
57770 <p><i>[
57771 2010-03-14 Howard adds:
57772 ]</i></p>
57773
57774
57775 <blockquote>
57776 We moved
57777 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
57778 to the formal motions page in Pittsburgh which should obsolete this issue.  I've
57779 moved this issue to NAD Editorial, solved by N3073.
57780 </blockquote>
57781
57782
57783
57784 <p><b>Rationale:</b></p>
57785 <p>
57786 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
57787 </p>
57788
57789
57790 <p><b>Proposed resolution:</b></p>
57791 <p>
57792 Change 20.9.9.2.1 [unique.ptr.single.ctor], p20-21
57793 </p>
57794
57795 <blockquote>
57796 <pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
57797 </pre>
57798
57799 <blockquote>
57800
57801 <p>
57802 -20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
57803 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
57804 shall be well formed and shall not throw an exception.
57805 <ins>
57806 Otherwise <tt>E</tt> is a reference type and construction of the deleter
57807 <tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
57808 shall not throw an exception.
57809 </ins>
57810 If <tt>D</tt> is
57811 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
57812 (diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
57813 implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
57814 requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
57815 <i>-- end note</i>]
57816 </p>
57817
57818 <p>
57819 -21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
57820 pointer which <tt>u</tt> owns (if any). If the deleter
57821 <ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
57822 deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
57823 <del>the reference</del> <ins>this deleter</ins> is copy constructed
57824 from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
57825 owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
57826 with <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;</tt>. <i>-- end
57827 note</i>]
57828 </p>
57829
57830 </blockquote>
57831 </blockquote>
57832
57833 <p>
57834 Change 20.9.9.2.3 [unique.ptr.single.asgn], p1-3
57835 </p>
57836
57837 <blockquote>
57838 <pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
57839 </pre>
57840 <blockquote>
57841
57842 <p>
57843 -1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
57844 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
57845 <ins>
57846 Otherwise the deleter <tt>D</tt> is a reference type,
57847 and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
57848 </p>
57849
57850 <p>
57851 -2- <i>Effects:</i> reset(u.release()) followed by
57852 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
57853 <ins><tt>std::forward&lt;D&gt;(u.get_deleter())</tt></ins>.
57854 </p>
57855
57856 <p>
57857 -3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
57858 which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
57859 <tt>D</tt> is a reference type, then the referenced lvalue deleters are
57860 move assigned. <i>-- end note</i>]</del>
57861 </p>
57862 </blockquote>
57863 </blockquote>
57864
57865 <p>
57866 Change 20.9.9.2.3 [unique.ptr.single.asgn], p6-7
57867 </p>
57868
57869 <blockquote>
57870 <pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
57871 </pre>
57872 <blockquote>
57873
57874 <p>
57875 <i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
57876 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
57877 <tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
57878 <ins>
57879 Otherwise the deleter <tt>E</tt> is a reference type,
57880 and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
57881 <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
57882 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U&gt;</tt>
57883 are complete types. <i>-- end note</i>]
57884 </p>
57885
57886 <p>
57887 <i>Effects:</i> <tt>reset(u.release())</tt> followed by
57888 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
57889 <ins><tt>std::forward&lt;E&gt;(u.get_deleter())</tt></ins>.
57890 <del>If either
57891 <tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
57892 deleter participates in the move assignment.</del>
57893 </p>
57894
57895 </blockquote>
57896 </blockquote>
57897
57898
57899
57900
57901
57902
57903 <hr>
57904 <h3><a name="984"></a>984. Does <tt>&lt;cinttypes&gt;</tt> have macro guards?</h3>
57905 <p><b>Section:</b> 27.9.2 [c.files] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57906  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2010-10-29</p>
57907 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57908 <p><b>Discussion:</b></p>
57909 <p>
57910 The C standard says about <tt>&lt;inttypes.h&gt;</tt>:
57911 </p>
57912
57913 <blockquote>
57914 C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined 
57915 before <tt>&lt;inttypes.h&gt;</tt> is included.
57916 </blockquote>
57917
57918 <p>
57919 The C standard has a similar note about <tt>&lt;stdint.h&gt;</tt>.  For <tt>&lt;cstdint&gt;</tt>
57920 we adopted a "thanks but no thanks" policy and documented that fact in
57921 18.4.1 [cstdint.syn]:
57922 </p>
57923
57924 <blockquote>
57925 ... [<i>Note:</i> The macros defined by <tt>&lt;stdint&gt;</tt> are
57926 provided unconditionally. In particular, the symbols
57927 <tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt>
57928 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
57929 <i>-- end note</i>]
57930 </blockquote>
57931
57932 <p>
57933 I recommend we put a similar note in 27.9.2 [c.files] regarding <tt>&lt;cinttypes&gt;</tt>.
57934 </p>
57935
57936 <p><i>[
57937 Batavia (2009-05):
57938 ]</i></p>
57939
57940 <blockquote>
57941 We agree with the proposed resolution.
57942 Move to Tentatively Ready.
57943 </blockquote>
57944
57945
57946 <p><b>Proposed resolution:</b></p>
57947 <p>
57948 Add to 27.9.2 [c.files]:
57949 </p>
57950
57951 <blockquote>
57952 Table 112 describes header <tt>&lt;cinttypes&gt;</tt>.
57953 <ins>
57954 [<i>Note:</i> The macros defined by <tt>&lt;cintypes&gt;</tt> are
57955 provided unconditionally. In particular, the symbol
57956 <tt>__STDC_FORMAT_MACROS</tt>
57957 (mentioned in C99 footnote 182) plays no role in C++.
57958 <i>-- end note</i>]
57959 </ins>
57960 </blockquote>
57961
57962
57963
57964
57965
57966 <hr>
57967 <h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3>
57968 <p><b>Section:</b> 30.4.3 [thread.lock.algorithm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
57969  <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14 <b>Last modified:</b> 2010-10-29</p>
57970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
57971 <p><b>Discussion:</b></p>
57972 <p>
57973 In 30.4.3 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed
57974 <tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In
57975 the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or
57976 throwing an exception, it states that <tt>unlock</tt> shall be called for all
57977 prior arguments. Then the returns clause (p3) goes on to state
57978 in a note that after returning, either all locks are locked or none
57979 will be. So what happens if multiple locks fail on <tt>try_lock</tt>?
57980 </p>
57981
57982 <p>
57983 Example:
57984 </p>
57985
57986 <blockquote><pre>#include &lt;mutex&gt;
57987
57988 int main() {
57989  std::mutex m0, m1, m2;
57990  std::unique_lock&lt;std::mutex&gt; l0(m0, std::defer_lock);
57991  std::unique_lock&lt;std::mutex&gt; l1(m1); //throws on try_lock
57992  std::unique_lock&lt;std::mutex&gt; l2(m2); //throws on try_lock
57993
57994  int result = std::try_lock(l0, l1, l2);
57995
57996  assert( !l0.owns_lock() );
57997  assert( l1.owns_lock() ); //??
57998  assert( l2.owns_lock() ); //??
57999 }
58000 </pre></blockquote>
58001
58002 <p>
58003 The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a
58004 lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause
58005 of 30.4.3 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
58006 clause states that either all arguments shall be locked or none will
58007 be. This seems to be a contradiction unless the intent is for
58008 implementations to make an effort to unlock not only prior arguments,
58009 but the one that failed and those that come after as well. Shouldn't
58010 the note only apply to the arguments that were successfully locked?
58011 </p>
58012
58013 <p>
58014 Further discussion and possible resolutions in c++std-lib-23049.
58015 </p>
58016
58017 <p><i>[
58018 Summit:
58019 ]</i></p>
58020
58021 <blockquote>
58022 Move to review. Agree with proposed resolution.
58023 </blockquote>
58024
58025 <p><i>[
58026 Batavia (2009-05):
58027 ]</i></p>
58028
58029 <blockquote>
58030 We agree with the proposed resolution.
58031 Move to Tentatively Ready.
58032 </blockquote>
58033
58034
58035 <p><b>Proposed resolution:</b></p>
58036
58037 <p>
58038 Change 30.4.3 [thread.lock.algorithm], p2:
58039 </p>
58040
58041 <blockquote>
58042 -2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order
58043 beginning with the first until all arguments have been processed or a
58044 call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an
58045 exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for
58046 all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>.
58047 </blockquote>
58048
58049 <p>
58050 Delete the note from 30.4.3 [thread.lock.algorithm], p3
58051 </p>
58052
58053 <blockquote>
58054 -3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>,
58055 otherwise a 0-based index value that indicates 
58056 the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i>
58057 On return, either all arguments will be 
58058 locked or none will be locked. -- <i>end note</i>]</del>
58059 </blockquote>
58060
58061
58062
58063
58064
58065 <hr>
58066 <h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
58067 <p><b>Section:</b> 20.8.4 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58068  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18 <b>Last modified:</b> 2010-10-29</p>
58069 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
58070 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58071 <p><b>Discussion:</b></p>
58072 <p>
58073 The synopsis in 20.8.4 [refwrap] says:
58074 </p>
58075
58076 <blockquote><pre>template &lt;<b>ObjectType</b> T&gt; class reference_wrapper
58077 ...
58078 </pre></blockquote>
58079
58080 <p>
58081 And then paragraph 3 says:
58082 </p>
58083
58084 <blockquote>
58085 <p>
58086 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall be
58087 derived from <tt>std::unary_function&lt;T1, R&gt;</tt> only if the type
58088 <tt>T</tt> is any of the following:
58089 </p>
58090
58091 <ul>
58092 <li>
58093 a <b>function type</b> or a pointer to function type taking one argument of
58094 type <tt>T1</tt> and returning <tt>R</tt>
58095 </li>
58096 </ul>
58097 </blockquote>
58098
58099 <p>
58100 But function types are not <tt>ObjectType</tt>s.
58101 </p>
58102
58103 <p>
58104 Paragraph 4 contains the same contradiction.
58105 </p>
58106
58107 <p><i>[
58108 Post Summit:
58109 ]</i></p>
58110
58111
58112 <blockquote>
58113 <p>
58114 Jens: restricted reference to ObjectType
58115 </p>
58116 <p>
58117 Recommend Review.
58118 </p>
58119 </blockquote>
58120
58121 <p><i>[
58122 Post Summit, Peter adds:
58123 ]</i></p>
58124
58125
58126 <blockquote>
58127 <p>
58128 In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
58129 however Eric Niebler makes the very reasonable point that <tt>reference_wrapper&lt;F&gt;</tt>,
58130 where <tt>F</tt> is a function type, represents a reference to a function,
58131 a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
58132 </p>
58133 <p>
58134 <a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
58135 </p>
58136 <p>
58137 Therefore, I believe an alternative proposed resolution for issue 987 could simply
58138 allow <tt>reference_wrapper</tt> to be used with function types.
58139 </p>
58140 </blockquote>
58141
58142 <p><i>[
58143 Post Summit, Howard adds:
58144 ]</i></p>
58145
58146
58147 <blockquote>
58148 <p>
58149 I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
58150 is code that demonstrates how easy (and useful) it is to instantiate
58151 <tt>reference_wrapper</tt> with a function type:
58152 </p>
58153
58154 <blockquote><pre>#include &lt;functional&gt;
58155
58156 template &lt;class F&gt;
58157 void test(F f);
58158
58159 void f() {}
58160
58161 int main()
58162 {
58163     test(std::ref(f));
58164 }
58165 </pre></blockquote>
58166
58167 <p>
58168 Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
58169 with function type):
58170 </p>
58171
58172 <blockquote><pre>Undefined symbols:
58173   "void test&lt;std::reference_wrapper&lt;void ()()&gt; &gt;(std::reference_wrapper&lt;void ()()&gt;)",...
58174 </pre></blockquote>
58175
58176 <p>
58177 I've taken the liberty of changing the proposed wording to allow function types
58178 and set to Open.  I'll also freely admit that I'm not positive <tt>ReferentType</tt>
58179 is the correct concept.
58180 </p>
58181
58182 </blockquote>
58183
58184
58185
58186 <p><i>[
58187 Batavia (2009-05):
58188 ]</i></p>
58189
58190 <blockquote>
58191 <p>
58192 Howard observed that <tt>FunctionType</tt>,
58193 a concept not (yet?) in the Working Paper,
58194 is likely the correct constraint to be applied.
58195 However, the proposed resolution provides an adequate approximation.
58196 </p>
58197 <p>
58198 Move to Review.
58199 </p>
58200 </blockquote>
58201
58202 <p><i>[
58203 2009-05-23 Alisdair adds:
58204 ]</i></p>
58205
58206
58207 <blockquote>
58208 <p>
58209 By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
58210 reference, and call in reference-collapsing.  I'm not sure if this is
58211 correct and intended, but would like to be sure the case was considered.
58212 </p>
58213 <p>
58214 Is dis-allowing reference types and the
58215 implied reference collapsing the intended result?
58216 </p>
58217 </blockquote>
58218
58219 <p><i>[
58220 2009-07 Frankfurt
58221 ]</i></p>
58222
58223
58224 <blockquote>
58225 Moved from Review to Open only because the wording needs to be
58226 tweaked for concepts removal.
58227 </blockquote>
58228
58229 <p><i>[
58230 2009-10-14 Daniel provided de-conceptified wording.
58231 ]</i></p>
58232
58233
58234 <p><i>[
58235 2009-10 post-Santa Cruz:
58236 ]</i></p>
58237
58238
58239 <blockquote>
58240 Move to Tentatively Ready.
58241 </blockquote>
58242
58243
58244
58245 <p><b>Proposed resolution:</b></p>
58246 <p>
58247 Change 20.8.4 [refwrap]/1 as indicated:
58248 </p>
58249
58250 <blockquote>
58251 <tt>reference_wrapper&lt;T&gt;</tt> is a <tt>CopyConstructible</tt> and
58252 <tt><ins>Copy</ins>Assignable</tt> wrapper around a
58253 reference to an object <ins>or function</ins> of type <tt>T</tt>.
58254 </blockquote>
58255
58256
58257
58258
58259
58260
58261
58262
58263 <hr>
58264 <h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3>
58265 <p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58266  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2010-10-29</p>
58267 <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>
58268 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58269 <p><b>Discussion:</b></p>
58270 <p>
58271 There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt>
58272 when <tt>monotonic_clock</tt> is a  synonym for <tt>system_clock</tt>.  The
58273 intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt>
58274 is <tt>true</tt>.
58275 </p>
58276
58277 <p><i>[
58278 Batavia (2009-05):
58279 ]</i></p>
58280
58281 <blockquote>
58282 <p>
58283 We agree with the proposed resolution.
58284 </p>
58285 <p>
58286 Move to Tentatively Ready.
58287 </p>
58288 </blockquote>
58289
58290
58291 <p><b>Proposed resolution:</b></p>
58292 <p>
58293 Change X [time.clock.monotonic], p1:
58294 </p>
58295
58296 <blockquote>
58297 -1- Objects of class <tt>monotonic_clock</tt> represent clocks for which
58298 values of <tt>time_point</tt> never decrease as physical time advances.
58299 <tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt>
58300 <ins>if and only if <tt>system_clock::is_monotonic</tt> is
58301 <tt>true</tt></ins>.
58302 </blockquote>
58303
58304
58305
58306
58307
58308 <hr>
58309 <h3><a name="991"></a>991. Response to JP 50</h3>
58310 <p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58311  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
58312 <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>
58313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58314 <p><b>Discussion:</b></p>
58315 <p>
58316 Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot
58317 allocate memory for strings from a custom allocator.
58318 </p>
58319
58320 <p><i>[
58321 Batavia (2009-05):
58322 ]</i></p>
58323
58324 <blockquote>
58325 We agree with the proposed resolution.
58326 Move to Tentatively Ready.
58327 </blockquote>
58328
58329
58330 <p><b>Proposed resolution:</b></p>
58331 <p>
58332 Change 22.3.3.2.2 [conversions.string]:
58333 </p>
58334
58335 <blockquote><pre>template&lt;class Codecvt, class Elem = wchar_t<ins>,
58336          class Wide_alloc = std::allocator&lt;Elem&gt;,
58337          class Byte_alloc = std::allocator&lt;char&gt; </ins>&gt; class wstring_convert {
58338   public:
58339     typedef std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt; byte_string;
58340     typedef std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt; wide_string;
58341      ...
58342 </pre></blockquote>
58343
58344 <p>
58345 Change 22.3.3.2.2 [conversions.string], p3:
58346 </p>
58347
58348 <blockquote>
58349 -3- The class template describes an ob ject that controls conversions
58350 between wide string ob jects of class
58351 <tt>std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt;</tt>
58352 and byte string objects of class
58353 <tt>std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt;</tt>
58354 <del>(also known as <tt>std::string</tt>)</del>.
58355 </blockquote>
58356
58357
58358
58359
58360
58361
58362 <hr>
58363 <h3><a name="993"></a>993. Response to UK 188</h3>
58364 <p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58365  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
58366 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
58367 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58368 <p><b>Discussion:</b></p>
58369 <p>
58370 The function <tt>_Exit</tt> does not appear to be defined in this standard.
58371 Should it be added to the table of functions included-by-reference to
58372 the C standard?
58373 </p>
58374
58375 <p><i>[
58376 2009-05-09 Alisdair fixed some minor issues in the wording.
58377 ]</i></p>
58378
58379
58380 <p><i>[
58381 Batavia (2009-05):
58382 ]</i></p>
58383
58384 <blockquote>
58385 We agree with the proposed resolution.
58386 Move to Tentatively Ready.
58387 </blockquote>
58388
58389
58390 <p><b>Proposed resolution:</b></p>
58391 <p>
58392 Add to 18.5 [support.start.term] Table 20 (Header
58393 <tt>&lt;cstdlib&gt;</tt> synopsis) Functions:
58394 </p>
58395
58396 <blockquote><pre>_Exit
58397 </pre></blockquote>
58398
58399 <p>
58400 Add before the description of <tt>abort(void)</tt>:
58401 </p>
58402
58403 <blockquote><pre>void _Exit [[noreturn]] (int status)
58404 </pre>
58405
58406 <blockquote>
58407 <p>
58408 The function <tt>_Exit(int status)</tt> has additional behavior in this
58409 International Standard:
58410 </p>
58411 <ul>
58412 <li>
58413 The program is terminated without executing destructors for objects of
58414 automatic, thread, or static storage duration and without calling the
58415 functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]).
58416 </li>
58417 </ul>
58418 </blockquote>
58419 </blockquote>
58420
58421
58422
58423
58424
58425
58426 <hr>
58427 <h3><a name="994"></a>994. Response to UK 193</h3>
58428 <p><b>Section:</b> 18.6.2.3 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58429  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
58430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58431 <p><b>Discussion:</b></p>
58432 <p>
58433 <tt>quick_exit</tt> has been added as a new valid way to terminate a program in a
58434 well defined way
58435 </p>
58436
58437 <p><i>[
58438 Batavia (2009-05):
58439 ]</i></p>
58440
58441 <blockquote>
58442 We agree with the proposed resolution.
58443 Move to Tentatively Ready.
58444 </blockquote>
58445
58446
58447 <p><b>Proposed resolution:</b></p>
58448 <p>
58449 Change 18.6.2.3 [new.handler], p2:
58450 </p>
58451
58452 <blockquote>
58453 <p>
58454 -2- <i>Required behavior:</i> ...
58455 </p>
58456 <ul>
58457 <li>...</li>
58458 <li>
58459 <del>call either <tt>abort()</tt> or <tt>exit();</tt></del>
58460 <ins>terminate execution of the program without returning to the caller</ins>
58461 </li>
58462 </ul>
58463 </blockquote>
58464
58465
58466
58467
58468
58469
58470
58471 <hr>
58472 <h3><a name="997"></a>997. Response to UK 163</h3>
58473 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58474  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
58475 <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>
58476 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58477 <p><b>Discussion:</b></p>
58478 <p>
58479 Many functions are defined as "Effects: Equivalent to a...", which seems
58480 to also define the preconditions, effects, etc. But this is not made
58481 clear.
58482 </p>
58483
58484 <p>
58485 After studying the occurrences of "Effects: Equivalent to", I agree with
58486 the diagnosis but disagree with the solution.  In 21.4.2 [string.cons]
58487 we find
58488 </p>
58489
58490 <blockquote>
58491 <p>
58492 14 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to
58493 <tt>basic_string(static_cast&lt;size_type&gt;(begin), static_cast&lt;value_type&gt;(end), a)</tt>
58494 </p>
58495 <p>
58496 15 Otherwise constructs a string from the values in the range <tt>[begin,
58497 end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3).
58498 </p>
58499 </blockquote>
58500
58501 <p>
58502 This would be devishly difficult to re-write with an explicit
58503 "Equivalent to:" clause.  Instead, I propose the following, which will
58504 result in much less editorial re-work.
58505 </p>
58506
58507 <p><i>[
58508 2009-05-09 Alisdair adds:
58509 ]</i></p>
58510
58511
58512 <blockquote>
58513 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>.
58514 </blockquote>
58515
58516 <p><i>[
58517 Batavia (2009-05):
58518 ]</i></p>
58519
58520 <blockquote>
58521 We agree with the proposed resolution.
58522 Move to Tentatively Ready.
58523 </blockquote>
58524
58525
58526 <p><b>Proposed resolution:</b></p>
58527 <p>
58528 Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
58529 </p>
58530
58531 <blockquote>
58532 <p>
58533 -3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup>
58534 </p>
58535
58536 <ul>
58537 <li>
58538 <i>Requires:</i> the preconditions for calling the function
58539 </li>
58540 <li>
58541 <i>Effects:</i> the actions performed by the function
58542 </li>
58543 <li>
58544 <i>Postconditions:</i> the observable results established by the function
58545 </li>
58546 <li>
58547 <i>Returns:</i> a description of the value(s) returned by the function
58548 </li>
58549 <li>
58550 <i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception
58551 </li>
58552 <li>
58553 <i>Complexity:</i> the time and/or space complexity of the function
58554 </li>
58555 <li>
58556 <i>Remarks:</i> additional semantic constraints on the function
58557 </li>
58558 <li>
58559 <i>Error conditions:</i> the error conditions for error codes reported by the function.
58560 </li>
58561 <li>
58562 <i>Notes:</i> non-normative comments about the function
58563 </li>
58564 </ul>
58565
58566 <p><ins>
58567 Whenever the <i>Effects</i> element specifies that the semantics of some
58568 function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then
58569 the various elements are interpreted as follows.  If <tt>F</tt>'s
58570 semantics specifies a <i>Requires</i> element, then that requirement is
58571 logically imposed prior to the <i>equivalent-to</i> semantics.  Then,
58572 the semantics of the <i>code-sequence</i> are determined by the
58573 <i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>,
58574 <i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error
58575 Conditions</i> and <i>Notes</i> specified for the (one or more) function
58576 invocations contained in the <i>code-sequence</i>. The value returned from
58577 <tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or
58578 if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified 
58579 by the <i>Returns</i> elements in <i>code-sequence</i>.  If
58580 <tt>F</tt>'s semantics contains a <i>Throws</i> (or
58581 <i>Postconditions</i>, or <i>Complexity</i>) element, then that
58582 supersedes any occurrences of that element in the <i>code-sequence</i>.
58583 </ins></p>
58584 </blockquote>
58585
58586
58587
58588
58589
58590
58591 <hr>
58592 <h3><a name="998"></a>998. Smart pointer referencing its owner</h3>
58593 <p><b>Section:</b> 20.9.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58594  <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26 <b>Last modified:</b> 2010-10-29</p>
58595 <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>
58596 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58597 <p><b>Discussion:</b></p>
58598 <p>
58599 Consider the following (simplified) implementation of 
58600 <tt>std::auto_ptr&lt;T&gt;::reset()</tt>: 
58601 </p>
58602
58603 <blockquote><pre>void reset(T* newptr = 0) { 
58604    if (this-&gt;ptr &amp;&amp; this-&gt;ptr != newptr) { 
58605      delete this-&gt;ptr; 
58606    } 
58607    this-&gt;ptr = newptr; 
58608
58609 </pre></blockquote>
58610
58611 <p>
58612 Now consider the following code which uses the above implementation: 
58613 </p>
58614
58615 <blockquote><pre>struct foo { 
58616    std::auto_ptr&lt;foo&gt; ap; 
58617    foo() : ap(this) {} 
58618    void reset() { ap.reset(); } 
58619 }; 
58620 int main() { 
58621    (new foo)-&gt;reset(); 
58622
58623 </pre></blockquote>
58624
58625 <p>
58626 With the above implementation of auto_ptr, this results in U.B. at the 
58627 point of auto_ptr::reset(). If this isn't obvious yet, let me explain 
58628 how this goes step by step: 
58629 </p>
58630
58631 <ol>
58632 <li>
58633 <tt>foo::reset()</tt> entered 
58634 </li>
58635 <li>
58636 <tt>auto_ptr::reset()</tt> entered 
58637 </li>
58638 <li>
58639 <tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt>
58640 </li>
58641 <li>
58642 <tt>foo::~foo()</tt> entered, tries to destruct its members 
58643 </li>
58644 <li>
58645 <tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object! 
58646 </li>
58647 <li>
58648 <tt>foo::~foo()</tt> left 
58649 </li>
58650 <li>
58651 <tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 &lt;- U.B.! <tt>auto_ptr</tt>
58652 is not a valid object here already! 
58653 </li>
58654 </ol>
58655
58656 <p><i>[
58657 Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and
58658 brought this to the attention of the LWG, and helped with the solution.
58659 ]</i></p>
58660
58661
58662 <p><i>[
58663 Howard adds:
58664 ]</i></p>
58665
58666
58667 <blockquote>
58668 To fix this behavior <tt>reset</tt> must be specified such that deleting the
58669 pointer is the last action to be taken within <tt>reset</tt>.
58670 </blockquote>
58671
58672 <p><i>[
58673 Alisdair adds:
58674 ]</i></p>
58675
58676
58677 <blockquote>
58678 <p>
58679 The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a> is poor, as it relies on
58680 broken semantics of having two object believing they are unique owners of a
58681 single resource.  It should not be surprising that UB results from such
58682 code, and I feel no need to go out of our way to support such behaviour.
58683 </p>
58684 <p>
58685 If an example is presented that does not imply multiple ownership of a
58686 unique resource, I would be much more ready to accept the proposed
58687 resolution.
58688 </p>
58689 </blockquote>
58690
58691 <p><i>[
58692 Batavia (2009-05):
58693 ]</i></p>
58694
58695 <blockquote>
58696 <p>
58697 Howard summarizes:
58698 </p>
58699 <blockquote>
58700 This issue has to do with circular ownership,
58701 and affects <tt>auto_ptr</tt>, too (but we don't really care about that).
58702 It is intended to spell out the order in which operations must be performed
58703 so as to avoid the possibility
58704 of undefined behavior in the self-referential case.
58705 </blockquote>
58706 <p>
58707 Howard points to message c++std-lib-23175 for another example,
58708 requested by Alisdair.
58709 </p>
58710 <p>
58711 We agree with the issue and with the proposed resolution.
58712 Move to Tentatively Ready.
58713 </p>
58714 </blockquote>
58715
58716
58717
58718 <p><b>Proposed resolution:</b></p>
58719 <p>
58720 Change 20.9.9.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6:
58721 </p>
58722
58723 <blockquote>
58724 <p>
58725 -5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
58726 <ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not
58727 equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>.
58728 [<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt>
58729 may destroy <tt>*this</tt>. <i>-- end note</i>]</ins>
58730 </p>
58731
58732 <p>
58733 -6- Postconditions: <tt>get() == p</tt>.
58734 <ins>[<i>Note:</i> The postcondition does not hold if the call to
58735 <tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this-&gt;get()</tt> is no longer a valid
58736 expression. <i>-- end note</i>]</ins>
58737 </p>
58738 </blockquote>
58739
58740
58741
58742
58743
58744 <hr>
58745 <h3><a name="999"></a>999. Taking the address of a function</h3>
58746 <p><b>Section:</b> 20.9.8 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58747  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2010-10-29</p>
58748 <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>
58749 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58750 <p><b>Discussion:</b></p>
58751 <p>
58752 The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
58753 <tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
58754 tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast&lt;char&amp;&gt;</tt>
58755 implementation of <tt>addressof</tt> failed.)
58756 </p>
58757
58758
58759
58760 <p><i>[
58761 Batavia (2009-05):
58762 ]</i></p>
58763
58764 <blockquote>
58765 <p>
58766 We agree.
58767 </p>
58768 <p>
58769 Move to Tentatively Ready.
58770 </p>
58771 </blockquote>
58772
58773 <p><i>[
58774 2009-07 Frankfurt
58775 ]</i></p>
58776
58777
58778 <blockquote>
58779 Moved from Tentatively Ready to Open only because the wording needs to be
58780 tweaked for concepts removal.
58781 </blockquote>
58782
58783 <p><i>[
58784 2009-10-10 Daniel updates wording to concept-free.
58785 ]</i></p>
58786
58787
58788 <p><i>[
58789 2009-10 post-Santa Cruz:
58790 ]</i></p>
58791
58792
58793 <blockquote>
58794 Move to Tentatively Ready.
58795 </blockquote>
58796
58797
58798
58799 <p><b>Proposed resolution:</b></p>
58800 <p><i>[
58801 The resolution assumes that <tt>addressof</tt> is reintroduced as described in
58802 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf">n2946</a>
58803 ]</i></p>
58804
58805
58806 <p>
58807 In 20.9.8 [specialized.algorithms] change as described:
58808 </p>
58809
58810 <blockquote><pre>template &lt;class T&gt; T* addressof(T&amp; r);
58811 </pre>
58812 <blockquote>
58813 <i>Returns:</i> The actual address of the object <ins>or function</ins>
58814 referenced by <tt>r</tt>, even in the
58815 presence of an overloaded <tt>operator&amp;</tt>.
58816 </blockquote>
58817 </blockquote>
58818
58819
58820
58821
58822
58823
58824
58825 <hr>
58826 <h3><a name="1004"></a>1004. Response to UK 179</h3>
58827 <p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58828  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
58829 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
58830 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58831 <p><b>Discussion:</b></p>
58832
58833 <p><b>Addresses UK 179</b></p>
58834
58835 <p>
58836 According to the 4th bullet there is a problem if "if any replacement
58837 function or handler function or destructor operation throws an
58838 exception". There should be no problem throwing exceptions so long as
58839 they are caught within the function.
58840 </p>
58841
58842 <p><i>[
58843 Batavia (2009-05):
58844 ]</i></p>
58845
58846 <blockquote>
58847 The phrasing "throws an exception" is commonly used elsewhere
58848 to mean "throws or propagates an exception."
58849 Move to Open pending a possible more general resolution.
58850 </blockquote>
58851
58852 <p><i>[
58853 2009-07 Frankfurt:
58854 ]</i></p>
58855
58856
58857 <blockquote>
58858 Replace "propagates" in the proposed resolution with the phrase "exits
58859 via" and move to Ready.
58860 </blockquote>
58861
58862
58863
58864 <p><b>Proposed resolution:</b></p>
58865 <p>
58866 Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
58867 </p>
58868
58869 <blockquote>
58870 <ul>
58871 <li>
58872 if any replacement function or handler function or destructor operation
58873 <del>throws</del> <ins>exits via</ins> an exception, unless specifically
58874 allowed in the applicable <i>Required behavior:</i> paragraph.
58875 </li>
58876 </ul>
58877 </blockquote>
58878
58879
58880
58881
58882
58883
58884 <hr>
58885 <h3><a name="1006"></a>1006. <tt>operator delete</tt> in garbage collected implementation</h3>
58886 <p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
58887  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
58888 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
58889 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
58890 <p><b>Discussion:</b></p>
58891
58892 <p><b>Addresses UK 190</b></p>
58893
58894 <p>
58895 It is not entirely clear how the current specification acts in the
58896 presence of a garbage collected implementation.
58897 </p>
58898
58899 <p><i>[
58900 Summit:
58901 ]</i></p>
58902
58903  
58904 <blockquote>
58905 Agreed.
58906 </blockquote>
58907
58908 <p><i>[
58909 2009-05-09 Alisdair adds:
58910 ]</i></p>
58911
58912
58913 <blockquote>
58914 Proposed wording is too strict for implementations that do not support
58915 garbage collection.  Updated wording supplied.
58916 </blockquote>
58917
58918 <p><i>[
58919 Batavia (2009-05):
58920 ]</i></p>
58921
58922 <blockquote>
58923 We recommend advancing this to Tentatively Ready
58924 with the understanding that it will not be moved for adoption
58925 unless and until the proposed resolution to Core issue #853 is adopted.
58926 </blockquote>
58927
58928
58929 <p><b>Proposed resolution:</b></p>
58930
58931 <p>
58932 (Editorial note: This wording ties into the proposed
58933 resolution for Core #853)
58934 </p>
58935
58936 <p>
58937 Add paragraphs to 18.6.1.1 [new.delete.single]:
58938 </p>
58939
58940 <blockquote><pre>void operator delete(void* ptr) throw();
58941 <del>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();</del>
58942 </pre>
58943
58944 <p><i>[
58945 The second signature deletion above is editorial.
58946 ]</i></p>
58947
58948
58949 <blockquote>
58950 <p><ins>
58951 <i>Requires:</i> If an implementation has strict pointer safety
58952 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
58953 be a safely-derived pointer.
58954 </ins></p>
58955
58956 <p>-10- ...</p>
58957 </blockquote>
58958
58959 <pre>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();
58960 </pre>
58961
58962 <blockquote>
58963 <p><ins>
58964 <i>Requires:</i> If an implementation has strict pointer safety
58965 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
58966 be a safely-derived pointer.
58967 </ins></p>
58968
58969 <p>-15- ...</p>
58970 </blockquote>
58971
58972 </blockquote>
58973
58974 <p>
58975 Add paragraphs to 18.6.1.2 [new.delete.array]:
58976 </p>
58977
58978 <blockquote><pre>void operator delete[](void* ptr) throw();
58979 <del>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();</del>
58980 </pre>
58981
58982 <p><i>[
58983 The second signature deletion above is editorial.
58984 ]</i></p>
58985
58986
58987 <blockquote>
58988 <p><ins>
58989 <i>Requires:</i> If an implementation has strict pointer safety
58990 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
58991 be a safely-derived pointer.
58992 </ins></p>
58993
58994 <p>-9- ...</p>
58995 </blockquote>
58996
58997 <pre>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();
58998 </pre>
58999
59000 <blockquote>
59001 <p><ins>
59002 <i>Requires:</i> If an implementation has strict pointer safety
59003 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
59004 be a safely-derived pointer.
59005 </ins></p>
59006
59007 <p>-13- ...</p>
59008 </blockquote>
59009
59010 </blockquote>
59011
59012
59013 <p>
59014 Add paragraphs to 18.6.1.3 [new.delete.placement]:
59015 </p>
59016
59017 <blockquote><pre>void operator delete(void* ptr, void*) throw();
59018 </pre>
59019
59020 <blockquote>
59021 <p><ins>
59022 <i>Requires:</i> If an implementation has strict pointer safety
59023 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
59024 be a safely-derived pointer.
59025 </ins></p>
59026
59027 <p>-7- ...</p>
59028 </blockquote>
59029
59030 <pre>void operator delete[](void* ptr, void*) throw();
59031 </pre>
59032
59033 <blockquote>
59034 <p><ins>
59035 <i>Requires:</i> If an implementation has strict pointer safety
59036 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
59037 be a safely-derived pointer.
59038 </ins></p>
59039
59040 <p>-9- ...</p>
59041 </blockquote>
59042
59043 </blockquote>
59044
59045
59046
59047
59048
59049
59050 <hr>
59051 <h3><a name="1011"></a>1011. <tt>next/prev</tt> wrong iterator type</h3>
59052 <p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59053  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59054 <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>
59055 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59056 <p><b>Discussion:</b></p>
59057
59058 <p><b>Addresses UK 271</b></p>
59059
59060 <p>
59061 <tt>next/prev</tt> return an incremented iterator without changing the value of
59062 the original iterator. However, even this may invalidate an
59063 <tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
59064 'multipass' property.
59065 </p>
59066
59067 <p><i>[
59068 Batavia (2009-05):
59069 ]</i></p>
59070
59071 <blockquote>
59072 We agree with the proposed resolution.
59073 Move to Tentatively Ready.
59074 </blockquote>
59075
59076 <p><i>[
59077 2009-07 Frankfurt
59078 ]</i></p>
59079
59080
59081 <blockquote>
59082 Moved from Tentatively Ready to Open only because the wording needs to be
59083 tweaked for concepts removal.
59084 </blockquote>
59085
59086 <p><i>[
59087 2009-10-14 Daniel provided de-conceptified wording.
59088 ]</i></p>
59089
59090
59091 <p><i>[
59092 2009-10 Santa Cruz:
59093 ]</i></p>
59094
59095
59096 <blockquote>
59097 Moved to Ready.
59098 </blockquote>
59099
59100
59101
59102 <p><b>Proposed resolution:</b></p>
59103
59104
59105 <ol>
59106 <li>
59107 <p>
59108 Change header <tt>&lt;iterator&gt;</tt> synopsis 24.3 [iterator.synopsis] as indicated:
59109 </p>
59110
59111 <blockquote><pre>// 24.4.4, iterator operations:
59112 ...
59113 template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
59114   <del>Input</del><ins>Forward</ins>Iterator
59115   next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
59116 </pre></blockquote>
59117 </li>
59118
59119 <li>
59120 <p>
59121 Change 24.4.4 [iterator.operations] before p.6 as indicated:
59122 </p>
59123
59124 <blockquote><pre>template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
59125   <del>Input</del><ins>Forward</ins>Iterator
59126   next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
59127 </pre></blockquote>
59128 </li>
59129 </ol>
59130
59131
59132
59133
59134
59135
59136 <hr>
59137 <h3><a name="1012"></a>1012. <tt>reverse_iterator</tt> default ctor should value initialize</h3>
59138 <p><b>Section:</b> 24.5.1.3.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59139  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59140 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59141 <p><b>Discussion:</b></p>
59142
59143 <p><b>Addresses UK 277</b></p>
59144
59145 <p>
59146 The default constructor default-initializes current, rather than
59147 value-initializes. This means that when Iterator corresponds to a
59148 trivial type, the current member is left un-initialized, even when the
59149 user explictly requests value intialization! At this point, it is not
59150 safe to perform any operations on the reverse_iterator other than assign
59151 it a new value or destroy it. Note that this does correspond to the
59152 basic definition of a singular iterator.
59153 </p>
59154
59155 <p><i>[
59156 Summit:
59157 ]</i></p>
59158
59159
59160 <blockquote>
59161 Agree with option i.
59162 </blockquote>
59163
59164 <p>
59165 Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>
59166 </p>
59167
59168 <p><i>[
59169 Batavia (2009-05):
59170 ]</i></p>
59171
59172 <blockquote>
59173 We believe this should be revisited
59174 in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>,
59175 which nearly duplicates this issue.
59176 Move to Open.
59177 </blockquote>
59178
59179 <p><i>[
59180 2009-07 post-Frankfurt:
59181 ]</i></p>
59182
59183
59184 <blockquote>
59185 <p>
59186 Change "constructed" to "initialized" in two places in the proposed resolution.
59187 </p>
59188 <p>
59189 Move to Tentatively Ready.
59190 </p>
59191 </blockquote>
59192
59193 <p><i>[
59194 2009 Santa Cruz:
59195 ]</i></p>
59196
59197
59198 <blockquote>
59199 Moved to Ready for this meeting.
59200 </blockquote>
59201
59202
59203
59204 <p><b>Proposed resolution:</b></p>
59205 <p>
59206 Change  [reverse.iter.con]:
59207 </p>
59208
59209 <blockquote><pre>reverse_iterator();
59210 </pre>
59211 <blockquote>
59212 -1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
59213 operations applied to the resulting iterator have defined behavior if and
59214 only if the corresponding operations are defined on a <del>default constructed</del>
59215 <ins>value initialized</ins>
59216 iterator of type <tt>Iterator</tt>.
59217 </blockquote>
59218 </blockquote>
59219
59220 <p>
59221 Change 24.5.3.3.1 [move.iter.op.const]:
59222 </p>
59223
59224 <blockquote><pre>move_iterator();
59225 </pre>
59226 <blockquote>
59227 -1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
59228 initializing <tt>current</tt>.
59229 <ins>Iterator
59230 operations applied to the resulting iterator have defined behavior if and
59231 only if the corresponding operations are defined on a
59232 value initialized
59233 iterator of type <tt>Iterator</tt>.</ins>
59234 </blockquote>
59235 </blockquote>
59236
59237
59238
59239
59240
59241
59242 <hr>
59243 <h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3>
59244 <p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59245  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59246 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
59247 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59248 <p><b>Discussion:</b></p>
59249
59250 <p><b>Addresses UK 317 and JP 74</b></p>
59251
59252 <p>
59253 UK 317:
59254 </p>
59255
59256 <blockquote>
59257 <tt>basic_string</tt> has both a constructor and an assignment operator that
59258 accepts an initializer list, <tt>basic_regex</tt> should have the same.
59259 </blockquote>
59260
59261 <p>
59262 JP 74:
59263 </p>
59264
59265 <blockquote>
59266 <tt>basic_regx &amp; operator= (initializer_list&lt;T&gt;);</tt> is not defined.
59267 </blockquote>
59268
59269 <p><i>[
59270 Batavia (2009-05):
59271 ]</i></p>
59272
59273 <blockquote>
59274 UK 317 asks for both assignment and constructor,
59275 but the requested constructor is already present in the current Working Paper.
59276 We agree with the proposed resolution.
59277 Move to Tentatively Ready.
59278 </blockquote>
59279
59280
59281 <p><b>Proposed resolution:</b></p>
59282 <p>
59283 Change 28.8 [re.regex]:
59284 </p>
59285
59286 <blockquote><pre>template &lt;class charT,
59287           class traits = regex_traits&lt;charT&gt; &gt;
59288 class basic_regex {
59289   ...
59290   basic_regex&amp; operator=(const charT* ptr);
59291   <ins>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);</ins>
59292   template &lt;class ST, class SA&gt;
59293     basic_regex&amp; operator=(const basic_string&lt;charT, ST, SA&gt;&amp; p);
59294   ...
59295 };
59296 </pre></blockquote>
59297
59298 <p>
59299 Add in  28.8.2 [re.regex.construct]:
59300 </p>
59301
59302 <blockquote>
59303 <blockquote>
59304 -20- ...
59305 </blockquote>
59306 <pre>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);
59307 </pre>
59308 <blockquote>
59309 -21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt>
59310 </blockquote>
59311 </blockquote>
59312
59313
59314
59315
59316
59317
59318 <hr>
59319 <h3><a name="1019"></a>1019. Response to UK 205</h3>
59320 <p><b>Section:</b> 20.7.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59321  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59322 <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>
59323 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59324 <p><b>Discussion:</b></p>
59325
59326 <p><b>Addresses UK 205</b></p>
59327
59328 <p>
59329 <tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
59330 The addition to the language of literal types and the enhanced rules for
59331 constant expressions make this possible.
59332 </p>
59333
59334 <p><i>[
59335 Batavia (2009-05):
59336 ]</i></p>
59337
59338 <blockquote>
59339 We agree that the <tt>static</tt> data member
59340 ought be declared <tt>constexpr</tt>,
59341 but do not see a need for the proposed <tt>operator value_type()</tt>.
59342 (A use case would be helpful.)
59343 Move to Open.
59344 </blockquote>
59345
59346 <p><i>[
59347 2009-05-23 Alisdair adds:
59348 ]</i></p>
59349
59350
59351 <blockquote>
59352 <p>
59353 The motivating case in my mind is that we can then use
59354 <tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
59355 a <tt>static_assert</tt> declaration.  In that sense it is purely a matter of style.
59356 </p>
59357 <p>
59358 Note that Boost has applied the non-explicit conversion operator for many
59359 years as it has valuable properties for extension into other metaprogramming
59360 libraries, such as MPL.  If additional rationale is desired I will poll the
59361 Boost lists for why this extension was originally applied.  I would argue
59362 that explicit conversion is more appropriate for 0x though.
59363 </p>
59364 </blockquote>
59365
59366 <p><i>[
59367 2009-07-04 Howard adds:
59368 ]</i></p>
59369
59370
59371 <blockquote>
59372 <p>
59373 Here's a use case which demonstrates the syntactic niceness which Alisdair describes:
59374 </p>
59375
59376 <blockquote><pre>#define requires(...) class = typename std::enable_if&lt;(__VA_ARGS__)&gt;::type
59377
59378 template &lt;class T, class U,
59379     requires(!is_lvalue_reference&lt;T&gt;() ||
59380               is_lvalue_reference&lt;T&gt;() &amp;&amp; is_lvalue_reference&lt;U&gt;()),
59381     requires(is_same&lt;typename base_type&lt;T&gt;::type,
59382                      typename base_type&lt;U&gt;::type&gt;)&gt;
59383 inline
59384 T&amp;&amp;
59385 forward(U&amp;&amp; t)
59386 {
59387     return static_cast&lt;T&amp;&amp;&gt;(t);
59388 }
59389 </pre></blockquote>
59390 </blockquote>
59391
59392 <p><i>[
59393 2009-07 post-Frankfurt:
59394 ]</i></p>
59395
59396
59397 <blockquote>
59398 Move to Tentatively Ready.
59399 </blockquote>
59400
59401 <p><i>[
59402 2009 Santa Cruz:
59403 ]</i></p>
59404
59405
59406 <blockquote>
59407 Moved to Ready for this meeting.
59408 </blockquote>
59409
59410
59411
59412 <p><b>Proposed resolution:</b></p>
59413 <p>
59414 Add to the <tt>integral_constant</tt> struct definition in 20.7.3 [meta.help]:
59415 </p>
59416
59417 <blockquote><pre>template &lt;class T, T v&gt;
59418 struct integral_constant {
59419   static const<ins>expr</ins> T value = v;
59420   typedef T value_type;
59421   typedef integral_constant&lt;T,v&gt; type;
59422   <ins>constexpr operator value_type() { return value; }</ins>
59423 };
59424 </pre></blockquote>
59425
59426
59427
59428
59429
59430 <hr>
59431 <h3><a name="1021"></a>1021. Response to UK 211</h3>
59432 <p><b>Section:</b> 20.9.9.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59433  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59434 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59435 <p><b>Discussion:</b></p>
59436
59437 <p><b>Addresses UK 211</b></p>
59438
59439 <p>
59440 The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
59441 problem. It should be used for the assignemnt operator, as with the
59442 constructor and elsewhere through the library.
59443 </p>
59444
59445 <p><i>[
59446 Batavia (2009-05):
59447 ]</i></p>
59448
59449 <blockquote>
59450 We agree with the proposed resolution.
59451 Move to Tentatively Ready.
59452 </blockquote>
59453
59454
59455 <p><b>Proposed resolution:</b></p>
59456 <p>
59457 Change the synopsis in 20.9.9.2 [unique.ptr.single]:
59458 </p>
59459
59460 <blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
59461 </pre></blockquote>
59462
59463 <p>
59464 Change 20.9.9.2.3 [unique.ptr.single.asgn]:
59465 </p>
59466
59467 <blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
59468 </pre>
59469 <blockquote>
59470 <del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The
59471 <i>unspecified-pointer-type</i> is often implemented as a pointer to a
59472 private data member, avoiding many of the implicit conversion pitfalls.
59473 <i>-- end note</i>]</del>
59474 </blockquote>
59475 </blockquote>
59476
59477
59478
59479
59480
59481 <hr>
59482 <h3><a name="1030"></a>1030. Response to JP 44</h3>
59483 <p><b>Section:</b> 20.9.10.5 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59484  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
59485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59486 <p><b>Discussion:</b></p>
59487
59488 <p><b>Addresses JP 44</b></p>
59489
59490 <p>
59491 The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
59492 <tt>shared_ptr&lt;T&gt;*</tt>.
59493 </p>
59494 <p>
59495 It should be <tt>shared_ptr&lt;T&gt;&amp;</tt>, or if these are
59496 <tt>shared_ptr&lt;T&gt;*</tt> then add the "<tt>p</tt> shall not be a
59497 null pointer" at the requires.
59498 </p>
59499
59500 <p><i>[
59501 Summit:
59502 ]</i></p>
59503
59504
59505 <blockquote>
59506 Agree. All of the functions need a requirement that <tt>p</tt> (or
59507 <tt>v</tt>) is a pointer to a valid object.
59508 </blockquote>
59509
59510 <p><i>[
59511 2009-07 post-Frankfurt:
59512 ]</i></p>
59513
59514
59515 <blockquote>
59516 <p>
59517 Lawrence explained that these signatures match the regular atomics. The
59518 regular atomics must not use references because these signatures are
59519 shared with C. The decision to pass shared_ptrs by pointer rather than
59520 by reference was deliberate and was motivated by the principle of least
59521 surprise.
59522 </p>
59523 <p>
59524 Lawrence to write wording that requires that the pointers not be null.
59525 </p>
59526 </blockquote>
59527
59528 <p><i>[
59529 2009-09-20 Lawrence provided wording:
59530 ]</i></p>
59531
59532
59533 <blockquote>
59534 <p>
59535 The parameter types for atomic shared pointer access
59536 were deliberately chosen to be pointers
59537 to match the corresponding parameters of the atomics chapter.
59538 Those in turn were deliberately chosen
59539 to match C functions,
59540 which do not have reference parameters.
59541 </p>
59542 <p>
59543 We adopt the second suggestion,
59544 to require that such pointers not be null.
59545 </p>
59546 </blockquote>
59547
59548 <p><i>[
59549 2009-10 Santa Cruz:
59550 ]</i></p>
59551
59552
59553 <blockquote>
59554 Moved to Ready.
59555 </blockquote>
59556
59557
59558
59559 <p><b>Proposed resolution:</b></p>
59560 <p>
59561 In section "<code>shared_ptr</code> atomic access"
59562 20.9.10.5 [util.smartptr.shared.atomic], add to each function the
59563 following clause.
59564 </p>
59565 <blockquote><p>
59566 <i>Requires:</i> <code>p</code> shall not be null.
59567 </p></blockquote>
59568
59569
59570
59571
59572
59573 <hr>
59574 <h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
59575 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59576  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
59577 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
59578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59579 <p><b>Discussion:</b></p>
59580
59581 <p>
59582 While looking at <tt>thread::join()</tt> I think I spotted a couple of
59583 possible defects in the specifications. I could not find a previous
59584 issue or NB comment about that, but I might have missed it.
59585 </p>
59586
59587 <p>
59588 The postconditions clause for <tt>thread::join()</tt> is:
59589 </p>
59590
59591 <blockquote>
59592 <i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
59593 returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
59594 </blockquote>
59595
59596 <p>
59597 and the throws clause is:
59598 </p>
59599
59600 <blockquote>
59601 <i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
59602 </blockquote>
59603
59604 <p>
59605 Now... how could the postconditions <em>not</em> be achieved?
59606 It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
59607 unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
59608 problem: in order to decide whether to throw or not I depend on the
59609 postconditions, but the postconditions are different in the two cases.
59610 </p>
59611
59612 <p>
59613 I believe the throws clause should be:
59614 </p>
59615
59616 <blockquote>
59617 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
59618 cannot be achieved.
59619 </blockquote>
59620
59621 <p>
59622 as it is in <tt>detach()</tt>, or, even better, as the postcondition is
59623 trivially satisfiable and to remove the circular dependency:
59624 </p>
59625
59626
59627 <blockquote>
59628 <i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
59629 </blockquote>
59630
59631 <p>
59632 Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
59633 </p>
59634
59635 <p><i>[
59636 See the thread starting at c++std-lib-23204 for more discussion.
59637 ]</i></p>
59638
59639
59640 <p><i>[
59641 Batavia (2009-05):
59642 ]</i></p>
59643
59644 <blockquote>
59645 <p>
59646 Pete believes there may be some more general language (in frontmatter)
59647 that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>.
59648 </p>
59649 <p>
59650 Move to Open.
59651 </p>
59652 </blockquote>
59653
59654 <p><i>[
59655 2009-11-18 Anthony provides wording.
59656 ]</i></p>
59657
59658
59659
59660 <p><i>[
59661 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
59662 ]</i></p>
59663
59664
59665 <p><b>Proposed resolution:</b></p>
59666 <p>
59667 Edit 30.3.1.5 [thread.thread.member] as indicated:
59668 </p>
59669
59670 <blockquote><pre>void join();
59671 </pre>
59672 <blockquote>
59673 <p>
59674 5 <i>Precondition:</i> <tt>joinable()</tt> is <tt>true</tt>.
59675 </p>
59676 <p><ins>
59677 <i>Effects:</i> Blocks until the thread represented by <tt>*this</tt> has completed.
59678 </ins></p>
59679
59680 <p>
59681 6 <i>Synchronization:</i> The completion of the thread represented by
59682 <tt>*this</tt> happens before (1.10 [intro.multithread])
59683 <tt>join()</tt> returns. [<i>Note:</i> Operations on <tt>*this</tt> are not
59684 synchronized. \97 <i>end note</i>]
59685 </p>
59686
59687 <p>
59688 7 <i>Postconditions:</i> <del>If <tt>join()</tt> throws an exception, the value
59689 returned by <tt>get_id()</tt> is unchanged. Otherwise,</del> <ins>The thread
59690 represented by <tt>*this</tt> has completed.</ins> <tt>get_id() == id()</tt>.
59691 </p>
59692
59693 <p>
59694 8 ...
59695 </p>
59696
59697
59698 </blockquote>
59699 </blockquote>
59700
59701
59702
59703
59704
59705
59706 <hr>
59707 <h3><a name="1034"></a>1034. Response to UK 222</h3>
59708 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59709  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
59710 <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>
59711 <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>
59712 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59713 <p><b>Discussion:</b></p>
59714
59715 <p><b>Addresses UK 222</b></p>
59716
59717 <p>
59718 It is not clear what purpose the Requirement tables serve in the
59719 Containers clause. Are they the definition of a library Container? Or
59720 simply a conventient shorthand to factor common semantics into a single
59721 place, simplifying the description of each subsequent container? This
59722 becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
59723 default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
59724 support the size operation. Are these components no longer containers?
59725 Does that mean the remaining requirements don't apply? Or are these
59726 contradictions that need fixing, despite being a clear design decision?
59727 </p>
59728
59729 <p>
59730 Recommend:
59731 </p>
59732
59733 <p>
59734 Clarify all the tables in 23.2 [container.requirements] are
59735 there as a convenience for documentation, rather than a strict set of
59736 requirements. Containers should be allowed to relax specific
59737 requirements if they call attention to them in their documentation. The
59738 introductory text for <tt>array</tt> should be expanded to mention a
59739 default constructed <tt>array</tt> is not empty, and
59740 <tt>forward_list</tt> introduction should mention it does not provide
59741 the required <tt>size</tt> operation as it cannot be implemented
59742 efficiently.
59743 </p>
59744
59745 <p><i>[
59746 Summit:
59747 ]</i></p>
59748
59749
59750 <blockquote>
59751 Agree in principle.
59752 </blockquote>
59753
59754 <p><i>[
59755 2009-07 post-Frankfurt:
59756 ]</i></p>
59757
59758
59759 <blockquote>
59760 We agree in principle, but we have a timetable. This group feels that
59761 the issue should be closed as NAD unless a proposed resolution is
59762 submitted prior to the March 2010 meeting.
59763 </blockquote>
59764
59765 <p><i>[
59766 2009-10 Santa Cruz:
59767 ]</i></p>
59768
59769
59770 <blockquote>
59771 Looked at this and still intend to close as NAD in March
59772 2010 unless there is proposed wording that we like.
59773 </blockquote>
59774
59775 <p><i>[
59776 2010-02-02 Nicolai M. Josuttis updates proposed wording and adds:
59777 ]</i></p>
59778
59779
59780 <blockquote>
59781 <p>
59782 I just came across issue #1034 (response to UK 222),
59783 which covers the role of container requirements.
59784 The reason I found this issue was that I am wondering why
59785 <tt>array&lt;&gt;</tt> is specified to be a sequence container.
59786 For me, currently, this follows from
59787 Sequence containers 23.2.3 [sequence.reqmts]
59788 saying:
59789 </p>
59790 <blockquote>
59791 The library provides five basic kinds of sequence containers: <tt>array</tt>,
59792 <tt>vector</tt>, <tt>forward_list</tt>, <tt>list</tt>, and <tt>deque</tt>. while
59793 later on in Table 94 "Sequence container requirements" are defined.
59794 </blockquote>
59795
59796 <p>
59797 IMO, you can hardly argue that this is NAD.
59798 We MUST say somewhere that either array is not a sequence container
59799 or does not provide all operations of a sequence container
59800 (even not all requirements of a container in general).
59801 </p>
59802 <p>
59803 Here is the number of requirements <tt>array&lt;&gt;</tt> does not meet
59804 (AFAIK):
59805 </p>
59806 <p>
59807 general container requirements:
59808 </p>
59809 <ul>
59810 <li>
59811 a default constructed <tt>array</tt> is not empty
59812 </li>
59813 <li>
59814 <tt>swap</tt> has no constant complexity
59815 </li>
59816 </ul>
59817
59818 <p>
59819  Note also that <tt>swap</tt> not only has linear complexity
59820  it also invalidates iterators (or to be more precise,
59821  assigns other values to the elements), which
59822  is different from the effect swap has for other containers.
59823  For this reason, I must say that i tend to propose to
59824  remove <tt>swap()</tt> for <tt>arrays</tt>.
59825  </p>
59826
59827 <p>
59828 sequence container requirements:
59829 </p>
59830
59831 <ul>
59832 <li>
59833 There is no constructor and assignment for a range
59834 </li>
59835 <li>
59836 There is no constructor and assignment for <tt>n</tt> copies of <tt>t</tt>
59837 </li>
59838 <li>
59839  There are no <tt>emplace</tt>, <tt>insert</tt>, <tt>erase</tt>, <tt>clear</tt>,
59840  <tt>assign</tt> operations
59841 </li>
59842 </ul>
59843
59844 <p>
59845 In fact, out of all sequence container requirements <tt>array&lt;&gt;</tt> only
59846 provides the following operations:
59847 from sequence requirements (Table 94):
59848 </p>
59849 <blockquote><pre>X(il);
59850 a = il;
59851 </pre></blockquote>
59852 <p>
59853 and from optional requirements (Table 95):
59854 </p>
59855 <blockquote><pre>[], at(), front(), back()
59856 </pre></blockquote>
59857 <p>
59858 This is almost nothing!
59859 </p>
59860
59861 <p>
59862 Note in addition, that due to the fact that
59863 <tt>array</tt> is an aggregate and not a container with
59864 <tt>initializer_lists</tt>
59865 a construction or assignment with an initializer list is valid
59866 for all sequence containers but not valid for array:
59867 </p>
59868
59869 <blockquote><pre>vector&lt;int&gt;  v({1,2,3});   // OK
59870 v = {4,5,6};               // OK
59871
59872 array&lt;int,3&gt; a({1,2,3});   // Error
59873 array&lt;int,3&gt; a = {1,2,3};  // OK
59874 a = {4,5,6};               // Error
59875 </pre></blockquote>
59876
59877 <p>
59878 BTW, for this reason, I am wondering, why <tt>&lt;array&gt;</tt> includes
59879 <tt>&lt;initializer_list&gt;</tt>.
59880 </p>
59881
59882 <p>
59883 IMO, we can't really say that <tt>array</tt> is a sequence container.
59884 <tt>array</tt> is special.
59885 As the solution to this issue seemed to miss some proposed wording
59886 where all could live with, let me try to suggest some.
59887 </p>
59888
59889 </blockquote>
59890
59891 <p><i>[
59892 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
59893 ]</i></p>
59894
59895
59896 <p><i>[
59897 2010 Pittsburgh:  Ok with move to Ready except for "OPEN:" part.
59898 ]</i></p>
59899
59900
59901
59902
59903 <p><b>Proposed resolution:</b></p>
59904
59905 <p><i>In Sequence containers 23.2.3 [sequence.reqmts] modify paragraph 1 as 
59906 indicated: </i> </p>
59907 <blockquote>
59908   <p>1 A sequence container organizes a finite set of objects, all of the same 
59909   type, into a strictly linear arrangement. The library provides <del>five</del>
59910   <ins>four</ins> basic kinds of sequence containers: <del><tt>array</tt>,</del>
59911   <tt>vector</tt>, <tt>forward_list</tt>, <tt>list</tt>, and <tt>deque</tt>.
59912   <ins>In addition, <tt>array</tt> is provided as a sequence container that 
59913   only provides limited sequence operations because it has a fixed number of 
59914   elements.</ins> <del>It</del> <ins>The library</ins> also provides container adaptors that make it easy to 
59915   construct abstract data types, such as <tt>stack</tt>s or <tt>queue</tt>s, out 
59916   of the basic sequence container kinds (or out of other kinds of sequence 
59917   containers that the user might define). </p>
59918 </blockquote>
59919 <p><i>Modify paragraph 2 as follows (just editorial): </i> </p>
59920 <blockquote>
59921   <p>2 The <del>five basic</del> sequence 
59922   containers offer the programmer different complexity trade-offs and should be 
59923   used accordingly. <tt>vector</tt> or <tt>array</tt> is the type of sequence 
59924   container that should be used by default. <tt>list</tt> or <tt>forward_list</tt> 
59925   should be used when there are frequent insertions and deletions from the 
59926   middle of the sequence. <tt>deque</tt> is the data structure of choice when 
59927   most insertions and deletions take place at the beginning or at the end of the 
59928   sequence. </p>
59929 </blockquote>
59930 <p><i>In Class template array 23.3.1 [array] modify paragraph 3 as indicated:
59931 </i> </p>
59932 <blockquote>
59933   <p>3 <del>Unless otherwise specified, all <tt>array</tt> operations are as 
59934   described in 23.2.</del> <ins>An array satisfies all of the requirements of a 
59935   container and of a reversible container (given in two tables in 23.2 [container.requirements]) 
59936   except that a default constructed <tt>array</tt> is not empty, <tt>swap</tt> 
59937   does not have constant complexity, and <tt>swap</tt> may throw exceptions. An <tt>array</tt> satisfies some of the requirements of a 
59938   sequence container (given in 23.2.3 [sequence.reqmts]).</ins> Descriptions are 
59939   provided here only for operations on <tt>array</tt> that are not described
59940   <del>in that Clause</del> <ins>in one of these tables</ins> or for operations 
59941   where there is additional semantic information. </p>
59942 </blockquote>
59943 <p><i>In array specialized algorithms 23.3.1.2 [array.special] add to the 
59944 specification of <tt>swap()</tt>: </i> </p>
59945 <blockquote>
59946   <pre>template &lt;class T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x, array&lt;T,N&gt;&amp; y);
59947 </pre>
59948   <blockquote>
59949     <p>1 <i>Effects:</i> ... </p>
59950     <p><ins><i>Complexity:</i> Linear in <tt>N</tt>. </ins></p>
59951   </blockquote>
59952 </blockquote>
59953
59954
59955
59956
59957
59958
59959
59960
59961
59962 <hr>
59963 <h3><a name="1037"></a>1037. Response to UK 232</h3>
59964 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
59965  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
59966 <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>
59967 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
59968 <p><b>Discussion:</b></p>
59969
59970 <p><b>Addresses UK 232</b></p>
59971
59972 <p>
59973 <tt>match_results</tt> may follow the requirements but is not listed a general
59974 purpose library container.
59975 </p>
59976
59977 <p>
59978 Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation.
59979 </p>
59980
59981 <p><i>[
59982 Summit:
59983 ]</i></p>
59984
59985
59986 <blockquote>
59987 Agree. <tt>operator[]</tt> is defined elsewhere.
59988 </blockquote>
59989
59990 <p><i>[
59991 Batavia (2009-05):
59992 ]</i></p>
59993
59994 <blockquote>
59995 We agree with the proposed resolution.
59996 Move to Tentatively Ready.
59997 </blockquote>
59998
59999
60000 <p><b>Proposed resolution:</b></p>
60001 <p>
60002 In 23.2.3 [sequence.reqmts] Table 84, remove reference to
60003 <tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation.
60004 </p>
60005
60006
60007
60008
60009
60010 <hr>
60011 <h3><a name="1038"></a>1038. Response to UK 233</h3>
60012 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60013  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
60014 <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>
60015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60016 <p><b>Discussion:</b></p>
60017
60018 <p><b>Addresses UK 233</b></p>
60019
60020 <p>
60021 Table 84 is missing references to several new container types.
60022 </p>
60023
60024 <p><i>[
60025 Summit:
60026 ]</i></p>
60027
60028
60029 <blockquote>
60030 Agree.
60031 </blockquote>
60032
60033 <p><i>[
60034 Batavia (2009-05):
60035 ]</i></p>
60036
60037 <blockquote>
60038 We agree with the proposed resolution.
60039 Move to Tentatively Ready.
60040 </blockquote>
60041
60042
60043 <p><b>Proposed resolution:</b></p>
60044 <p>
60045 In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
60046 containers to the following rows:
60047 </p>
60048
60049 <blockquote>
60050 <table border="1">
60051 <caption>Table 84 -- Optional sequence container operations</caption>
60052 <tbody><tr>
60053 <th>Expression</th>
60054 <th>Return type</th>
60055 <th>Operational semantics</th>
60056 <th>Container</th>
60057 </tr>
60058 <tr>
60059 <td><tt>a.front()</tt></td>
60060 <td>...</td>
60061 <td>...</td>
60062 <td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td>
60063 </tr>
60064 <tr>
60065 <td><tt>a.back()</tt></td>
60066 <td>...</td>
60067 <td>...</td>
60068 <td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td>
60069 </tr>
60070 <tr>
60071 <td><tt>a.emplace_front(args)</tt></td>
60072 <td>...</td>
60073 <td>...</td>
60074 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
60075 </tr>
60076 <tr>
60077 <td><tt>a.push_front(t)</tt></td>
60078 <td>...</td>
60079 <td>...</td>
60080 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
60081 </tr>
60082 <tr>
60083 <td><tt>a.push_front(rv)</tt></td>
60084 <td>...</td>
60085 <td>...</td>
60086 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
60087 </tr>
60088 <tr>
60089 <td><tt>a.pop_front()</tt></td>
60090 <td>...</td>
60091 <td>...</td>
60092 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
60093 </tr>
60094 <tr>
60095 <td><tt>a[n]</tt></td>
60096 <td>...</td>
60097 <td>...</td>
60098 <td><tt>vector, deque, basic_string<ins>, array</ins></tt></td>
60099 </tr>
60100 <tr>
60101 <td><tt>a.at(n)</tt></td>
60102 <td>...</td>
60103 <td>...</td>
60104 <td><tt>vector, deque<ins>, basic_string, array</ins></tt></td>
60105 </tr>
60106 </tbody></table>
60107 </blockquote>
60108
60109
60110
60111
60112
60113 <hr>
60114 <h3><a name="1039"></a>1039. Response to UK 234</h3>
60115 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60116  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
60117 <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>
60118 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60119 <p><b>Discussion:</b></p>
60120
60121 <p><b>Addresses UK 234</b></p>
60122
60123 <p>
60124 The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should
60125 also allow for <tt>const_iterator</tt> when called on a const-qualified
60126 container. This would be ugly to specify in the 03 standard, but is
60127 quite easy with the addition of <tt>auto</tt> in this new standard.
60128 </p>
60129
60130 <p><i>[
60131 Summit:
60132 ]</i></p>
60133
60134
60135 <blockquote>
60136 Agree.
60137 </blockquote>
60138
60139 <p><i>[
60140 Batavia (2009-05):
60141 ]</i></p>
60142
60143 <blockquote>
60144 We agree with the proposed resolution.
60145 Move to Tentatively Ready.
60146 </blockquote>
60147
60148
60149 <p><b>Proposed resolution:</b></p>
60150 <p>
60151 In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
60152 </p>
60153
60154 <blockquote>
60155 <table border="1">
60156 <caption>Table 84 -- Optional sequence container operations</caption>
60157 <tbody><tr>
60158 <th>Expression</th>
60159 <th>Return type</th>
60160 <th>Operational semantics</th>
60161 <th>Container</th>
60162 </tr>
60163 <tr>
60164 <td><tt>a.back()</tt></td>
60165 <td><tt>reference; const_reference</tt> for constant <tt>a</tt></td>
60166 <td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td>
60167 <td><tt>vector, list, deque, basic_string</tt></td>
60168 </tr>
60169 </tbody></table>
60170 </blockquote>
60171
60172
60173
60174
60175
60176 <hr>
60177 <h3><a name="1040"></a>1040. Response to UK 238</h3>
60178 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60179  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
60180 <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>
60181 <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>
60182 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60183 <p><b>Discussion:</b></p>
60184
60185 <p><b>Addresses UK 238</b></p>
60186
60187 <p>
60188 Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
60189 same type is dangerous, as user code may or may not violate the One
60190 Definition Rule by providing overloads for 
60191 both types. It is probably too late to specify a single behaviour, but
60192 implementors should document what to expect. Observing that problems can be
60193 avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect. 
60194 </p>
60195 <p>
60196 Suggest Change 'unspecified' to 'implementation defined'.
60197 </p>
60198
60199 <p><i>[
60200 Summit:
60201 ]</i></p>
60202
60203
60204 <blockquote>
60205 Agree with issue. Agree with adding the note but not with changing the
60206 normative text. We believe the note provides sufficient guidance.
60207 </blockquote>
60208
60209 <p><i>[
60210 Batavia (2009-05):
60211 ]</i></p>
60212
60213 <blockquote>
60214 We agree with the proposed resolution.
60215 Move to Tentatively Ready.
60216 </blockquote>
60217
60218
60219 <p><b>Proposed resolution:</b></p>
60220 <p>
60221 In 23.2.4 [associative.reqmts] p6, add:
60222 </p>
60223
60224 <blockquote>
60225 -6- <tt>iterator</tt> of an associative container meets the requirements
60226 of the <tt>BidirectionalIterator</tt> concept. For associative
60227 containers where the value type is the same as the key type, both
60228 <tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It
60229 is unspecified whether or not <tt>iterator</tt> and
60230 <tt>const_iterator</tt> are the same type.
60231 <ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in
60232 this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid
60233 violating the One Definition Rule by always using <tt>const_iterator</tt>
60234 in their function parameter lists <i>-- end note</i>]</ins>
60235 </blockquote>
60236
60237
60238
60239
60240
60241 <hr>
60242 <h3><a name="1044"></a>1044. Response to UK 325</h3>
60243 <p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60244  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
60245 <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>
60246 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60247 <p><b>Discussion:</b></p>
60248
60249 <p><b>Addresses UK 325</b></p>
60250
60251 <p>
60252 We believe constexpr literal values should be a more natural expression
60253 of empty tag types than extern objects as it should improve the
60254 compiler's ability to optimize the empty object away completely.
60255 </p>
60256
60257 <p><i>[
60258 Summit:
60259 ]</i></p>
60260
60261
60262 <blockquote>
60263 Move to review. The current specification is a "hack", and the proposed
60264 specification is a better "hack".
60265 </blockquote>
60266
60267 <p><i>[
60268 Batavia (2009-05):
60269 ]</i></p>
60270
60271 <blockquote>
60272 We agree with the proposed resolution.
60273 Move to Tentatively Ready.
60274 </blockquote>
60275
60276
60277 <p><b>Proposed resolution:</b></p>
60278 <p>
60279 Change the synopsis in 30.4 [thread.mutex]:
60280 </p>
60281
60282 <blockquote><pre>struct defer_lock_t <ins>{}</ins>;
60283 struct try_to_lock_t <ins>{}</ins>;
60284 struct adopt_lock_t <ins>{}</ins>;
60285
60286 <del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>;
60287 <del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>;
60288 <del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>;
60289 </pre></blockquote>
60290
60291
60292
60293
60294
60295
60296 <hr>
60297 <h3><a name="1045"></a>1045. Response to UK 326</h3>
60298 <p><b>Section:</b> 30.4.2.2.1 [thread.lock.unique.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60299  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
60300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60301 <p><b>Discussion:</b></p>
60302
60303 <p><b>Addresses UK 326</b></p>
60304
60305 <p>
60306 The precondition that the mutex is not owned by this thread offers
60307 introduces the risk of un-necessary undefined behaviour into the
60308 program. The only time it matters whether the current thread owns the
60309 mutex is in the lock operation, and that will happen subsequent to
60310 construction in this case. The lock operation has the identical
60311 pre-condition, so there is nothing gained by asserting that precondition
60312 earlier and denying the program the right to get into a valid state
60313 before calling lock.
60314 </p>
60315
60316 <p><i>[
60317 Summit:
60318 ]</i></p>
60319
60320
60321 <blockquote>
60322 Agree, move to review.
60323 </blockquote>
60324
60325 <p><i>[
60326 Batavia (2009-05):
60327 ]</i></p>
60328
60329 <blockquote>
60330 We agree with the proposed resolution.
60331 Move to Tentatively Ready.
60332 </blockquote>
60333
60334
60335 <p><b>Proposed resolution:</b></p>
60336 <p>
60337 Strike 30.4.2.2.1 [thread.lock.unique.cons] p7:
60338 </p>
60339
60340 <blockquote><pre>unique_lock(mutex_type&amp; m, defer_lock_t);
60341 </pre>
60342 <blockquote>
60343 <del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex
60344 the calling thread does not own the mutex.</del>
60345 </blockquote>
60346 </blockquote>
60347
60348
60349
60350
60351
60352
60353 <hr>
60354 <h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
60355 <p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
60356  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-11-20</p>
60357 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
60358 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
60359 <p><b>Discussion:</b></p>
60360
60361 <p>
60362 This is a placeholder issue to track the fact that we (well I) put the standard
60363 into an inconsistent state by requesting that we accept
60364 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
60365 except for the proposed changes to [forward].
60366 </p>
60367
60368 <p>
60369 There will exist in the post meeting mailing
60370 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
60371 which in its current state reflects the state of affairs prior to the Summit
60372 meeting.  I hope to update it in time for the post Summit mailing, but as I write
60373 this issue I have not done so yet.
60374 </p>
60375
60376 <p><i>[
60377 Batavia (2009-05):
60378 ]</i></p>
60379
60380 <blockquote>
60381 Move to Open, awaiting the promised paper.
60382 </blockquote>
60383
60384 <p><i>[
60385 2009-08-02 Howard adds:
60386 ]</i></p>
60387
60388
60389 <blockquote>
60390 <p>
60391 My current preferred solution is:
60392 </p>
60393
60394 <blockquote><pre>template &lt;class T&gt;
60395 struct __base_type
60396 {
60397    typedef typename remove_cv&lt;typename remove_reference&lt;T&gt;::type&gt;::type type;
60398 };
60399
60400 template &lt;class T, class U,
60401    class = typename enable_if&lt;
60402        !is_lvalue_reference&lt;T&gt;::value ||
60403         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
60404         is_lvalue_reference&lt;U&gt;::value&gt;::type,
60405    class = typename enable_if&lt;
60406         is_same&lt;typename __base_type&lt;T&gt;::type,
60407                 typename __base_type&lt;U&gt;::type&gt;::value&gt;::type&gt;
60408 inline
60409 T&amp;&amp;
60410 forward(U&amp;&amp; t)
60411 {
60412    return static_cast&lt;T&amp;&amp;&gt;(t);
60413 }
60414 </pre></blockquote>
60415
60416 <p>
60417 This has been tested by Bill, Jason and myself.
60418 </p>
60419
60420 <p>
60421 It allows the following lvalue/rvalue casts:
60422 </p>
60423
60424 <ol>
60425 <li>
60426 Cast an lvalue <tt>t</tt> to an lvalue <tt>T</tt> (identity).
60427 </li>
60428 <li>
60429 Cast an lvalue <tt>t</tt> to an rvalue <tt>T</tt>.
60430 </li>
60431 <li>
60432 Cast an rvalue <tt>t</tt> to an rvalue <tt>T</tt> (identity).
60433 </li>
60434 </ol>
60435
60436 <p>
60437 It disallows:
60438 </p>
60439
60440 <ol type="a">
60441 <li>
60442 Cast an rvalue <tt>t</tt> to an lvalue <tt>T</tt>.
60443 </li>
60444 <li>
60445 Cast one type <tt>t</tt> to another type <tt>T</tt> (such as <tt>int</tt> to <tt>double</tt>).
60446 </li>
60447 </ol>
60448
60449 <p>
60450 "a." is disallowed as it can easily lead to dangling references.
60451 "b." is disallowed as this function is meant to only change the lvalue/rvalue
60452 characteristic of an expression.
60453 </p>
60454
60455 <p>
60456 Jason has expressed concern that "b." is not dangerous and is useful in contexts
60457 where you want to "forward" a derived type as a base type.  I find this use case
60458 neither dangerous, nor compelling.  I.e. I could live with or without the "b."
60459 constraint.  Without it, forward would look like:
60460 </p>
60461
60462 <blockquote><pre>template &lt;class T, class U,
60463    class = typename enable_if&lt;
60464        !is_lvalue_reference&lt;T&gt;::value ||
60465         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
60466         is_lvalue_reference&lt;U&gt;::value&gt;::type&gt;
60467 inline
60468 T&amp;&amp;
60469 forward(U&amp;&amp; t)
60470 {
60471    return static_cast&lt;T&amp;&amp;&gt;(t);
60472 }
60473 </pre></blockquote>
60474
60475 <p>
60476 Or possibly:
60477 </p>
60478
60479 <blockquote><pre>template &lt;class T, class U,
60480    class = typename enable_if&lt;
60481        !is_lvalue_reference&lt;T&gt;::value ||
60482         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
60483         is_lvalue_reference&lt;U&gt;::value&gt;::type,
60484    class = typename enable_if&lt;
60485         is_base_of&lt;typename __base_type&lt;U&gt;::type,
60486                    typename __base_type&lt;T&gt;::type&gt;::value&gt;::type&gt;
60487 inline
60488 T&amp;&amp;
60489 forward(U&amp;&amp; t)
60490 {
60491    return static_cast&lt;T&amp;&amp;&gt;(t);
60492 }
60493 </pre></blockquote>
60494
60495
60496 <p>
60497 The "promised paper" is not in the post-Frankfurt mailing only because I'm waiting
60498 for the non-concepts draft.  But I'm hoping that by adding this information here
60499 I can keep people up to date.
60500 </p>
60501 </blockquote>
60502
60503 <p><i>[
60504 2009-08-02 David adds:
60505 ]</i></p>
60506
60507
60508 <blockquote>
60509 <p>
60510 <tt>forward</tt> was originally designed to do one thing: perfect forwarding.
60511 That is, inside a function template whose actual argument can be a const
60512 or non-const lvalue or rvalue, restore the original "rvalue-ness" of the
60513 actual argument:
60514 </p>
60515
60516 <blockquote><pre>template &lt;class T&gt;
60517 void f(T&amp;&amp; x)
60518 {
60519     // x is an lvalue here.  If the actual argument to f was an
60520     // rvalue, pass static_cast&lt;T&amp;&amp;&gt;(x) to g; otherwise, pass x.
60521     g( forward&lt;T&gt;(x) );
60522 }
60523 </pre></blockquote>
60524
60525 <p>
60526 Attempting to engineer <tt>forward</tt> to accomodate uses other than perfect
60527 forwarding dilutes its idiomatic meaning.  The solution proposed here
60528 declares that <tt>forward&lt;T&gt;(x)</tt> means nothing more than <tt>static_cast&lt;T&amp;&amp;&gt;(x)</tt>,
60529 with a patchwork of restrictions on what <tt>T</tt> and <tt>x</tt> can be that can't be
60530 expressed in simple English.
60531 </p>
60532
60533 <p>
60534 I would be happy with either of two approaches, whose code I hope (but
60535 can't guarantee) I got right.
60536 </p>
60537
60538 <ol>
60539 <li>
60540 <p>
60541 Use a simple definition of <tt>forward</tt> that accomplishes its original
60542 purpose without complications to accomodate other uses:
60543 </p>
60544
60545 <blockquote><pre>template &lt;class T, class U&gt;
60546 T&amp;&amp; forward(U&amp; x)
60547 {
60548     return static_cast&lt;T&amp;&amp;&gt;(x);
60549 }
60550 </pre></blockquote>
60551 </li>
60552
60553 <li>
60554 <p>
60555 Use a definition of <tt>forward</tt> that protects the user from as many
60556 potential mistakes as possible, by actively preventing <em>all</em> other
60557 uses:
60558 </p>
60559
60560 <blockquote><pre>template &lt;class T, class U&gt;
60561 boost::enable_if_c&lt;
60562     // in forward&lt;T&gt;(x), x is a parameter of the caller, thus an lvalue
60563     is_lvalue_reference&lt;U&gt;::value
60564     // in caller's deduced T&amp;&amp; argument, T can only be non-ref or lvalue ref
60565     &amp;&amp; !is_rvalue_reference&lt;T&gt;::value
60566     // Must not cast cv-qualifications or do any type conversions
60567     &amp;&amp; is_same&lt;T&amp;,U&amp;&gt;::value
60568     , T&amp;&amp;&gt;::type forward(U&amp;&amp; a)
60569 {
60570     return static_cast&lt;T&amp;&amp;&gt;(a);
60571 }
60572 </pre></blockquote>
60573 </li>
60574 </ol>
60575
60576 </blockquote>
60577
60578 <p><i>[
60579 2009-09-27 Howard adds:
60580 ]</i></p>
60581
60582
60583 <blockquote>
60584 A paper,
60585 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>,
60586 is available which compares several implementations (including David's) with respect to several
60587 use cases (including Jason's) and provides wording for one implementation.
60588 </blockquote>
60589
60590 <p><i>[
60591 2009-10 Santa Cruz:
60592 ]</i></p>
60593
60594
60595 <blockquote>
60596 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
60597 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>.
60598 </blockquote>
60599
60600
60601
60602 <p><b>Proposed resolution:</b></p>
60603
60604
60605
60606
60607
60608 <hr>
60609 <h3><a name="1055"></a>1055. Response to UK 98</h3>
60610 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
60611  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-11-20</p>
60612 <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>
60613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
60614 <p><b>Discussion:</b></p>
60615
60616 <p><b>Addresses UK 98</b></p>
60617
60618 <p>
60619 It would be useful to be able to determine the underlying
60620 type of an arbitrary enumeration type. This would allow
60621 safe casting to an integral type (especially needed for
60622 scoped enums, which do not promote), and would allow
60623 use of <tt>numeric_limits</tt>. In general it makes generic
60624 programming with enumerations easier.
60625 </p>
60626
60627 <p><i>[
60628 Batavia (2009-05):
60629 ]</i></p>
60630
60631 <blockquote>
60632 Pete observes (and Tom concurs)
60633 that the proposed resolution seems to require compiler support
60634 for its implementation,
60635 as it seems necessary to look at the range of values
60636 of the enumerated type.
60637 To a first approximation,
60638 a library solution could give an answer based on the size of the type.
60639 If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
60640 then the library might be able to do better,
60641 but there is no such requirement.
60642 Keep status as Open
60643 and solicit input from CWG.
60644 </blockquote>
60645
60646 <p><i>[
60647 2009-05-23 Alisdair adds:
60648 ]</i></p>
60649
60650
60651 <blockquote>
60652 Just to confirm that the BSI originator of this comment assumed it did
60653 indeed imply a compiler intrinsic.  Rather than request a Core extension, it
60654 seemed in keeping with that the type traits interface provides a library API
60655 to unspecified compiler features - where we require several other traits
60656 (e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
60657 </blockquote>
60658
60659 <p><i>[
60660 Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
60661 ]</i></p>
60662
60663
60664 <p><i>[
60665 2009-10 Santa Cruz:
60666 ]</i></p>
60667
60668
60669 <blockquote>
60670 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
60671 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
60672 </blockquote>
60673
60674
60675
60676 <p><b>Proposed resolution:</b></p>
60677 <p>
60678 Add a new row to the table in 20.7.7.6 [meta.trans.other]:
60679 </p>
60680
60681 <blockquote>
60682 <table border="1">
60683 <caption>Table 41 -- Other transformations</caption>
60684 <tbody><tr>
60685 <th>Template</th>
60686 <th>Condition</th>
60687 <th>Comments</th>
60688 </tr>
60689 <tr>
60690 <td>
60691 <tt>template&lt;&nbsp;class&nbsp;T&nbsp;&gt; struct enum_base;</tt>
60692 </td>
60693 <td>
60694 <tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
60695 </td>
60696 <td>
60697 The member typedef <tt>type</tt> shall name the underlying type
60698 of the enum <tt>T</tt>.
60699 </td>
60700 </tr>
60701 </tbody></table>
60702 </blockquote>
60703
60704
60705
60706
60707
60708 <hr>
60709 <h3><a name="1065"></a>1065. Response to UK 168</h3>
60710 <p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60711  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
60712 <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>
60713 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60714 <p><b>Discussion:</b></p>
60715 <p><b>Addresses UK 168</b></p>
60716 <p>
60717 We should make it clear (either by note or normatively) that namespace
60718 <tt>std</tt> may contain inline namespaces, and that entities specified to be
60719 defined in std may in fact be defined in one of these inline namespaces.
60720 (If we're going to use them for versioning, eg when TR2 comes along,
60721 we're going to need that.)
60722 </p>
60723
60724 <p>
60725 Replace "namespace std or namespaces nested within namespace std" with
60726 "namespace std or namespaces nested within namespace std or inline
60727 namespaces nested directly or indirectly within namespace std"
60728 </p>
60729
60730 <p><i>[
60731 Summit:
60732 ]</i></p>
60733
60734 <blockquote>
60735 adopt UK words (some have reservations whether it is correct)
60736 </blockquote>
60737
60738 <p><i>[
60739 2009-05-09 Alisdair improves the wording.
60740 ]</i></p>
60741
60742
60743 <p><i>[
60744 Batavia (2009-05):
60745 ]</i></p>
60746
60747 <blockquote>
60748 <p>
60749 Bill believes there is strictly speaking no need to say that
60750 because no portable test can detect the difference.
60751 However he agrees that it doesn't hurt to say this.
60752 </p>
60753 <p>
60754 Move to Tentatively Ready.
60755 </p>
60756 </blockquote>
60757
60758
60759 <p><b>Proposed resolution:</b></p>
60760 <p>
60761 Change 17.6.1.1 [contents] p2:
60762 </p>
60763
60764 <blockquote>
60765 All library entities except macros, <tt>operator new</tt> and
60766 <tt>operator delete</tt> are defined within the namespace <tt>std</tt> or
60767 namespaces nested within namespace <tt>std</tt>.
60768 <ins>It is unspecified whether names declared in a specific namespace
60769 are declared directly in that namespace, or in an inline namespace inside
60770 that namespace. [<i>Footnote:</i> This gives implementers freedom to support
60771 multiple configurations of the library.]</ins>
60772 </blockquote>
60773
60774
60775
60776
60777
60778 <hr>
60779 <h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3>
60780 <p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60781  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
60782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60783 <p><b>Discussion:</b></p>
60784 <p><b>Addresses UK 189 and JP 27</b></p>
60785 <p>
60786 The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an
60787 important aid for static analysis tools.
60788 </p>
60789
60790 <p>
60791 The following functions should be declared in C++ with the
60792 <tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt>
60793 <tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt>
60794 <tt>rethrow_exception</tt> <tt>throw_with_nested</tt>.
60795 </p>
60796
60797 <p><i>[
60798 Summit:
60799 ]</i></p>
60800
60801 <blockquote>
60802 Agreed.
60803 </blockquote>
60804
60805 <p><i>[
60806 Batavia (2009-05):
60807 ]</i></p>
60808
60809 <blockquote>
60810 We agree with the proposed resolution.
60811 Move to Tentatively Ready.
60812 </blockquote>
60813
60814
60815 <p><b>Proposed resolution:</b></p>
60816 <p>
60817 Change 18.5 [support.start.term] p3:
60818 </p>
60819
60820 <blockquote>
60821 <p>-2- ...</p>
60822 <pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void)
60823 </pre>
60824 <p>-3- ...</p>
60825 <p>-6- ...</p>
60826 <pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status)
60827 </pre>
60828 <p>-7- ...</p>
60829 <p>-11- ...</p>
60830 <pre>void quick_exit<ins> [[noreturn]] </ins>(int status)
60831 </pre>
60832 <p>-12- ...</p>
60833 </blockquote>
60834
60835 <p>
60836 Change the <tt>&lt;exception&gt;</tt> synopsis in 18.8 [support.exception]:
60837 </p>
60838
60839 <blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
60840 ...
60841 void terminate<ins> [[noreturn]] </ins>();
60842 ...
60843 void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
60844 ...
60845 template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
60846 </pre></blockquote>
60847
60848 <p>
60849 Change D.13.3 [unexpected]:
60850 </p>
60851
60852 <blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
60853 </pre></blockquote>
60854
60855 <p>
60856 Change 18.8.3.3 [terminate]:
60857 </p>
60858
60859 <blockquote><pre>void terminate<ins> [[noreturn]] </ins>();
60860 </pre></blockquote>
60861
60862 <p>
60863 Change 18.8.5 [propagation]:
60864 </p>
60865
60866 <blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
60867 </pre></blockquote>
60868
60869 <p>
60870 In the synopsis of 18.8.6 [except.nested] and the definition area change:
60871 </p>
60872
60873 <blockquote><pre>template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
60874 </pre></blockquote>
60875
60876
60877
60878
60879
60880 <hr>
60881 <h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3>
60882 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60883  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
60884 <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>
60885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60886 <p><b>Discussion:</b></p>
60887 <p>
60888 The synopsis in 20.8.14.2 [func.wrap.func] says:
60889 </p>
60890
60891 <blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
60892 class function&lt;R(ArgTypes...)&gt;
60893 {
60894     ...
60895     template&lt;class F&gt; 
60896       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60897             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60898       function(F); 
60899     template&lt;class F&gt; 
60900       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60901             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60902       function(F&amp;&amp;);
60903     ...
60904     template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
60905     template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);
60906     ...
60907     template&lt;class F&gt; 
60908       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
60909             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
60910       function&amp; operator=(F); 
60911     template&lt;class F&gt; 
60912       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60913             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60914       function&amp; operator=(F&amp;&amp;);
60915     ...
60916 };
60917 </pre></blockquote>
60918
60919 <p>
60920 Each of the 3 pairs above are ambiguous.  We need only one of each pair, and we
60921 could do it with either one.  If we choose the <tt>F&amp;&amp;</tt> version we
60922 need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior.
60923 In the proposed wording I've gotten lazy and just used the pass-by-value signature.
60924 </p>
60925
60926 <p><i>[
60927 2009-05-01 Daniel adds:
60928 ]</i></p>
60929
60930
60931 <blockquote>
60932 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a> modifies the second removed constructor.
60933 </blockquote>
60934
60935 <p><i>[
60936 Batavia (2009-05):
60937 ]</i></p>
60938
60939 <blockquote>
60940 <p>
60941 We briefly discussed whether we ought support moveable function objects,
60942 but decided that should be a separate issue if someone cares to propose it.
60943 </p>
60944 <p>
60945 Move to Tentatively Ready.
60946 </p>
60947 </blockquote>
60948
60949
60950 <p><b>Proposed resolution:</b></p>
60951 <p>
60952 Change the synopsis of 20.8.14.2 [func.wrap.func], and remove the associated definitions in
60953 20.8.14.2.1 [func.wrap.func.con]:
60954 </p>
60955
60956 <blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
60957 class function&lt;R(ArgTypes...)&gt;
60958 {
60959     ...
60960     template&lt;class F&gt; 
60961       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60962             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60963       function(F); 
60964     <del>template&lt;class F&gt; 
60965       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60966             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60967       function(F&amp;&amp;);</del>
60968     ...
60969     template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
60970     <del>template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);</del>
60971     ...
60972     template&lt;class F&gt; 
60973       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
60974             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
60975       function&amp; operator=(F); 
60976     <del>template&lt;class F&gt; 
60977       requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
60978             &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
60979       function&amp; operator=(F&amp;&amp;);</del>
60980     ...
60981 };
60982 </pre></blockquote>
60983
60984
60985
60986
60987
60988
60989 <hr>
60990 <h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant&lt;bool&gt;</h3>
60991 <p><b>Section:</b> 20.8.10.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
60992  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
60993 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.isbind">issues</a> in [func.bind.isbind].</p>
60994 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
60995 <p><b>Discussion:</b></p>
60996
60997 <p>
60998 Class template is_bind_expression 20.8.10.1.1 [func.bind.isbind]:
60999 </p>
61000
61001 <blockquote><pre>namespace std {
61002   template&lt;class T&gt; struct is_bind_expression {
61003     static const bool value = see below;
61004   };
61005 }
61006 </pre></blockquote>
61007 <p>
61008 <tt>is_bind_expression</tt> should derive from <tt>std::integral_constant&lt;bool&gt;</tt> like
61009 other similar trait types.
61010 </p>
61011
61012 <p><i>[
61013 Daniel adds:
61014 ]</i></p>
61015
61016 <blockquote>
61017 We need the same thing for the trait <tt>is_placeholder</tt> as well.
61018 </blockquote>
61019 <p><i>[
61020 2009-03-22 Daniel provided wording.
61021 ]</i></p>
61022
61023
61024 <p><i>[
61025 Batavia (2009-05):
61026 ]</i></p>
61027
61028 <blockquote>
61029 <p>
61030 We recommend this be deferred until after the next Committee Draft is issued.
61031 </p>
61032 <p>
61033 Move to Open.
61034 </p>
61035 </blockquote>
61036
61037 <p><i>[
61038 2009-05-31 Peter adds:
61039 ]</i></p>
61040
61041
61042 <blockquote>
61043 <p>
61044 I am opposed to the proposed resolution and to the premise of the issue
61045 in general. The traits's default definitions should NOT derive from
61046 <tt>integral_constant</tt>, because this is harmful, as it misleads people into
61047 thinking that <tt>is_bind_expression&lt;E&gt;</tt> always derives from
61048 <tt>integral_constant</tt>, whereas it may not.
61049 </p>
61050 <p>
61051 <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
61052 specializations, and in fact, this is their primary purpose. Such user
61053 specializations may not derive from <tt>integral_constant</tt>, and the
61054 places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
61055 used intentionally do not require such derivation.
61056 </p>
61057 <p>
61058 The long-term approach here is to switch to
61059 <tt>BindExpression&lt;E&gt;</tt> and <tt>Placeholder&lt;P&gt;</tt>
61060 explicit concepts, of course, but until that happens, I say leave them
61061 alone.
61062 </p>
61063 </blockquote>
61064
61065 <p><i>[
61066 2009-10 post-Santa Cruz:
61067 ]</i></p>
61068
61069
61070 <blockquote>
61071 Move to Tentatively Ready.  We are comfortable with requiring user specializations
61072 to derive from <tt>integral_constant</tt>.
61073 </blockquote>
61074
61075
61076
61077 <p><b>Proposed resolution:</b></p>
61078 <ol>
61079 <li>
61080 <p>
61081 In 20.8.10.1.1 [func.bind.isbind] change as indicated:
61082 </p>
61083 <blockquote><pre>namespace std {
61084  template&lt;class T&gt; struct is_bind_expression <ins>: integral_constant&lt;bool, <i>see below</i>&gt; { };</ins><del>{
61085    static const bool value = <i>see below</i>;
61086  };</del>
61087 }
61088 </pre></blockquote>
61089 </li>
61090 <li>
61091 <p>
61092 In 20.8.10.1.1 [func.bind.isbind]/2 change as indicated:
61093 </p>
61094 <blockquote><pre><del>static const bool value;</del>
61095 </pre>
61096 <blockquote>
61097 -2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
61098   <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression&lt;T&gt;</tt> shall
61099 be publicly derived from
61100         <tt>integral_constant&lt;bool, true&gt;</tt>, otherwise it shall be
61101 publicly derived from
61102           <tt>integral_constant&lt;bool, false&gt;</tt>.</ins>
61103 </blockquote>
61104 </blockquote>
61105 </li>
61106 <li>
61107 <p>
61108 In  [func.bind.isplace] change as indicated:
61109 </p>
61110 <blockquote><pre>namespace std {
61111  template&lt;class T&gt; struct is_placeholder <ins>: integral_constant&lt;int, <i>see below</i>&gt; { };</ins><del>{
61112    static const int value = <i>see below</i>;
61113  };</del>
61114 }
61115 </pre></blockquote>
61116 </li>
61117 <li>
61118 <p>
61119 In  [func.bind.isplace]/2 change as indicated:
61120 </p>
61121 <blockquote><pre><del>static const int value;</del>
61122 </pre>
61123 <blockquote>
61124 -2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
61125   <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt>
61126 shall be publicly
61127           derived from <tt>integral_constant&lt;int, J&gt;</tt> otherwise it shall
61128 be publicly derived
61129           from <tt>integral_constant&lt;int, 0&gt;</tt>.</ins>
61130 </blockquote>
61131 </blockquote>
61132 </li>
61133 </ol>
61134
61135
61136
61137
61138
61139 <hr>
61140 <h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3>
61141 <p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
61142  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
61143 <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>
61144 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
61145 <p><b>Discussion:</b></p>
61146
61147 <p>
61148 Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant
61149 initialization.
61150 </p>
61151
61152 <p><i>[
61153 Batavia (2009-05):
61154 ]</i></p>
61155
61156 <blockquote>
61157 We agree with the proposed resolution.  Move to Tentatively Ready.
61158 </blockquote>
61159
61160
61161 <p><b>Proposed resolution:</b></p>
61162 <p>
61163 Change 20.9 [memory] p2:
61164 </p>
61165
61166 <blockquote><pre>// 20.8.1, allocator argument tag
61167 struct allocator_arg_t { };
61168 const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t();
61169 </pre></blockquote>
61170
61171
61172
61173
61174
61175
61176 <hr>
61177 <h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
61178 <p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
61179  <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-11-20</p>
61180 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
61181 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
61182 <p><b>Discussion:</b></p>
61183 <p><b>Addresses US 65 and US 74.1</b></p>
61184
61185 <p>US 65:</p>
61186
61187 <blockquote>
61188 Scoped allocators and allocator propagation traits add a small amount of
61189 utility at the cost of a great deal of machinery. The machinery is user
61190 visible, and it extends to library components that don't have any
61191 obvious connection to allocators, including basic concepts and simple
61192 components like <tt>pair</tt> and <tt>tuple</tt>.
61193
61194 <p>Suggested resolution:</p>
61195
61196 <p>
61197 Sketch of proposed resolution: Eliminate scoped allocators, replace
61198 allocator propagation traits with a simple uniform rule (e.g. always
61199 propagate on copy and move), remove all mention of allocators from
61200 components that don't explicitly allocate memory (e.g. pair), and adjust
61201 container interfaces to reflect this simplification.
61202 </p>
61203 <p>
61204 Components that I propose eliminating include HasAllocatorType,
61205 is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
61206 and ConstructibleAsElement.
61207 </p>
61208 </blockquote>
61209
61210 <p>US 74.1:</p>
61211
61212 <blockquote>
61213 <p>
61214 Scoped allocators represent a poor trade-off for standardization, since
61215 (1) scoped-allocator--aware containers can be implemented outside the
61216 C++ standard library but used with its algorithms, (2) scoped
61217 allocators only benefit a tiny proportion of the C++ community
61218 (since few C++ programmers even use today's allocators), and (3) all C++
61219 users, especially the vast majority of the C++ community that won't ever
61220 use scoped allocators are forced to cope with the interface complexity
61221 introduced by scoped allocators.
61222 </p>
61223 <p>
61224 In essence, the larger community will suffer to support a very small
61225 subset of the community who can already implement their own
61226 data structures outside of the standard library. Therefore, scoped
61227 allocators should be removed from the working paper.
61228 </p>
61229 <p>
61230 Some evidence of the complexity introduced by scoped allocators:
61231 </p>
61232 <blockquote>
61233 <p>
61234 20.3.5 [pairs], 20.4 [tuple]: Large increase in the
61235 number of pair and tuple constructors.
61236 </p>
61237 <p>
61238 23 [containers]: Confusing "AllocatableElement" requirements throughout.
61239 </p>
61240 </blockquote>
61241 <p>Suggested resolution:</p>
61242
61243 <p>
61244 Remove support for scoped allocators from the working paper. This
61245 includes at least the following changes:
61246 </p>
61247
61248 <blockquote>
61249 <p>
61250 Remove X [allocator.element.concepts]
61251 </p>
61252 <p>
61253 Remove 20.10 [allocator.adaptor]
61254 </p>
61255 <p>
61256 Remove  [construct.element]
61257 </p>
61258 <p>
61259 In Clause 23 [containers]: replace requirements naming the
61260 <tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
61261 <tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
61262 appropriate.
61263 </p>
61264 </blockquote>
61265
61266 </blockquote>
61267
61268 <p><i>[
61269 Post Summit Alan moved from NAD to Open.
61270 ]</i></p>
61271
61272
61273 <p><i>[
61274 2009-05-15 Ganesh adds:
61275 ]</i></p>
61276
61277
61278 <blockquote>
61279 <p>
61280 The requirement <tt>AllocatableElement</tt> should not be replaced with
61281 <tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
61282 one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
61283 the constructor is explicit (as per  [concept.map.fct], twelfth
61284 bullet) but we do want to allow explicit constructors in emplace, as the
61285 following example shows:
61286 </p>
61287
61288 <blockquote><pre>vector&lt;shared_ptr&lt;int&gt;&gt; v;
61289 v.emplace_back(new int); <font color="#C80000">// should be allowed</font>
61290 </pre></blockquote>
61291
61292 <p>
61293 If the issue is accepted and scoped allocators are removed, I suggest to
61294 add a new pair of concepts to  [concept.construct], namely:
61295 </p>
61296
61297 <blockquote><pre>auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
61298  explicit T::T(Args...);
61299 }
61300
61301 auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
61302  : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
61303 { }
61304 </pre></blockquote>
61305
61306 <p>
61307 We should then use <tt>ExplicitConstructible</tt> as the requirement for all
61308 <tt>emplace_xxx()</tt> member functions.
61309 </p>
61310 <p>
61311 For coherence and consistency with the similar concepts
61312 <tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
61313 <tt>Constructible</tt> to:
61314 </p>
61315
61316 <blockquote><pre>auto concept Constructible&lt;typename T, typename... Args&gt;
61317  : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
61318 { }
61319 </pre></blockquote>
61320
61321 <p>
61322 Moreover, all emplace-related concepts in  [container.concepts]
61323 should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
61324 definitions of their axioms. In fact the concepts in  [container.concepts] should be
61325 corrected even if the issue is not accepted.
61326 </p>
61327 <p>
61328 On the other hand, if the issue is not accepted, the scoped allocator
61329 adaptors should be fixed because the following code:
61330 </p>
61331
61332 <blockquote><pre>template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;
61333
61334 vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
61335 v.emplace_back(new int); <font color="#C80000">// ops! doesn't compile</font>
61336 </pre></blockquote>
61337
61338 <p>
61339 doesn't compile, as the member function <tt>construct()</tt> of the scoped
61340 allocator requires non-explicit constructors through concept
61341 <tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
61342 more work than it's worth and is therefore, IMHO, one more reason in
61343 support of the complete removal of scoped allocators.
61344 </p>
61345 </blockquote>
61346
61347 <p><i>[
61348 2009-06-09 Alan adds:
61349 ]</i></p>
61350
61351
61352 <blockquote>
61353 <p>
61354 I reopened this issue because I did not think that these National Body
61355 comments were adequately addressed by marking them NAD. My understanding
61356 is that something can be marked NAD if it is clearly a misunderstanding
61357 or trivial, but a substantive issue that has any technical merit
61358 requires a disposition that addresses the concerns.
61359 </p>
61360 <p>
61361 The notes in the NB comment list (US 65 &amp; US 74.1) say that:
61362 </p>
61363 <ol type="a">
61364 <li>
61365 this issue has not introduced any new arguments not previously discussed,
61366 </li>
61367 <li>
61368 the vote (4-9-3) was not a consensus for removing scoped allocators,
61369 </li>
61370 <li>
61371 the issue is resolved by
61372 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
61373 </li>
61374 </ol>
61375 <p>
61376 My opinion is:
61377 </p>
61378 <ol type="a">
61379 <li>
61380 there are new arguments in both comments regarding concepts (which were
61381 not present in the library when the scoped allocator proposal was voted
61382 in),
61383 </li>
61384 <li>
61385 the vote was clearly not a consensus for removal, but just saying there
61386 was a vote does not provide a rationale,
61387 </li>
61388 <li>
61389 I do not believe that N2840 addresses these comments (although it does
61390 many other things and was voted in with strong approval).
61391 </li>
61392 </ol>
61393
61394 <p>
61395 My motivation to open the issue was to ensure that the NB comments were
61396 adequately addressed in a way that would not risk a "no" vote on our
61397 FCD. If there are responses to the technical concerns raised, then
61398 perhaps they should be recorded. If the members of the NB who authored
61399 the comments are satisfied with N2840 and the other disposition remarks
61400 in the comment list, then I am sure they will say so. In either case,
61401 this issue can be closed very quickly in Frankfurt, and hopefully will
61402 have helped make us more confident of approval with little effort. If in
61403 fact there is controversy, my thought is that it is better to know now
61404 rather than later so there is more time to deal with it.
61405 </p>
61406 </blockquote>
61407
61408 <p><i>[
61409 2009-10 Santa Cruz:
61410 ]</i></p>
61411
61412
61413 <blockquote>
61414 <del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
61415 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
61416 </blockquote>
61417
61418
61419
61420 <p><b>Proposed resolution:</b></p>
61421
61422
61423 <p><b>Rationale:</b></p>
61424 Scoped allocators have been revised significantly.
61425
61426
61427
61428
61429
61430 <hr>
61431 <h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
61432 <p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
61433  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-10-23</p>
61434 <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>
61435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
61436 <p><b>Discussion:</b></p>
61437 <p><b>Addresses UK 265</b></p>
61438
61439 <p>UK-265:</p>
61440 <p>
61441 This effects clause is nonesense. It looks more like an axiom stating
61442 equivalence, and certainly an effects clause cannot change the state of
61443 two arguments passed by const reference
61444 </p>
61445
61446 <p><i>[
61447 2009-09-18 Alisdair adds:
61448 ]</i></p>
61449
61450
61451 <blockquote>
61452 <p>
61453 For random access iterators, the definitions of <tt>(b-a)</tt> and
61454 <tt>(a&lt;b)</tt> are circular:
61455 </p>
61456
61457 <p>
61458 From table Table 104 -- Random access iterator requirements:
61459 </p>
61460
61461 <blockquote><pre>b - a :==&gt;  (a &lt; b) ? distance(a,b) : -distance(b,a)
61462
61463 a &lt; b :==&gt;  b - a &gt; 0
61464 </pre></blockquote>
61465 </blockquote>
61466
61467 <p><i>[
61468 2009-10 Santa Cruz:
61469 ]</i></p>
61470
61471
61472 <blockquote>
61473 Moved to Ready.
61474 </blockquote>
61475
61476 <p><i>[
61477 2010-02-13 Alisdair opens.
61478 ]</i></p>
61479
61480
61481 <blockquote>
61482 <p>
61483 Looking again at LWG #1079, the wording in the issue no longer exists, and
61484 appears to be entirely an artefact of the concepts wording.
61485 </p>
61486
61487 <p>
61488 This issue is currently on our Ready list (not even Tentative!) but I think it
61489 has to be pulled as there is no way to apply the resolution.
61490 </p>
61491
61492 <p>
61493 Looking at the current paper, I think this issue is now "NAD, solved by the
61494 removal of concepts".  Unfortunately it is too late to poll again, so we will
61495 have to perform that review in Pittsburgh.
61496 </p>
61497 </blockquote>
61498
61499 <p><i>[
61500 2010-02-13 Daniel updates the wording to address the circularity problem.
61501 ]</i></p>
61502
61503
61504 <blockquote>
61505 <p><i>[
61506 The previous wording is preserved here:
61507 ]</i></p>
61508
61509 <blockquote>
61510
61511 <p>Modify 24.2.7 [random.access.iterators]p7-9 as follows:</p>
61512
61513 <blockquote><pre>difference_type operator-(const X&amp; a, const X&amp; b);
61514 </pre>
61515 <ol start="7">
61516   <li><i>Precondition</i>: there exists a value <code>n</code> of
61517   <code>difference_type</code> such that <code>a == b + n</code>.</li>
61518   <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
61519   <li><i>Returns</i>: <del><code>(a &lt; b) ? distance(a,b) :
61520   -distance(b,a)</code></del><ins><code>n</code></ins></li>
61521 </ol>
61522 </blockquote>
61523
61524 </blockquote>
61525 </blockquote>
61526
61527 <p><i>[
61528 2010 Pittsburgh:
61529 ]</i></p>
61530
61531
61532 <blockquote>
61533 Moved to Ready for Pittsburgh.
61534 </blockquote>
61535
61536
61537
61538 <p><b>Proposed resolution:</b></p>
61539 <p>
61540 Modify Table 105 in 24.2.7 [random.access.iterators]:
61541 </p>
61542
61543 <blockquote>
61544 <table border="1">
61545 <caption>Table 105 \97 Random access iterator requirements (in addition to
61546 bidirectional iterator)</caption>
61547
61548 <tbody><tr>
61549 <th>Expression</th>
61550 <th>Return type</th>
61551 <th>Operational semantics</th>
61552 <th>Assertion/note<br>pre-/post-condition</th>
61553 </tr>
61554
61555 <tr>
61556 <td><tt>b - a</tt></td>
61557 <td><tt>Distance</tt></td>
61558 <td><tt><del>distance(a,b)</del></tt>
61559 <ins>return <tt>n</tt></ins></td>
61560 <td>pre: there exists a value <tt>n</tt> of <tt>Distance</tt> such that <tt>a +
61561 n == b</tt>. <tt>b == a + (b - a)</tt>.</td>
61562 </tr>
61563
61564 </tbody></table>
61565 </blockquote>
61566
61567
61568
61569
61570
61571 <hr>
61572 <h3><a name="1089"></a>1089. Response to JP 76</h3>
61573 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
61574  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
61575 <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>
61576 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
61577 <p><b>Discussion:</b></p>
61578 <p><b>Addresses JP 76</b></p>
61579
61580 <p>
61581 A description for "Throws: Nothing." are not unified.
61582 </p>
61583
61584 <p>
61585 At the part without throw, "Throws: Nothing." should be described.
61586 </p>
61587
61588 <p>
61589 Add "Throws: Nothing." to the following.
61590 </p>
61591
61592 <ul>
61593 <li>
61594 30.3.1.6 [thread.thread.static] p1
61595 </li>
61596 <li>
61597 30.4.2.1 [thread.lock.guard] p4
61598 </li>
61599 <li>
61600 30.4.2.2.1 [thread.lock.unique.cons] p6
61601 </li>
61602 <li>
61603 30.5.1 [thread.condition.condvar] p7 and p8
61604 </li>
61605 <li>
61606 30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
61607 </li>
61608 </ul>
61609
61610 <p><i>[
61611 Summit:
61612 ]</i></p>
61613
61614 <blockquote>
61615 Pass on to editor.
61616 </blockquote>
61617
61618 <p><i>[
61619 Post Summit:  Editor declares this non-editorial.
61620 ]</i></p>
61621
61622
61623 <p><i>[
61624 2009-08-01 Howard provided wording:
61625 ]</i></p>
61626
61627
61628 <blockquote>
61629
61630 <p>
61631 The definition of "<i>Throws:</i> Nothing." that I added is probably going to
61632 be controversial, but I beg you to consider it seriously.
61633 </p>
61634
61635 <blockquote>
61636 <p>
61637 In C++ there are three "flow control" options for a function:
61638 </p>
61639
61640 <ol>
61641 <li>
61642 It can return, either with a value, or with <tt>void</tt>.
61643 </li>
61644 <li>
61645 It can call a function which never returns, such as <tt>std::exit</tt> or
61646 <tt>std::terminate</tt>.
61647 </li>
61648 <li>
61649 It can throw an exception.
61650 </li>
61651 </ol>
61652
61653 The above list can be abbreviated with:
61654
61655 <ol>
61656 <li><b>R</b>eturns.</li>
61657 <li><b>E</b>nds program.</li>
61658 <li><b>T</b>hrows exception.</li>
61659 </ol>
61660
61661 <p>
61662 In general a function can have the behavior of any of these 3, or any combination
61663 of any of these three, depending upon run time data.
61664 </p>
61665
61666 <ol>
61667 <li><b>R</b></li>
61668 <li><b>E</b></li>
61669 <li><b>T</b></li>
61670 <li><b>RE</b></li>
61671 <li><b>RT</b></li>
61672 <li><b>ET</b></li>
61673 <li><b>RET</b></li>
61674 </ol>
61675
61676 <p>
61677 A function with no throw spec, and no documentation, is in general a <b>RET</b>
61678 function.  It may return, it may end the program, or it may throw.  When we
61679 specify a function with an empty throw spec:
61680 </p>
61681
61682 <blockquote><pre>void f() throw();
61683 </pre></blockquote>
61684
61685 <p>
61686 We are saying that <tt>f()</tt> is an <b>RE</b> function:  It may return or end
61687 the program, but it will not throw.
61688 </p>
61689
61690 <p>
61691 I posit that there are very few places in the library half of the standard
61692 where we intend for functions to be able to end the program (call <tt>terminate</tt>).
61693 And none of those places where we do say <tt>terminate</tt> could be called,
61694 do we currently say "<i>Throws:</i> Nothing.".
61695 </p>
61696
61697 <p>
61698 I believe that if we define "<i>Throws:</i> Nothing." to mean <b>R</b>,
61699 we will both clarify many, many places in the standard, <em>and</em> give us a
61700 good rationale for choosing between "<i>Throws:</i> Nothing." (<b>R</b>)
61701 and <tt>throw()</tt> (<b>RE</b>) in the future.  Indeed, this may give us motivation
61702 to change several <tt>throw()</tt>s to "<i>Throws:</i> Nothing.".
61703 </p>
61704 </blockquote>
61705
61706 <p>
61707 I did not add the following changes as JP 76 requested as I believe we want to
61708 allow these functions to throw:
61709 </p>
61710
61711 <blockquote>
61712 <p>
61713 Add a paragraph under 30.4.2.1 [thread.lock.guard] p4:
61714 </p>
61715
61716 <blockquote><pre>explicit lock_guard(mutex_type&amp; m);
61717 </pre>
61718
61719 <p><ins>
61720 <i>Throws:</i> Nothing.
61721 </ins></p>
61722 </blockquote>
61723
61724 <p>
61725 Add a paragraph under 30.4.2.2.1 [thread.lock.unique.cons] p6:
61726 </p>
61727
61728 <blockquote><pre>explicit unique_lock(mutex_type&amp; m);
61729 </pre>
61730
61731 <p><ins>
61732 <i>Throws:</i> Nothing.
61733 </ins></p>
61734 </blockquote>
61735
61736 <p>
61737 Add a paragraph under 30.5.2 [thread.condition.condvarany] p19, p21 and p25:
61738 </p>
61739
61740 <blockquote><pre>template &lt;class Lock, class Rep, class Period&gt; 
61741   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
61742 </pre>
61743
61744 <p><ins>
61745 <i>Throws:</i> Nothing.
61746 </ins></p>
61747 </blockquote>
61748
61749 <blockquote><pre>template &lt;class Lock, class Duration, class Predicate&gt; 
61750   bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; rel_time, Predicate pred);
61751 </pre>
61752
61753 <p><ins>
61754 <i>Throws:</i> Nothing.
61755 </ins></p>
61756 </blockquote>
61757
61758 <blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
61759   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
61760 </pre>
61761
61762 <p><ins>
61763 <i>Throws:</i> Nothing.
61764 </ins></p>
61765 </blockquote>
61766
61767 </blockquote>
61768
61769 </blockquote>
61770
61771 <p><i>[
61772 2009-10 Santa Cruz:
61773 ]</i></p>
61774
61775
61776 <blockquote>
61777 Defer pending further developments with exception restriction annotations.
61778 </blockquote>
61779
61780 <p><i>[
61781 2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
61782 ]</i></p>
61783
61784
61785 <p><i>[
61786 2010-02-24 Pete moved to Open:
61787 ]</i></p>
61788
61789
61790 <blockquote>
61791 A "<i>Throws:</i> Nothing" specification is not the place to say that a function
61792 is not allowed to call <tt>exit()</tt>. While I agree with the thrust of the
61793 proposed resolution, "doesn't throw exceptions" is a subset of "always returns
61794 normally". If it's important to say that most library functions don't call
61795 <tt>exit()</tt>, say so.
61796 </blockquote>
61797
61798 <p><i>[
61799 2010 Pittsburgh:
61800 ]</i></p>
61801
61802
61803 <blockquote>
61804 Move to Ready except for the added paragraph to 17.5.1.4 [structure.specifications].
61805 </blockquote>
61806
61807
61808
61809 <p><b>Proposed resolution:</b></p>
61810
61811
61812 <p>
61813 Add a paragraph under 30.3.1.6 [thread.thread.static] p1:
61814 </p>
61815
61816 <blockquote><pre>unsigned hardware_concurrency();
61817 </pre>
61818
61819 <p>
61820 -1- <i>Returns:</i> ...
61821 </p>
61822
61823 <p><ins>
61824 <i>Throws:</i> Nothing.
61825 </ins></p>
61826 </blockquote>
61827
61828 <p>
61829 Add a paragraph under 30.5.1 [thread.condition.condvar] p7 and p8:
61830 </p>
61831
61832 <blockquote>
61833 <p>
61834 <i>[Informational, not to be incluced in the WP: The POSIX spec allows only:</i>
61835 </p>
61836 <dl>
61837 <dt><i>[EINVAL]</i></dt>
61838 <dd><i>The value <tt>cond</tt> does not refer to an initialized condition variable. \97 end informational]</i></dd>
61839 </dl>
61840
61841 <pre>void notify_one();
61842 </pre>
61843
61844 <p>
61845 -7- <i>Effects:</i> ...
61846 </p>
61847
61848 <p><ins>
61849 <i>Throws:</i> Nothing.
61850 </ins></p>
61851 </blockquote>
61852
61853 <blockquote><pre>void notify_all();
61854 </pre>
61855
61856 <p>
61857 -8- <i>Effects:</i> ...
61858 </p>
61859
61860 <p><ins>
61861 <i>Throws:</i> Nothing.
61862 </ins></p>
61863 </blockquote>
61864
61865
61866 <p>
61867 Add a paragraph under 30.5.2 [thread.condition.condvarany] p6 and p7:
61868 </p>
61869
61870 <blockquote>
61871 <pre>void notify_one();
61872 </pre>
61873
61874 <p>
61875 -6- <i>Effects:</i> ...
61876 </p>
61877
61878 <p><ins>
61879 <i>Throws:</i> Nothing.
61880 </ins></p>
61881 </blockquote>
61882
61883 <blockquote><pre>void notify_all();
61884 </pre>
61885
61886 <p>
61887 -7- <i>Effects:</i> ...
61888 </p>
61889
61890 <p><ins>
61891 <i>Throws:</i> Nothing.
61892 </ins></p>
61893 </blockquote>
61894
61895
61896
61897
61898
61899
61900
61901 <hr>
61902 <h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
61903 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
61904  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24 <b>Last modified:</b> 2010-10-23</p>
61905 <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>
61906 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
61907 <p><b>Discussion:</b></p>
61908 <p><b>Addresses JP 65 and JP 66</b></p>
61909
61910 <p>
61911 Switch from "unspecified-bool-type" to "explicit operator bool() const". 
61912 </p>
61913
61914 <p>
61915 Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
61916 </p>
61917
61918 <p><i>[
61919 Batavia (2009-05):
61920 ]</i></p>
61921
61922 <blockquote>
61923 We agree with the proposed resolution.
61924 Move to Review.
61925 </blockquote>
61926
61927 <p><i>[
61928 2009 Santa Cruz:
61929 ]</i></p>
61930
61931
61932 <blockquote>
61933 Moved to Ready.
61934 </blockquote>
61935
61936
61937
61938 <p><b>Proposed resolution:</b></p>
61939 <p>
61940 Change the synopis in 27.5.4 [ios]:
61941 </p>
61942
61943 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
61944 </pre></blockquote>
61945
61946 <p>
61947 Change 27.5.4.3 [iostate.flags]:
61948 </p>
61949
61950 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
61951 </pre>
61952
61953 <blockquote>
61954 <p>
61955 -1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
61956 false in a boolean context; otherwise a value that will evaluate true in
61957 a boolean context. The value type returned shall not be convertible to
61958 int.</del>
61959 </p>
61960 <p>
61961 <del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
61962 (e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
61963 to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
61964 eliminating some sources of user error. One possible implementation
61965 choice for this type is pointer-to-member. <i>-- end note</i>]</del>
61966 </p>
61967 </blockquote>
61968 </blockquote>
61969
61970
61971
61972
61973
61974
61975
61976 <hr>
61977 <h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
61978 <p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
61979  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27 <b>Last modified:</b> 2010-10-23</p>
61980 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
61981 <p><b>Discussion:</b></p>
61982 <p>
61983 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
61984 <i>Small library thread-safety revisions</i>, among other changes, removed a note from
61985 17.6.3.10 [res.on.objects] that read:
61986 </p>
61987
61988 <blockquote>
61989 [<i>Note:</i> This prohibition against concurrent non-const access means that
61990 modifying an object of a standard library type shared between threads
61991 without using a locking mechanism may result in a data race. <i>--end note</i>.]
61992 </blockquote>
61993
61994 <p>
61995 That resulted in wording which is technically correct but can only be
61996 understood by reading the lengthy and complex 17.6.4.9 [res.on.data.races]
61997 Data race avoidance. This has the effect of making
61998 17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
61999 to the LWG reflector. See c++std-lib-23194.
62000 </p>
62001
62002 <p><i>[
62003 Batavia (2009-05):
62004 ]</i></p>
62005
62006 <blockquote>
62007 <p>
62008 The proposed wording seems to need a bit of tweaking
62009 ("really bad idea" isn't quite up to standardese).
62010 We would like feedback
62011 as to whether the original Note's removal was intentional.
62012 </p>
62013 <p>
62014 Change the phrase "is a really bad idea"
62015 to "risks undefined behavior" and
62016 move to Review status.
62017 </p>
62018 </blockquote>
62019
62020 <p><i>[
62021 2009-10 Santa Cruz:
62022 ]</i></p>
62023
62024
62025 <blockquote>
62026 Note: Change to read: "Modifying...", Delete 'thus', move to Ready
62027 </blockquote>
62028
62029
62030
62031 <p><b>Proposed resolution:</b></p>
62032 <p>
62033 Change 17.6.3.10 [res.on.objects] as indicated:
62034 </p>
62035
62036 <blockquote>
62037 <p>
62038 The behavior of a program is undefined if calls to standard library
62039 functions from different threads may introduce a data race. The
62040 conditions under which this may occur are specified in 17.6.4.7.
62041 </p>
62042 <p><ins>
62043 [<i>Note:</i> Modifying an object of a standard library type shared between
62044 threads risks undefined behavior unless objects of the type are explicitly
62045 specified as being sharable without data races or the user supplies a
62046 locking mechanism. <i>--end note</i>]
62047 </ins></p>
62048 </blockquote>
62049
62050
62051
62052
62053
62054 <hr>
62055 <h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
62056 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62057  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
62058 <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>
62059 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62060 <p><b>Discussion:</b></p>
62061 <p><b>Addresses DE 18</b></p>
62062
62063 <p>
62064 Freestanding implementations do not (necessarily) have
62065   support for multiple threads (see 1.10 [intro.multithread]).
62066   Applications and libraries may want to optimize for the
62067   absence of threads.  I therefore propose a preprocessor
62068   macro to indicate whether multiple threads can occur.
62069 </p>
62070
62071 <p>
62072 There is ample prior implementation experience for this
62073   feature with various spellings of the macro name.  For
62074   example, gcc implicitly defines <tt>_REENTRANT</tt>
62075   if multi-threading support is selected on the compiler
62076   command-line.
62077 </p>
62078
62079 <p>
62080 While this is submitted as a library issue, it may be more
62081   appropriate to add the macro in 16.8 cpp.predefined in the
62082   core language.
62083 </p>
62084
62085 <p>
62086 See also
62087 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
62088 </p>
62089
62090 <p><i>[
62091 Batavia (2009-05):
62092 ]</i></p>
62093
62094 <blockquote>
62095 <p>
62096 We agree with the issue, and believe it is properly a library issue.
62097 </p>
62098 <p>
62099 We prefer that the macro be conditionally defined
62100 as part of the <tt>&lt;thread&gt;</tt> header.
62101 </p>
62102 <p>
62103 Move to Review.
62104 </p>
62105 </blockquote>
62106
62107 <p><i>[
62108 2009-10 Santa Cruz:
62109 ]</i></p>
62110
62111
62112 <blockquote>
62113 Move to Ready.
62114 </blockquote>
62115
62116 <p><i>[
62117 2010-02-25 Pete moved to Open:
62118 ]</i></p>
62119
62120
62121 <blockquote>
62122 <p>
62123 The proposed resolution adds a feature-test macro named
62124 <tt>__STDCPP_THREADS</tt>, described after the following new text:
62125 </p>
62126
62127 <blockquote>
62128 The standard library defines the following macros; no explicit prior inclusion
62129 of any header file is necessary.
62130 </blockquote>
62131
62132 <p>
62133 The correct term here is "header", not "header file". But that's minor. The real
62134 problem is that library entities are always defined in headers. If
62135 <tt>__STDCPP_THREADS</tt> is defined without including any header it's part of
62136 the language and belongs with the other predefined macros in the Preprocessor
62137 clause.
62138 </p>
62139
62140 <p>
62141 Oddly enough, the comments from Batavia say "We prefer that the macro be
62142 conditionally defined as part of the <tt>&lt;thread&gt;</tt> header." There's no
62143 mention of a decision to change this.
62144 </p>
62145 </blockquote>
62146
62147 <p><i>[
62148 2010-02-26 Ganesh updates wording.
62149 ]</i></p>
62150
62151
62152 <p><i>[
62153 2010 Pittsburgh:  Adopt Ganesh's wording and move to Review.
62154 ]</i></p>
62155
62156
62157 <p><i>[
62158 2010-03-08 Pete adds:
62159 ]</i></p>
62160
62161
62162 <blockquote>
62163 Most macros we have begin and end with with double underbars, this one
62164 only begins with double underbars.
62165 </blockquote>
62166
62167 <p><i>[
62168 2010 Pittsburgh:  Ganesh's wording adopted and moved to Ready for Pittsburgh.
62169 ]</i></p>
62170
62171
62172
62173
62174 <p><b>Proposed resolution:</b></p>
62175
62176 <p>
62177 Change 17.6.1.3 [compliance]/3:
62178 </p>
62179
62180 <blockquote>
62181 3 The supplied version of the header <tt>&lt;cstdlib&gt;</tt> shall
62182 declare at least the functions <tt>abort()</tt>, <tt>atexit()</tt>, and
62183 <tt>exit()</tt> (18.5). <ins>The supplied version of the header
62184 <tt>&lt;thread&gt;</tt> either shall meet the same requirements as for a
62185 hosted implementation or including it shall have no effect.</ins> The
62186 other headers listed in this table shall meet the same requirements as
62187 for a hosted implementation.
62188 </blockquote>
62189
62190 <p>
62191 Add the following line to table 15:
62192 </p>
62193
62194 <blockquote>
62195 <table border="1">
62196 <caption>Table 15 \97 C++ headers for freestanding implementations</caption>
62197
62198 <tbody><tr>
62199 <th>Subclause</th>
62200 <th>Header(s)</th>
62201 </tr>
62202
62203 <tr>
62204 <td colspan="2">...</td>
62205 </tr>
62206
62207 <tr>
62208 <td><ins>30.3 [thread.threads] Threads</ins></td>
62209 <td><ins><tt>&lt;thread&gt;</tt></ins></td>
62210 </tr>
62211
62212 </tbody></table>
62213
62214 </blockquote>
62215
62216 <p>
62217 Add to the <tt>&lt;thread&gt;</tt> synopsis in 30.3 [thread.threads]/1 the line:
62218 </p>
62219
62220 <blockquote><pre>namespace std {
62221
62222 <ins>#define __STDCPP_THREADS __cplusplus</ins>
62223
62224   class thread;
62225   ...
62226 </pre></blockquote>
62227
62228
62229
62230
62231
62232
62233
62234
62235
62236 <hr>
62237 <h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
62238 <p><b>Section:</b> 20.9.11 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62239  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
62240 <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>
62241 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62242 <p><b>Discussion:</b></p>
62243 <p><b>Addresses DE 18</b></p>
62244
62245 <p>
62246  In 20.9.11 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
62247 to define behavior for
62248  non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
62249  the cited core-language section in paragraph 4 specifies undefined behavior
62250  for the use of such pointer values.  This seems an unfortunate near-contradiction.
62251  I suggest to specify the term <i>relaxed pointer safety</i> in
62252  the core language section and refer to it from the library description.
62253  This issue deals with the library part, the corresponding core issue (c++std-core-13940)
62254  deals with the core modifications.
62255 </p>
62256
62257 <p>
62258 See also
62259 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
62260 </p>
62261
62262 <p><i>[
62263 Batavia (2009-05):
62264 ]</i></p>
62265
62266 <blockquote>
62267 <p>
62268 We recommend if this issue is to be moved,
62269 the issue be moved concurrently with the cited Core issue.
62270 </p>
62271 <p>
62272 We agree with the intent of the proposed resolution.
62273 We would like input from garbage collection specialists.
62274 </p>
62275 <p>
62276 Move to Open.
62277 </p>
62278 </blockquote>
62279
62280 <p><i>[
62281 2009-10 Santa Cruz:
62282 ]</i></p>
62283
62284
62285 <blockquote>
62286 The core issue is 853 and is in Ready status.
62287 </blockquote>
62288
62289
62290
62291 <p><b>Proposed resolution:</b></p>
62292 <p>
62293 In 20.9.11 [util.dynamic.safety] p16, replace the description of
62294 <tt>get_pointer_safety()</tt> with:
62295 </p>
62296
62297 <blockquote>
62298 <p>
62299 <tt>pointer_safety get_pointer_safety();</tt>
62300 </p>
62301 <blockquote>
62302 <p>
62303 <del><i>Returns:</i> an enumeration value indicating the implementation's treatment
62304 of pointers that are not safely derived (3.7.4.3). Returns
62305 <tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
62306 treated the same as pointers that are safely derived for the duration of
62307 the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
62308 safely derived will be treated the same as pointers that are safely
62309 derived for the duration of the program but allows the implementation to
62310 hint that it could be desirable to avoid dereferencing pointers that are
62311 not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
62312 might be returned to detect if a leak detector is running to avoid
62313 spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
62314 pointers that are not safely derived might be treated differently than
62315 pointers that are safely derived.</del>
62316 </p>
62317 <p><ins>
62318 <i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
62319    strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
62320    implementation-defined whether <tt>get_pointer_safety</tt> returns
62321    <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
62322    implementation has relaxed pointer safety
62323    (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
62324 </ins></p>
62325
62326 <p><ins>
62327 <i>Throws:</i> nothing
62328 </ins></p>
62329
62330 <p><ins>
62331 Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
62332    program that a leak detector is running so that the program can avoid
62333    spurious leak reports.
62334 </ins>
62335 </p>
62336
62337 </blockquote>
62338 </blockquote>
62339
62340
62341
62342
62343
62344 <hr>
62345 <h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
62346 <p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
62347  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-11-19</p>
62348 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
62349 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
62350 <p><b>Discussion:</b></p>
62351 <p>
62352 Message c++std-lib-23182 led to a discussion in which several people
62353 expressed interest in being able to convert an <tt>auto_ptr</tt> to a
62354 <tt>unique_ptr</tt> without the need to call <tt>release</tt>.  Below is
62355 wording to accomplish this.
62356 </p>
62357
62358 <p><i>[
62359 Batavia (2009-05):
62360 ]</i></p>
62361
62362 <blockquote>
62363 <p>
62364 Pete believes it not a good idea to separate parts of a class's definition.
62365 Therefore, if we do this,
62366 it should be part of <tt>unique-ptr</tt>'s specification.
62367 </p>
62368 <p>
62369 Alisdair believes the lvalue overload may be not necessary.
62370 </p>
62371 <p>
62372 Marc believes it is more than just sugar,
62373 as it does ease the transition to <tt>unique-ptr</tt>.
62374 </p>
62375 <p>
62376 We agree with the resolution as presented.
62377 Move to Tentatively Ready.
62378 </p>
62379 </blockquote>
62380
62381 <p><i>[
62382 2009-07 Frankfurt
62383 ]</i></p>
62384
62385
62386 <blockquote>
62387 Moved from Tentatively Ready to Open only because the wording needs to be
62388 tweaked for concepts removal.
62389 </blockquote>
62390
62391 <p><i>[
62392 2009-08-01 Howard deconceptifies wording:
62393 ]</i></p>
62394
62395
62396 <blockquote>
62397 I also moved the change from D.12 [depr.auto.ptr]
62398 to 20.9.9.2 [unique.ptr.single] per the Editor's request
62399 in Batavia (as long as I was making changes anyway).  Set back
62400 to Review.
62401 </blockquote>
62402
62403 <p><i>[
62404 2009-10 Santa Cruz:
62405 ]</i></p>
62406
62407
62408 <blockquote>
62409 Move to Ready.
62410 </blockquote>
62411
62412 <p><i>[
62413 2010-03-14 Howard adds:
62414 ]</i></p>
62415
62416
62417 <blockquote>
62418 We moved
62419 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
62420 to the formal motions page in Pittsburgh which should obsolete this issue.  I've
62421 moved this issue to NAD Editorial, solved by N3073.
62422 </blockquote>
62423
62424
62425
62426 <p><b>Rationale:</b></p>
62427 <p>
62428 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
62429 </p>
62430
62431
62432 <p><b>Proposed resolution:</b></p>
62433 <p>
62434 Add to 20.9.9.2 [unique.ptr.single]:
62435 </p>
62436
62437 <blockquote><pre>template &lt;class T, class D&gt;
62438 class unique_ptr
62439 {
62440 public:
62441 <ins>    template &lt;class U&gt;
62442       unique_ptr(auto_ptr&lt;U&gt;&amp; u);
62443     template &lt;class U&gt;
62444       unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);</ins>
62445 };
62446 </pre></blockquote>
62447
62448 <p>
62449 Add to 20.9.9.2.1 [unique.ptr.single.ctor]:
62450 </p>
62451
62452 <blockquote><pre>template &lt;class U&gt;
62453   unique_ptr(auto_ptr&lt;U&gt;&amp; u);
62454 template &lt;class U&gt;
62455   unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);
62456 </pre>
62457 <blockquote>
62458 <p>
62459 <i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
62460 </p>
62461
62462 <p>
62463 <i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
62464 the construciton, modulo any required offset adjustments resulting from the cast from
62465 <tt>U*</tt> to <tt>T*</tt>.  <tt>u.get() == nullptr</tt>.
62466 </p>
62467
62468 <p>
62469 <i>Throws:</i> nothing.
62470 </p>
62471
62472 <p>
62473 <i>Remarks:</i> <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt> and
62474 <tt>D</tt> shall be the same type as <tt>default_delete&lt;T&gt;</tt>, else these
62475 constructors shall not participate in overload resolution.
62476 </p>
62477 </blockquote>
62478 </blockquote>
62479
62480
62481
62482
62483
62484
62485 <hr>
62486 <h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3>
62487 <p><b>Section:</b> 19.5.6.2 [syserr.syserr.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62488  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
62489 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62490 <p><b>Discussion:</b></p>
62491 <p>
62492 19.5.6.2 [syserr.syserr.members] says:
62493 </p>
62494
62495 <blockquote><pre>system_error(error_code ec, const string&amp; what_arg);
62496 </pre>
62497 <blockquote>
62498 <p>
62499 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
62500 </p>
62501 <p>
62502 <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
62503 </p>
62504 </blockquote>
62505 </blockquote>
62506
62507 <p>
62508 However the intent is for:
62509 </p>
62510
62511 <blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar");
62512 ...
62513 se.what();  <font color="#C80000">// returns something along the lines of:</font>
62514             <font color="#C80000">//   "In FooBar: Not a directory"</font>
62515 </pre></blockquote>
62516
62517 <p>
62518 The way the constructor postconditions are set up now, to achieve both
62519 conformance, and the desired intent in the <tt>what()</tt> string, the
62520 <tt>system_error</tt> constructor must store "In FooBar" in the base class,
62521 and then form the desired output each time <tt>what()</tt> is called.  Or
62522 alternatively, store "In FooBar" in the base class, and store the desired
62523 <tt>what()</tt> string in the derived <tt>system_error</tt>, and override
62524 <tt>what()</tt> to return the string in the derived part.
62525 </p>
62526
62527 <p>
62528 Both of the above implementations seem suboptimal to me.  In one I'm computing
62529 a new string every time <tt>what()</tt> is called.  And since <tt>what()</tt>
62530 can't propagate exceptions, the client may get a different string on different
62531 calls.
62532 </p>
62533
62534 <p>
62535 The second solution requires storing two strings instead of one.
62536 </p>
62537
62538 <p>
62539 What I would like to be able to do is form the desired <tt>what()</tt> string
62540 once in the <tt>system_error</tt> constructor, and store <em>that</em> in the
62541 base class.  Now I'm:
62542 </p>
62543
62544 <ol>
62545 <li>Computing the desired <tt>what()</tt> only once.</li>
62546 <li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li>
62547 <li>I'm not storing multiple strings.</li>
62548 </ol>
62549
62550 <p>
62551 This is smaller code, smaller data, and faster.
62552 </p>
62553
62554 <p>
62555 <tt>ios_base::failure</tt> has the same issue.
62556 </p>
62557
62558 <p><i>[
62559 Comments about this change received favorable comments from the <tt>system_error</tt>
62560 designers.
62561 ]</i></p>
62562
62563
62564 <p><i>[
62565 Batavia (2009-05):
62566 ]</i></p>
62567
62568
62569 <blockquote>
62570 <p>
62571 We agree with the proposed resolution.
62572 </p>
62573 <p>
62574 Move to Tentatively Ready.
62575 </p>
62576 </blockquote>
62577
62578
62579 <p><b>Proposed resolution:</b></p>
62580 <p>
62581 In 19.5.6.2 [syserr.syserr.members], change the following constructor postconditions:
62582 </p>
62583
62584 <blockquote>
62585 <pre>system_error(error_code ec, const string&amp; what_arg);
62586 </pre>
62587 <blockquote>
62588 -2- <i>Postconditions:</i> <tt>code() == ec</tt>
62589 and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
62590 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
62591 </blockquote>
62592
62593 <pre>system_error(error_code ec, const char* what_arg);
62594 </pre>
62595 <blockquote>
62596 -4- <i>Postconditions:</i> <tt>code() == ec</tt>
62597 and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
62598 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
62599 </blockquote>
62600
62601 <pre>system_error(error_code ec);
62602 </pre>
62603 <blockquote>
62604 -6- <i>Postconditions:</i> <tt>code() == ec</tt>
62605 <del>and <tt>strcmp(runtime_error::what(), ""</tt></del>.
62606 </blockquote>
62607
62608 <pre>system_error(int ev, const error_category&amp; ecat, const string&amp; what_arg);
62609 </pre>
62610 <blockquote>
62611 -8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
62612 and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
62613 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
62614 </blockquote>
62615
62616 <pre>system_error(int ev, const error_category&amp; ecat, const char* what_arg);
62617 </pre>
62618 <blockquote>
62619 -10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
62620 and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
62621 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
62622 </blockquote>
62623
62624 <pre>system_error(int ev, const error_category&amp; ecat);
62625 </pre>
62626 <blockquote>
62627 -12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
62628 <del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>.
62629 </blockquote>
62630
62631 </blockquote>
62632
62633 <p>
62634 In 19.5.6.2 [syserr.syserr.members], change the description of <tt>what()</tt>:
62635 </p>
62636
62637 <blockquote>
62638 <pre>const char *what() const throw();
62639 </pre>
62640 <blockquote>
62641 <p>
62642 -14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and
62643 <tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>.
62644 </p>
62645 <p>
62646 [<i>Note:</i> <del>One possible implementation would be:</del>
62647 <ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins>
62648 </p>
62649 <blockquote><pre><del>
62650 if (msg.empty()) { 
62651   try { 
62652     string tmp = runtime_error::what(); 
62653     if (code()) { 
62654       if (!tmp.empty()) 
62655         tmp += ": "; 
62656       tmp += code().message(); 
62657     } 
62658     swap(msg, tmp); 
62659   } catch(...) { 
62660     return runtime_error::what(); 
62661   } 
62662 return msg.c_str();
62663 </del></pre></blockquote>
62664 <p>
62665 \97 <i>end note</i>]
62666 </p>
62667 </blockquote>
62668 </blockquote>
62669
62670 <p>
62671 In 27.5.2.1.1 [ios::failure], change the synopsis:
62672 </p>
62673
62674 <blockquote><pre>namespace std { 
62675   class ios_base::failure : public system_error { 
62676   public: 
62677     explicit failure(const string&amp; msg, const error_code&amp; ec = io_errc::stream); 
62678     explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream); 
62679     <del>virtual const char* what() const throw();</del>
62680   }; 
62681 }
62682 </pre></blockquote>
62683
62684 <p>
62685 In 27.5.2.1.1 [ios::failure], change the description of the constructors:
62686 </p>
62687
62688 <blockquote>
62689
62690 <pre>explicit failure(const string&amp; msg, , const error_code&amp; ec = io_errc::stream);
62691 </pre>
62692 <blockquote>
62693 <p>
62694 -3- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
62695 <ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
62696 </p>
62697 <p>
62698 <del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del>
62699 </p>
62700 </blockquote>
62701
62702 <pre>explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream);
62703 </pre>
62704 <blockquote>
62705 <p>
62706 -5- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
62707 <ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
62708 </p>
62709 <p>
62710 <del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del>
62711 </p>
62712 </blockquote>
62713
62714 </blockquote>
62715
62716 <p>
62717 In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition
62718 need not be repeated here).
62719 </p>
62720
62721 <blockquote>
62722 <pre><del>const char* what() const;</del>
62723 </pre>
62724 <blockquote>
62725 <del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del>
62726 </blockquote>
62727
62728 </blockquote>
62729
62730
62731
62732
62733
62734
62735 <hr>
62736 <h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
62737 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62738  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
62739 <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>
62740 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62741 <p><b>Discussion:</b></p>
62742 <p>
62743 With the rvalue reference changes in
62744 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
62745 <tt>basic_ios::move</tt> no longer has the most convenient signature:
62746 </p>
62747
62748 <blockquote><pre>void move(basic_ios&amp;&amp; rhs);
62749 </pre></blockquote>
62750
62751 <p>
62752 This signature should be changed to accept lvalues.  It does not need to be
62753 overloaded to accept rvalues.  This is a special case that only derived clients
62754 will see.  The generic <tt>move</tt> still needs to accept rvalues.
62755 </p>
62756
62757 <p><i>[
62758 Batavia (2009-05):
62759 ]</i></p>
62760
62761 <blockquote>
62762 <p>
62763 Tom prefers, on general principles, to provide both overloads.
62764 Alisdair agrees.
62765 </p>
62766 <p>
62767 Howard points out that there is no backward compatibility issue
62768 as this is new to C++0X.
62769 </p>
62770 <p>
62771 We agree that both overloads should be provided,
62772 and Howard will provide the additional wording.
62773 Move to Open.
62774 </p>
62775 </blockquote>
62776
62777 <p><i>[
62778 2009-05-23 Howard adds:
62779 ]</i></p>
62780
62781
62782 <blockquote>
62783 Added overload, moved to Review.
62784 </blockquote>
62785
62786 <p><i>[
62787 2009 Santa Cruz:
62788 ]</i></p>
62789
62790
62791 <blockquote>
62792 Move to Ready.
62793 </blockquote>
62794
62795
62796
62797 <p><b>Proposed resolution:</b></p>
62798 <p>
62799 Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
62800 and in 27.5.4.2 [basic.ios.members]:
62801 </p>
62802
62803 <blockquote><pre><ins>void move(basic_ios&amp; rhs);</ins>
62804 void move(basic_ios&amp;&amp; rhs);
62805 </pre></blockquote>
62806
62807
62808
62809
62810
62811 <hr>
62812 <h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
62813 <p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62814  <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
62815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62816 <p><b>Discussion:</b></p>
62817 <p>
62818 The current formulation of 30.2.2 [thread.req.exception]/2 reads:
62819 </p>
62820 <blockquote>
62821 The error_category of the <tt>error_code</tt> reported by such an
62822 exception's <tt>code()</tt> member function is as specified in the error
62823 condition Clause.
62824 </blockquote>
62825 <p>
62826 This constraint on the code's associated <tt>error_categor</tt> means an
62827 implementation must perform a mapping from the system-generated
62828 error to a <tt>generic_category()</tt> error code. The problems with this
62829 include:
62830 </p>
62831
62832 <ul>
62833 <li>
62834 The mapping is always performed, even if the resultant value is
62835  never used.
62836 </li>
62837 <li>
62838 <p>
62839 The original error produced by the operating system is lost.
62840 </p>
62841 </li>
62842 </ul>
62843 <p>
62844 The latter was one of Peter Dimov's main objections (in a private
62845 email discussion) to the original <tt>error_code</tt>-only design, and led to
62846 the creation of <tt>error_condition</tt> in the first place. Specifically,
62847 <tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
62848 roles:
62849 </p>
62850 <ul>
62851 <li>
62852 <tt>error_code</tt> holds the original error produced by the operating
62853  system.
62854 </li>
62855 <li>
62856 <tt>error_condition</tt> and the generic category provide a set of well
62857  known error constants that error codes may be tested against.
62858 </li>
62859 </ul>
62860 <p>
62861 Any mapping determining correspondence of the returned error code to
62862 the conditions listed in the error condition clause falls under the
62863 "latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
62864 (Although obviously their latitude is restricted a little by the
62865 need to match the right error condition when returning an error code
62866 from a library function.)
62867 </p>
62868 <p>
62869 It is important that this <tt>error_code/error_condition</tt> usage is done
62870 correctly for the thread library since it is likely to set the
62871 pattern for future TR libraries that interact with the operating
62872 system.
62873 </p>
62874
62875 <p><i>[
62876 Batavia (2009-05):
62877 ]</i></p>
62878
62879 <blockquote>
62880 Move to Open, and recommend the issue be deferred until after the next
62881 Committee Draft is issued.
62882 </blockquote>
62883
62884 <p><i>[
62885 2009-10 post-Santa Cruz:
62886 ]</i></p>
62887
62888
62889 <blockquote>
62890 Move to Tentatively Ready.
62891 </blockquote>
62892
62893
62894
62895 <p><b>Proposed resolution:</b></p>
62896 <p>
62897 Change 30.2.2 [thread.req.exception]/2:
62898 </p>
62899
62900 <blockquote>
62901 <p>
62902 -2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
62903 such an exception's <tt>code()</tt> member function 
62904 is as specified in the error condition Clause.</del>
62905 <ins>
62906 The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
62907 function shall compare equal to one of the conditions specified in
62908 the function's error condition Clause. [<i>Example:</i> When the thread
62909 constructor fails:
62910 </ins>
62911 </p>
62912 <blockquote><pre><ins>
62913 ec.category() == implementation-defined // probably system_category
62914 ec == errc::resource_unavailable_try_again // holds true
62915 </ins></pre></blockquote>
62916
62917 <p><ins>
62918 \97 <i>end example</i>]
62919 </ins></p>
62920
62921 </blockquote>
62922
62923
62924
62925
62926
62927
62928 <hr>
62929 <h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
62930 <p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
62931  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2010-10-23</p>
62932 <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>
62933 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
62934 <p><b>Discussion:</b></p>
62935 <p>
62936 Quoting working paper for reference (25.2.4 [alg.foreach]):
62937 </p>
62938
62939 <blockquote>
62940 <pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
62941   requires CopyConstructible&lt;Function&gt;
62942   Function for_each(Iter first, Iter last, Function f);
62943 </pre>
62944 <blockquote>
62945 <p>
62946 1 Effects: Applies f to the result of dereferencing every iterator in the
62947  range [first,last), starting from first and proceeding to last - 1.
62948 </p>
62949 <p>
62950 2 Returns: f.
62951 </p>
62952 <p>
62953 3 Complexity: Applies f exactly last - first times.
62954 </p>
62955 </blockquote>
62956 </blockquote>
62957
62958 <p>
62959 P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
62960 some copy of <tt>f</tt>.  This is important if the return value is to usefully
62961 accumulate changes.  So the requirements are an object of type <tt>Function</tt> can
62962 be passed-by-value, invoked multiple times, and then return by value.  In
62963 this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
62964 move-only functors, which might become important in concurrent code as you
62965 can assume there are no other references (copies) of a move-only type and so
62966 freely use them concurrently without additional locks.
62967 </p>
62968
62969 <p><i>[
62970 See further discussion starting with c++std-lib-23686.
62971 ]</i></p>
62972
62973
62974 <p><i>[
62975 Batavia (2009-05):
62976 ]</i></p>
62977
62978 <blockquote>
62979 <p>
62980 Pete suggests we may want to look at this in a broader context
62981 involving other algorithms.
62982 We should also consider the implications of parallelism.
62983 </p>
62984 <p>
62985 Move to Open, and recommend the issue be deferred until after the next
62986 Committee Draft is issued.
62987 </p>
62988 </blockquote>
62989
62990 <p><i>[
62991 2009-10-14 Daniel de-conceptified the proposed resolution.
62992 ]</i></p>
62993
62994
62995 <blockquote>
62996 <p>
62997 The note in 25.1 [algorithms.general]/9 already says the right thing:
62998 </p>
62999 <blockquote>
63000 Unless otherwise specified, algorithms that take function objects
63001 as arguments are permitted to copy those function objects freely.
63002 </blockquote>
63003 <p>
63004 So we only need to ensure that the wording for <tt>for_each</tt> is sufficiently
63005 clear, which is the intend of the following rewording.
63006 </p>
63007 </blockquote>
63008
63009 <p><i>[
63010 2009-10-15 Daniel proposes:
63011 ]</i></p>
63012
63013
63014 <blockquote>
63015 <ul>
63016 <li>
63017 <p>
63018 Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
63019 </p>
63020 <blockquote>
63021 <p>
63022 <ins><i>Requires:</i> <tt>Function</tt> shall be <tt>MoveConstructible</tt>
63023 ( [moveconstructible]), <tt>CopyConstructible</tt> is not required.</ins>
63024 </p>
63025 </blockquote>
63026 </li>
63027 <li>
63028 <p>
63029 Change 25.2.4 [alg.foreach]/2 as indicated:
63030 </p>
63031
63032 <blockquote>
63033 <i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
63034 </blockquote>
63035 </li>
63036 </ul>
63037 </blockquote>
63038
63039 <p><i>[
63040 2009-10 post-Santa Cruz:
63041 ]</i></p>
63042
63043
63044 <blockquote>
63045 Move to Tentatively Ready, using Daniel's wording without the portion
63046 saying "CopyConstructible is not required".
63047 </blockquote>
63048
63049 <p><i>[
63050 2009-10-27 Daniel adds:
63051 ]</i></p>
63052
63053
63054 <blockquote>
63055 <p>
63056 I see that during the Santa Cruz meeting the originally proposed addition
63057 </p>
63058
63059 <blockquote>
63060 , <tt>CopyConstructible</tt> is not required.
63061 </blockquote>
63062
63063 <p>
63064 was removed. I don't think that this removal was a good idea. The combination
63065 of 25.1 [algorithms.general]/9
63066 </p>
63067
63068 <blockquote>
63069 [<i>Note:</i> Unless otherwise specified, algorithms that take function objects
63070 as arguments are permitted to copy those function objects freely.[..]
63071 </blockquote>
63072
63073 <p>
63074 with the fact that <tt>CopyConstructible</tt> is a refinement <tt>MoveConstructible</tt>
63075 makes it necessary that such an explicit statement is given. Even the
63076 existence of the usage of <tt>std::move</tt> in the <i>Returns</i> clause doesn't
63077 help much, because this would still be well-formed for a <tt>CopyConstructible</tt>
63078 without move constructor. Let me add that the originally proposed
63079 addition reflects current practice in the standard, e.g. 25.3.9 [alg.unique]/5
63080 usages a similar terminology.
63081 </p>
63082
63083 <p>
63084 For similar wording need in case for auto_ptr see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>.
63085 </p>
63086
63087 <p><i>[
63088 Howard: Moved from Tentatively Ready to Open.
63089 ]</i></p>
63090
63091 </blockquote>
63092
63093 <p><i>[
63094 2009-11-20 Howard restores "not <tt>CopyConstructible</tt>" to the spec.
63095 ]</i></p>
63096
63097
63098 <p><i>[
63099 2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
63100 ]</i></p>
63101
63102
63103
63104 <p><b>Proposed resolution:</b></p>
63105 <ul>
63106 <li>
63107 <p>
63108 Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
63109 </p>
63110 <blockquote>
63111 <p>
63112 <ins><i>Requires:</i> <tt>Function</tt> shall meet the requirements of
63113 <tt>MoveConstructible</tt> ( [moveconstructible]). 
63114 <tt>Function</tt> need not meet the requirements of
63115 <tt>CopyConstructible</tt> ( [copyconstructible]).</ins>
63116 </p>
63117 </blockquote>
63118 </li>
63119 <li>
63120 <p>
63121 Change 25.2.4 [alg.foreach]/2 as indicated:
63122 </p>
63123
63124 <blockquote>
63125 <i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
63126 </blockquote>
63127 </li>
63128 </ul>
63129
63130
63131
63132
63133
63134
63135
63136
63137 <hr>
63138 <h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
63139 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63140  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2010-10-23</p>
63141 <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>
63142 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63143 <p><b>Discussion:</b></p>
63144 <p>
63145 In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> our resolution is changing the signature by adding two
63146 defaulting arguments to 3 calls.  In principle, this means that ABI breakage
63147 is not an issue, while API is preserved.
63148 </p>
63149 <p>
63150 With that observation, it would be very nice to use the new ability to
63151 supply default template parameters to function templates to collapse all 3
63152 signatures into 1.  In that spirit, this issue offers an alternative resolution
63153 than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>.
63154 </p>
63155
63156 <p><i>[
63157 Batavia (2009-05):
63158 ]</i></p>
63159
63160 <blockquote>
63161 Move to Open,
63162 and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> has been accepted.
63163 We further recommend this be deferred until after the next Committee Draft.
63164 </blockquote>
63165
63166 <p><i>[
63167 2009-10 post-Santa Cruz:
63168 ]</i></p>
63169
63170
63171 <blockquote>
63172 Move to Tentatively Ready.
63173 </blockquote>
63174
63175
63176
63177 <p><b>Proposed resolution:</b></p>
63178
63179 <ol type="A">
63180 <li>
63181 <p>
63182 In 20.5 [template.bitset]/1 (class bitset) ammend:
63183 </p>
63184 <blockquote><pre>template &lt;class charT <ins>= char</ins>,
63185             class traits <ins>= char_traits&lt;charT&gt;</ins>,
63186             class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
63187   basic_string&lt;charT, traits, Allocator&gt;
63188   to_string(charT zero = charT('0'), charT one = charT('1')) const;
63189 <del>template &lt;class charT, class traits&gt; 
63190   basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string() const; 
63191 template &lt;class charT&gt; 
63192   basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string() const; 
63193 basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string() const;</del>
63194 </pre></blockquote>
63195 </li>
63196 <li>
63197 <p>
63198 In 20.5.2 [bitset.members] prior to p35 ammend:
63199 </p>
63200 <blockquote><pre>template &lt;class charT <ins>= char</ins>,
63201             class traits <ins>= char_traits&lt;charT&gt;</ins>,
63202             class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
63203   basic_string&lt;charT, traits, Allocator&gt;
63204   to_string(charT zero = charT('0'), charT one = charT('1')) const;
63205 </pre></blockquote>
63206 </li>
63207 <li>
63208 Strike 20.5.2 [bitset.members] paragraphs 37 -&gt; 39 (including signature
63209 above 37)
63210 </li>
63211 </ol>
63212
63213
63214
63215
63216
63217
63218 <hr>
63219 <h3><a name="1114"></a>1114. Type traits underspecified</h3>
63220 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63221  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12 <b>Last modified:</b> 2010-10-23</p>
63222 <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>
63223 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63224 <p><b>Discussion:</b></p>
63225
63226 <p>
63227 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.
63228 </p>
63229
63230 <p>
63231 The current wording in 20.7.1 [meta.rqmts] is still unclear concerning
63232 it's requirements on the type traits classes regarding ambiguities.
63233 Specifically it's unclear
63234 </p>
63235
63236 <ul>
63237 <li>
63238 if a predicate trait (20.7.4 [meta.unary], 20.7.6 [meta.rel]) could derive from both
63239 <tt>true_type</tt>/<tt>false_type</tt>.
63240 </li>
63241 <li>
63242 if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could ambiguously derive
63243 from the same specified result type.
63244 </li>
63245 <li>
63246 if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could derive from other
63247 <tt>integral_constant</tt> types making the contained names ambiguous
63248 </li>
63249 <li>
63250 if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could have other base
63251 classes that contain members hiding the name of the result type members
63252 or make the contained member names ambiguous.
63253 </li>
63254 </ul>
63255
63256 <p><i>[
63257 Batavia (2009-05):
63258 ]</i></p>
63259
63260 <blockquote>
63261 <p>
63262 Alisdair would prefer to factor some of the repeated text,
63263 but modulo a corner case or two,
63264 he believes the proposed wording is otherwise substantially correct.
63265 </p>
63266 <p>
63267 Move to Open.
63268 </p>
63269 </blockquote>
63270
63271 <p><i>[
63272 2009-10 post-Santa Cruz:
63273 ]</i></p>
63274
63275
63276 <blockquote>
63277 Move to Tentatively Ready.
63278 </blockquote>
63279
63280
63281
63282 <p><b>Proposed resolution:</b></p>
63283 <p><i>[
63284 The usage of the notion of a <i>BaseCharacteristic</i> below might be
63285 useful in other places - e.g. to define the base class relation in 20.8.4 [refwrap], 20.8.13 [func.memfn], or 20.8.14.2 [func.wrap.func]. In this case it's definition should probably
63286 be moved to Clause 17
63287 ]</i></p>
63288
63289
63290 <ol>
63291 <li>
63292 <p>
63293 Change 20.7.1 [meta.rqmts]/1 as indicated:
63294 </p>
63295 <blockquote>
63296 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
63297 <ins>and unambiguously</ins> derived, directly or indirectly, from
63298 <ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
63299 template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
63300 <tt>integral_constant</tt> determined by the requirements for the particular
63301 property being described. <ins>The member names of the
63302 <i>BaseCharacteristic</i> shall be unhidden and unambiguously
63303 available in the <i>UnaryTypeTrait</i>.</ins>
63304 </blockquote>
63305 </li>
63306 <li>
63307 <p>
63308 Change 20.7.1 [meta.rqmts]/2 as indicated:
63309 </p>
63310 <blockquote>
63311 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
63312 <ins>and unambiguously</ins> derived, directly or indirectly, from
63313 <del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
63314 specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
63315 the arguments to the template <tt>integral_constant</tt> determined by the
63316 requirements for the particular relationship being described. <ins>The
63317 member names of the <i>BaseCharacteristic</i> shall be unhidden
63318 and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
63319 </blockquote>
63320 </li>
63321 <li>
63322 <p>
63323 Change 20.7.4 [meta.unary]/2 as indicated:
63324 </p>
63325 <blockquote>
63326 Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
63327 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
63328 corresponding condition is true, otherwise from <tt>false_type</tt></del>
63329 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
63330 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
63331 </blockquote>
63332 </li>
63333 <li>
63334 <p>
63335 Change 20.7.6 [meta.rel]/2 as indicated:
63336 </p>
63337
63338 <blockquote>
63339 Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
63340 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
63341 corresponding condition is true, otherwise from <tt>false_type</tt></del>
63342 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
63343 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
63344 </blockquote>
63345 </li>
63346 </ol>
63347
63348
63349
63350
63351
63352
63353 <hr>
63354 <h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
63355 <p><b>Section:</b> 20.4.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
63356  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-20</p>
63357 <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>
63358 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
63359 <p><b>Discussion:</b></p>
63360 <p>
63361 It is not currently possible to construct <tt>tuple</tt> literal values,
63362 even if the elements are all literal types.  This is because parameters
63363 are passed to constructor by reference.
63364 </p>
63365 <p>
63366 An alternative would be to pass all constructor arguments by value, where it
63367 is known that *all* elements are literal types.  This can be determined with
63368 concepts, although note that the negative constraint really requires
63369 factoring out a separate concept, as there is no way to provide an 'any of
63370 these fails' constraint inline.
63371 </p>
63372 <p>
63373 Note that we will have similar issues with <tt>pair</tt> (and
63374 <tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
63375 clear of that class while other constructor-related issues settle.
63376 </p>
63377
63378 <p><i>[
63379 2009-10 Santa Cruz:
63380 ]</i></p>
63381
63382
63383 <blockquote>
63384 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
63385 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
63386 </blockquote>
63387
63388
63389 <p><b>Proposed resolution:</b></p>
63390 <p>
63391 Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
63392 follows
63393 </p>
63394
63395 <blockquote>
63396 <p>
63397 Add the following concept:
63398 </p>
63399
63400 <blockquote><pre>auto concept AllLiteral&lt; typename ... Types &gt; {
63401   requires LiteralType&lt;Types&gt;...;
63402 }
63403 </pre></blockquote>
63404
63405 <p>
63406 ammend the constructor 
63407 </p>
63408
63409 <blockquote><pre><ins>template &lt;class... UTypes&gt;
63410   requires AllLiteral&lt;Types...&gt;
63411         &amp;&amp; Constructible&lt;Types, UTypes&gt;...
63412   explicit tuple(UTypes...);</ins>
63413
63414 template &lt;class... UTypes&gt;
63415   requires <ins>!AllLiteral&lt;Types...&gt;</ins>
63416         <ins>&amp;&amp;</ins> Constructible&lt;Types, UTypes&amp;&amp;&gt;...
63417   explicit tuple(UTypes&amp;&amp;...);
63418 </pre></blockquote>
63419
63420 <p>
63421 ammend the constructor
63422 </p>
63423
63424 <blockquote><pre><ins>template &lt;class... UTypes&gt;
63425   requires AllLiteral&lt;Types...&gt;
63426         &amp;&amp; Constructible&lt;Types, UTypes&gt;...
63427   tuple(tuple&lt;UTypes...&gt;);</ins>
63428
63429 template &lt;class... UTypes&gt;
63430   requires <ins>!AllLiteral&lt;Types...&gt;</ins>
63431         <ins>&amp;&amp;</ins> Constructible&lt;Types, const UTypes&amp;&gt;...
63432   tuple(const tuple&lt;UTypes...&gt;&amp;);
63433 </pre></blockquote>
63434
63435 </blockquote>
63436
63437 <p>
63438 Update the same signatures in 20.4.2.1 [tuple.cnstr], paras 3 and 5.
63439 </p>
63440
63441
63442
63443
63444
63445 <hr>
63446 <h3><a name="1117"></a>1117. tuple copy constructor</h3>
63447 <p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
63448  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-20</p>
63449 <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>
63450 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
63451 <p><b>Discussion:</b></p>
63452 <p>
63453 The copy constructor for the <tt>tuple</tt> template is constrained.  This seems an
63454 unusual strategy, as the copy constructor will be implicitly deleted if the
63455 constraints are not met.  This is exactly the same effect as requesting an
63456 <tt>=default;</tt> constructor.  The advantage of the latter is that it retains
63457 triviality, and provides support for <tt>tuple</tt>s as literal types if issue
63458 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a> is also accepted.
63459 </p>
63460 <p>
63461 Actually, it might be worth checking with core if a constrained copy
63462 constructor is treated as a constructor template, and as such does not
63463 suppress the implicit generation of the copy constructor which would hide
63464 the template in this case.
63465 </p>
63466
63467 <p><i>[
63468 2009-05-27 Daniel adds:
63469 ]</i></p>
63470
63471
63472 <blockquote>
63473 This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
63474 </blockquote>
63475
63476 <p><i>[
63477 2009-10 Santa Cruz:
63478 ]</i></p>
63479
63480
63481 <blockquote>
63482 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
63483 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.htm">N2994</a>.
63484 </blockquote>
63485
63486
63487 <p><b>Proposed resolution:</b></p>
63488 <p>
63489 Change 20.4.2 [tuple.tuple] and 20.4.2.1 [tuple.cnstr] p4:
63490 </p>
63491
63492 <blockquote><pre><del>requires CopyConstructible&lt;Types&gt;...</del> tuple(const tuple&amp;)<ins> = default</ins>;
63493 </pre></blockquote>
63494
63495
63496
63497
63498
63499 <hr>
63500 <h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
63501 <p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63502  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-23</p>
63503 <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>
63504 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63505 <p><b>Discussion:</b></p>
63506 <p>
63507 The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
63508 cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
63509 </p>
63510 <p>
63511 The most generic solution would be to supply partial specializations once
63512 for each cv-type in the <tt>tuple</tt> header.  However, requiring this header for
63513 cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful.  The BSI editorial
63514 suggestion (UK-198/US-69,
63515 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
63516 to merge <tt>tuple</tt> into <tt>&lt;utility&gt;</tt> would help with <tt>pair</tt>,
63517 but not <tt>array</tt>.  That might be resolved by making a dependency between the
63518 <tt>&lt;array&gt;</tt> header and <tt>&lt;utility&gt;</tt>, or simply recognising
63519 the dependency be fulfilled in a Remark.
63520 </p>
63521
63522 <p><i>[
63523 2009-05-24 Daniel adds:
63524 ]</i></p>
63525
63526
63527 <blockquote>
63528 <p>
63529 All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
63530 </p>
63531
63532 <blockquote><pre>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; :
63533    <ins>public</ins> tuple_size&lt;T&gt; {};
63534 </pre></blockquote>
63535
63536 <p>
63537 The same applies to the tuple_element class hierarchies.
63538 </p>
63539 <p>
63540 What is actually meant with the comment
63541 </p>
63542 <blockquote>
63543 this solution relies on 'metafunction forwarding' to inherit the
63544 nested typename type
63545 </blockquote>
63546 <p>
63547 ?
63548 </p>
63549 <p>
63550 I ask, because all base classes are currently unconstrained and their
63551 instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
63552 template specializations.
63553 </p>
63554 </blockquote>
63555
63556 <p><i>[
63557 2009-05-24 Alisdair adds:
63558 ]</i></p>
63559
63560
63561 <blockquote>
63562 <p>
63563 I think a better solution might be to ask Pete editorially to change all
63564 declarations of tupling APIs to use the struct specifier instead of class.
63565 </p>
63566 <p>
63567 "metafunction forwarding" refers to the MPL metafunction protocol, where a
63568 metafunction result is declared as a nested typedef with the name "type",
63569 allowing metafunctions to be chained by means of inheritance.  It is a
63570 neater syntax than repeatedly declaring a typedef, and inheritance syntax is
63571 slightly nicer when it comes to additional typename keywords.
63572 </p>
63573 <p>
63574 The constrained template with an unconstrained base is a good observation
63575 though.
63576 </p>
63577 </blockquote>
63578
63579 <p><i>[
63580 2009-10 post-Santa Cruz:
63581 ]</i></p>
63582
63583
63584 <blockquote>
63585 Move to Open, Alisdair to provide wording. Once wording is
63586 provided, Howard will move to Review.
63587 </blockquote>
63588
63589 <p><i>[
63590 2010-03-28 Daniel deconceptified wording.
63591 ]</i></p>
63592
63593
63594 <p><i>[
63595 Post-Rapperswil - Daniel provides wording:
63596 ]</i></p>
63597
63598
63599 <p>
63600 The below given P/R reflects the discussion from the Rapperswil meeting that the wording should not constrain 
63601 implementation freedom to realize the actual issue target. Thus the original code form was replaced by
63602 normative words.
63603 </p>
63604 <p>
63605 While preparing this wording it turned out that several <tt>tuple_size</tt> specializations as 
63606 that of <tt>pair</tt> and <tt>array</tt> are underspecified, because the underlying type of the member 
63607 value is not specified except that it is an integral type. For the specializations we could introduce a 
63608 canonical one - like <tt>size_t</tt> - or we could use the same type as the specialization of the 
63609 unqualified type uses. The following wording follows the second approach.
63610 </p>
63611 <p>
63612 The wording refers to N3126.
63613 </p>
63614
63615 <blockquote>
63616 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
63617 </blockquote>
63618
63619 <p><i>[
63620 Adopted at 2010-11 Batavia
63621 ]</i></p>
63622
63623
63624
63625
63626 <p><b>Proposed resolution:</b></p>
63627
63628 <ol>
63629 <li>Change 20.4.1 [tuple.general]/2, header <tt>&lt;tuple&gt;</tt> synopsis, as indicated:
63630 <blockquote><pre>// 20.4.2.5, tuple helper classes:
63631 template &lt;class T&gt; class tuple_size; // undefined
63632 <ins>template &lt;class T&gt; class tuple_size&lt;const T&gt;;</ins>
63633 <ins>template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;</ins>
63634 <ins>template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</ins>
63635 <ins></ins>
63636 template &lt;class... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;
63637         
63638 template &lt;size_t I, class T&gt; class tuple_element; // undefined
63639 <ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;</ins>
63640 <ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
63641 <ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
63642 <ins></ins>
63643 template &lt;size_t I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
63644 </pre></blockquote>
63645 </li>
63646 <li>Add the end of subclause 20.4.2.5 [tuple.helper] insert the following two paragraphs:
63647 <blockquote><pre><ins>template &lt;class T&gt; class tuple_size&lt;const T&gt;;</ins>
63648 <ins>template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;</ins>
63649 <ins>template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</ins>
63650 </pre><blockquote>
63651 <ins>Let <em>TS</em> denote <tt>tuple_size&lt;T&gt;</tt> of the <em>cv</em>-unqualified type <tt>T</tt>. 
63652 Then each of the three templates shall meet the UnaryTypeTrait requirements (20.7.1) with a BaseCharacteristic of 
63653 <tt>integral_constant&lt;remove_cv&lt;decltype(<em>TS</em>::value)&gt;::type, <em>TS</em>::value&gt;</tt>.</ins>
63654 </blockquote></blockquote>
63655
63656 <blockquote><pre><ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;</ins>
63657 <ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
63658 <ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
63659 </pre><blockquote>
63660 <ins>Let <em>TE</em> denote <tt>tuple_element&lt;I, T&gt;</tt> of the <em>cv</em>-unqualified type <tt>T</tt>. Then each of the 
63661 three templates shall meet the TransformationTrait requirements (20.7.1) with a member typedef <tt>type</tt> that shall name the 
63662 same type as the following type:</ins>
63663 <ul>
63664 <li><ins>for the first specialization, the type <tt>add_const&lt;<em>TE</em>::type&gt;::type</tt>,</ins></li>
63665 <li><ins>for the second specialization, the type <tt>add_volatile&lt;<em>TE</em>::type&gt;::type</tt>, and</ins></li>
63666 <li><ins>for the third specialization, the type <tt>add_cv&lt;<em>TE</em>::type&gt;::type</tt></ins></li>
63667 </ul>
63668 </blockquote></blockquote>
63669 </li>
63670 </ol>
63671
63672
63673
63674
63675
63676
63677 <hr>
63678 <h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
63679 <p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
63680  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2010-11-20</p>
63681 <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>
63682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
63683 <p><b>Discussion:</b></p>
63684 <p>
63685 The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
63686 should be declared <tt>constexpr</tt>.
63687 </p>
63688
63689 <p><i>[
63690 2009-10 Santa Cruz:
63691 ]</i></p>
63692
63693
63694 <blockquote>
63695 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
63696 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.htm">N2994</a>.
63697 </blockquote>
63698
63699
63700 <p><b>Proposed resolution:</b></p>
63701 <p>
63702 20.6.1 [ratio.ratio]
63703 </p>
63704
63705 <blockquote><pre>namespace std {
63706   template &lt;intmax_t N, intmax_t D = 1&gt;
63707   class ratio {
63708   public:
63709     static const<ins>expr</ins> intmax_t num;
63710     static const<ins>expr</ins> intmax_t den;
63711   };
63712 }
63713 </pre></blockquote>
63714
63715
63716
63717
63718
63719
63720 <hr>
63721 <h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
63722 <p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63723  <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14 <b>Last modified:</b> 2010-10-23</p>
63724 <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>
63725 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63726 <p><b>Discussion:</b></p>
63727 <p>
63728 As currently formulated, the standard doesn't require that there 
63729 is ever a flush of <tt>cout</tt>, etc.  (This implies, for example, that 
63730 the classical hello, world program may have no output.)  In the 
63731 current draft
63732 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
63733 there is a requirement that the objects 
63734 be constructed before <tt>main</tt>, and before the dynamic 
63735 initialization of any non-local objects defined after the 
63736 inclusion of <tt>&lt;iostream&gt;</tt> in the same translation unit.  The only 
63737 requirement that I can find concerning flushing, however, is in 
63738 27.5.2.1.6 [ios::Init], where the destructor of the last 
63739 <tt>std::ios_base::Init</tt> object flushes.  But there is, as far as I 
63740 can see, no guarantee that such an object ever exists. 
63741 </p>
63742 <p>
63743 Also, the wording in  [iostreams.objects] says that:
63744 </p>
63745 <blockquote>
63746 The objects 
63747 are constructed and the associations are established at some 
63748 time prior to or during the first time an object of class 
63749 <tt>ios_base::Init</tt> is constructed, and in any case before the body 
63750 of main begins execution.
63751 </blockquote>
63752 <p>
63753 In 27.5.2.1.6 [ios::Init], however, as an 
63754 effect of the constructor, it says that
63755 </p>
63756 <blockquote>
63757 If <tt>init_cnt</tt> is zero, 
63758 the function stores the value one in <tt>init_cnt</tt>, then constructs 
63759 and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> 
63760 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
63761 </blockquote>
63762
63763 <p>
63764 which seems to forbid earlier 
63765 construction. 
63766 </p>
63767
63768 <p>
63769 (Note that with these changes, the exposition only "<tt>static 
63770 int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.) 
63771 </p>
63772 <p>
63773 Of course, a determined programmer can still inhibit the 
63774 flush with things like: 
63775 </p>
63776 <blockquote><pre>new std::ios_base::Init ;       //  never deleted 
63777 </pre></blockquote>
63778 <p>
63779 or (in a function): 
63780 </p>
63781 <blockquote><pre>std::ios_base::Init ensureConstruction ; 
63782 //  ... 
63783 exit( EXIT_SUCCESS ) ; 
63784 </pre></blockquote>
63785 <p>
63786 Perhaps some words somewhere to the effect that all 
63787 <tt>std::ios_base::Init</tt> objects should have static lifetime 
63788 would be in order. 
63789 </p>
63790
63791 <p><i>[
63792 2009 Santa Cruz:
63793 ]</i></p>
63794
63795
63796 <blockquote>
63797 Moved to Ready.  Some editorial changes are expected (in addition to the
63798 proposed wording) to remove <tt>init_cnt</tt> from <tt>Init</tt>.
63799 </blockquote>
63800
63801
63802
63803 <p><b>Proposed resolution:</b></p>
63804 <p>
63805 Change 27.4 [iostream.objects]/2:
63806 </p>
63807
63808 <blockquote>
63809 -2- The objects are constructed and the associations are established at
63810 some time prior to or during the first time an object of class
63811 <tt>ios_base::Init</tt> is constructed, and in any case before the body
63812 of main begins execution.<sup>292</sup> The objects are not destroyed
63813 during program execution.<sup>293</sup>
63814 <del>If a translation unit includes
63815 <tt>&lt;iostream&gt;</tt> or explicitly constructs an
63816 <tt>ios_base::Init</tt> object, these stream objects shall be
63817 constructed before dynamic initialization of non-local objects defined
63818 later in that translation unit.</del>
63819 <ins>The results of including <tt>&lt;iostream&gt;</tt> in a translation
63820 unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of
63821 <tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
63822 program shall behave as if there were at least one instance of
63823 <tt>ios_base::Init</tt> with static lifetime.</ins>
63824 </blockquote>
63825
63826 <p>
63827 Change 27.5.2.1.6 [ios::Init]/3:
63828 </p>
63829
63830 <blockquote>
63831 <pre>Init();
63832 </pre>
63833 <blockquote>
63834 -3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>. 
63835 <del>If <tt>init_cnt</tt> is zero, the function stores the value one in
63836 <tt>init_cnt</tt>, then constructs and initializes the objects
63837 <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
63838 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
63839 (27.4.2). In any case, the function then adds one to the value stored in
63840 <tt>init_cnt</tt>.</del>
63841 <ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
63842 <tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
63843 <tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
63844 constructed and initialized.</ins>
63845 </blockquote>
63846 </blockquote>
63847
63848 <p>
63849 Change 27.5.2.1.6 [ios::Init]/4:
63850 </p>
63851
63852 <blockquote>
63853 <pre>~Init();
63854 </pre>
63855 <blockquote>
63856 -4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
63857 <del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
63858 if the resulting stored value is one,</del>
63859 <ins>If there are no other instances of the class still in
63860 existance,</ins>
63861 calls <tt>cout.flush()</tt>,
63862 <tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
63863 <tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
63864 </blockquote>
63865 </blockquote>
63866
63867
63868
63869
63870
63871
63872 <hr>
63873 <h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const &amp; parameter</h3>
63874 <p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63875  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
63876 <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>
63877 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63878 <p><b>Discussion:</b></p>
63879 <p>
63880 The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
63881 declared <tt>const</tt>, but takes its argument by non-const reference.
63882 </p>
63883 <p>
63884 This is not compatible with the <tt>operator==</tt> free function overload, which is
63885 defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
63886 const.
63887 </p>
63888
63889 <p><i>[
63890 The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
63891 ]</i></p>
63892
63893
63894 <p><i>[
63895 2009-11-02 Howard adds:
63896 ]</i></p>
63897
63898
63899 <blockquote>
63900 Set to Tentatively Ready after 5 positive votes on c++std-lib.
63901 </blockquote>
63902
63903
63904
63905 <p><b>Proposed resolution:</b></p>
63906 <p>
63907 Ammend in both:<br>
63908 24.6.3 [istreambuf.iterator]<br>
63909 24.6.3.5 [istreambuf.iterator::equal]<br>
63910 </p>
63911
63912 <blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator&amp; b) const;
63913 </pre></blockquote>
63914
63915
63916
63917
63918
63919
63920 <hr>
63921 <h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
63922 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
63923  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13 <b>Last modified:</b> 2010-10-23</p>
63924 <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>
63925 <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>
63926 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
63927 <p><b>Discussion:</b></p>
63928 <p>
63929 The naming of <tt>std::copy_exception</tt> misleads almost everyone
63930 (experts included!) to think that it is the function that copies an
63931 <tt>exception_ptr</tt>:
63932 </p>
63933
63934 <blockquote><pre>exception_ptr p1 = current_exception();
63935 exception_ptr p2 = copy_exception( p1 );
63936 </pre></blockquote>
63937
63938 <p>
63939 But this is not at all what it does. The above actually creates an
63940 <tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
63941 the exception to which <tt>p1</tt> refers!
63942 </p>
63943 <p>
63944 This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
63945 because I was unable to think of a better name.
63946 </p>
63947 <p>
63948 But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
63949 </p>
63950 <p>
63951 Therefore, I propose <tt>copy_exception</tt> to be renamed to
63952 <tt>create_exception</tt>:
63953 </p>
63954
63955 <blockquote><pre>template&lt;class E&gt; exception_ptr create_exception(E e);
63956 </pre></blockquote>
63957
63958 <p>
63959 with the following explanatory paragraph after it:
63960 </p>
63961
63962 <blockquote>
63963 Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
63964 </blockquote>
63965
63966 <p><i>[
63967 2009-05-13 Daniel adds:
63968 ]</i></p>
63969
63970
63971 <blockquote>
63972 <p>
63973 What about
63974 </p>
63975 <blockquote><pre>make_exception_ptr
63976 </pre></blockquote>
63977 <p>
63978 in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
63979 <tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
63980 <tt>current_exception</tt> is preferred:
63981 </p>
63982
63983 <blockquote><pre>make_exception
63984 </pre></blockquote>
63985 <p>
63986 We have not a single <tt>create_*</tt> function in the library, it was always
63987 <tt>make_*</tt> used.
63988 </p>
63989 </blockquote>
63990
63991 <p><i>[
63992 2009-05-13 Peter adds:
63993 ]</i></p>
63994
63995
63996 <blockquote>
63997 <tt>make_exception_ptr</tt> works for me.
63998 </blockquote>
63999
64000 <p><i>[
64001 2009-06-02 Thomas J. Gritzan adds:
64002 ]</i></p>
64003
64004
64005 <blockquote>
64006 <p>
64007 To avoid surprises and unwanted recursion, how about making a call to
64008 <tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
64009 </p>
64010 <p>
64011 It might work like this:
64012 </p>
64013 <blockquote><pre>template&lt;class E&gt;
64014 exception_ptr make_exception_ptr(E e);
64015 template&lt;&gt;
64016 exception_ptr make_exception_ptr&lt;exception_ptr&gt;(exception_ptr e) = delete;
64017 </pre></blockquote>
64018 </blockquote>
64019
64020 <p><i>[
64021 2009 Santa Cruz:
64022 ]</i></p>
64023
64024
64025 <blockquote>
64026 Move to Review for the time being. The subgroup thinks this is a good
64027 idea, but doesn't want to break compatibility unnecessarily if someone
64028 is already shipping this. Let's talk to Benjamin and PJP tomorrow to
64029 make sure neither objects.
64030 </blockquote>
64031
64032 <p><i>[
64033 2009-11-16 Jonathan Wakely adds:
64034 ]</i></p>
64035
64036
64037 <blockquote>
64038 GCC 4.4 shipped with <tt>copy_exception</tt> but we could certainly keep that
64039 symbol in the library (but not the headers) so it can still be found
64040 by any apps foolishly relying on the experimental C++0x mode being ABI
64041 stable.
64042 </blockquote>
64043
64044 <p><i>[
64045 2009-11-16 Peter adopts wording supplied by Daniel.
64046 ]</i></p>
64047
64048
64049 <p><i>[
64050 2009-11-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
64051 ]</i></p>
64052
64053
64054
64055 <p><b>Proposed resolution:</b></p>
64056 <ol>
64057 <li>
64058 <p>
64059 Change 18.8 [support.exception]/1, header <tt>&lt;exception&gt;</tt>
64060 synopsis as indicated:
64061 </p>
64062
64063 <blockquote><pre>exception_ptr current_exception();
64064 void rethrow_exception [[noreturn]] (exception_ptr p);
64065 template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
64066 </pre></blockquote>
64067 </li>
64068
64069 <li>
64070 <p>
64071 Change 18.8.5 [propagation]:
64072 </p>
64073
64074 <blockquote>
64075 <pre>template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
64076 </pre>
64077
64078 <blockquote>
64079 <p>
64080 -11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
64081 to a copy of <tt>e</tt>,</ins> as if
64082 </p>
64083
64084 <blockquote><pre>try {
64085   throw e;
64086 } catch(...) {
64087   return current_exception();
64088 }
64089 </pre></blockquote>
64090
64091 <p>...</p>
64092 </blockquote>
64093
64094 </blockquote>
64095 </li>
64096
64097 <li>
64098 <p>
64099 Change 30.6.5 [futures.promise]/7 as indicated:
64100 </p>
64101
64102 <blockquote>
64103 <i>Effects:</i> if the associated state of <tt>*this</tt> is not ready, stores an exception
64104 object of type <tt>future_error</tt> with an error code of <tt>broken_promise</tt> as if by
64105 <tt>this-&gt;set_exception(<del>copy_exception</del><ins>make_exception_ptr</ins>(
64106 future_error(future_errc::broken_promise))</tt>.  Destroys ...
64107 </blockquote>
64108 </li>
64109 </ol>
64110
64111
64112
64113
64114
64115
64116 <hr>
64117 <h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
64118 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64119  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2010-10-23</p>
64120 <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>
64121 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64122 <p><b>Discussion:</b></p>
64123 <p>
64124 The <tt>alignment_of</tt> template is no longer necessary, now that the
64125 core language will provide <tt>alignof</tt>. Scott Meyers raised this
64126 issue at comp.std.c++,
64127 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
64128 May 21, 2009.  In a reply, Daniel Krügler pointed out that
64129 <tt>alignof</tt> was added to the working paper <i>after</i>
64130 <tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
64131 part of the current Working Draft 
64132 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
64133 because it is in TR1.
64134 </p>
64135 <p>
64136 Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
64137 unwanted confusion. In general, I think TR1 functionality should not be
64138 brought into C++0x if it is entirely redundant with other C++0x language
64139 or library features.
64140 </p>
64141
64142 <p><i>[
64143 2009-11-16 Chris adds:
64144 ]</i></p>
64145
64146
64147 <blockquote>
64148 <p>
64149 I would like to suggest the following new wording for this issue, based on
64150 recent discussions. Basically this doesn't delete <tt>alignment_of</tt>, it just
64151 makes it clear that it is just a wrapper for <tt>alignof</tt>. This deletes the
64152 first part of the proposed resolution, changes the second part by leaving in
64153 <tt>alignof(T)</tt> but changing the precondition and leaves the 3rd part
64154 unchanged.
64155 </p>
64156
64157 <p>
64158 Suggested Resolution:
64159 </p>
64160
64161 <blockquote>
64162 <p>
64163 Change the first row of Table 44 ("Type property queries"), from Type properties
64164 20.7.4.3 [meta.unary.prop]:
64165 </p>
64166
64167 <blockquote>
64168 <table border="1">
64169 <caption>Table 44 \97 Type property queries</caption>
64170 <tbody><tr>
64171 <td>
64172 <tt>template &lt;class T&gt; struct alignment_of;</tt>
64173 </td>
64174 <td>
64175 <tt>alignof(T)</tt>.<br>
64176 <i>Precondition:</i> <del><tt>T</tt> shall be a complete type, a reference type,
64177 or an array of unknown bound, but shall not be a function type or (possibly
64178 cv-qualified) <tt>void</tt>.</del> <ins><tt>alignof(T)</tt> shall be defined</ins>
64179 </td>
64180 </tr>
64181
64182 </tbody></table>
64183 </blockquote>
64184
64185 <p>
64186 Change text in Table 51 ("Other transformations"), from Other transformations
64187 20.7.7.6 [meta.trans.other], as follows:
64188 </p>
64189
64190 <blockquote>
64191 <table border="1">
64192 <caption>Table 51 \97 Other transformations</caption>
64193 <tbody><tr><td>...<tt>aligned_storage;</tt></td>
64194 <td>
64195 <tt>Len</tt> shall not be zero. <tt>Align</tt> shall be equal to
64196 <tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
64197 type <tt>T</tt> or to <i>default-alignment</i>.
64198 </td>
64199 <td>...</td>
64200 </tr></tbody></table>
64201 </blockquote>
64202 </blockquote>
64203 </blockquote>
64204
64205 <p><i>[
64206 2010-01-30 Alisdair proposes that Chris' wording be moved into the proposed wording
64207 section and tweaks it on the way.
64208 ]</i></p>
64209
64210
64211 <blockquote>
64212 <p>
64213 Original proposed wording saved here:
64214 </p>
64215 <blockquote>
64216 <p>
64217 Remove from Header &lt;type_traits&gt; synopsis 20.7.2 [meta.type.synop]:
64218 </p>
64219 <blockquote><pre><del>template &lt;class T&gt; struct alignment_of;</del>
64220 </pre></blockquote>
64221
64222 <p>
64223 Remove the first row of Table 44 ("Type property queries"), from
64224 Type properties 20.7.4.3 [meta.unary.prop]:
64225 </p>
64226 <blockquote>
64227 <table border="1">
64228 <caption>Table 44 \97 Type property queries</caption>
64229 <tbody><tr>
64230 <td><del><tt>template &lt;class T&gt; struct alignment_of;</tt></del></td>
64231 <td><del><tt>alignof(T)</tt>.</del><br>
64232 <del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
64233 type, or an array of unknown bound, but shall not be a function type or
64234 (possibly cv-qualified) <tt>void</tt>.</del>
64235 </td>
64236 </tr>
64237 </tbody></table>
64238 </blockquote>
64239
64240 <p>
64241 Change text in Table 51 ("Other transformations"), from Other
64242 transformations 20.7.7.6 [meta.trans.other], as follows:
64243 </p>
64244 <blockquote>
64245 <table border="1">
64246 <caption>Table 51 \97 Other transformations</caption>
64247 <tbody><tr><td>...<tt>aligned_storage;</tt></td>
64248 <td>
64249 <tt>Len</tt> shall not be zero.  Align shall be equal to
64250 <tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
64251 type <tt>T</tt> or to <i>default-alignment</i>.
64252 </td>
64253 <td>...</td>
64254 </tr></tbody></table>
64255 </blockquote>
64256 </blockquote>
64257 </blockquote>
64258
64259 <p><i>[
64260 2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
64261 ]</i></p>
64262
64263
64264
64265
64266 <p><b>Proposed resolution:</b></p>
64267
64268 <p>
64269 Change the first row of Table 43 ("Type property queries"), from Type properties
64270 20.7.4.3 [meta.unary.prop]:
64271 </p>
64272
64273 <blockquote>
64274 <table border="1">
64275 <caption>Table 43 \97 Type property queries</caption>
64276 <tbody><tr>
64277 <td>
64278 <tt>template &lt;class T&gt; struct alignment_of;</tt>
64279 </td>
64280 <td>
64281 <tt>alignof(T)</tt>.<br>
64282 <i>Precondition:</i> <del><tt>T</tt> shall be a complete type, a reference type,
64283 or an array of unknown bound, but shall not be a function type or (possibly
64284 cv-qualified) <tt>void</tt>.</del> <ins><tt>alignof(T)</tt> is a valid
64285 expression (5.3.6 [expr.alignof])</ins>
64286 </td>
64287 </tr>
64288
64289 </tbody></table>
64290 </blockquote>
64291
64292 <p>
64293 Change text in Table 51 ("Other transformations"), from Other transformations
64294 20.7.7.6 [meta.trans.other], as follows:
64295 </p>
64296
64297 <blockquote>
64298 <table border="1">
64299 <caption>Table 51 \97 Other transformations</caption>
64300 <tbody><tr><td>...<tt>aligned_storage;</tt></td>
64301 <td>
64302 <tt>Len</tt> shall not be zero. <tt>Align</tt> shall be equal to
64303 <tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
64304 type <tt>T</tt> or to <i>default-alignment</i>.
64305 </td>
64306 <td>...</td>
64307 </tr></tbody></table>
64308 </blockquote>
64309
64310
64311
64312
64313
64314
64315 <hr>
64316 <h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
64317 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64318  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2010-10-23</p>
64319 <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>
64320 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64321 <p><b>Discussion:</b></p>
64322 <p>
64323 IIUC,
64324 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
64325 means that lvalues will no longer bind to rvalue references.
64326 Therefore, the current specification of <tt>list::splice</tt> (list
64327 operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
64328 programs.  That is because we changed the signature to swallow via an rvalue
64329 reference rather than the lvalue reference used in 03.
64330 </p>
64331 <p>
64332 Retaining this form would be safer, requiring an explicit move when splicing
64333 from lvalues.  However, this will break existing programs.
64334 We have the same problem with <tt>forward_list</tt>, although without the risk of
64335 breaking programs so here it might be viewed as a positive feature.
64336 </p>
64337 <p>
64338 The problem signatures:
64339 </p>
64340 <blockquote><pre>void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x);
64341 void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
64342                   const_iterator i);
64343 void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
64344                   const_iterator first, const_iterator last);
64345
64346 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x);
64347 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
64348             const_iterator i);
64349 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
64350             const_iterator first, const_iterator last);
64351 </pre></blockquote>
64352
64353 <b>Possible resolutions:</b>
64354
64355 <p>
64356 Option A.   Add an additional (non-const) lvalue-reference
64357 overload in each case
64358 </p>
64359 <p>
64360 Option B.   Change rvalue reference back to (non-const)
64361 lvalue-reference overload in each case
64362 </p>
64363 <p>
64364 Option C.   Add an additional (non-const) lvalue-reference
64365 overload in just the <tt>std::list</tt> cases
64366 </p>
64367 <p>
64368 I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
64369 behaviour in (C) but feel (A) is needed for consistency.
64370 </p>
64371 <p>
64372 My actual preference would be NAD, ship with this as a breaking change as it
64373 is a more explicit interface.  I don't think that will fly though!
64374 </p>
64375
64376 <p>
64377 See the thread starting with c++std-lib-23725 for more discussion.
64378 </p>
64379
64380 <p><i>[
64381 2009-10-27 Christopher Jefferson provides proposed wording for Option C.
64382 ]</i></p>
64383
64384
64385 <p><i>[
64386 2009-12-08 Jonathan Wakely adds:
64387 ]</i></p>
64388
64389
64390 <blockquote>
64391 <p>
64392 As Bill Plauger pointed out, <tt>list::merge</tt> needs similar treatment.
64393 </p>
64394 <p><i>[
64395 Wording updated.
64396 ]</i></p>
64397
64398 </blockquote>
64399
64400 <p><i>[
64401 2009-12-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
64402 ]</i></p>
64403
64404
64405
64406 <p><b>Proposed resolution:</b></p>
64407 <p>
64408 In 23.3.4 [list]
64409 </p>
64410
64411 <p>
64412 Add lvalue overloads before rvalue ones:
64413 </p>
64414
64415 <blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
64416 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
64417 <ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
64418 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
64419 <ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
64420             const_iterator first, const_iterator last);</ins>
64421 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
64422             const_iterator first, const_iterator last);
64423 <ins>void merge(list&lt;T,Allocator&gt;&amp; x);
64424 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp; x, Compare comp);</ins>
64425 void merge(list&lt;T,Allocator&gt;&amp;&amp; x);
64426 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
64427
64428 </pre></blockquote>
64429
64430 <p>
64431 In 23.3.4.4 [list.ops], similarly add lvalue overload before each rvalue one:
64432 </p>
64433 <p>
64434 (After paragraph 2)
64435 </p>
64436
64437 <blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
64438 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
64439 </pre></blockquote>
64440
64441 <p>
64442 (After paragraph 6)
64443 </p>
64444
64445 <blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
64446 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, <ins>const_</ins>iterator i);
64447 </pre></blockquote>
64448
64449 <p>
64450 (After paragraph 10)
64451 </p>
64452
64453 <blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
64454             const_iterator first, const_iterator last);</ins>
64455 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
64456             <ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
64457 </pre></blockquote>
64458
64459 <p>
64460 In 23.3.4.4 [list.ops], after paragraph 21
64461 </p>
64462
64463 <blockquote><pre><ins>void merge(list&lt;T,Allocator&gt;&amp; x);
64464 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp; x, Compare comp);</ins>
64465 void merge(list&lt;T,Allocator&gt;&amp;&amp; x);
64466 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
64467 </pre></blockquote>
64468
64469
64470
64471
64472
64473
64474 <hr>
64475 <h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
64476 <p><b>Section:</b> X [stdinth], X [fenv], 26.8 [c.math], X [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64477  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26 <b>Last modified:</b> 2010-10-23</p>
64478 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64479 <p><b>Discussion:</b></p>
64480 <p>
64481 This is probably editorial.
64482 </p>
64483 <p>
64484 The following items should be removed from the draft, because they're
64485 redundant with Annex D, and they arguably make some *.h headers
64486 non-deprecated:
64487 </p>
64488 <p>
64489 X [stdinth] (regarding <tt>&lt;stdint.h&gt;</tt>) 
64490 </p>
64491 <p>
64492 X [fenv] (regarding <tt>&lt;fenv.h&gt;</tt>
64493 </p>
64494 <p>
64495 Line 3 of 26.8 [c.math] (regarding <tt>&lt;tgmath.h&gt;</tt>) 
64496 </p>
64497 <p>
64498 X [cmplxh] (regarding <tt>&lt;complex.h&gt;</tt>, though the note in this subclause is not redundant) 
64499 </p>
64500
64501 <p><i>[
64502 2009-06-10 Ganesh adds:
64503 ]</i></p>
64504
64505
64506 <blockquote>
64507 While searching for <tt>stdint</tt> in the CD, I found that <tt>&lt;stdint.h&gt;</tt> is also
64508 mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
64509 <tt>&lt;cstdint&gt;</tt> instead.
64510 </blockquote>
64511
64512 <p><i>[
64513 2009 Santa Cruz:
64514 ]</i></p>
64515
64516
64517 <blockquote>
64518 Real issue. Maybe just editorial, maybe not. Move to Ready.
64519 </blockquote>
64520
64521
64522
64523 <p><b>Proposed resolution:</b></p>
64524 <p>
64525 Remove the section X [stdinth].
64526 </p>
64527 <p>
64528 Remove the section X [fenv].
64529 </p>
64530 <p>
64531 Remove 26.8 [c.math], p3:
64532 </p>
64533
64534 <blockquote>
64535 <del>-3- The header <tt>&lt;tgmath.h&gt;</tt> effectively includes the headers <tt>&lt;complex.h&gt;</tt>
64536 and <tt>&lt;math.h&gt;</tt>.</del>
64537 </blockquote>
64538 <p>
64539 Remove the section X [cmplxh].
64540 </p>
64541
64542
64543
64544
64545
64546 <hr>
64547 <h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
64548 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
64549  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2010-11-19</p>
64550 <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>
64551 <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>
64552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
64553 <p><b>Discussion:</b></p>
64554 <p>
64555 As of
64556 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
64557 18.8.5 [propagation]/5, the implementation-defined type
64558 <tt>exception_ptr</tt> does provide the following ways to check whether
64559 it is a null value:
64560 </p>
64561 <blockquote><pre>void f(std::exception_ptr p) {
64562   p == nullptr;
64563   p == 0;
64564   p == exception_ptr();
64565 }
64566 </pre></blockquote>
64567 <p>
64568 This is rather cumbersome way of checking for the null value
64569 and I suggest to require support for evaluation in a boolean
64570 context like so:
64571 </p>
64572
64573 <blockquote><pre>void g(std::exception_ptr p) {
64574   if (p) {}
64575   !p;
64576 }
64577 </pre></blockquote>
64578
64579 <p><i>[
64580 2009 Santa Cruz:
64581 ]</i></p>
64582
64583
64584 <blockquote>
64585 Move to Ready. Note to editor: considering putting in a cross-reference
64586 to 4 [conv], paragraph 3, which defines the phrase
64587 "contextually converted to <tt>bool</tt>".
64588 </blockquote>
64589
64590 <p><i>[
64591 2010-03-14 Howard adds:
64592 ]</i></p>
64593
64594
64595 <blockquote>
64596 We moved
64597 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
64598 to the formal motions page in Pittsburgh which should obsolete this issue.  I've
64599 moved this issue to NAD Editorial, solved by N3073.
64600 </blockquote>
64601
64602
64603
64604 <p><b>Rationale:</b></p>
64605 <p>
64606 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
64607 </p>
64608
64609
64610 <p><b>Proposed resolution:</b></p>
64611 <p>
64612 In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
64613 </p>
64614
64615 <blockquote>
64616 <ins>
64617 An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
64618 The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
64619 of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
64620 enumeration type or to pointer type.
64621 </ins>
64622 </blockquote>
64623
64624
64625
64626
64627
64628 <hr>
64629 <h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
64630 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64631  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2010-10-23</p>
64632 <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>
64633 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64634 <p><b>Discussion:</b></p>
64635 <p>
64636 It was recently mentioned in a newsgroup article
64637 <a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
64638 that the specification of the member function <tt>rethrow_nested()</tt> of the
64639 class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
64640 what happens, if member <tt>nested_ptr()</tt> returns a null value. In
64641 18.8.6 [except.nested] we find only the following paragraph related to that:
64642 </p>
64643 <blockquote><pre>void rethrow_nested() const; // [[noreturn]]
64644 </pre>
64645 <blockquote>
64646 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
64647 </blockquote>
64648 </blockquote>
64649 <p>
64650 This is a problem, because it is possible to create an object of
64651 <tt>nested_exception</tt> with exactly such a state, e.g.
64652 </p>
64653 <blockquote><pre>#include &lt;exception&gt;
64654 #include &lt;iostream&gt;
64655
64656 int main() try {
64657   std::nested_exception e; // OK, calls current_exception() and stores it's null value
64658   e.rethrow_nested(); // ?
64659   std::cout &lt;&lt; "A" &lt;&lt; std::endl;
64660 }
64661 catch(...) {
64662   std::cout &lt;&lt; "B" &lt;&lt; std::endl;
64663 }
64664 </pre></blockquote>
64665 <p>
64666 I suggest to follow the proposal of the reporter, namely to invoke
64667 <tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
64668 of relying on the fallback position of undefined behavior. This would
64669 be consistent to the behavior of a <tt>throw;</tt> statement when no
64670 exception is being handled.
64671 </p>
64672
64673 <p><i>[
64674 2009 Santa Cruz:
64675 ]</i></p>
64676
64677
64678 <blockquote>
64679 Move to Ready.
64680 </blockquote>
64681
64682
64683
64684 <p><b>Proposed resolution:</b></p>
64685 <p>
64686 Change around 18.8.6 [except.nested]/4 as indicated:
64687 </p>
64688 <blockquote>
64689 <p>
64690 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
64691 object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
64692 </p>
64693 <p>
64694 <ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
64695 shall be called.</ins>
64696 </p>
64697 </blockquote>
64698
64699
64700
64701
64702
64703 <hr>
64704 <h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
64705 <p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64706  <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11 <b>Last modified:</b> 2010-10-23</p>
64707 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
64708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64709 <p><b>Discussion:</b></p>
64710 <p>
64711 In clause 1, the Working Draft 
64712 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
64713 specifies overloads of the
64714 functions
64715 </p>
64716 <blockquote><pre>arg, conj, imag, norm, proj, real
64717 </pre></blockquote>
64718 <p>
64719 for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
64720 <tt>long double</tt>, and integers).
64721 The only requirement (clause 2) specifies effective type promotion of arguments.
64722 </p>
64723 <p>
64724 I strongly suggest to add the following requirement on the return types:
64725 </p>
64726 <blockquote>
64727 All the specified overloads must return real (i.e., non-complex) values,
64728 specifically, the nested <tt>value_type</tt> of effectively promoted arguments.
64729 </blockquote>
64730
64731 <p>
64732 (This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
64733 they are real-valued anyway.)
64734 </p>
64735 <p><b>Rationale:</b></p>
64736 <p>
64737 Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
64738 complex-valued in general but map the (extended) real line to itself.
64739 In fact, both functions act as identity on the reals.
64740 A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
64741 mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
64742 A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
64743 </p>
64744
64745 <blockquote><pre>template&lt;typename T&gt;
64746 inline T
64747 scalar_product(size_t n, T const* x, T const* y) {
64748   T result = 0;
64749   for (size_t i = 0; i &lt; n; ++i)
64750     result += x[i] * std::conj(y[i]);
64751   return result;
64752 }
64753 </pre></blockquote>
64754 <p>
64755 This will work equally well for real and complex floating-point types <tt>T</tt> if
64756 <tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
64757 returns complex values.
64758 </p>
64759 <p>
64760 Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
64761 and less useful (if a complex result is always returned), or unnecessarily
64762 complicated (if overloaded versions with proper return types are defined).
64763 In the second case, the real-argument overload of <tt>conj()</tt> cannot be used.
64764 In fact, it must be avoided.
64765 </p>
64766 <p>
64767 Overloaded <tt>conj()</tt> and <tt>proj()</tt> are principally needed in generic programming.
64768 All such use cases will benefit from the proposed return type requirement,
64769 in a similar way as the <tt>scalar_product</tt> example.
64770 The requirement will not harm use cases where a complex return value
64771 is expected, because of implicit conversion to complex.
64772 Without the proposed return type guarantee, I find overloaded versions
64773 of <tt>conj()</tt> and <tt>proj()</tt> not only useless but actually troublesome.
64774 </p>
64775
64776
64777 <p><i>[
64778 2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
64779 ]</i></p>
64780
64781
64782
64783
64784 <p><b>Proposed resolution:</b></p>
64785 <p>
64786 Insert a new paragraph after 26.4.9 [cmplx.over]/2:
64787 </p>
64788
64789 <blockquote>
64790 <ins>
64791 All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
64792 the effectively cast arguments.
64793 </ins>
64794 </blockquote>
64795
64796
64797
64798
64799
64800 <hr>
64801 <h3><a name="1138"></a>1138. unusual return value for operator+</h3>
64802 <p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64803  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12 <b>Last modified:</b> 2010-10-23</p>
64804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64805 <p><b>Discussion:</b></p>
64806 <p>
64807 Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference.  Is
64808 that really intended?
64809 </p>
64810 <p>
64811 I'm considering it might be a mild performance tweak to avoid making
64812 un-necessary copies of a cheaply movable type, but it opens risk to dangling
64813 references in code like:
64814 </p>
64815
64816 <blockquote><pre>auto &amp;&amp; s = string{"x"} + string{y};
64817 </pre></blockquote>
64818
64819 <p>
64820 and I'm not sure about:
64821 </p>
64822
64823 <blockquote><pre>auto s = string{"x"} + string{y};
64824 </pre></blockquote>
64825
64826 <p><i>[
64827 2009-10-11 Howard updated <i>Returns:</i> clause for each of these.
64828 ]</i></p>
64829
64830
64831 <p><i>[
64832 2009-11-05 Howard adds:
64833 ]</i></p>
64834
64835
64836 <blockquote>
64837 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
64838 </blockquote>
64839
64840
64841 <p><b>Proposed resolution:</b></p>
64842 <p>
64843 Strike the <tt>&amp;&amp;</tt> from the return type in the following function
64844 signatures:
64845 </p>
64846
64847 <blockquote>
64848 <p>
64849 21.3 [string.classes] p2 Header Synopsis
64850 </p>
64851
64852 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
64853   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64854     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64855               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
64856
64857 template&lt;class charT, class traits, class Allocator&gt;
64858   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64859     operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
64860               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64861
64862 template&lt;class charT, class traits, class Allocator&gt;
64863   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64864     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64865               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64866
64867
64868 template&lt;class charT, class traits, class Allocator&gt;
64869   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64870     operator+(const charT* lhs,
64871               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64872
64873 template&lt;class charT, class traits, class Allocator&gt;
64874   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64875     operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64876
64877 template&lt;class charT, class traits, class Allocator&gt;
64878   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64879     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64880               const charT* rhs);
64881
64882 template&lt;class charT, class traits, class Allocator&gt;
64883   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64884     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
64885 </pre></blockquote>
64886
64887 <p>
64888 21.4.8.1 [string::op+]
64889 </p>
64890
64891 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
64892   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64893     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64894               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
64895 </pre>
64896 <blockquote>
64897 <i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>
64898 </blockquote>
64899 <pre>template&lt;class charT, class traits, class Allocator&gt;
64900   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64901     operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
64902               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64903 </pre>
64904 <blockquote>
64905 <i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>
64906 </blockquote>
64907 <pre>template&lt;class charT, class traits, class Allocator&gt;
64908   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64909     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64910               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64911 </pre>
64912 <blockquote>
64913 <i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt> [<i>Note:</i> Or equivalently
64914 <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt> \97 <i>end note</i>]
64915 </blockquote>
64916 <pre>template&lt;class charT, class traits, class Allocator&gt;
64917   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64918     operator+(const charT* lhs,
64919               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64920 </pre>
64921 <blockquote>
64922 <i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>.
64923 </blockquote>
64924 <pre>template&lt;class charT, class traits, class Allocator&gt;
64925   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64926     operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
64927 </pre>
64928 <blockquote>
64929 <i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, 1, lhs)<ins>)</ins></tt>.
64930 </blockquote>
64931 <pre>template&lt;class charT, class traits, class Allocator&gt;
64932   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64933     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
64934               const charT* rhs);
64935 </pre>
64936 <blockquote>
64937 <i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>.
64938 </blockquote>
64939 <pre>template&lt;class charT, class traits, class Allocator&gt;
64940   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
64941     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
64942 </pre>
64943 <blockquote>
64944 <i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(1, rhs)<ins>)</ins></tt>.
64945 </blockquote>
64946 </blockquote>
64947
64948 </blockquote>
64949
64950
64951
64952
64953
64954
64955 <hr>
64956 <h3><a name="1144"></a>1144. "thread safe" is undefined</h3>
64957 <p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
64958  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16 <b>Last modified:</b> 2010-10-23</p>
64959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
64960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
64961 <p><b>Discussion:</b></p>
64962
64963 <p><b>Addresses UK 187</b></p>
64964
64965 <p>
64966 The term "thread safe" is not defined nor used in this context
64967 anywhere else in the standard.
64968 </p>
64969
64970 <p><b>Suggested action:</b></p>
64971 <p>
64972 Clarify the meaning of "thread safe".
64973 </p>
64974
64975 <p><i>[
64976 2009 Santa Cruz:
64977 ]</i></p>
64978
64979
64980 <blockquote>
64981 <p>
64982 The "thread safe" language has already been change in the WP. It was
64983 changed to "happen before", but the current WP text is still a little
64984 incomplete: "happen before" is binary, but the current WP text only
64985 mentions one thing.
64986 </p>
64987 <p>
64988 Move to Ready.
64989 </p>
64990 </blockquote>
64991
64992
64993
64994 <p><b>Proposed resolution:</b></p>
64995 <p>
64996 For the following functions in 18.5 [support.start.term].
64997 </p>
64998 <blockquote><pre><code>
64999 extern "C" int at_quick_exit(void (*f)(void));
65000 extern "C++" int at_quick_exit(void (*f)(void));
65001 </code></pre></blockquote>
65002
65003 <p>
65004 Edit paragraph 10 as follows.
65005 The intent is
65006 to provide the other half of the happens before relation;
65007 to note indeterminate ordering;
65008 and to clean up some formatting.
65009 </p>
65010 <blockquote><p>
65011 <i>Effects:</i>
65012 The <code>at_quick_exit()</code> functions
65013 register the function pointed to by <code>f</code>
65014 to be called without arguments when <code>quick_exit</code> is called.
65015 It is unspecified whether a call to <code>at_quick_exit()</code>
65016 that does not <del>happen-before</del> <ins>happen before</ins> (1.10)
65017 <ins>all calls to <code>quick_exit</code></ins>
65018 will succeed.
65019 [<i>Note:</i>
65020 the <code>at_quick_exit()</code> functions
65021 shall not introduce a data race (17.6.4.7).
65022 <del>exitnote</del>
65023 <ins>\97<i>end note</i>]</ins>
65024 <ins>
65025 [<i>Note:</i>
65026 The order of registration may be indeterminate
65027 if <code>at_quick_exit</code> was called from more than one thread.
65028 \97<i>end note</i>]
65029 </ins>
65030 [<i>Note:</i> The <code>at_quick_exit</code> registrations
65031 are distinct from the <code>atexit</code> registrations,
65032 and applications may need to call both registration functions
65033 with the same argument.
65034 \97<i>end note</i>]
65035 </p></blockquote>
65036
65037 <p>
65038 For the following function.
65039 </p>
65040 <blockquote><pre><code>
65041 void quick_exit [[noreturn]] (int status)
65042 </code></pre></blockquote>
65043
65044 <p>
65045 Edit paragraph 13 as follows.
65046 The intent is to note that thread-local variables may be different.
65047 </p>
65048 <blockquote><p>
65049 <i>Effects:</i>
65050 Functions registered by calls to <code>at_quick_exit</code>
65051 are called in the reverse order of their registration,
65052 except that a function shall be called
65053 after any previously registered functions
65054 that had already been called at the time it was registered.
65055 Objects shall not be destroyed as a result of calling <code>quick_exit</code>.
65056 If control leaves a registered function called by <code>quick_exit</code>
65057 because the function does not provide a handler for a thrown exception,
65058 <code>terminate()</code> shall be called.
65059 <ins>
65060 [<i>Note:</i>
65061 Functions registered by one thread may be called by any thread,
65062 and hence should not rely on the identity of thread-storage-duration objects.
65063 \97<i>end note</i>]
65064 </ins>
65065 After calling registered functions,
65066 <code>quick_exit</code> shall call <code>_Exit(status)</code>.
65067 [<i>Note:</i>
65068 The standard file buffers are not flushed.
65069 See: ISO C 7.20.4.4.
65070 \97<i>end note</i>]
65071 </p></blockquote>
65072
65073
65074
65075
65076
65077 <hr>
65078 <h3><a name="1151"></a>1151. Behavior of the library in the presence of threads is incompletely specified</h3>
65079 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
65080  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-11-19</p>
65081 <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>
65082 <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>
65083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
65084 <p><b>Discussion:</b></p>
65085 <p><b>Addresses US 63</b></p>
65086
65087    <p><b>Description</b></p>
65088         <p>The behavior of the library in the presence of threads
65089         is incompletely specified.</p>
65090         <p>For example, if thread 1 assigns to <tt>X</tt>, then writes data
65091         to file <tt>f</tt>, which is read by thread 2, and then accesses
65092         variable <tt>X</tt>, is thread 2 guaranteed to be able to see the
65093         value assigned to <tt>X</tt> by thread 1? In other words, does the
65094         write of the data "happen before" the read?</p>
65095         <p>Another example: does simultaneous access using <tt>operator
65096         at()</tt> to different characters in the same non-const string
65097         really introduce a data race?</p>
65098 <p><b>Suggestion</b></p>
65099 <p><b>Notes</b></p><p>17 SG: should go to threads group; misclassified in document
65100 </p>
65101
65102     <p>Concurrency SG: Create an issue. Hans will look into it.</p>
65103
65104 <p><i>[
65105 2009 Santa Cruz:
65106 ]</i></p>
65107
65108
65109 <blockquote>
65110 Move to "Open". Hans and the rest of the concurrency working group will
65111 study this. We can't make progress without a thorough review and a
65112 paper.
65113 </blockquote>
65114
65115 <p><i>[
65116 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
65117 ]</i></p>
65118
65119
65120
65121
65122 <p><b>Rationale:</b></p>
65123 <p>
65124 Solved by
65125 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3069.html">N3069</a>.
65126 </p>
65127
65128
65129 <p><b>Proposed resolution:</b></p>
65130
65131
65132
65133
65134
65135 <hr>
65136 <h3><a name="1152"></a>1152. expressions parsed differently than intended</h3>
65137 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65138  <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2009-06-27 <b>Last modified:</b> 2010-10-23</p>
65139 <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>
65140 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65141 <p><b>Discussion:</b></p>
65142 <p>
65143 In Table 73 -- Floating-point conversions, 22.4.2.2.2 [facet.num.put.virtuals], 
65144 in
65145 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
65146 we have the following entries: 
65147 </p>
65148 <table border="1">
65149 <caption>Table 73 \97 Floating-point conversions</caption>
65150 <tbody><tr>
65151 <th>State</th> <th><tt>stdio</tt> equivalent</th>
65152 </tr>
65153 <tr>
65154 <td><tt>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase</tt></td>
65155 <td align="center"><tt>%a</tt></td>
65156 </tr>
65157
65158 <tr>
65159 <td><tt>floatfield == ios_base::fixed | ios_base::scientific</tt></td>
65160 <td align="center"><tt>%A</tt></td>
65161 </tr>
65162 </tbody></table>
65163
65164 <p>
65165 These expressions are supposed to mean: 
65166 </p>
65167
65168 <blockquote><pre>floatfield == (ios_base::fixed | ios_base::scientific) &amp;&amp; !uppercase 
65169 floatfield == (ios_base::fixed | ios_base::scientific) 
65170 </pre></blockquote>
65171 <p>
65172 but technically parsed as: 
65173 </p>
65174 <blockquote><pre>((floatfield == ios_base::fixed) | ios_base::scientific) &amp;&amp; (!uppercase) 
65175 ((floatfield == ios_base::fixed) | ios_base::scientific) 
65176 </pre></blockquote>
65177 <p>
65178 and should be corrected with additional parentheses, as shown above. 
65179 </p>
65180
65181 <p><i>[
65182 2009-10-28 Howard:
65183 ]</i></p>
65184
65185
65186 <blockquote>
65187 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
65188 </blockquote>
65189
65190
65191
65192 <p><b>Proposed resolution:</b></p>
65193 <p>
65194 Change Table 83 \97 Floating-point conversions in  22.4.2.2.2 [facet.num.put.virtuals]:
65195 </p>
65196
65197 <table border="1">
65198 <caption>Table 83 \97 Floating-point conversions</caption>
65199 <tbody><tr>
65200 <th>State</th> <th><tt>stdio</tt> equivalent</th>
65201 </tr>
65202 <tr>
65203 <td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins> &amp;&amp; !uppercase</tt></td>
65204 <td align="center"><tt>%a</tt></td>
65205 </tr>
65206
65207 <tr>
65208 <td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins></tt></td>
65209 <td align="center"><tt>%A</tt></td>
65210 </tr>
65211 </tbody></table>
65212
65213
65214
65215
65216
65217 <hr>
65218 <h3><a name="1157"></a>1157. Local types can now instantiate templates</h3>
65219 <p><b>Section:</b> 17.6.3.2.1 [namespace.std] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65220  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
65221 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65222 <p><b>Discussion:</b></p>
65223
65224 <p><b>Addresses UK 175</b></p>
65225
65226 <p><b>Description</b></p>
65227         <p>Local types can
65228         now be used to instantiate templates, but don't have
65229         external linkage.</p>
65230 <p><b>Suggestion</b></p>
65231         <p>Remove the reference to external linkage.</p>
65232
65233 <p><b>Notes</b></p>
65234 <p>We accept the proposed solution. Martin will draft an issue.</p>
65235
65236 <p><i>[
65237 2009-07-28 Alisdair provided wording.
65238 ]</i></p>
65239
65240
65241 <p><i>[
65242 2009-10 Santa Cruz:
65243 ]</i></p>
65244
65245
65246 <blockquote>
65247 Moved to Ready.
65248 </blockquote>
65249
65250
65251
65252 <p><b>Proposed resolution:</b></p>
65253 <p>
65254 17.6.3.2.1 [namespace.std]
65255 </p>
65256 <p>
65257 Strike "of external linkage" in p1 and p2:
65258 </p>
65259
65260 <blockquote>
65261 <p>
65262 -1- The behavior of a C++ program is undefined if it adds declarations or
65263 definitions to namespace <tt>std</tt> or to a namespace within namespace <tt>std</tt>
65264 unless otherwise specified. A program may add a concept map for any
65265 standard library concept or a template specialization for any standard
65266 library template to namespace <tt>std</tt> only if the declaration depends on a
65267 user-defined type <del>of external linkage</del> and the specialization meets the
65268 standard library requirements for the original template and is not
65269 explicitly prohibited.<sup>179</sup>
65270 </p>
65271
65272 <p>
65273 -2- The behavior of a C++ program is undefined if it declares
65274 </p>
65275 <ul>
65276 <li>
65277 an explicit specialization of any member function of a standard library
65278 class template, or
65279 </li>
65280 <li>
65281 an explicit specialization of any member function template of a standard
65282 library class or class template, or
65283 </li>
65284 <li>
65285 an explicit or partial specialization of any member class template of a
65286 standard library class or class template.
65287 </li>
65288 </ul>
65289 <p>
65290 A program may explicitly instantiate a template defined in the standard
65291 library only if the declaration depends on the name of a user-defined
65292 type <del>of external linkage</del> and the instantiation meets the standard
65293 library requirements for the original template.
65294 </p>
65295 </blockquote>
65296
65297
65298
65299
65300
65301
65302 <hr>
65303 <h3><a name="1158"></a>1158. Encouragement to use monotonic clock</h3>
65304 <p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65305  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
65306 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.req.timing">issues</a> in [thread.req.timing].</p>
65307 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65308 <p><b>Discussion:</b></p>
65309
65310 <p><b>Addresses UK 322, US 96</b></p>
65311
65312 <p><b>Description</b></p>
65313         <p>Not all systems
65314         can provide a monotonic clock. How are they expected to
65315         treat a _for function?</p>
65316 <p><b>Suggestion</b></p>
65317         <p>Add at least a note explaining the intent
65318         for systems that do not support a monotonic clock.</p>
65319
65320 <p><b>Notes</b></p>
65321 <p>Create an issue, together with UK 96. Note that the specification as is 
65322     already allows a non-monotonic clock due to the word \93should\94 rather than 
65323     \93shall\94. If this wording is kept, a footnote should be added to make the 
65324     meaning clear.</p>
65325
65326 <p><i>[ 2009-06-29 Beman provided a proposed resolution. ] </i></p>
65327
65328 <p><i>[
65329 2009-10-31 Howard adds:
65330 ]</i></p>
65331
65332
65333 <blockquote>
65334 Set to Tentatively Ready after 5 positive votes on c++std-lib.
65335 </blockquote>
65336
65337 <p><i>[
65338 2010-02-24 Pete moved to Open:
65339 ]</i></p>
65340
65341
65342 <blockquote>
65343 LWG 1158's proposed resolution replaces the ISO-specified normative term
65344 "should" with "are encouraged but not required to", which presumably means the
65345 same thing, but has no ISO normative status. The WD used the latter formulation
65346 in quite a few non-normative places, but only three normative ones. I've changed
65347 all the normative uses to "should".
65348 </blockquote>
65349
65350 <p><i>[
65351 2010-03-06 Beman updates wording.
65352 ]</i></p>
65353
65354
65355 <p><i>[
65356 2010 Pittsburgh:  Moved to Ready.
65357 ]</i></p>
65358
65359
65360
65361
65362 <p><b>Proposed resolution:</b></p>
65363
65364 <p><i>Change Timing specifications 30.2.4 [thread.req.timing] as indicated:</i></p>
65365
65366 <p>
65367 The member functions whose names end in <tt>_for</tt> take an argument that
65368 specifies a relative time. Implementations should use a monotonic clock to
65369 measure time for these functions.  <ins>[<i>Note:</i> Implementations are not
65370 required to use a monotonic clock because such a clock may be unavailable.
65371 \97 <i>end note</i>]</ins>
65372 </p>
65373
65374
65375
65376
65377
65378
65379 <hr>
65380 <h3><a name="1159"></a>1159. Unclear spec for <tt>resource_deadlock_would_occur</tt></h3>
65381 <p><b>Section:</b> 30.4.2.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65382  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
65383 <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>
65384 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65385 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a></p>
65386 <p><b>Discussion:</b></p>
65387
65388 <p><b>Addresses UK 327, UK 328</b></p>
65389
65390 <p><b>UK 327 Description</b></p>
65391         <p>Not clear what
65392         the specification for error condition
65393         <tt>resource_deadlock_would_occur</tt> means. It is perfectly
65394         possible for this thread to own the mutex without setting
65395         owns to true on this specific lock object. It is also
65396         possible for lock operations to succeed even if the thread
65397         does own the mutex, if the mutex is recursive. Likewise, if
65398         the mutex is not recursive and the mutex has been locked
65399         externally, it is not always possible to know that this
65400         error condition should be raised, depending on the host
65401         operating system facilities. It is possible that 'i.e.' was
65402         supposed to be 'e.g.' and that suggests that recursive
65403         locks are not allowed. That makes sense, as the
65404         exposition-only member owns is boolean and not a integer to
65405         count recursive locks.</p>
65406         
65407 <p><b>UK 327 Suggestion</b></p>
65408         <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
65409         in the error condition to be 'e.g.' to allow for this
65410         condition to propogate deadlock detection by the host OS.</p>
65411 <p><b>UK 327 Notes</b></p>
65412 <p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
65413     means for recursive locks when you are the owner. POSIX has language on 
65414     this, which should ideally be followed. Proposed fix is not quite right, for 
65415     example, try_lock should have different wording from lock.</p>
65416
65417 <p><b>UK 328 Description</b></p>
65418
65419         <p>There is a missing precondition that <tt>owns</tt>
65420         is true, or an <tt>if(owns)</tt> test is missing from the effect
65421         clause</p>
65422 <p><b>UK 328 Suggestion</b></p>
65423         <p>Add a
65424         precondition that <tt>owns == true</tt>. Add an error condition to
65425         detect a violation, rather than yield undefined behaviour.</p>
65426 <p><b>UK 328 Notes</b></p>
65427 <p>Handle in same issue as UK 327. Also uncertain that the proposed resolution 
65428     is the correct one.</p>
65429
65430 <p><i>[
65431 2009-11-11 Alisdair notes that this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>,
65432 if not a dup.
65433 ]</i></p>
65434
65435
65436 <p><i>[
65437 2010-02-12 Anthony provided wording.
65438 ]</i></p>
65439
65440
65441 <p><i>[
65442 2010 Pittsburgh:
65443 ]</i></p>
65444
65445
65446 <blockquote>
65447 Wording updated and moved to Ready for Pittsburgh.
65448 </blockquote>
65449
65450
65451
65452 <p><b>Proposed resolution:</b></p>
65453 <p>
65454 Modify 30.4.2.2.2 [thread.lock.unique.locking] p3 to say:
65455 </p>
65456
65457 <blockquote>
65458 <pre>void lock();</pre>
65459 <blockquote>
65460 <p>...</p>
65461 <p>
65462 3 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;lock()</tt>.
65463 <tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
65464 <tt>std::system_error</tt> with an error condition of
65465 <tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
65466 <tt>std::system_error</tt> with an error condition of
65467 <tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
65468 <del><tt>std::system_error</tt> when the
65469 postcondition cannot be achieved.</del>
65470 </p>
65471 </blockquote>
65472 </blockquote>
65473
65474 <p>
65475 Remove 30.4.2.2.2 [thread.lock.unique.locking] p4 (Error condition clause).
65476 </p>
65477
65478 <p>
65479 Modify 30.4.2.2.2 [thread.lock.unique.locking] p8 to say:
65480 </p>
65481
65482 <blockquote>
65483 <pre>bool try_lock();</pre>
65484 <blockquote>
65485 <p>...</p>
65486 <p>
65487 8 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock()</tt>.
65488 <tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
65489 <tt>std::system_error</tt> with an error condition of
65490 <tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
65491 <tt>std::system_error</tt> with an error condition of
65492 <tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
65493 <del><tt>std::system_error</tt> when the
65494 postcondition cannot be achieved.</del>
65495 </p>
65496 </blockquote>
65497 </blockquote>
65498
65499 <p>
65500 Remove 30.4.2.2.2 [thread.lock.unique.locking] p9 (Error condition clause).
65501 </p>
65502
65503 <p>
65504 Modify 30.4.2.2.2 [thread.lock.unique.locking] p13 to say:
65505 </p>
65506
65507 <blockquote>
65508 <pre>template &lt;class Clock, class Duration&gt;
65509   bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);</pre>
65510 <blockquote>
65511 <p>...</p>
65512 <p>
65513 13 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock_until()</tt>.
65514 <tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
65515 <tt>std::system_error</tt> with an error condition of
65516 <tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
65517 <tt>std::system_error</tt> with an error condition of
65518 <tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
65519 <del><tt>std::system_error</tt> when the
65520 postcondition cannot be achieved.</del>
65521 </p>
65522 </blockquote>
65523 </blockquote>
65524
65525 <p>
65526 Remove 30.4.2.2.2 [thread.lock.unique.locking] p14 (Error condition clause).
65527 </p>
65528
65529 <p>
65530 Modify 30.4.2.2.2 [thread.lock.unique.locking] p18 to say:
65531 </p>
65532
65533 <blockquote>
65534 <pre>template &lt;class Rep, class Period&gt;
65535   bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
65536 <blockquote>
65537 <p>...</p>
65538 <p>
65539 18 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock_for()</tt>.
65540 <tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
65541 <tt>std::system_error</tt> with an error condition of
65542 <tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
65543 <tt>std::system_error</tt> with an error condition of
65544 <tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
65545 <del><tt>std::system_error</tt> when the
65546 postcondition cannot be achieved.</del>
65547 </p>
65548 </blockquote>
65549 </blockquote>
65550
65551 <p>
65552 Remove 30.4.2.2.2 [thread.lock.unique.locking] p19 (Error condition clause).
65553 </p>
65554
65555
65556
65557
65558
65559
65560 <hr>
65561 <h3><a name="1170"></a>1170. String <i>char-like types</i> no longer PODs</h3>
65562 <p><b>Section:</b> 21.1 [strings.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65563  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-22 <b>Last modified:</b> 2010-10-23</p>
65564 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65565 <p><b>Discussion:</b></p>
65566
65567 <p><b>Addresses UK 218</b></p>
65568
65569 <p>Prior to the introduction of constant expressions into the library, 
65570 <tt>basic_string</tt> elements had to be POD types, and thus had to be both trivially 
65571 copyable and standard-layout. This ensured that they could be memcpy'ed and 
65572 would be compatible with other libraries and languages, particularly the C 
65573 language and its library.</p>
65574 <p>
65575 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>,
65576 Constant Expressions in the Standard Library Revision 2, changed the 
65577 requirement in 21/1 from "POD type" to "literal type". That change had the 
65578 effect of removing the trivially copyable and standard-layout requirements from 
65579 <tt>basic_string</tt> elements.</p>
65580 <p>This means that <tt>basic_string</tt> elements no longer are guaranteed to be 
65581 memcpy'able, and are no longer guaranteed to be standard-layout types:</p>
65582 <blockquote>
65583   <p>3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is 
65584   required for memcpy to be guaranteed to work.</p>
65585   <p>Literal types (3.9p12) may have a non-trivial copy assignment operator, and 
65586   that violates the trivially copyable requirements given in 9/p 6, bullet item 
65587   2. </p>
65588   <p>Literal types (3.9p12) have no standard-layout requirement, either.</p>
65589 </blockquote>
65590 <p>This situation probably arose because the wording for "Constant Expressions 
65591 in the Standard Library" was in process at the same time the C++ POD 
65592 deconstruction wording was in process. </p>
65593 <p>Since trivially copyable types meet the C++0x requirements for literal types, 
65594 and thus work with constant expressions, it seems an easy fix to revert the 
65595 <tt>basic_string</tt> element wording to its original state.</p>
65596
65597  <p><i>[
65598  2009-07-28 Alisdair adds:
65599  ]</i></p>
65600
65601  
65602 <blockquote>
65603 When looking for any resolution for this issue, consider the definition of
65604 "character container type" in 17.3.5 [defns.character.container].  This
65605 does require the character type to be a POD, and this term is used in a
65606 number of places through clause 21 and 28. This suggests the PODness
65607 constraint remains, but is much more subtle than before.  Meanwhile, I
65608 suspect the change from POD type to literal type was intentional with
65609 the assumption that trivially copyable types with
65610 non-trivial-but-constexpr constructors should serve as well.  I don't
65611 believe the current wording offers the right guarantees for either of
65612 the above designs.
65613 </blockquote>
65614
65615 <p><i>[
65616 2009-11-04 Howard modifies proposed wording to disallow array types as
65617 char-like types.
65618 ]</i></p>
65619
65620
65621 <p><i>[
65622 2010-01-23 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
65623 ]</i></p>
65624
65625
65626
65627
65628 <p><b>Proposed resolution:</b></p>
65629
65630 <p><i>Change General 21.1 [strings.general] as indicated:</i></p>
65631 <blockquote>
65632 <p>This Clause describes components for manipulating sequences of any
65633 <del>literal</del> <ins>non-array POD</ins> (3.9) type. In this Clause
65634 such types are called <i>char-like types</i>, and objects of char-like
65635 types are called <i>char-like objects</i> or simply
65636 <i>characters</i>.</p>
65637 </blockquote>
65638
65639
65640
65641
65642
65643
65644 <hr>
65645 <h3><a name="1171"></a>1171. duration types should be literal</h3>
65646 <p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65647  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06 <b>Last modified:</b> 2010-11-29</p>
65648 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
65649 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65650 <p><b>Discussion:</b></p>
65651 <p>
65652 The <tt>duration</tt> types in 20.11.3 [time.duration] are exactly the sort of type
65653 that should be "literal types" in the new standard.  Likewise,
65654 arithmetic operations on <tt>duration</tt>s should be declared <tt>constexpr</tt>.
65655 </p>
65656
65657 <p><i>[
65658 2009-09-21 Daniel adds:
65659 ]</i></p>
65660
65661
65662 <blockquote>
65663 An alternative (and possibly preferable solution for potentially
65664 heap-allocating big_int representation types) would be to ask the core
65665 language to allow references to <tt>const</tt> literal types as feasible
65666 arguments for <tt>constexpr</tt> functions.
65667 </blockquote>
65668
65669 <p><i>[
65670 2009-10-30 Alisdair adds:
65671 ]</i></p>
65672
65673
65674 <blockquote>
65675 <p>
65676 I suggest this issue moves from New to Open.
65677 </p>
65678
65679 <p>
65680 Half of this issue was dealt with in paper
65681 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">n2994</a>
65682 on constexpr constructors.
65683 </p>
65684
65685 <p>
65686 The other half (duration arithmetic) is on hold pending Core support for
65687 <tt>const &amp;</tt> in <tt>constexpr</tt> functions.
65688 </p>
65689
65690 </blockquote>
65691
65692 <p><i>[
65693 2010-03-15 Alisdair updated wording to be consistent with
65694 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3078.html">N3078</a>.
65695 ]</i></p>
65696
65697
65698
65699 <p><i>[
65700 2010 Rapperswil:
65701 ]</i></p>
65702
65703
65704 <blockquote>
65705 This issue was the motivation for Core adding the facility for <tt>constexpr</tt> functions to take parameters by <tt>const &amp;</tt>.
65706
65707 Move to Tentatively Ready.
65708 </blockquote>
65709
65710 <p><i>[
65711 Adopted at 2010-11 Batavia.
65712 ]</i></p>
65713
65714
65715
65716
65717 <p><b>Proposed resolution:</b></p>
65718 <p>
65719 Add <tt>constexpr</tt> to declaration of following functions and constructors:
65720 </p>
65721 <p>
65722 Modify p1 20.11 [time], and the prototype definitions in 20.11.3.5 [time.duration.nonmember], 20.11.3.6 [time.duration.comparisons],
65723 and 20.11.3.7 [time.duration.cast]:
65724 </p>
65725
65726 <blockquote>
65727 <p>
65728 <b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
65729 </p>
65730
65731 <pre><i>// duration arithmetic</i>
65732 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65733    typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
65734    <ins>constexpr</ins> operator+(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65735 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65736    typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
65737    <ins>constexpr</ins> operator-(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65738 template &lt;class Rep1, class Period, class Rep2&gt;
65739    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
65740    <ins>constexpr</ins> operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
65741 template &lt;class Rep1, class Period, class Rep2&gt;
65742    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
65743    <ins>constexpr</ins> operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
65744 template &lt;class Rep1, class Period, class Rep2&gt;
65745    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
65746    <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
65747 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65748    typename common_type&lt;Rep1, Rep2&gt;::type
65749    <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65750
65751 <i>// duration comparisons</i>
65752 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65753    <ins>constexpr</ins> bool operator==(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65754 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65755    <ins>constexpr</ins> bool operator!=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65756 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65757    <ins>constexpr</ins> bool operator&lt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65758 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65759    <ins>constexpr</ins> bool operator&lt;=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65760 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65761    <ins>constexpr</ins> bool operator&gt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65762 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
65763    <ins>constexpr</ins> bool operator&gt;=(const  duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
65764
65765 <i>// duration_cast</i>
65766 template &lt;class ToDuration, class Rep, class Period&gt;
65767    <ins>constexpr</ins> ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
65768 </pre>
65769
65770 </blockquote>
65771
65772 <p>
65773 Change 20.11.3 [time.duration]:
65774 </p>
65775
65776 <blockquote>
65777
65778 <pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
65779 class duration {
65780   ...
65781 public:
65782   ...
65783   <ins>constexpr</ins> duration(const duration&amp;) = default;
65784   ...
65785
65786 };
65787 </pre>
65788 </blockquote>
65789 <p><i>[
65790 Note - this edit already seems assumed by definition of the duration static members <tt>zero/min/max</tt>.
65791 They cannot meaningfully be <tt>constexpr</tt> without this change.
65792 ]</i></p>
65793
65794
65795
65796
65797
65798
65799 <hr>
65800 <h3><a name="1174"></a>1174. type property predicates</h3>
65801 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
65802  <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-07-16 <b>Last modified:</b> 2010-11-20</p>
65803 <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>
65804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
65805 <p><b>Discussion:</b></p>
65806 <p>
65807 I've been implementing compiler support for <tt>is_standard_layout</tt>, and
65808 noticed a few nits about 20.7.4.3 [meta.unary.prop]:
65809 </p>
65810
65811 <ol>
65812 <li>
65813 There's no trait for "trivially copyable type", which is now the
65814 property that lets you do bitwise copying of a type, and therefore seems
65815 useful to be able to query.  <tt>has_trivial_assign</tt> &amp;&amp;
65816 <tt>has_trivial_copy_constructor</tt> &amp;&amp; <tt>has_trivial_destructor</tt>
65817 is similar, but
65818 not identical, specifically with respect to const types.
65819 </li>
65820 <li>
65821 <tt>has_trivial_copy_constructor</tt> and <tt>has_trivial_assign</tt> lack the "or an
65822 array of such a class type" language that most other traits in that
65823 section, including <tt>has_nothrow_copy_constructor</tt> and <tt>has_nothrow_assign</tt>,
65824 have; this seems like an oversight.
65825 </li>
65826 </ol>
65827
65828 <p><i>[
65829 See the thread starting with c++std-lib-24420 for further discussion.
65830 ]</i></p>
65831
65832
65833 <p><i>[
65834 Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
65835 ]</i></p>
65836
65837
65838 <p><i>[
65839 2009-10 Santa Cruz:
65840 ]</i></p>
65841
65842
65843 <blockquote>
65844 <del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
65845 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
65846 </blockquote>
65847
65848
65849
65850 <p><b>Proposed resolution:</b></p>
65851 <p>
65852 </p>
65853
65854
65855
65856
65857
65858 <hr>
65859 <h3><a name="1177"></a>1177. Improve "diagnostic required" wording</h3>
65860 <p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
65861  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18 <b>Last modified:</b> 2010-10-23</p>
65862 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
65863 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
65864 <p><b>Discussion:</b></p>
65865 <p>
65866 "diagnostic required" has been used (by me) for code words meaning "use
65867 <tt>enable_if</tt> to constrain templated functions.  This needs to be
65868 improved by referring to the function signature as not participating in
65869 the overload set, and moving this wording to a <i>Remarks</i> paragraph.
65870 </p>
65871
65872 <p><i>[
65873 2009-10 Santa Cruz:
65874 ]</i></p>
65875
65876
65877 <blockquote>
65878 Moved to Ready.
65879 </blockquote>
65880
65881 <p><i>[
65882 2009-11-19 Pete opens:
65883 ]</i></p>
65884
65885
65886 <blockquote>
65887 <p>
65888 Oh, and speaking of 1177, most of the changes result in rather convoluted prose.
65889 Instead of saying
65890 </p>
65891
65892 <blockquote>
65893 A shall be B, else C
65894 </blockquote>
65895
65896 <p>
65897 it should be
65898 </p>
65899
65900 <blockquote>
65901 C if A is not B
65902 </blockquote>
65903
65904 <p>
65905 That is:
65906 </p>
65907
65908 <blockquote>
65909 <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>, else
65910 this signature shall not participate in overload resolution.
65911 </blockquote>
65912
65913 <p>
65914 should be
65915 </p>
65916
65917 <blockquote>
65918 This signature shall not participate in overload resolution if <tt>Rep2</tt> is
65919 not implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
65920 </blockquote>
65921
65922 <p>
65923 That is clearer, and eliminates the false requirement that <tt>Rep2</tt> "shall
65924 be" convertible.
65925 </p>
65926
65927 </blockquote>
65928
65929 <p><i>[
65930 2009-11-19 Howard adds:
65931 ]</i></p>
65932
65933
65934 <blockquote>
65935 I've updated the wording to match Pete's suggestion and included bullet 16
65936 from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>.
65937 </blockquote>
65938
65939 <p><i>[
65940 2009-11-19 Jens adds:
65941 ]</i></p>
65942
65943
65944 <blockquote>
65945 <p>
65946 Further wording suggestion using "unless":
65947 </p>
65948
65949 <blockquote>
65950 This signature shall not participate in overload resolution unless <tt>Rep2</tt>
65951 is implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
65952 </blockquote>
65953 </blockquote>
65954
65955 <p><i>[
65956 2009-11-20 Howard adds:
65957 ]</i></p>
65958
65959
65960 <blockquote>
65961 I've updated the wording to match Jens' suggestion.
65962 </blockquote>
65963
65964 <p><i>[
65965 2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
65966 ]</i></p>
65967
65968
65969
65970
65971 <p><b>Proposed resolution:</b></p>
65972 <p><i>[
65973 This proposed resolution addresses <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>. 
65974 ]</i></p>
65975
65976
65977 <ol>
65978 <li>
65979 <p>
65980 Change 20.11.3.1 [time.duration.cons] (and reorder the <i>Remarks</i>
65981 paragraphs per 17.5.1.4 [structure.specifications]):
65982 </p>
65983
65984 <blockquote>
65985 <pre>template &lt;class Rep2&gt; 
65986   explicit duration(const Rep2&amp; r);
65987 </pre>
65988 <blockquote>
65989 <p>
65990 <i><del>Requires:</del> <ins>Remarks:</ins></i> <ins>This constructor shall not
65991 participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall be</del>
65992 <ins>is</ins> implicitly convertible to <tt>rep</tt> and
65993 </p>
65994 <ul>
65995 <li>
65996 <tt>treat_as_floating_point&lt;rep&gt;::value</tt> <del>shall be</del>
65997 <ins>is</ins> <tt>true</tt><ins>,</ins> or
65998 </li>
65999 <li>
66000 <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> <del>shall be</del>
66001 <ins>is</ins> <tt>false</tt>.
66002 </li>
66003 </ul>
66004 <p>
66005 <del>Diagnostic required</del> [<i>Example:</i>
66006 </p>
66007 <blockquote><pre>duration&lt;int, milli&gt; d(3); // OK 
66008 duration&lt;int, milli&gt; d(3.5); // error 
66009 </pre></blockquote>
66010
66011 <p>
66012 \97 <i>end example</i>]
66013 </p>
66014
66015 <p>
66016 <i>Effects:</i> Constructs an object of type <tt>duration</tt>.
66017 </p>
66018
66019 <p>
66020 <i>Postcondition:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
66021 </p>
66022
66023 </blockquote>
66024
66025 <pre>template &lt;class Rep2, class Period2&gt;
66026   duration(const duration&lt;Rep2, Period2&gt;&amp; d);
66027 </pre>
66028 <blockquote>
66029 <p>
66030 <i><del>Requires:</del> <ins>Remarks:</ins></i> <ins>This constructor shall not
66031 participate in overload resolution unless</ins>
66032 <tt>treat_as_floating_point&lt;rep&gt;::value</tt> <del>shall be</del>
66033 <ins>is</ins> <tt>true</tt> or <tt>ratio_divide&lt;Period2,
66034 period&gt;::type::den</tt> <del>shall be</del> <ins>is</ins> 1. <del>Diagnostic
66035 required.</del> [<i>Note:</i> This requirement prevents implicit truncation
66036 error when converting between integral-based duration types. Such a construction
66037 could easily lead to confusion about the value of the duration. \97 <i>end
66038 note</i>] [<i>Example:</i>
66039 </p>
66040
66041 <blockquote><pre>duration&lt;int, milli&gt; ms(3); 
66042 duration&lt;int, micro&gt; us = ms; // OK 
66043 duration&lt;int, milli&gt; ms2 = us; // error 
66044 </pre></blockquote>
66045
66046 <p>
66047 \97 <i>end example</i>]
66048 </p>
66049
66050 <p>
66051 <i>Effects:</i> Constructs an object of type <tt>duration</tt>, constructing
66052 <tt>rep_</tt> from
66053 <tt>duration_cast&lt;duration&gt;(d).count()</tt>.
66054 </p>
66055
66056 </blockquote>
66057
66058
66059 </blockquote>
66060 </li>
66061
66062 <li>
66063 <p>
66064 Change the following paragraphs in 20.11.3.5 [time.duration.nonmember]:
66065 </p>
66066
66067 <blockquote>
66068 <pre>template &lt;class Rep1, class Period, class Rep2&gt; 
66069   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
66070   operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
66071 </pre>
66072 <blockquote>
66073 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
66074 participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
66075 be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
66076 <del>Diagnostic required.</del>
66077 </blockquote>
66078
66079 <pre>template &lt;class Rep1, class Period, class Rep2&gt; 
66080   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
66081   operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
66082 </pre>
66083 <blockquote>
66084 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
66085 participate in overload resolution unless</ins> <tt>Rep1</tt> <del>shall
66086 be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
66087 <del>Diagnostic required.</del>
66088 </blockquote>
66089
66090 <pre>template &lt;class Rep1, class Period, class Rep2&gt; 
66091   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
66092   operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
66093 </pre>
66094 <blockquote>
66095 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
66096 participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
66097 be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
66098 <tt>Rep2</tt> <del>shall not be</del> <ins>is not</ins> an instantiation of
66099 <tt>duration</tt>. <del>Diagnostic required.</del>
66100 </blockquote>
66101
66102 <pre>template &lt;class Rep1, class Period, class Rep2&gt; 
66103   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
66104   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
66105 </pre>
66106 <blockquote>
66107 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
66108 participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
66109 be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
66110 <tt>Rep2</tt> <del>shall not be</del> <ins>is not</ins> an instantiation of
66111 <tt>duration</tt>. <del>Diagnostic required.</del>
66112 </blockquote>
66113
66114 </blockquote>
66115 </li>
66116
66117 <li>
66118 <p>
66119 Change the following paragraphs in 20.11.3.7 [time.duration.cast]:
66120 </p>
66121
66122 <blockquote><pre>template &lt;class ToDuration, class Rep, class Period&gt; 
66123   ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
66124 </pre>
66125
66126 <blockquote>
66127 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This function shall not
66128 participate in overload resolution unless</ins> <tt>ToDuration</tt> <del>shall
66129 be</del> <ins>is</ins> an instantiation of <tt>duration</tt>. <del>Diagnostic
66130 required.</del>
66131 </blockquote>
66132 </blockquote>
66133 </li>
66134
66135 <li>
66136 <p>
66137 Change 20.11.4.1 [time.point.cons]/3 as indicated:
66138 </p>
66139
66140 <blockquote>
66141 <p>
66142 <del><i>Requires:</i> <tt>Duration2</tt> shall be implicitly convertible to <tt>duration</tt>.
66143 Diagnostic required.</del>
66144 </p>
66145
66146 <p>
66147 <ins><i>Remarks:</i> This constructor shall not participate in overload
66148 resolution unless <tt>Duration2</tt> is implicitly convertible to
66149 <tt>duration</tt>.</ins>
66150 </p>
66151 </blockquote>
66152
66153 </li>
66154
66155 <li>
66156 <p>
66157 Change the following paragraphs in 20.11.4.7 [time.point.cast]:
66158 </p>
66159
66160 <blockquote><pre>template &lt;class ToDuration, class Clock, class Duration&gt; 
66161   time_point&lt;Clock, ToDuration&gt; time_point_cast(const time_point&lt;Clock, Duration&gt;&amp; t);
66162 </pre>
66163
66164 <blockquote>
66165 <i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This function shall not
66166 participate in overload resolution unless</ins> <tt>ToDuration</tt> <del>shall
66167 be</del> <ins>is</ins> an instantiation of <tt>duration</tt>. <del>Diagnostic
66168 required.</del>
66169 </blockquote>
66170 </blockquote>
66171 </li>
66172 </ol>
66173
66174
66175
66176
66177
66178
66179 <hr>
66180 <h3><a name="1178"></a>1178. Header dependencies</h3>
66181 <p><b>Section:</b> 17.6.4.2 [res.on.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
66182  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-07-18 <b>Last modified:</b> 2010-10-23</p>
66183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
66184 <p><b>Discussion:</b></p>
66185 <p>
66186 See Frankfurt notes of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>.
66187 </p>
66188
66189
66190 <p><b>Proposed resolution:</b></p>
66191 <p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
66192
66193 <blockquote>
66194
66195 <p>
66196 A C++ header may include other C++
66197 headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
66198 the declarations and definitions that appear in its synopsis
66199 (3.2 [basic.def.odr]). A C++ header shown in its synopsis as including 
66200 other C++ headers shall provide the declarations and definitions that appear in
66201 the synopses of those other headers.</ins>
66202 </p>
66203
66204   <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
66205   any needed definition (3.2).</del></p>
66206 </blockquote>
66207
66208
66209
66210
66211
66212
66213 <hr>
66214 <h3><a name="1180"></a>1180. Missing string_type member typedef in class <tt>sub_match</tt></h3>
66215 <p><b>Section:</b> 28.9.1 [re.submatch.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
66216  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25 <b>Last modified:</b> 2010-10-23</p>
66217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
66218 <p><b>Discussion:</b></p>
66219 <p>
66220 The definition of class template <tt>sub_match</tt> is strongly dependent
66221 on the type <tt>basic_string&lt;value_type&gt;</tt>, both in interface and effects,
66222 but does not provide a corresponding typedef <tt>string_type</tt>, as e.g.
66223 class <tt>match_results</tt> does, which looks like an oversight to me that
66224 should be fixed.
66225 </p>
66226
66227 <p><i>[
66228 2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
66229 ]</i></p>
66230
66231
66232
66233 <p><b>Proposed resolution:</b></p>
66234
66235 <ol>
66236 <li>
66237 <p>
66238 In the class template <tt>sub_match</tt> synopsis 28.9 [re.submatch]/1
66239 change as indicated:
66240 </p>
66241
66242 <blockquote><pre>template &lt;class BidirectionalIterator&gt;
66243 class sub_match : public std::pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
66244 public:
66245   typedef typename iterator_traits&lt;BidirectionalIterator&gt;::value_type value_type;
66246   typedef typename iterator_traits&lt;BidirectionalIterator&gt;::difference_type difference_type;
66247   typedef BidirectionalIterator iterator;
66248   <ins>typedef basic_string&lt;value_type&gt; string_type;</ins>
66249
66250   bool matched;
66251
66252   difference_type length() const;
66253   operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
66254   <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
66255   int compare(const sub_match&amp; s) const;
66256   int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
66257   int compare(const value_type* s) const;
66258 };
66259 </pre></blockquote>
66260 </li>
66261
66262 <li>
66263 <p>
66264 In 28.9.1 [re.submatch.members]/2 change as indicated:
66265 </p>
66266
66267 <blockquote><pre>operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
66268 </pre>
66269
66270 <blockquote>
66271 <i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
66272 <ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
66273 <ins>string_type</ins>()</tt>.
66274 </blockquote>
66275 </blockquote>
66276 </li>
66277
66278 <li>
66279 <p>
66280 In 28.9.1 [re.submatch.members]/3 change as indicated:
66281 </p>
66282
66283 <blockquote><pre><del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
66284 </pre>
66285
66286 <blockquote>
66287 <i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
66288 <ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
66289 <ins>string_type</ins>()</tt>.
66290 </blockquote>
66291 </blockquote>
66292 </li>
66293
66294 <li>
66295 <p>
66296 In 28.9.1 [re.submatch.members]/5 change as indicated:
66297 </p>
66298
66299 <blockquote><pre>int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
66300 </pre></blockquote>
66301 </li>
66302 </ol>
66303
66304
66305
66306
66307
66308
66309 <hr>
66310 <h3><a name="1181"></a>1181. Invalid <tt>sub_match</tt> comparison operators</h3>
66311 <p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
66312  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25 <b>Last modified:</b> 2010-11-24</p>
66313 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
66314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
66315 <p><b>Discussion:</b></p>
66316 <p>
66317 Several heterogeneous comparison operators of class template
66318 <tt>sub_match</tt> are specified by return clauses that are not valid
66319 in general. E.g. 28.9.2 [re.submatch.op]/7:
66320 </p>
66321
66322 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66323 bool operator==(
66324   const basic_string&lt;
66325     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66326   const sub_match&lt;BiIter&gt;&amp; rhs);
66327 </pre>
66328 <blockquote>
66329 <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
66330 </blockquote>
66331 </blockquote>
66332
66333 <p>
66334 The returns clause would be ill-formed for all cases where
66335 <tt>ST != std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>
66336 or <tt>SA != std::allocator&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>.
66337 </p>
66338 <p>
66339 The generic character of the comparison was intended, so
66340 there are basically two approaches to fix the problem: The
66341 first one would define the semantics of the comparison
66342 using the traits class <tt>ST</tt> (The semantic of <tt>basic_string::compare</tt>
66343 is defined in terms of the compare function of the corresponding
66344 traits class), the second one would define the semantics of the
66345 comparison using the traits class
66346 </p>
66347
66348 <blockquote><pre>std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
66349 </pre></blockquote>
66350
66351 <p>
66352 which is essentially identical to
66353 </p>
66354
66355 <blockquote><pre>std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
66356 </pre></blockquote>
66357
66358 <p>
66359 I suggest to follow the second approach, because
66360 this emphasizes the central role of the <tt>sub_match</tt>
66361 object as part of the comparison and would also
66362 make sure that a <tt>sub_match</tt> comparison using some
66363 <tt>basic_string&lt;char_t, ..&gt;</tt> always is equivalent to
66364 a corresponding comparison with a string literal
66365 because of the existence of further overloads (beginning
66366 from 28.9.2 [re.submatch.op]/19). If users really want to
66367 take advantage of their own <tt>traits::compare</tt>, they can
66368 simply write a corresponding compare function that
66369 does so.
66370 </p>
66371
66372 <p><i>[
66373 Post-Rapperswil
66374 ]</i></p>
66375
66376
66377 <p>
66378 The following update is a result of the discussion during the Rapperswil meeting, the P/R expresses all comparisons by 
66379 delegating to sub_match's compare functions. The processing is rather mechanical: Only <tt>==</tt> and <tt>&lt;</tt>
66380 where defined by referring to <tt>sub_match</tt>'s compare function, all remaining ones where replaced by the canonical
66381 definitions in terms of these two.
66382 </p>
66383
66384 <blockquote>
66385 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
66386 </blockquote>
66387
66388 <p><i>[
66389 Adopted at 2010-11 Batavia
66390 ]</i></p>
66391
66392
66393
66394
66395 <p><b>Proposed resolution:</b></p>
66396 <p>
66397 <i>The wording refers to N3126.</i>
66398 </p>
66399
66400 <ol>
66401 <li>Change 28.9.2 [re.submatch.op]/7 as indicated:
66402 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66403  bool operator==(
66404    const basic_string&lt;
66405      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66406    const sub_match&lt;BiIter&gt;&amp; rhs);
66407 </pre>
66408 7 <em>Returns</em>: <tt><del>lhs == rhs.str()</del><ins>rhs.compare(lhs.c_str()) == 0</ins></tt>.
66409 </blockquote>
66410 </li>
66411 <li>Change 28.9.2 [re.submatch.op]/8 as indicated:
66412 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66413  bool operator!=(
66414    const basic_string&lt;
66415      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66416    const sub_match&lt;BiIter&gt;&amp; rhs);
66417 </pre>
66418 8 <em>Returns</em>: <tt><del>lhs != rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
66419 </blockquote>
66420 </li>
66421 <li>Change 28.9.2 [re.submatch.op]/9 as indicated:
66422 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66423  bool operator&lt;(
66424    const basic_string&lt;
66425      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66426    const sub_match&lt;BiIter&gt;&amp; rhs);
66427 </pre>
66428 9 <em>Returns</em>: <tt><del>lhs &lt; rhs.str()</del><ins>rhs.compare(lhs.c_str()) &gt; 0</ins></tt>.
66429 </blockquote>
66430 </li>
66431 <li>Change 28.9.2 [re.submatch.op]/10 as indicated:
66432 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66433  bool operator&gt;(
66434    const basic_string&lt;
66435      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66436    const sub_match&lt;BiIter&gt;&amp; rhs);
66437 </pre>
66438 10 <em>Returns</em>: <tt><del>lhs &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
66439 </blockquote>
66440 </li>
66441 <li>Change 28.9.2 [re.submatch.op]/11 as indicated:
66442 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66443  bool operator&gt;=(
66444    const basic_string&lt;
66445    typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66446  const sub_match&lt;BiIter&gt;&amp; rhs);
66447 </pre>
66448 11 <em>Returns</em>: <tt><del>lhs &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
66449 </blockquote>
66450 </li>
66451 <li>Change 28.9.2 [re.submatch.op]/12 as indicated:
66452 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66453  bool operator&lt;=(
66454    const basic_string&lt;
66455      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
66456    const sub_match&lt;BiIter&gt;&amp; rhs);
66457 </pre>
66458 12 <em>Returns</em>: <tt><del>lhs &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
66459 </blockquote>
66460 </li>
66461 <li>Change 28.9.2 [re.submatch.op]/13 as indicated:
66462 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66463  bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
66464    const basic_string&lt;
66465      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66466 </pre>
66467 13 <em>Returns</em>: <tt><del>lhs.str() == rhs</del><ins>lhs.compare(rhs.c_str()) == 0</ins></tt>.
66468 </blockquote>
66469 </li>
66470 <li>Change 28.9.2 [re.submatch.op]/14 as indicated:
66471 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66472  bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
66473    const basic_string&lt;
66474      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66475 </pre>
66476 14 <em>Returns</em>: <tt><del>lhs.str() != rhs</del><ins>!(lhs == rhs)</ins></tt>.
66477 </blockquote>
66478 </li>
66479 <li>Change 28.9.2 [re.submatch.op]/15 as indicated:
66480 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66481  bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66482    const basic_string&lt;
66483      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66484 </pre>
66485 15 <em>Returns</em>: <tt><del>lhs.str() &lt; rhs</del><ins>lhs.compare(rhs.c_str()) &lt; 0</ins></tt>.
66486 </blockquote>
66487 </li>
66488 <li>Change 28.9.2 [re.submatch.op]/16 as indicated:
66489 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66490  bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66491    const basic_string&lt;
66492      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66493 </pre>
66494 16 <em>Returns</em>: <tt><del>lhs.str() &gt; rhs</del><ins>rhs &lt; lhs</ins></tt>.
66495 </blockquote>
66496 </li>
66497 <li>Change 28.9.2 [re.submatch.op]/17 as indicated:
66498 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66499  bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66500    const basic_string&lt;
66501      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66502 </pre>
66503 17 <em>Returns</em>: <tt><del>lhs.str() &gt;= rhs</del><ins>!(lhs &lt; rhs)</ins></tt>.
66504 </blockquote>
66505 </li>
66506 <li>Change 28.9.2 [re.submatch.op]/18 as indicated:
66507 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
66508  bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66509    const basic_string&lt;
66510      typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
66511 </pre>
66512 18 <em>Returns</em>: <tt><del>lhs.str() &lt;= rhs</del><ins>!(rhs &lt; lhs)</ins></tt>.
66513 </blockquote>
66514 </li>
66515 <li>Change 28.9.2 [re.submatch.op]/19 as indicated:
66516 <blockquote><pre>template &lt;class BiIter&gt;
66517  bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66518    const sub_match&lt;BiIter&gt;&amp; rhs);
66519 </pre>
66520 19 <em>Returns</em>: <tt><del>lhs == rhs.str()</del><ins>rhs.compare(lhs) == 0</ins></tt>.
66521 </blockquote>
66522 </li>
66523 <li>Change 28.9.2 [re.submatch.op]/20 as indicated:
66524 <blockquote><pre>template &lt;class BiIter&gt;
66525  bool operator!=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66526    const sub_match&lt;BiIter&gt;&amp; rhs);
66527 </pre>
66528 20 <em>Returns</em>: <tt><del>lhs != rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
66529 </blockquote>
66530 </li>
66531 <li>Change 28.9.2 [re.submatch.op]/21 as indicated:
66532 <blockquote><pre>template &lt;class BiIter&gt;
66533  bool operator&lt;(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66534    const sub_match&lt;BiIter&gt;&amp; rhs);
66535 </pre>
66536 21 <em>Returns</em>: <tt><del>lhs &lt; rhs.str()</del><ins>rhs.compare(lhs) &gt; 0</ins></tt>.
66537 </blockquote>
66538 </li>
66539 <li>Change 28.9.2 [re.submatch.op]/22 as indicated:
66540 <blockquote><pre>template &lt;class BiIter&gt;
66541  bool operator&gt;(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66542    const sub_match&lt;BiIter&gt;&amp; rhs);
66543 </pre>
66544 22 <em>Returns</em>: <tt><del>lhs &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
66545 </blockquote>
66546 </li>
66547 <li>Change 28.9.2 [re.submatch.op]/23 as indicated:
66548 <blockquote><pre>template &lt;class BiIter&gt;
66549  bool operator&gt;=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66550    const sub_match&lt;BiIter&gt;&amp; rhs);
66551 </pre>
66552 23 <em>Returns</em>: <tt><del>lhs &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
66553 </blockquote>
66554 </li>
66555 <li>Change 28.9.2 [re.submatch.op]/24 as indicated:
66556 <blockquote><pre>template &lt;class BiIter&gt;
66557  bool operator&lt;=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
66558    const sub_match&lt;BiIter&gt;&amp; rhs);
66559 </pre>
66560 24 <em>Returns</em>: <tt><del>lhs &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
66561 </blockquote>
66562 </li>
66563 <li>Change 28.9.2 [re.submatch.op]/25 as indicated:
66564 <blockquote><pre>template &lt;class BiIter&gt;
66565  bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
66566    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66567 </pre>
66568 25 <em>Returns</em>: <tt><del>lhs.str() == rhs</del><ins>lhs.compare(rhs) == 0</ins></tt>.
66569 </blockquote>
66570 </li>
66571 <li>Change 28.9.2 [re.submatch.op]/26 as indicated:
66572 <blockquote><pre>template &lt;class BiIter&gt;
66573  bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
66574    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66575 </pre>
66576 26 <em>Returns</em>: <tt><del>lhs.str() != rhs</del><ins>!(lhs == rhs)</ins></tt>.
66577 </blockquote>
66578 </li>
66579 <li>Change 28.9.2 [re.submatch.op]/27 as indicated:
66580 <blockquote><pre>template &lt;class BiIter&gt;
66581  bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66582    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66583 </pre>
66584 27 <em>Returns</em>: <tt><del>lhs.str() &lt; rhs</del><ins>lhs.compare(rhs) &lt; 0</ins></tt>.
66585 </blockquote>
66586 </li>
66587 <li>Change 28.9.2 [re.submatch.op]/28 as indicated:
66588 <blockquote><pre>template &lt;class BiIter&gt;
66589  bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66590    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66591 </pre>
66592 28 <em>Returns</em>: <tt><del>lhs.str() &gt; rhs</del><ins>rhs &lt; lhs</ins></tt>.
66593 </blockquote>
66594 </li>
66595 <li>Change 28.9.2 [re.submatch.op]/29 as indicated:
66596 <blockquote><pre>template &lt;class BiIter&gt;
66597  bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66598    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66599 </pre>
66600 29 <em>Returns</em>: <tt><del>lhs.str() &gt;= rhs</del><ins>!(lhs &lt; rhs)</ins></tt>.
66601 </blockquote>
66602 </li>
66603 <li>Change 28.9.2 [re.submatch.op]/30 as indicated:
66604 <blockquote><pre>template &lt;class BiIter&gt;
66605  bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66606    typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
66607 </pre>
66608 30 <em>Returns</em>: <tt><del>lhs.str() &lt;= rhs</del><ins>!(rhs &lt; lhs)</ins></tt>.
66609 </blockquote>
66610 </li>
66611 <li>Change 28.9.2 [re.submatch.op]/31 as indicated:
66612 <blockquote><pre>template &lt;class BiIter&gt;
66613  bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66614    const sub_match&lt;BiIter&gt;&amp; rhs);
66615 </pre>
66616 <del>31 <em>Returns</em>: <tt>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) == rhs.str()</tt>.</del><br>
66617 <ins>31 <em>Returns</em>: <tt>rhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, lhs)) == 0</tt>.</ins>
66618 </blockquote>
66619 </li>
66620 <li>Change 28.9.2 [re.submatch.op]/32 as indicated:
66621 <blockquote><pre>template &lt;class BiIter&gt;
66622  bool operator!=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66623    const sub_match&lt;BiIter&gt;&amp; rhs);
66624 </pre>
66625 32 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) !=
66626 rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
66627 </blockquote>
66628 </li>
66629 <li>Change 28.9.2 [re.submatch.op]/33 as indicated:
66630 <blockquote><pre>template &lt;class BiIter&gt;
66631  bool operator&lt;(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66632    const sub_match&lt;BiIter&gt;&amp; rhs);
66633 </pre>
66634 <del>33 <em>Returns</em>: <tt>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &lt; rhs.str()</tt>.</del><br>
66635 <ins>33 <em>Returns</em>: <tt>rhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, lhs)) &gt; 0</tt>.</ins>
66636 </blockquote>
66637 </li>
66638 <li>Change 28.9.2 [re.submatch.op]/34 as indicated:
66639 <blockquote><pre>template &lt;class BiIter&gt;
66640  bool operator&gt;(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66641    const sub_match&lt;BiIter&gt;&amp; rhs);
66642 </pre>
66643 34 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
66644 </blockquote>
66645 </li>
66646 <li>Change 28.9.2 [re.submatch.op]/35 as indicated:
66647 <blockquote><pre>template &lt;class BiIter&gt;
66648  bool operator&gt;=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66649    const sub_match&lt;BiIter&gt;&amp; rhs);
66650 </pre>
66651 35 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
66652 </blockquote>
66653 </li>
66654 <li>Change 28.9.2 [re.submatch.op]/36 as indicated:
66655 <blockquote><pre>template &lt;class BiIter&gt;
66656  bool operator&lt;=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
66657    const sub_match&lt;BiIter&gt;&amp; rhs);
66658 </pre>
66659 36 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
66660 </blockquote>
66661 </li>
66662 <li>Change 28.9.2 [re.submatch.op]/37 as indicated:
66663 <blockquote><pre>template &lt;class BiIter&gt;
66664  bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
66665    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66666 </pre>
66667 <del>37 <em>Returns</em>: <tt>lhs.str() == basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</tt>.</del><br>
66668 <ins>37 <em>Returns</em>: <tt>lhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, rhs)) == 0</tt>.</ins>
66669 </blockquote>
66670 </li>
66671 <li>Change 28.9.2 [re.submatch.op]/38 as indicated:
66672 <blockquote><pre>template &lt;class BiIter&gt;
66673  bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
66674    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66675 </pre>
66676 38 <em>Returns</em>: <tt><del>lhs.str() != basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(lhs == rhs)</ins></tt>.
66677 </blockquote>
66678 </li>
66679 <li>Change 28.9.2 [re.submatch.op]/39 as indicated:
66680 <blockquote><pre>template &lt;class BiIter&gt;
66681  bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66682    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66683 </pre>
66684 <del>39 <em>Returns</em>: <tt>lhs.str() &lt; basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</tt>.</del><br>
66685 <ins>39 <em>Returns</em>: <tt>lhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, rhs)) &lt; 0</tt>.</ins>
66686 </blockquote>
66687 </li>
66688 <li>Change 28.9.2 [re.submatch.op]/40 as indicated:
66689 <blockquote><pre>template &lt;class BiIter&gt;
66690  bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
66691    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66692 </pre>
66693 40 <em>Returns</em>: <tt><del>lhs.str() &gt; basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>rhs &lt; lhs</ins></tt>.
66694 </blockquote>
66695 </li>
66696 <li>Change 28.9.2 [re.submatch.op]/41 as indicated:
66697 <blockquote><pre>template &lt;class BiIter&gt;
66698  bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66699    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66700 </pre>
66701 41 <em>Returns</em>: <tt><del>lhs.str() &gt;= basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(lhs &lt; rhs)</ins></tt>.
66702 </blockquote>
66703 </li>
66704 <li>Change 28.9.2 [re.submatch.op]/42 as indicated:
66705 <blockquote><pre>template &lt;class BiIter&gt;
66706  bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
66707    typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
66708 </pre>
66709 42 <em>Returns</em>: <tt><del>lhs.str() &lt;= basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(rhs &lt; lhs)</ins></tt>.
66710 </blockquote>
66711 </li>
66712 </ol>
66713
66714
66715
66716
66717
66718
66719 <hr>
66720 <h3><a name="1182"></a>1182. Unfortunate hash dependencies</h3>
66721 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
66722  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-28 <b>Last modified:</b> 2010-10-23</p>
66723 <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>
66724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
66725 <p><b>Discussion:</b></p>
66726 <p><b>Addresses UK 324</b></p>
66727
66728 <p>
66729 The implied library dependencies created by spelling out all the <tt>hash</tt>
66730 template specializations in the <tt>&lt;functional&gt;</tt> synopsis are unfortunate. 
66731 The potential coupling is greatly reduced if the <tt>hash</tt> specialization is
66732 declared in the appropriate header for each library type, as it is much
66733 simpler to forward declare the primary template and provide a single
66734 specialization than it is to implement a <tt>hash</tt> function for a <tt>string</tt> or
66735 <tt>vector</tt> without providing a definition for the whole <tt>string/vector</tt>
66736 template in order to access the necessary bits.
66737 </p>
66738
66739 <p>
66740 Note that the proposed resolution purely involves moving the
66741 declarations of a few specializations, it specifically does not make any
66742 changes to 20.8.15 [unord.hash].
66743 </p>
66744
66745 <p><i>[
66746 2009-09-15 Daniel adds:
66747 ]</i></p>
66748
66749
66750 <blockquote>
66751 </blockquote>
66752 <p>
66753 I suggest to add to the current existing
66754 proposed resolution the following items.
66755 </p>
66756
66757 <ul>
66758 <li>
66759 <p>
66760 Add to the very first strike-list of the currently suggested resolution
66761 the following lines:
66762 </p>
66763
66764 <blockquote><pre><del>template &lt;&gt; struct hash&lt;std::error_code&gt;;</del>
66765 <del>template &lt;&gt; struct hash&lt;std::thread::id&gt;;</del>
66766 </pre></blockquote>
66767 </li>
66768
66769 <li>
66770 <p>
66771 Add the following declarations to 19.5 [syserr], header
66772 <tt>&lt;system_error&gt;</tt> synopsis after // 19.5.4:
66773 </p>
66774
66775 <blockquote><pre><ins>
66776 // 19.5.x hash support
66777 template &lt;class T&gt; struct hash;
66778 template &lt;&gt; struct hash&lt;error_code&gt;;
66779 </ins>
66780 </pre></blockquote>
66781 </li>
66782
66783 <li>
66784 <p>
66785 Add a new clause 19.5.X (probably after 19.5.4):
66786 </p>
66787
66788 <blockquote>
66789 <p><ins>
66790 19.5.X Hash support [syserr.hash]
66791 </ins></p>
66792
66793 <pre><ins>
66794 template &lt;&gt; struct hash&lt;error_code&gt;;
66795 </ins></pre>
66796
66797 <blockquote><ins>
66798 An explicit specialization of the class template hash (20.8.15 [unord.hash])
66799 shall be provided
66800 for the type <tt>error_code</tt> suitable for using this type as key in
66801 unordered associative
66802 containers (23.7 [unord]).
66803 </ins></blockquote>
66804 </blockquote>
66805 </li>
66806
66807 <li>
66808 <p>
66809 Add the following declarations to 30.3.1.1 [thread.thread.id] just after the
66810 declaration of
66811 the comparison operators:
66812 </p>
66813
66814 <blockquote><pre><ins>
66815 template &lt;class T&gt; struct hash;
66816 template &lt;&gt; struct hash&lt;thread::id&gt;;
66817 </ins></pre></blockquote>
66818 </li>
66819
66820 <li>
66821 <p>
66822 Add a new paragraph at the end of 30.3.1.1 [thread.thread.id]:
66823 </p>
66824
66825 <blockquote>
66826 <pre><ins>
66827 template &lt;&gt; struct hash&lt;thread::id&gt;;
66828 </ins></pre>
66829
66830 <blockquote><ins>
66831 An explicit specialization of the class template hash (20.8.15 [unord.hash])
66832 shall be provided
66833 for the type <tt>thread::id</tt> suitable for using this type as key in
66834 unordered associative
66835 containers (23.7 [unord]).
66836 </ins></blockquote>
66837 </blockquote>
66838 </li>
66839
66840 <li>
66841 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a> independently suggests moving the specialization
66842 <tt>std::hash&lt;std::thread::id&gt;</tt> to header <tt>&lt;thread&gt;</tt>.
66843 </li>
66844 </ul>
66845
66846 <p><i>[
66847 2009-11-13 Alisdair adopts Daniel's suggestion and the extended note from
66848 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>.
66849 ]</i></p>
66850
66851
66852 <p><i>[
66853 2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>.
66854 ]</i></p>
66855
66856
66857 <p><i>[
66858 2010-02-07 Proposed wording updated by Beman, Daniel, Alisdair and Ganesh.
66859 ]</i></p>
66860
66861
66862 <p><i>[
66863 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
66864 ]</i></p>
66865
66866
66867
66868
66869 <p><b>Proposed resolution:</b></p>
66870 <p><i>Strike the following specializations declared in the <tt>&lt;functional&gt;</tt> 
66871 synopsis p2 20.8 [function.objects] </i> </p>
66872 <blockquote>
66873   <pre><del>template &lt;&gt; struct hash&lt;std::string&gt;;</del>
66874 <del>template &lt;&gt; struct hash&lt;std::u16string&gt;;</del>
66875 <del>template &lt;&gt; struct hash&lt;std::u32string&gt;;</del>
66876 <del>template &lt;&gt; struct hash&lt;std::wstring&gt;;</del>
66877
66878 <del>template &lt;&gt; struct hash&lt;std::error_code&gt;;</del>
66879 <del>template &lt;&gt; struct hash&lt;std::thread::id&gt;;</del>
66880 <del>template &lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool, Allocator&gt; &gt;;</del>
66881 <del>template &lt;std::size_t N&gt; struct hash&lt;std::bitset&lt;N&gt; &gt;;</del></pre>
66882 </blockquote>
66883 <p><i>Add the following at the end of 20.8.15 [unord.hash]:</i></p>
66884 <blockquote>
66885   <pre><ins>template &lt;&gt; struct hash&lt;bool&gt;;
66886 template &lt;&gt; struct hash&lt;char&gt;;
66887 template &lt;&gt; struct hash&lt;signed char&gt;;
66888 template &lt;&gt; struct hash&lt;unsigned char&gt;;
66889 template &lt;&gt; struct hash&lt;char16_t&gt;;
66890 template &lt;&gt; struct hash&lt;char32_t&gt;;
66891 template &lt;&gt; struct hash&lt;wchar_t&gt;;
66892 template &lt;&gt; struct hash&lt;short&gt;;
66893 template &lt;&gt; struct hash&lt;unsigned short&gt;;
66894 template &lt;&gt; struct hash&lt;int&gt;;
66895 template &lt;&gt; struct hash&lt;unsigned int&gt;;
66896 template &lt;&gt; struct hash&lt;long&gt;;
66897 template &lt;&gt; struct hash&lt;long long&gt;;
66898 template &lt;&gt; struct hash&lt;unsigned long&gt;;
66899 template &lt;&gt; struct hash&lt;unsigned long long&gt;;
66900 template &lt;&gt; struct hash&lt;float&gt;;
66901 template &lt;&gt; struct hash&lt;double&gt;;
66902 template &lt;&gt; struct hash&lt;long double&gt;;
66903 template&lt;class T&gt; struct hash&lt;T*&gt;;</ins></pre>
66904   <p><ins>
66905   Specializations meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66906 </blockquote>
66907 <p><i>Add the following declarations to 19.5 [syserr], header <tt>&lt;system_error&gt;</tt> 
66908 synopsis after // 19.5.4: </i> </p>
66909 <blockquote>
66910   <pre><ins>// [syserr.hash] hash support
66911 template &lt;class T&gt; struct hash;
66912 template &lt;&gt; struct hash&lt;error_code&gt;;</ins></pre>
66913 </blockquote>
66914 <p><i>Add a new clause 19.5.X (probably after 19.5.4): </i> </p>
66915 <blockquote>
66916   <p><ins>19.5.X Hash support [syserr.hash] </ins></p>
66917   <pre><ins>template &lt;&gt; struct hash&lt;error_code&gt;;</ins></pre>
66918     <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66919 </blockquote>
66920 <p><i>Add the following declarations to the synopsis of <tt>&lt;string&gt;</tt> in 21.3 [string.classes]
66921 </i>
66922 </p>
66923 <blockquote>
66924   <pre><ins>// [basic.string.hash] hash support
66925 template &lt;class T&gt; struct hash;
66926 template &lt;&gt; struct hash&lt;string&gt;;
66927 template &lt;&gt; struct hash&lt;u16string&gt;;
66928 template &lt;&gt; struct hash&lt;u32string&gt;;
66929 template &lt;&gt; struct hash&lt;wstring&gt;;</ins></pre>
66930 </blockquote>
66931 <p><i>Add a new clause 21.4.X </i> </p>
66932 <blockquote>
66933   <p><ins>21.4.X Hash support [basic.string.hash]&gt;</ins></p>
66934   <pre><ins>template &lt;&gt; struct hash&lt;string&gt;;
66935 template &lt;&gt; struct hash&lt;u16string&gt;;
66936 template &lt;&gt; struct hash&lt;u32string&gt;;
66937 template &lt;&gt; struct hash&lt;wstring&gt;;</ins></pre>
66938     <p><ins>Specializations meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66939 </blockquote>
66940 <p><i>Add the following declarations to the synopsis of <tt>&lt;vector&gt;</tt> in
66941 23.3 [sequences]</i> </p>
66942 <blockquote>
66943   <pre><ins>// 21.4.x hash support
66944 template &lt;class T&gt; struct hash;
66945 template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;</ins></pre>
66946 </blockquote>
66947 <p><i>Add a new paragraph to the end of 23.4.2 [vector.bool] </i> </p>
66948 <blockquote>
66949   <pre><ins>template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;</ins></pre>
66950     <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66951 </blockquote>
66952 <p><i>Add the following declarations to the synopsis of <tt>&lt;bitset&gt;</tt> in 20.5 [template.bitset] </i> </p>
66953 <blockquote>
66954   <pre><ins>// [bitset.hash] hash support
66955 template &lt;class T&gt; struct hash;
66956 template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;</ins></pre>
66957 </blockquote>
66958 <p><i>Add a new subclause 20.3.7.X [bitset.hash] </i> </p>
66959 <blockquote>
66960   <p><ins>20.3.7.X bitset hash support [bitset.hash]</ins></p>
66961   <pre><ins>template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;</ins></pre>
66962     <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66963 </blockquote>
66964 <p><i>Add the following declarations to 30.3.1.1 [thread.thread.id] synopsis just after the 
66965 declaration of the comparison operators: </i> </p>
66966 <blockquote>
66967   <pre><ins>template &lt;class T&gt; struct hash;
66968 template &lt;&gt; struct hash&lt;thread::id&gt;;</ins></pre>
66969 </blockquote>
66970 <p><i>Add a new paragraph at the end of 30.3.1.1 [thread.thread.id]: </i> </p>
66971 <blockquote>
66972   <pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins></pre>
66973   <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
66974 </blockquote>
66975
66976 <p><i>Change Header &lt;typeindex&gt; synopsis 20.13.1 [type.index.synopsis] as 
66977 indicated:</i></p>
66978 <blockquote>
66979 <pre>namespace std {
66980 class type_index;
66981   <ins>// [type.index.hash] hash support</ins>
66982   template &lt;class T&gt; struct hash;
66983   template&lt;&gt; struct hash&lt;type_index&gt;<ins>;</ins> <del> : public unary_function&lt;type_index, size_t&gt; {
66984     size_t operator()(type_index index) const;
66985   }</del>
66986 }</pre>
66987 </blockquote>
66988
66989 <p><i>Change Template specialization hash&lt;type_index&gt;  [type.index.templ]
66990   as indicated:</i></p>
66991
66992 <blockquote>
66993
66994   <p>20.11.4 <del>Template specialization hash&lt;type_index&gt; [type.index.templ]</del>
66995   <ins>Hash support [type.index.hash]</ins></p>
66996
66997   <pre><del>size_t operator()(type_index index) const;</del></pre>
66998   <blockquote>
66999     <p><del><i>Returns:</i> <tt>index.hash_code()</tt></del></p>
67000   </blockquote>
67001   
67002   <pre><ins>template&lt;&gt; struct hash&lt;type_index&gt;;</ins></pre>
67003   <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> [unord.hash]. 
67004   For an object <tt>index</tt> of type <tt>type_index</tt>, <tt>hash&lt;type_index&gt;()(index)</tt> 
67005   shall evaluate to the same value as <tt>index.hash_code()</tt>.</ins></p>
67006   
67007 </blockquote>
67008
67009
67010
67011
67012
67013
67014 <hr>
67015 <h3><a name="1183"></a>1183. <tt>basic_ios::set_rdbuf</tt> may break class invariants</h3>
67016 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67017  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-28 <b>Last modified:</b> 2010-11-24</p>
67018 <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>
67019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67020 <p><b>Discussion:</b></p>
67021 <p>
67022 The protected member function <tt>set_rdbuf</tt> had been added during the
67023 process of adding move and swap semantics to IO classes. A relevant
67024 property of this function is described by it's effects in
67025 27.5.4.2 [basic.ios.members]/19:
67026 </p>
67027
67028 <blockquote>
67029 <i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by sb with
67030 this stream without calling <tt>clear()</tt>.
67031 </blockquote>
67032
67033 <p>
67034 This means that implementors of or those who derive from existing IO classes
67035 could cause an internal state where the stream buffer could be 0, but the
67036 IO class has the state <tt>good()</tt>. This would break several currently existing
67037 implementations which rely on the fact that setting a stream buffer via the
67038 currently only ways, i.e. either by calling
67039 </p>
67040
67041 <blockquote><pre>void init(basic_streambuf&lt;charT,traits&gt;* sb);
67042 </pre></blockquote>
67043
67044 <p>
67045 or by calling
67046 </p>
67047
67048 <blockquote><pre>basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
67049 </pre></blockquote>
67050
67051 <p>
67052 to set <tt>rdstate()</tt> to <tt>badbit</tt>, if the buffer is 0. This has the effect that many
67053 internal functions can simply check <tt>rdstate()</tt> instead of <tt>rdbuf()</tt> for being 0.
67054 </p>
67055
67056 <p>
67057 I therefore suggest that a requirement is added for callers of <tt>set_rdbuf</tt> to
67058 set a non-0 value.
67059 </p>
67060
67061 <p><i>[
67062 2009-10 Santa Cruz:
67063 ]</i></p>
67064
67065
67066 <blockquote>
67067 Moved to Open.  Martin volunteers to provide new wording, where
67068 <tt>set_rdbuf()</tt> sets the <tt>badbit</tt> but does not cause an
67069 exception to be thrown like a call to <tt>clear()</tt> would.
67070 </blockquote>
67071
67072 <p><i>[
67073 2009-10-20 Martin provides wording:
67074 ]</i></p>
67075
67076
67077 <p>
67078 Change 27.5.4.2 [basic.ios.members] around p. 19 as indicated:
67079 </p>
67080
67081 <blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
67082 </pre>
67083
67084 <blockquote>
67085 <p><del>
67086 <i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed
67087 to by <tt>sb</tt> with this stream without calling <tt>clear()</tt>.
67088 <i>Postconditions:</i> <tt>rdbuf() == sb</tt>.
67089 </del></p>
67090
67091 <p><ins>
67092 <i>Effects:</i> As if:
67093 </ins></p>
67094
67095 <blockquote><pre><ins>
67096 iostate state = rdstate();
67097 try { rdbuf(sb); }
67098 catch(ios_base::failure) {
67099    if (0 == (state &amp; ios_base::badbit))
67100        unsetf(badbit);
67101 }
67102 </ins></pre></blockquote>
67103
67104 <p>
67105 <i>Throws:</i> Nothing.
67106 </p>
67107
67108 </blockquote>
67109 </blockquote>
67110
67111 <p><b>Rationale:</b></p>
67112 We need to be able to call <tt>set_rdbuf()</tt> on stream objects
67113 for which (<tt>rdbuf() == 0</tt>) holds without causing <tt>ios_base::failure</tt> to
67114 be thrown. We also don't want <tt>badbit</tt> to be set as a result of
67115 setting <tt>rdbuf()</tt> to 0 if it wasn't set before the call. This changed
67116 Effects clause maintains the current behavior (as of N2914) without
67117 requiring that <tt>sb</tt> be non-null.
67118
67119
67120 <p><i>[
67121 Post-Rapperswil
67122 ]</i></p>
67123
67124
67125 <p>
67126 Several reviewers and the submitter believe that the best solution would be to add a pre-condition that the 
67127 buffer shall not be a null pointer value.
67128 </p>
67129
67130 <blockquote>
67131 Moved to Tentatively Ready with revised wording provided by Daniel after 5 positive votes on c++std-lib.
67132 </blockquote>
67133
67134 <p><i>[
67135 Adopted at 2010-11 Batavia
67136 ]</i></p>
67137
67138
67139
67140
67141 <p><b>Proposed resolution:</b></p>
67142 <ol>
67143 <li>Add a new pre-condition just before 27.5.4.2 [basic.ios.members]/23 as indicated:
67144 <blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
67145 </pre>
67146 <blockquote>
67147 <ins>?? <em>Requires</em>: <tt>sb != nullptr</tt>.</ins>
67148 <p>
67149 23 <em>Effects</em>: Associates the <tt>basic_streambuf</tt> object pointed to by <tt>sb</tt> with this stream without calling <tt>clear()</tt>.
67150 </p>
67151 <p>
67152 24 <em>Postconditions</em>: <tt>rdbuf() == sb</tt>.
67153 </p>
67154 <p>
67155 25 <em>Throws</em>: Nothing.
67156 </p>
67157 </blockquote></blockquote>
67158 </li>
67159 </ol>
67160
67161
67162 <p><b>Rationale:</b></p>
67163 We believe that setting a <tt>nullptr</tt> stream buffer can be prevented.
67164
67165
67166
67167
67168
67169 <hr>
67170 <h3><a name="1187"></a>1187. std::decay</h3>
67171 <p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67172  <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-08-07 <b>Last modified:</b> 2010-10-23</p>
67173 <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>
67174 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67175 <p><b>Discussion:</b></p>
67176 <p>
67177 I notice that <tt>std::decay</tt> is specified to strip the cv-quals from
67178 anything but an array or pointer.  This seems incorrect for values of
67179 class type, since class rvalues can have cv-qualified type (3.10 [basic.lval]/9).
67180 </p>
67181
67182 <p><i>[
67183 2009-08-09 Howard adds:
67184 ]</i></p>
67185
67186
67187 <blockquote>
67188 See the thread starting with c++std-lib-24568 for further discussion.  And
67189 here is a convenience link to the
67190 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2069.html">original proposal</a>.
67191 Also see the closely related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>.
67192 </blockquote>
67193
67194 <p><i>[
67195 2010 Pittsburgh:  Moved to Ready.
67196 ]</i></p>
67197
67198
67199
67200
67201 <p><b>Proposed resolution:</b></p>
67202
67203 <p>
67204 Add a note to <tt>decay</tt> in 20.7.7.6 [meta.trans.other]:
67205 </p>
67206
67207 <blockquote>
67208 [<i>Note:</i> This behavior is similar to the lvalue-to-rvalue (4.1),
67209 array-to-pointer (4.2), and function-to-pointer (4.3) conversions
67210 applied when an lvalue expression is used as an rvalue, but also strips
67211 cv-qualifiers from class types in order to more closely model by-value
67212 argument passing. \97 <i>end note</i>]
67213 </blockquote>
67214
67215
67216
67217
67218
67219
67220
67221
67222 <hr>
67223 <h3><a name="1189"></a>1189. Awkward interface for changing the number of buckets in an unordered associative container</h3>
67224 <p><b>Section:</b> 23.2.5 [unord.req], 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67225  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10 <b>Last modified:</b> 2010-10-23</p>
67226 <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>
67227 <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>
67228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67229 <p><b>Discussion:</b></p>
67230 <p>
67231 Consider a typical use case: I create an <tt>unordered_map</tt> and then start
67232 adding elements to it one at a time. I know that it will eventually need
67233 to store a few million elements, so, for performance reasons, I would
67234 like to reserve enough capacity that none of the calls to <tt>insert</tt> will
67235 trigger a rehash.
67236 </p>
67237
67238 <p>
67239 Unfortunately, the existing interface makes this awkward. The user
67240 naturally sees the problem in terms of the number of elements, but the
67241 interface presents it as buckets. If <tt>m</tt> is the map and <tt>n</tt> is the expected
67242 number of elements, this operation is written <tt>m.rehash(n /
67243 m.max_load_factor())</tt> \97 not very novice friendly.
67244 </p>
67245
67246 <p><i>[
67247 2009-09-30 Daniel adds:
67248 ]</i></p>
67249
67250
67251 <blockquote>
67252 I recommend to replace "<tt>resize</tt>" by a different name like
67253 "<tt>reserve</tt>", because that would better match the intended
67254 use-case. Rational: Any existing resize function has the on-success
67255 post-condition that the provided size is equal to <tt>size()</tt>, which
67256 is not satisfied for the proposal. Reserve seems to fit the purpose of
67257 the actual renaming suggestion.
67258 </blockquote>
67259
67260 <p><i>[
67261 2009-10-28 Ganesh summarizes alternative resolutions and expresses a
67262 strong preference for the second (and opposition to the first):
67263 ]</i></p>
67264
67265
67266 <blockquote>
67267 <ol>
67268 <li>
67269 <p>
67270 In the unordered associative container requirements (23.2.5 [unord.req]),
67271 remove the row for
67272 rehash and replace it with:
67273 </p>
67274
67275 <blockquote>
67276 <table border="1">
67277 <caption>Table 87 \97 Unordered associative container requirements
67278 (in addition to container)</caption>
67279
67280 <tbody><tr>
67281 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
67282 <th>Complexity</th>
67283 </tr>
67284 <tr>
67285 <td><tt>a.<del>rehash</del><ins>reserve</ins>(n)</tt></td>
67286 <td><tt>void</tt></td>
67287 <td>
67288 Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
67289 / a.max_load_factor()</tt><del> and <tt>a.bucket_count()
67290 &gt;= n</tt></del>.
67291 </td>
67292 <td>
67293 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67294 </td>
67295 </tr>
67296 </tbody></table>
67297 </blockquote>
67298
67299 <p>
67300 Make the corresponding change in the class synopses in 23.7.1 [unord.map], 23.7.2 [unord.multimap],  23.7.3 [unord.set], and 23.7.4 [unord.multiset].
67301 </p>
67302 </li>
67303 <li>
67304
67305 <p>
67306 In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
67307 </p>
67308
67309 <blockquote>
67310 <table border="1">
67311 <caption>Table 87 \97 Unordered associative container requirements
67312 (in addition to container)</caption>
67313
67314 <tbody><tr>
67315 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
67316 <th>Complexity</th>
67317 </tr>
67318 <tr>
67319 <td><tt>a.rehash(n)</tt></td>
67320 <td><tt>void</tt></td>
67321 <td>
67322 Post: <tt>a.bucket_count &gt; a.size()
67323 / a.max_load_factor()</tt> and <tt>a.bucket_count()
67324 &gt;= n</tt>.
67325 </td>
67326 <td>
67327 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67328 </td>
67329 </tr>
67330 <tr>
67331 <td><ins>
67332 <tt>a.reserve(n)</tt>
67333 </ins></td>
67334 <td><ins>
67335 <tt>void</tt>
67336 </ins></td>
67337 <td><ins>
67338 Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
67339 </ins></td>
67340 <td><ins>
67341 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67342 </ins></td>
67343 </tr>
67344 </tbody></table>
67345 </blockquote>
67346
67347 <p>
67348 In 23.7.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
67349 23.7.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
67350 23.7.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
67351 23.7.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
67352 following line after member function <tt>rehash()</tt>:
67353 </p>
67354
67355 <blockquote><pre>void reserve(size_type n);
67356 </pre></blockquote>
67357
67358 </li>
67359 </ol>
67360 </blockquote>
67361
67362 <p><i>[
67363 2009-10-28 Howard:
67364 ]</i></p>
67365
67366
67367 <blockquote>
67368 <p>
67369 Moved to Tentatively Ready after 5 votes in favor of Ganesh's option 2 above.
67370 The original proposed wording now appears here:
67371 </p>
67372
67373 <blockquote>
67374 <p>
67375 Informally: instead of providing <tt>rehash(n)</tt> provide <tt>resize(n)</tt>, with the
67376 semantics "make the container a good size for <tt>n</tt> elements".
67377 </p>
67378
67379 <p>
67380 In the unordered associative container requirements (23.2.5 [unord.req]),
67381 remove the row for
67382 rehash and replace it with:
67383 </p>
67384
67385 <blockquote>
67386 <table border="1">
67387 <caption>Table 87 \97 Unordered associative container requirements
67388 (in addition to container)</caption>
67389
67390 <tbody><tr>
67391 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
67392 <th>Complexity</th>
67393 </tr>
67394 <tr>
67395 <td><tt>a.<del>rehash</del><ins>resize</ins>(n)</tt></td>
67396 <td><tt>void</tt></td>
67397 <td>
67398 Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
67399 / a.max_load_factor()</tt><del> and <tt>a.bucket_count()
67400 &gt;= n</tt></del>.
67401 </td>
67402 <td>
67403 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67404 </td>
67405 </tr>
67406 </tbody></table>
67407 </blockquote>
67408
67409 <p>
67410 Make the corresponding change in the class synopses in 23.7.1 [unord.map], 23.7.2 [unord.multimap],  23.7.3 [unord.set], and 23.7.4 [unord.multiset].
67411 </p>
67412
67413 </blockquote>
67414 </blockquote>
67415
67416
67417 <p><b>Proposed resolution:</b></p>
67418 <p>
67419 In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
67420 </p>
67421
67422 <blockquote>
67423 <table border="1">
67424 <caption>Table 87 \97 Unordered associative container requirements
67425 (in addition to container)</caption>
67426
67427 <tbody><tr>
67428 <th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
67429 <th>Complexity</th>
67430 </tr>
67431 <tr>
67432 <td><tt>a.rehash(n)</tt></td>
67433 <td><tt>void</tt></td>
67434 <td>
67435 Post: <tt>a.bucket_count &gt; a.size()
67436 / a.max_load_factor()</tt> and <tt>a.bucket_count()
67437 &gt;= n</tt>.
67438 </td>
67439 <td>
67440 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67441 </td>
67442 </tr>
67443 <tr>
67444 <td><ins>
67445 <tt>a.reserve(n)</tt>
67446 </ins></td>
67447 <td><ins>
67448 <tt>void</tt>
67449 </ins></td>
67450 <td><ins>
67451 Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
67452 </ins></td>
67453 <td><ins>
67454 Average case linear in <tt>a.size()</tt>, worst case quadratic.
67455 </ins></td>
67456 </tr>
67457 </tbody></table>
67458 </blockquote>
67459
67460 <p>
67461 In 23.7.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
67462 23.7.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
67463 23.7.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
67464 23.7.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
67465 following line after member function <tt>rehash()</tt>:
67466 </p>
67467
67468 <blockquote><pre>void reserve(size_type n);
67469 </pre></blockquote>
67470
67471
67472
67473
67474
67475 <hr>
67476 <h3><a name="1191"></a>1191. <tt>tuple get</tt> API should respect rvalues</h3>
67477 <p><b>Section:</b> 20.4.2.6 [tuple.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67478  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-11-23</p>
67479 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67480 <p><b>Discussion:</b></p>
67481 <p>
67482 The <tt>tuple get</tt> API should respect rvalues.  This would allow for moving a
67483 single element out of a <tt>tuple</tt>-like type.
67484 </p>
67485
67486 <p><i>[
67487 2009-10-30 Alisdair adds:
67488 ]</i></p>
67489
67490
67491 <blockquote>
67492 <p>
67493 The issue of rvalue overloads of get for tuple-like types was briefly
67494 discussed in Santa Cruz.
67495 </p>
67496
67497 <p>
67498 The feedback was this would be welcome, but we need full wording for the
67499 other types (<tt>pair</tt> and <tt>array</tt>) before advancing.
67500 </p>
67501
67502 <p>
67503 I suggest the issue moves to Open from New as it has been considered,
67504 feedback given, and it has not (yet) been rejected as NAD.
67505 </p>
67506 </blockquote>
67507
67508
67509 <p><i>[
67510 2010 Rapperswil:
67511 ]</i></p>
67512
67513
67514 <blockquote>
67515 Note that wording has been provided, and this issue becomes more important now that we have added a function to support forwarding argument lists as <tt>tuple</tt>s.
67516
67517 Move to Tentatively Ready.
67518 </blockquote>
67519
67520 <p><i>[
67521 Adopted at 2010-11 Batavia
67522 ]</i></p>
67523
67524
67525
67526
67527 <p><b>Proposed resolution:</b></p>
67528 <p>
67529 Add the following signature to p2 20.4.1 [tuple.general]
67530 </p>
67531
67532 <blockquote><pre><ins>
67533 template &lt;size_t I, class ... Types&gt;
67534 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt; &amp;&amp;);
67535 </ins></pre></blockquote>
67536
67537 <p>
67538 And again to 20.4.2.6 [tuple.elem].
67539 </p>
67540
67541 <blockquote><pre><ins>
67542 template &lt;size_t I, class ... Types&gt;
67543 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t);
67544 </ins></pre>
67545
67546 <blockquote>
67547 <p><ins>
67548 <i>Effects:</i> Equivalent to <tt>return std::forward&lt;typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp;&gt;(get&lt;I&gt;(t));</tt>
67549 </ins></p>
67550
67551
67552 <p><ins>
67553 [<i>Note:</i> If a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>,
67554 the return type is <tt>X&amp;</tt>, not <tt>X&amp;&amp;</tt>.
67555 However, if the element type is non-reference type <tt>T</tt>,
67556 the return type is <tt>T&amp;&amp;</tt>. \97 <i>end note</i>]
67557 </ins></p>
67558
67559 </blockquote>
67560 </blockquote>
67561
67562 <p>
67563 Add the following signature to p1 20.3 [utility]
67564 </p>
67565
67566 <blockquote><pre><ins>
67567 template &lt;size_t I, class T1, class T2&gt;
67568 typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp;);
67569 </ins></pre></blockquote>
67570
67571 <p>
67572 And to p5 20.3.5.4 [pair.astuple]
67573 </p>
67574
67575 <blockquote><pre><ins>
67576 template &lt;size_t I, class T1, class T2&gt;
67577 typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp; p);
67578 </ins></pre>
67579
67580 <blockquote>
67581 <p><ins>
67582 <i>Returns:</i> If <tt>I == 0</tt> returns <tt>std::forward&lt;T1&amp;&amp;&gt;(p.first)</tt>;
67583 if <tt>I == 1</tt>
67584 returns <tt>std::forward&lt;T2&amp;&amp;&gt;(p.second)</tt>; otherwise the program is ill-formed.
67585 </ins></p>
67586
67587 <p><ins>
67588 <i>Throws:</i> Nothing.
67589 </ins></p>
67590
67591 </blockquote>
67592
67593 </blockquote>
67594
67595 <p>
67596 Add the following signature to 23.3 [sequences] <tt>&lt;array&gt;</tt> synopsis
67597 </p>
67598
67599 <blockquote><pre><ins>template &lt;size_t I, class T, size_t N&gt;
67600 T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp;);
67601 </ins></pre></blockquote>
67602
67603 <p>
67604 And after p8 23.3.1.8 [array.tuple]
67605 </p>
67606
67607 <blockquote><pre><ins>template &lt;size_t I, class T, size_t N&gt;
67608 T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp; a);
67609 </ins></pre>
67610
67611 <blockquote><ins>
67612 <i>Effects:</i> Equivalent to <tt>return std::move(get&lt;I&gt;(a));</tt>
67613 </ins></blockquote>
67614 </blockquote>
67615
67616
67617
67618
67619
67620
67621 <hr>
67622 <h3><a name="1192"></a>1192. <tt>basic_string</tt> missing definitions for <tt>cbegin</tt> / <tt>cend</tt> / <tt>crbegin</tt> / <tt>crend</tt></h3>
67623 <p><b>Section:</b> 21.4.3 [string.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67624  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-08-14 <b>Last modified:</b> 2010-10-23</p>
67625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67626 <p><b>Discussion:</b></p>
67627 <p>
67628 Unlike the containers in clause 23, <tt>basic_string</tt> has definitions for
67629 <tt>begin()</tt> and <tt>end()</tt>, but these have not been updated to include <tt>cbegin</tt>,
67630 <tt>cend</tt>, <tt>crbegin</tt> and <tt>crend</tt>.
67631 </p>
67632
67633 <p><i>[
67634 2009-10-28 Howard:
67635 ]</i></p>
67636
67637
67638 <blockquote>
67639 Moved to Tentatively NAD after 5 positive votes on c++std-lib.  Added
67640 rationale.
67641 </blockquote>
67642
67643 <p><i>[
67644 2009-10-28 Alisdair disagrees:
67645 ]</i></p>
67646
67647
67648 <blockquote>
67649 <p>
67650 I'm going to have to speak up as the dissenting voice.
67651 </p>
67652
67653 <p>
67654 I agree the issue could be handled editorially, and that would be my
67655 preference if Pete feels this is appropriate. Failing that, I really
67656 think this issue should be accepted and moved to ready.  The other
67657 begin/end functions all have a semantic definition for this template,
67658 and it is confusing if a small few are missing.
67659 </p>
67660
67661 <p>
67662 I agree that an alternative would be to strike <em>all</em> the definitions for
67663 <tt>begin/end/rbegin/rend</tt> and defer completely to the requirements tables in
67664 clause 23.  I think that might be confusing without a forward reference
67665 though, as those tables are defined in a *later* clause than the
67666 basic_string template itself.  If someone wants to pursue this I would
67667 support it, but recommend it as a separate issue.
67668 </p>
67669
67670 <p>
67671 So my preference is strongly to move Ready over NAD, and a stronger
67672 preference for NAD Editorial if Pete is happy to make these changes.
67673 </p>
67674
67675 </blockquote>
67676
67677 <p><i>[
67678 2009-10-29 Howard:
67679 ]</i></p>
67680
67681
67682 <blockquote>
67683 Moved to Tentatively Ready after 5 positive votes on c++std-lib.  Removed
67684 rationale to mark it NAD.  :-)
67685 </blockquote>
67686
67687
67688
67689 <p><b>Proposed resolution:</b></p>
67690 <p>
67691 Add to 21.4.3 [string.iterators]
67692 </p>
67693
67694 <blockquote><pre>iterator       begin();
67695 const_iterator begin() const;
67696 <ins>const_iterator cbegin() const;</ins>
67697 </pre>
67698
67699 <p>...</p>
67700
67701 <pre>iterator       end();
67702 const_iterator end() const;
67703 <ins>const_iterator cend() const;</ins>
67704 </pre>
67705
67706 <p>...</p>
67707
67708 <pre>reverse_iterator       rbegin();
67709 const_reverse_iterator rbegin() const;
67710 <ins>const_reverse_iterator crbegin() const;</ins>
67711 </pre>
67712
67713 <p>...</p>
67714
67715 <pre>reverse_iterator       rend();
67716 const_reverse_iterator rend() const;
67717 <ins>const_reverse_iterator crend() const;</ins>
67718 </pre>
67719
67720 </blockquote>
67721
67722
67723
67724
67725
67726 <hr>
67727 <h3><a name="1193"></a>1193. <tt>default_delete</tt> cannot be instantiated with  incomplete types</h3>
67728 <p><b>Section:</b> 20.9.9.1 [unique.ptr.dltr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67729  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-10-23</p>
67730 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67731 <p><b>Discussion:</b></p>
67732 <p>
67733 According to the general rules of 17.6.3.8 [res.on.functions]/2 b 5 the effects
67734 are undefined, if an incomplete type is used to instantiate a library template. But neither in
67735 20.9.9.1 [unique.ptr.dltr] nor
67736 in any other place of the standard such explicit allowance is given.
67737 Since this template is intended to be instantiated with incomplete
67738 types, this must
67739 be fixed.
67740 </p>
67741
67742 <p><i>[
67743 2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
67744 ]</i></p>
67745
67746
67747 <p><i>[
67748 2009-11-17 Alisdair Opens:
67749 ]</i></p>
67750
67751
67752 <blockquote>
67753 <p>
67754 LWG 1193 tries to support unique_ptr for incomplete types.  I believe the
67755 proposed wording goes too far:
67756 </p>
67757
67758 <blockquote>
67759 The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an
67760 incomplete type.
67761 </blockquote>
67762
67763 <p>
67764 Do we really want to support <tt>cv-void</tt>?  Suggested ammendment:
67765 </p>
67766
67767 <blockquote>
67768 The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an
67769 incomplete type <ins>other than <tt>cv-void</tt></ins>.
67770 </blockquote>
67771
67772 <p>
67773 We might also consider saying something about arrays of incomplete types.
67774 </p>
67775
67776 <p>
67777 Did we lose support for <tt>unique_ptr&lt;function-type&gt;</tt> when the
67778 concept-enabled work was shelved?  If so, we might want a
67779 <tt>default_delete</tt> partial specialization for function types that does
67780 nothing.  Alternatively, function types should <em>not</em> be supported by
67781 default, but there is no reason a user cannot support them via their own
67782 deletion policy.
67783 </p>
67784
67785 <p>
67786 Function-type support might also lead to conditionally supporting a
67787 function-call operator in the general case, and that seems way too inventive at
67788 this stage to me, even if we could largely steal wording directly from
67789 <tt>reference_wrapper</tt>.  <tt>shared_ptr</tt> would have similar problems
67790 too.
67791 </p>
67792
67793 </blockquote>
67794
67795 <p><i>[
67796 2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
67797 ]</i></p>
67798
67799
67800
67801
67802 <p><b>Proposed resolution:</b></p>
67803 <p>
67804 Add two new paragraphs directly to 20.9.9.1 [unique.ptr.dltr] (before
67805 20.9.9.1.2 [unique.ptr.dltr.dflt]) with the following
67806 content:
67807 </p>
67808
67809 <blockquote>
67810 <p><ins>
67811 The class template <tt>default_delete</tt> serves as the default deleter (destruction policy) for
67812 the class template <tt>unique_ptr</tt>.
67813 </ins></p>
67814
67815 <p><ins>
67816 The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an incomplete type.
67817 </ins></p>
67818 </blockquote>
67819
67820
67821
67822
67823
67824 <hr>
67825 <h3><a name="1194"></a>1194. Unintended <tt>queue</tt> constructor</h3>
67826 <p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
67827  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-20 <b>Last modified:</b> 2010-10-23</p>
67828 <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>
67829 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
67830 <p><b>Discussion:</b></p>
67831 <p>
67832 23.5.1.1 [queue.defn] has the following <tt>queue</tt> constructor:
67833 </p>
67834
67835 <blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
67836 </pre></blockquote>
67837
67838 <p>
67839 This will be implemented like so:
67840 </p>
67841
67842 <blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp; a) : c(a) {}
67843 </pre></blockquote>
67844
67845 <p>
67846 The issue is that <tt>Alloc</tt> can be anything that a container will construct
67847 from, for example an <tt>int</tt>.  Is this intended to compile?
67848 </p>
67849
67850 <blockquote><pre>queue&lt;int&gt; q(5);
67851 </pre></blockquote>
67852
67853 <p>
67854 Before the addition of this constructor, <tt>queue&lt;int&gt;(5)</tt> would not compile.
67855 I ask, not because this crashes, but because it is new and appears to be
67856 unintended.  We do not want to be in a position of accidently introducing this
67857 "feature" in C++0X and later attempting to remove it.
67858 </p>
67859
67860 <p>
67861 I've picked on <tt>queue</tt>.  <tt>priority_queue</tt> and <tt>stack</tt> have
67862 the same issue.  Is it useful to create a <tt>priority_queue</tt> of 5
67863 identical elements?
67864 </p>
67865
67866 <p><i>[
67867 Daniel, Howard and Pablo collaborated on the proposed wording.
67868 ]</i></p>
67869
67870
67871 <p><i>[
67872 2009-10 Santa Cruz:
67873 ]</i></p>
67874
67875
67876 <blockquote>
67877 Move to Ready.
67878 </blockquote>
67879
67880
67881
67882 <p><b>Proposed resolution:</b></p>
67883
67884 <p><i>[
67885 This resolution includes a semi-editorial clean up, giving definitions to members
67886 which in some cases weren't defined since C++98.
67887 This resolution also offers editorially different wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>,
67888 and it also provides wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.
67889 ]</i></p>
67890
67891
67892 <p>
67893 Change  container.adaptors, p1:
67894 </p>
67895
67896 <blockquote>
67897 The container adaptors each take a <tt>Container</tt> template parameter, and
67898 each constructor takes a <tt>Container</tt> reference argument. This container is
67899 copied into the <tt>Container</tt> member of each adaptor. If the container takes
67900 an allocator, then a compatible allocator may be passed in to the
67901 adaptor's constructor. Otherwise, normal copy or move construction is
67902 used for the container argument. <del>[<i>Note:</i> it is not necessary for an
67903 implementation to distinguish between the one-argument constructor that
67904 takes a <tt>Container</tt> and the one- argument constructor that takes an
67905 allocator_type. Both forms use their argument to construct an instance
67906 of the container. \97 <i>end note</i>]</del>
67907 </blockquote>
67908
67909 <p>
67910 Change  queue.defn, p1:
67911 </p>
67912
67913 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
67914 class queue {
67915 public:
67916   typedef typename Container::value_type      value_type;
67917   typedef typename Container::reference       reference;
67918   typedef typename Container::const_reference const_reference;
67919   typedef typename Container::size_type       size_type;
67920   typedef Container                           container_type;
67921 protected:
67922   Container c;
67923
67924 public:
67925   explicit queue(const Container&amp;);
67926   explicit queue(Container&amp;&amp; = Container());
67927   queue(queue&amp;&amp; q)<ins>;</ins><del> : c(std::move(q.c)) {}</del>
67928   template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
67929   template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
67930   template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
67931   template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
67932   queue&amp; operator=(queue&amp;&amp; q)<ins>;</ins><del> { c = std::move(q.c); return *this; }</del>
67933
67934   bool empty() const          { return c.empty(); }
67935   ...
67936 };
67937 </pre></blockquote>
67938
67939 <p>
67940 Add a new section after 23.5.1.1 [queue.defn], [queue.cons]:
67941 </p>
67942
67943 <blockquote>
67944 <p><b><tt>queue</tt> constructors [queue.cons]</b></p>
67945
67946 <pre>explicit queue(const Container&amp; cont);
67947 </pre>
67948
67949 <blockquote>
67950
67951 <p>
67952 <i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt>.
67953 </p>
67954
67955 </blockquote>
67956
67957 <pre>explicit queue(Container&amp;&amp; cont = Container());
67958 </pre>
67959
67960 <blockquote>
67961
67962 <p>
67963 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt>.
67964 </p>
67965
67966 </blockquote>
67967
67968 <pre>queue(queue&amp;&amp; q)
67969 </pre>
67970
67971 <blockquote>
67972
67973 <p>
67974 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt>.
67975 </p>
67976
67977 </blockquote>
67978
67979 <p>
67980 For each of the following constructors,
67981 if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
67982 then the constructor shall not participate in overload resolution.
67983 </p>
67984
67985 <pre>template &lt;class Alloc&gt; 
67986   explicit queue(const Alloc&amp; a);
67987 </pre>
67988
67989 <blockquote>
67990
67991 <p>
67992 <i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
67993 </p>
67994
67995 </blockquote>
67996
67997 <pre>template &lt;class Alloc&gt; 
67998   queue(const container_type&amp; cont, const Alloc&amp; a);
67999 </pre>
68000
68001 <blockquote>
68002
68003 <p>
68004 <i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first
68005 argument and <tt>a</tt> as the second argument.
68006 </p>
68007
68008 </blockquote>
68009
68010 <pre>template &lt;class Alloc&gt; 
68011   queue(container_type&amp;&amp; cont, const Alloc&amp; a);
68012 </pre>
68013
68014 <blockquote>
68015
68016 <p>
68017 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
68018 first argument and <tt>a</tt> as the second argument.
68019 </p>
68020
68021 </blockquote>
68022
68023 <pre>template &lt;class Alloc&gt; 
68024   queue(queue&amp;&amp; q, const Alloc&amp; a);
68025 </pre>
68026
68027 <blockquote>
68028
68029 <p>
68030 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
68031 first argument and <tt>a</tt> as the second argument.
68032 </p>
68033
68034 </blockquote>
68035
68036 <pre>queue&amp; operator=(queue&amp;&amp; q);
68037 </pre>
68038
68039 <blockquote>
68040
68041 <p>
68042 <i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt>.
68043 </p>
68044
68045 <p>
68046 <i>Returns:</i> <tt>*this</tt>.
68047 </p>
68048
68049 </blockquote>
68050
68051
68052
68053 </blockquote>
68054
68055 <p>
68056 Add to 23.5.2.1 [priqueue.cons]:
68057 </p>
68058
68059 <blockquote>
68060
68061 <pre>priority_queue(priority_queue&amp;&amp; q);
68062 </pre>
68063
68064 <blockquote>
68065
68066 <p>
68067 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> and
68068 initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
68069 </p>
68070
68071 </blockquote>
68072
68073 <p>
68074 For each of the following constructors,
68075 if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
68076 then the constructor shall not participate in overload resolution.
68077 </p>
68078
68079 <pre>template &lt;class Alloc&gt;
68080   explicit priority_queue(const Alloc&amp; a);
68081 </pre>
68082
68083 <blockquote>
68084
68085 <p>
68086 <i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and value-initializes <tt>comp</tt>.
68087 </p>
68088
68089 </blockquote>
68090
68091 <pre>template &lt;class Alloc&gt;
68092   priority_queue(const Compare&amp; compare, const Alloc&amp; a);
68093 </pre>
68094
68095 <blockquote>
68096
68097 <p>
68098 <i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and initializes <tt>comp</tt>
68099 with <tt>compare</tt>.
68100 </p>
68101
68102 </blockquote>
68103
68104 <pre>template &lt;class Alloc&gt;
68105   priority_queue(const Compare&amp; compare, const Container&amp; cont, const Alloc&amp; a);
68106 </pre>
68107
68108 <blockquote>
68109
68110 <p>
68111 <i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first argument
68112 and <tt>a</tt> as the second argument,
68113 and initializes <tt>comp</tt> with <tt>compare</tt>.
68114 </p>
68115
68116 </blockquote>
68117
68118 <pre>template &lt;class Alloc&gt;
68119   priority_queue(const Compare&amp; compare, Container&amp;&amp; cont, const Alloc&amp; a);
68120 </pre>
68121
68122 <blockquote>
68123
68124 <p>
68125 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as 
68126 the first argument and <tt>a</tt> as the second argument,
68127 and initializes <tt>comp</tt> with <tt>compare</tt>.
68128 </p>
68129
68130 </blockquote>
68131
68132 <pre>template &lt;class Alloc&gt;
68133   priority_queue(priority_queue&amp;&amp; q, const Alloc&amp; a);
68134 </pre>
68135
68136 <blockquote>
68137
68138 <p>
68139 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
68140 first argument and <tt>a</tt> as the second argument, 
68141 and initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
68142 </p>
68143
68144 </blockquote>
68145
68146 <pre>priority_queue&amp; operator=(priority_queue&amp;&amp; q);
68147 </pre>
68148
68149 <blockquote>
68150
68151 <p>
68152 <i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt> and
68153 assigns <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
68154 </p>
68155
68156 <p>
68157 <i>Returns:</i> <tt>*this</tt>.
68158 </p>
68159
68160 </blockquote>
68161
68162 </blockquote>
68163
68164
68165
68166
68167 <p>
68168 Change 23.5.3.1 [stack.defn]:
68169 </p>
68170
68171 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
68172 class stack {
68173 public:
68174   typedef typename Container::value_type      value_type;
68175   typedef typename Container::reference       reference;
68176   typedef typename Container::const_reference const_reference;
68177   typedef typename Container::size_type       size_type;
68178   typedef Container                           container_type;
68179 protected:
68180   Container c;
68181
68182 public:
68183   explicit stack(const Container&amp;);
68184   explicit stack(Container&amp;&amp; = Container());
68185   <ins>stack(stack&amp;&amp; s);</ins>
68186   template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
68187   template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
68188   template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
68189   template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
68190   <ins>stack&amp; operator=(stack&amp;&amp; s);</ins>
68191
68192   bool empty() const          { return c.empty(); }
68193   ...
68194 };
68195 </pre></blockquote>
68196
68197 <p>
68198 Add a new section after 23.5.3.1 [stack.defn], [stack.cons]:
68199 </p>
68200
68201 <blockquote>
68202 <p><b><tt>stack</tt> constructors [stack.cons]</b></p>
68203
68204 <pre>stack(stack&amp;&amp; s);
68205 </pre>
68206
68207 <blockquote>
68208
68209 <p>
68210 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt>.
68211 </p>
68212
68213 </blockquote>
68214
68215 <p>
68216 For each of the following constructors,
68217 if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
68218 then the constructor shall not participate in overload resolution.
68219 </p>
68220
68221 <pre>template &lt;class Alloc&gt; 
68222   explicit stack(const Alloc&amp; a);
68223 </pre>
68224
68225 <blockquote>
68226
68227 <p>
68228 <i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
68229 </p>
68230
68231 </blockquote>
68232
68233 <pre>template &lt;class Alloc&gt; 
68234   stack(const container_type&amp; cont, const Alloc&amp; a);
68235 </pre>
68236
68237 <blockquote>
68238
68239 <p>
68240 <i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the
68241 first argument and <tt>a</tt> as the second argument.
68242 </p>
68243
68244 </blockquote>
68245
68246 <pre>template &lt;class Alloc&gt; 
68247   stack(container_type&amp;&amp; cont, const Alloc&amp; a);
68248 </pre>
68249
68250 <blockquote>
68251
68252 <p>
68253 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
68254 first argument and <tt>a</tt> as the second argument.
68255 </p>
68256
68257 </blockquote>
68258
68259 <pre>template &lt;class Alloc&gt; 
68260   stack(stack&amp;&amp; s, const Alloc&amp; a);
68261 </pre>
68262
68263 <blockquote>
68264
68265 <p>
68266 <i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt> as the
68267 first argument and <tt>a</tt> as the second argument.
68268 </p>
68269
68270 </blockquote>
68271
68272 <pre>stack&amp; operator=(stack&amp;&amp; s);
68273 </pre>
68274
68275 <blockquote>
68276
68277 <p>
68278 <i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(s.c)</tt>.
68279 </p>
68280
68281 <p>
68282 <i>Returns:</i> <tt>*this</tt>.
68283 </p>
68284
68285 </blockquote>
68286
68287 </blockquote>
68288
68289
68290
68291
68292
68293
68294 <hr>
68295 <h3><a name="1195"></a>1195. "Diagnostic required" wording is insufficient to  prevent UB</h3>
68296 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
68297  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-10-23</p>
68298 <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>
68299 <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>
68300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
68301 <p><b>Discussion:</b></p>
68302 <p>
68303 Several parts of the library use the notion of "Diagnostic required"
68304 to indicate that
68305 in the corresponding situation an error diagnostic should occur, e.g.
68306 20.9.9.1.2 [unique.ptr.dltr.dflt]/2
68307 </p>
68308 <blockquote><pre>void operator()(T *ptr) const;
68309 </pre>
68310
68311 <blockquote>
68312 <i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>. A diagnostic is required if <tt>T</tt> is an
68313 incomplete type.
68314 </blockquote>
68315 </blockquote>
68316
68317 <p>
68318 The problem with this approach is that such a requirement is
68319 insufficient to prevent
68320 undefined behavior, if this situation occurs. According to 1.3.6 [defns.diagnostic]
68321 a <i>diagnostic message</i> is defined as
68322 </p>
68323
68324 <blockquote>
68325 a message belonging to an implementation-defined subset of the
68326 implementation's output messages.
68327 </blockquote>
68328
68329 <p>
68330 which doesn't indicate any relation to an ill-formed program. In fact,
68331 "compiler warnings"
68332 are a typical expression of such diagnostics. This means that above
68333 wording can be interpreted
68334 by compiler writers that they satisfy the requirements of the standard
68335 if they just produce
68336 such a "warning", if the compiler happens to compile code like this:
68337 </p>
68338
68339 <blockquote><pre>#include &lt;memory&gt;
68340
68341 struct Ukn; // defined somewhere else
68342 Ukn* create_ukn(); // defined somewhere else
68343
68344 int main() {
68345  std::default_delete&lt;Ukn&gt;()(create_ukn());
68346 }
68347 </pre></blockquote>
68348
68349 <p>
68350 In this and other examples discussed here it was the authors intent to
68351 guarantee that the
68352 program is ill-formed with a required diagnostic, therefore such
68353 wording should be used instead.
68354 According to the general rules outlined in 1.4 [intro.compliance] it
68355 should be sufficient
68356 to require that these situations produce an ill-formed program and the
68357 "diagnostic
68358 required" part should be implied. The proposed resolution also
68359 suggests to remove
68360 several <i>redundant</i> wording of "Diagnostics required" to ensure that
68361 the absence of
68362 such saying does not cause a misleading interpretation.
68363 </p>
68364
68365 <p><i>[
68366 2009 Santa Cruz:
68367 ]</i></p>
68368
68369
68370 <blockquote>
68371 <p>
68372 Move to NAD.
68373 </p>
68374 <p>
68375 It's not clear that there's any important difference between
68376 "ill-formed" and "diagnostic required". From 1.4 [intro.compliance], 1.3.9 [defns.ill.formed], and 1.3.26 [defns.well.formed] it appears that an ill-formed program is one
68377 that is not correctly constructed according to the syntax rules and
68378 diagnosable semantic rules, which means that... "a conforming
68379 implementation shall issue at least one diagnostic message." The
68380 author's intent seems to be that we should be requiring a fatal error
68381 instead of a mere warning, but the standard just doesn't have language
68382 to express that distinction. The strongest thing we can ever require is
68383 a "diagnostic".
68384 </p>
68385 <p>
68386 The proposed rewording may be a clearer way of expressing the same thing
68387 that the WP already says, but such a rewording is editorial.
68388 </p>
68389 </blockquote>
68390
68391 <p><i>[
68392 2009 Santa Cruz:
68393 ]</i></p>
68394
68395
68396 <blockquote>
68397 Considered again.  Group disagrees that the change is technical, but likes
68398 it editorially.  Moved to NAD Editorial.
68399 </blockquote>
68400
68401 <p><i>[
68402 2009-11-19: Moved from NAD Editorial to Open.  Please see the thread starting
68403 with Message c++std-lib-25916.
68404 ]</i></p>
68405
68406
68407 <p><i>[
68408 2009-11-20 Daniel updated wording.
68409 ]</i></p>
68410
68411
68412 <blockquote>
68413 <p>
68414 The following resolution differs from the previous one by avoiding the unusual
68415 and misleading term "shall be ill-formed", which does also not follow the core
68416 language style. This resolution has the advantage of a minimum impact on the
68417 current wording, but I would like to mention that a more intrusive solution
68418 might be preferrable - at least as a long-term solution: Jens Maurer suggested
68419 the following approach to get rid of the usage of the term "ill-formed" from the
68420 library by introducing a new category to existing elements to the list of 17.5.1.4 [structure.specifications]/3, e.g. "type requirements" or "static
68421 constraints" that define conditions that can be checked during compile-time and
68422 any violation would make the program ill-formed. As an example, the currently
68423 existing phrase 20.4.2.5 [tuple.helper]/1
68424 </p>
68425
68426 <blockquote>
68427 <i>Requires:</i> <tt>I &lt; sizeof...(Types)</tt>. The program is ill-formed if
68428 <tt>I</tt> is out of bounds.
68429 </blockquote>
68430
68431 <p>
68432 could then be written as
68433 </p>
68434
68435 <blockquote>
68436 <i>Static constraints:</i> <tt>I &lt; sizeof...(Types)</tt>.
68437 </blockquote>
68438
68439 </blockquote>
68440
68441 <p><i>[
68442 2009-11-21 Daniel updated wording.
68443 ]</i></p>
68444
68445
68446 <p><i>[
68447 2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
68448 ]</i></p>
68449
68450
68451
68452
68453 <p><b>Proposed resolution:</b></p>
68454 <ol>
68455 <li>
68456 <p>
68457 Change 20.6 [ratio]/2 as indicated:
68458 </p>
68459
68460 <blockquote>
68461 Throughout this subclause, <ins>if</ins> the template argument types <tt>R1</tt>
68462 and <tt>R2</tt> <del>shall be</del> <ins>are not</ins> specializations of the
68463 <tt>ratio</tt> template<ins>, the program is ill-formed</ins>. <del>Diagnostic
68464 required.</del>
68465 </blockquote>
68466 </li>
68467
68468 <li>
68469 <p>
68470 Change 20.6.1 [ratio.ratio]/1 as indicated:
68471 </p>
68472
68473 <p>
68474 <ins>If t</ins><del>T</del>he template argument <tt>D</tt> <del>shall not
68475 be</del> <ins>is</ins> zero<del>, and</del> <ins>or</ins> the absolute values of
68476 the template arguments <tt>N</tt> and <tt>D</tt> <del>shall be</del> <ins>are
68477 not</ins> representable by type <tt>intmax_t</tt><ins>, the program is
68478 ill-formed</ins>. <del>Diagnostic required.</del> [..]
68479 </p>
68480
68481 </li>
68482
68483 <li>
68484 <p>
68485 Change 20.6.2 [ratio.arithmetic]/1 as indicated:
68486 </p>
68487
68488 <blockquote>
68489 Implementations may use other algorithms to compute these values. If overflow
68490 occurs, <ins>the program is ill-formed</ins> <del>a diagnostic shall be
68491 issued</del>.
68492 </blockquote>
68493
68494 </li>
68495
68496 <li>
68497 <p>
68498 Change 20.6.3 [ratio.comparison]/2 as indicated:
68499 </p>
68500
68501 <blockquote>
68502 [...] Implementations may use other algorithms to compute this relationship to
68503 avoid overflow. If overflow occurs, <ins>the program is ill-formed</ins> <del>a
68504 diagnostic is required</del>.
68505 </blockquote>
68506
68507 </li>
68508
68509 <li>
68510 <p>
68511 Change 20.9.9.1.2 [unique.ptr.dltr.dflt]/2 as indicated:
68512 </p>
68513
68514 <blockquote>
68515 <p>
68516 <i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>. <del>A diagnostic is
68517 required if <tt>T</tt> is an incomplete type.</del>
68518 </p>
68519
68520 <p>
68521 <ins><i>Remarks:</i> If <tt>T</tt> is an incomplete type, the program is
68522 ill-formed.</ins>
68523 </p>
68524 </blockquote>
68525
68526 </li>
68527
68528 <li>
68529 <p>
68530 Change 20.9.9.1.3 [unique.ptr.dltr.dflt1]/1 as indicated:
68531 </p>
68532
68533 <blockquote><pre>void operator()(T* ptr) const;
68534 </pre>
68535 <blockquote>
68536 <p>
68537 <ins><i>Effects:</i></ins> <del><tt>operator()</tt></del> calls
68538 <tt>delete[]</tt> on <tt>ptr</tt>. <del>A diagnostic is required if <tt>T</tt>
68539 is an incomplete type.</del>
68540 </p>
68541 <p>
68542 <ins><i>Remarks:</i> If <tt>T</tt> is an incomplete type, the program is
68543 ill-formed.</ins>
68544 </p>
68545 </blockquote>
68546 </blockquote>
68547
68548 </li>
68549
68550 <li>
68551 <p>
68552 Change 20.9.9.2.1 [unique.ptr.single.ctor] as indicated: <i>[Note: This
68553 editorially improves the currently suggested wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a> by
68554 replacing</i>
68555 </p>
68556 <blockquote>
68557 <i>"shall be ill-formed" by "is ill-formed"]</i>
68558 </blockquote>
68559
68560 <p>
68561 <i>[If
68562 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3025.html">N3025</a>
68563 is accepted this bullet is applied identically in that paper as well.]</i>
68564 </p>
68565
68566 <blockquote>
68567 <p>
68568 -1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that
68569 construction shall not throw an exception. <del><tt>D</tt> shall not be a
68570 reference type or pointer type (diagnostic required).</del>
68571 </p>
68572
68573 <p>...</p>
68574
68575 <p><ins>
68576 <i>Remarks:</i> If this constructor is instantiated with a pointer type
68577 or reference type for the template argument <tt>D</tt>, the program is
68578 ill-formed.
68579 </ins></p>
68580 </blockquote>
68581
68582 </li>
68583
68584 <li>
68585 <p>
68586 Change 20.9.9.2.1 [unique.ptr.single.ctor]/8 as indicated: <i>[Note: This
68587 editorially improves the currently suggested wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a> by
68588 replacing</i>
68589 </p>
68590 <blockquote>
68591 <i>"shall be ill-formed" by "is ill-formed"]</i>
68592 </blockquote>
68593
68594 <p>
68595 <i>[If
68596 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3025.html">N3025</a>
68597 is accepted this bullet is applied identically in that paper as well.]</i>
68598 </p>
68599
68600 <blockquote><pre>unique_ptr(pointer p);
68601 </pre>
68602 <blockquote>
68603 <p>...</p>
68604 <p><ins>
68605 <i>Remarks:</i> If this constructor is instantiated with a pointer type
68606 or reference type for the template argument <tt>D</tt>, the program is
68607 ill-formed.
68608 </ins></p>
68609 </blockquote>
68610 </blockquote>
68611
68612 </li>
68613
68614 <li>
68615 <p>
68616 Change 20.9.9.2.1 [unique.ptr.single.ctor]/13 as indicated:
68617 </p>
68618
68619 <blockquote>
68620 [..] If <tt>d</tt> is an rvalue, it will bind to the second constructor of this
68621 pair <ins>and the program is ill-formed</ins>. <del>That constructor shall emit
68622 a diagnostic.</del> [<i>Note:</i> The diagnostic could be implemented using a
68623 <tt>static_assert</tt> which assures that <tt>D</tt> is not a reference type.
68624 \97 <i>end note</i>] Else <tt>d</tt> is an lvalue and will bind to the first
68625 constructor of this pair. [..]
68626 </blockquote>
68627
68628 </li>
68629
68630 <li>
68631 20.9.9.2.1 [unique.ptr.single.ctor]/20: Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>.
68632 </li>
68633
68634 <li>
68635 <p>
68636 Change 20.9.9.3 [unique.ptr.runtime]/1 as indicated:
68637 </p>
68638
68639 <blockquote>
68640 <p>
68641 A specialization for array types is provided with a slightly altered interface.
68642 </p>
68643 <ul>
68644 <li>
68645 Conversions among different types of <tt>unique_ptr&lt;T[], D&gt;</tt> or to or
68646 from the non-array forms of <tt>unique_ptr</tt> <del>are disallowed (diagnostic
68647 required)</del> <ins>produce an ill-formed program</ins>.
68648 </li>
68649 <li>...</li>
68650 </ul>
68651 </blockquote>
68652
68653 </li>
68654
68655 <li>
68656 <p>
68657 Change 20.11.3 [time.duration]/2-4 as indicated:
68658 </p>
68659
68660 <blockquote>
68661 <p>
68662 2 <i>Requires:</i> <tt>Rep</tt> shall be an arithmetic type or a class emulating
68663 an arithmetic type. <del>If a program instantiates <tt>duration</tt> with a
68664 <tt>duration</tt> type for the template argument <tt>Rep</tt> a diagnostic is
68665 required.</del>
68666 </p>
68667 <p>
68668 <ins>3 <i>Remarks:</i> If <tt>duration</tt> is instantiated with a
68669 <tt>duration</tt> type for the template argument <tt>Rep</tt>, the program is
68670 ill-formed.</ins>
68671 </p>
68672
68673 <p>
68674 <del>3</del> <ins>4</ins> <i><del>Requires</del> <ins>Remarks</ins>:</i>
68675 <ins>If</ins> <tt>Period</tt> <del>shall be</del> <ins>is not</ins> a
68676 specialization of <tt>ratio</tt>, <del>diagnostic required</del> <ins>the
68677 program is ill-formed</ins>.
68678 </p>
68679
68680 <p>
68681 <del>4</del> <ins>5</ins> <i><del>Requires</del> <ins>Remarks</ins>:</i>
68682 <ins>If</ins> <tt>Period::num</tt> <del>shall be</del> <ins>is not</ins>
68683 positive, <del>diagnostic required</del> <ins>the program is ill-formed</ins>.
68684 </p>
68685 </blockquote>
68686
68687 </li>
68688
68689 <li>
68690 20.11.3.1 [time.duration.cons]/1+4: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
68691 </li>
68692
68693 <li>
68694 20.11.3.5 [time.duration.nonmember]/4+6+8+11: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
68695 </li>
68696
68697 <li>
68698 20.11.3.7 [time.duration.cast]/1: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
68699 </li>
68700
68701 <li>
68702 <p>
68703 Change 20.11.4 [time.point]/2 as indicated:
68704 </p>
68705 <blockquote>
68706 <ins>If</ins> <tt>Duration</tt> <del>shall be</del> <ins>is not</ins> an
68707 instance of <tt>duration</tt><ins>, the program is ill-formed</ins>.
68708 <del>Diagnostic required.</del>
68709 </blockquote>
68710 </li>
68711
68712 <li>
68713 20.11.4.1 [time.point.cons]/3: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
68714 </li>
68715
68716 <li>
68717 20.11.4.7 [time.point.cast]/1: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
68718 </li>
68719
68720 </ol>
68721
68722
68723
68724
68725
68726
68727 <hr>
68728 <h3><a name="1197"></a>1197. Can unordered containers have <tt>bucket_count() == 0</tt>?</h3>
68729 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
68730  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-24 <b>Last modified:</b> 2010-10-23</p>
68731 <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>
68732 <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>
68733 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
68734 <p><b>Discussion:</b></p>
68735 <p>
68736 Table 97 "Unordered associative container requirements" in
68737 23.2.5 [unord.req] says:
68738 </p>
68739
68740 <blockquote>
68741 <table border="1">
68742 <caption>Table 97 \97 Unordered associative container requirements
68743 (in addition to container)</caption>
68744
68745 <tbody><tr>
68746 <th>Expression</th>
68747 <th>Return type</th>
68748 <th>Assertion/note pre-/post-condition</th>
68749 <th>Complexity</th>
68750 </tr>
68751
68752 <tr>
68753 <td><tt>b.bucket(k)</tt></td>
68754 <td><tt>size_type</tt></td>
68755 <td>Returns the index of the bucket in which elements with keys 
68756 equivalent to <tt>k</tt> would be found, 
68757 if any such element existed. 
68758 Post: the return value shall be 
68759 in the range <tt>[0, 
68760 b.bucket_count())</tt>.</td>
68761 <td>Constant</td>
68762 </tr>
68763
68764 </tbody></table>
68765 </blockquote>
68766
68767 <p>
68768 What should <tt>b.bucket(k)</tt> return if <tt>b.bucket_count() == 0</tt>?
68769 </p>
68770
68771 <p>
68772 I believe allowing <tt>b.bucket_count() == 0</tt> is important.  It is a
68773 very reasonable post-condition of the default constructor, or of a moved-from
68774 container.
68775 </p>
68776
68777 <p>
68778 I can think of several reasonable results from <tt>b.bucket(k)</tt> when
68779 <tt>b.bucket_count() == 0</tt>:
68780 </p>
68781
68782 <ol>
68783 <li>
68784 Return 0.
68785 </li>
68786 <li>
68787 Return <tt>numeric_limits&lt;size_type&gt;::max()</tt>.
68788 </li>
68789 <li>
68790 Throw a <tt>domain_error</tt>.
68791 </li>
68792 <li>
68793 Requires: <tt>b.bucket_count() != 0</tt>.
68794 </li>
68795 </ol>
68796
68797 <p><i>[
68798 2009-08-26 Daniel adds:
68799 ]</i></p>
68800
68801
68802 <blockquote>
68803 <p>
68804 A forth choice would be to add the pre-condition "<tt>b.bucket_count() != 0</tt>"
68805 and thus imply undefined behavior if this is violated.
68806 </p>
68807
68808 <p><i>[
68809 Howard:  I like this option too, added to the list.
68810 ]</i></p>
68811
68812
68813 <p>
68814 Further on here my own favorite solution (rationale see below):
68815 </p>
68816
68817 <p><b>Suggested resolution:</b></p>
68818
68819 <p>
68820 [Rationale: I suggest to follow choice (1). The main reason is
68821 that all associative container functions which take a key argument,
68822 are basically free of pre-conditions and non-disrupting, therefore
68823 excluding choices (3) and (4). Option (2) seems a bit unexpected
68824 to me. It would be more natural, if several similar functions
68825 would exist which would also justify the existence of a symbolic
68826 constant like npos for this situation. The value 0 is both simple
68827 and consistent, it has exactly the same role as a past-the-end
68828 iterator value. A typical use-case is:
68829 </p>
68830
68831 <blockquote><pre>size_type pos = m.bucket(key);
68832 if (pos != m.bucket_count()) {
68833  ...
68834 } else {
68835  ...
68836 }
68837 </pre></blockquote>
68838
68839 <p>\97 end Rationale]</p>
68840
68841 <p>
68842 - Change Table 97 in 23.2.5 [unord.req] as follows (Row b.bucket(k), Column "Assertion/..."):
68843 </p>
68844
68845 <blockquote>
68846 <table border="1">
68847 <caption>Table 97 \97 Unordered associative container requirements
68848 (in addition to container)</caption>
68849
68850 <tbody><tr>
68851 <th>Expression</th>
68852 <th>Return type</th>
68853 <th>Assertion/note pre-/post-condition</th>
68854 <th>Complexity</th>
68855 </tr>
68856
68857 <tr>
68858 <td><tt>b.bucket(k)</tt></td>
68859 <td><tt>size_type</tt></td>
68860 <td>Returns the index of the bucket in which elements with keys 
68861 equivalent to <tt>k</tt> would be found, 
68862 if any such element existed. 
68863 Post: <ins>if b.bucket_count() != 0, </ins>the return value shall be 
68864 in the range <tt>[0, 
68865 b.bucket_count())</tt><ins>, otherwise 0</ins>.</td>
68866 <td>Constant</td>
68867 </tr>
68868
68869 </tbody></table>
68870 </blockquote>
68871
68872 </blockquote>
68873
68874 <p><i>[
68875 2010-01-25 Choice 4 put into proposed resolution section.
68876 ]</i></p>
68877
68878
68879 <p><i>[
68880 2010-01-31 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
68881 ]</i></p>
68882
68883
68884
68885 <p><b>Proposed resolution:</b></p>
68886 <p>
68887 Change Table 97 in 23.2.5 [unord.req] as follows (Row b.bucket(k), Column
68888 "Assertion/..."):
68889 </p>
68890
68891 <blockquote>
68892 <table border="1">
68893 <caption>Table 97 \97 Unordered associative container requirements
68894 (in addition to container)</caption>
68895
68896 <tbody><tr>
68897 <th>Expression</th>
68898 <th>Return type</th>
68899 <th>Assertion/note pre-/post-condition</th>
68900 <th>Complexity</th>
68901 </tr>
68902
68903 <tr>
68904 <td><tt>b.bucket(k)</tt></td>
68905 <td><tt>size_type</tt></td>
68906 <td><ins>Pre:  <tt>b.bucket_count() &gt; 0</tt></ins> Returns the index of the
68907 bucket in which elements with keys equivalent to <tt>k</tt> would be found, if
68908 any such element existed. Post: the return value shall be in the range <tt>[0,
68909 b.bucket_count())</tt>.</td>
68910 <td>Constant</td>
68911 </tr>
68912
68913 </tbody></table>
68914 </blockquote>
68915
68916
68917
68918
68919
68920
68921 <hr>
68922 <h3><a name="1198"></a>1198. Container adaptor swap: member or non-member?</h3>
68923 <p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
68924  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26 <b>Last modified:</b> 2010-11-24</p>
68925 <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>
68926 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
68927 <p><b>Discussion:</b></p>
68928 <p>
68929 Under 23.5 [container.adaptors] of
68930 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
68931 the member function of <tt>swap</tt> of <tt>queue</tt> and <tt>stack</tt> call:
68932 </p>
68933
68934 <blockquote><pre>swap(c, q.c);
68935 </pre></blockquote>
68936
68937 <p>
68938 But under 23.5 [container.adaptors] of
68939 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
68940 these members are specified to call:
68941 </p>
68942
68943 <blockquote><pre>c.swap(q.c);
68944 </pre></blockquote>
68945
68946 <p>
68947 Neither draft specifies the semantics of member <tt>swap</tt> for
68948 <tt>priority_queue</tt> though it is declared.
68949 </p>
68950
68951 <p>
68952 Although the distinction between member <tt>swap</tt> and non-member
68953 <tt>swap</tt> is not important when these adaptors are adapting standard
68954 containers, it may be important for user-defined containers.
68955 </p>
68956 <p>
68957 We (Pablo and Howard) feel that
68958 it is more likely for a user-defined container to support a namespace scope
68959 <tt>swap</tt> than a member <tt>swap</tt>, and therefore these adaptors
68960 should use the container's namespace scope <tt>swap</tt>.
68961 </p>
68962
68963 <p><i>[
68964 2009-09-30 Daniel adds:
68965 ]</i></p>
68966
68967
68968 <blockquote>
68969 The outcome of this issue should be considered with the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a> both in style and in content (e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a> bullet 9
68970 suggests to define the semantic of <tt>void
68971 priority_queue::swap(priority_queue&amp;)</tt> in terms of the member
68972 <tt>swap</tt> of the container).
68973 </blockquote>
68974
68975 <p><i>[
68976 2010-03-28 Daniel update to diff against N3092.
68977 ]</i></p>
68978
68979
68980
68981 <p><i>[
68982 2010 Rapperswil:
68983 ]</i></p>
68984
68985
68986 <blockquote>
68987 Preference to move the wording into normative text, rather than inline function definitions in the class synopsis.
68988
68989 Move to Tenatively Ready.
68990 </blockquote>
68991
68992 <p><i>[
68993 Adopted at 2010-11 Batavia
68994 ]</i></p>
68995
68996
68997
68998
68999 <p><b>Proposed resolution:</b></p>
69000
69001 <p>
69002 Change 23.5.1.1 [queue.defn]:
69003 </p>
69004
69005 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
69006 class queue {
69007    ...
69008    void swap(queue&amp; q) { <ins>using std::swap;</ins>
69009                           <del>c.</del>swap(<ins>c, </ins>q.c); }
69010    ...
69011 };
69012 </pre></blockquote>
69013
69014 <p>
69015 Change 23.5.2 [priority.queue]:
69016 </p>
69017
69018 <blockquote><pre>template &lt;class T, class Container = vector&lt;T&gt;, 
69019           class Compare = less&lt;typename Container::value_type&gt; &gt; 
69020 class priority_queue { 
69021     ...
69022     void swap(priority_queue&amp; <ins>q</ins>)<del>;</del> <ins>{ using std::swap;</ins>
69023                                      <ins>swap(c, q.c);</ins>
69024                                      <ins>swap(comp, q.comp); }</ins>
69025     ...
69026 };
69027 </pre></blockquote>
69028
69029 <p>
69030 Change 23.5.3.1 [stack.defn]:
69031 </p>
69032
69033 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
69034 class stack {
69035    ...
69036    void swap(stack&amp; s) { <ins>using std::swap;</ins>
69037                           <del>c.</del>swap(<ins>c, </ins>s.c); }
69038    ...
69039 };
69040 </pre></blockquote>
69041
69042
69043
69044
69045
69046
69047 <hr>
69048 <h3><a name="1199"></a>1199. Missing extended copy constructor in container adaptors</h3>
69049 <p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
69050  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26 <b>Last modified:</b> 2010-10-23</p>
69051 <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>
69052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
69053 <p><b>Discussion:</b></p>
69054 <p>
69055 <tt>queue</tt> has a constructor:
69056 </p>
69057
69058 <blockquote><pre>template &lt;class Alloc&gt;
69059   queue(queue&amp;&amp;, const Alloc&amp;);
69060 </pre></blockquote>
69061
69062 <p>
69063 but it is missing a corresponding constructor:
69064 </p>
69065
69066 <blockquote><pre>template &lt;class Alloc&gt;
69067   queue(const queue&amp;, const Alloc&amp;);
69068 </pre></blockquote>
69069
69070 <p>
69071 The same is true of <tt>priority_queue</tt>, and <tt>stack</tt>.  This
69072 "extended copy constructor" is needed for consistency and to ensure that the
69073 user of a container adaptor can always specify the allocator for his adaptor.
69074 </p>
69075
69076 <p><i>[
69077 2010-02-01 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
69078 ]</i></p>
69079
69080
69081
69082
69083 <p><b>Proposed resolution:</b></p>
69084 <p><i>[
69085 This resolution has been harmonized with the proposed resolution to issue
69086 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>
69087 ]</i></p>
69088
69089
69090 <p>Change 23.5.1.1 [queue.defn], p1:</p>
69091
69092 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
69093 class queue {
69094 public:
69095   typedef typename Container::value_type      value_type;
69096   typedef typename Container::reference       reference;
69097   typedef typename Container::const_reference const_reference;
69098   typedef typename Container::size_type       size_type;
69099   typedef Container                           container_type;
69100 protected:
69101   Container c;
69102
69103 public:
69104   explicit queue(const Container&amp;);
69105   explicit queue(Container&amp;&amp; = Container());
69106   queue(queue&amp;&amp; q);
69107
69108   template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
69109   template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
69110   template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
69111   <ins>template &lt;class Alloc&gt; queue(const queue&amp;, const Alloc&amp;);</ins>
69112   template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
69113   queue&amp; operator=(queue&amp;&amp; q);
69114
69115   bool empty() const          { return c.empty(); }
69116   ...
69117 };
69118 </pre></blockquote>
69119
69120 <p>
69121 To the new section 23.5.1.2 [queue.cons], introduced
69122 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, add:
69123 </p>
69124
69125 <blockquote>
69126
69127 <pre>template &lt;class Alloc&gt; 
69128   queue(const queue&amp; q, const Alloc&amp; a);
69129 </pre>
69130
69131 <blockquote><p>
69132 <i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
69133 first argument and <tt>a</tt> as the second argument.
69134 </p></blockquote>
69135
69136 </blockquote>
69137
69138 <p>Change 23.5.2 [priority.queue] as follows (I've an included an editorial change to
69139   move the poorly-placed move-assignment operator):</p>
69140
69141 <blockquote><pre>template &lt;class T, class Container = vector&lt;T&gt;,
69142           class Compare = less&lt;typename Container::value_type&gt; &gt;
69143 class priority_queue {
69144 public:
69145   typedef typename Container::value_type      value_type;
69146   typedef typename Container::reference       reference;
69147   typedef typename Container::const_reference const_reference;
69148   typedef typename Container::size_type       size_type;
69149   typedef          Container                  container_type;
69150 protected:
69151   Container c;
69152   Compare comp;
69153
69154 public:
69155   priority_queue(const Compare&amp; x, const Container&amp;);
69156   explicit priority_queue(const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
69157   template &lt;class InputIterator&gt;
69158     priority_queue(InputIterator first, InputIterator last,
69159                    const Compare&amp; x, const Container&amp;);
69160   template &lt;class InputIterator&gt;
69161     priority_queue(InputIterator first, InputIterator last,
69162                    const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
69163   priority_queue(priority_queue&amp;&amp;);
69164   <del>priority_queue&amp; operator=(priority_queue&amp;&amp;);</del>
69165   template &lt;class Alloc&gt; explicit priority_queue(const Alloc&amp;);
69166   template &lt;class Alloc&gt; priority_queue(const Compare&amp;, const Alloc&amp;);
69167   template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
69168                                         const Container&amp;, const Alloc&amp;);
69169   template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
69170                                         Container&amp;&amp;, const Alloc&amp;);
69171   <ins>template &lt;class Alloc&gt; priority_queue(const priority_queue&amp;, const Alloc&amp;);</ins>
69172   template &lt;class Alloc&gt; priority_queue(priority_queue&amp;&amp;, const Alloc&amp;);
69173
69174   <ins>priority_queue&amp; operator=(priority_queue&amp;&amp;);</ins>
69175   ...
69176 };
69177 </pre></blockquote>
69178
69179 <p>
69180 Add to 23.5.2.1 [priqueue.cons]:
69181 </p>
69182
69183 <blockquote>
69184
69185 <pre>template &lt;class Alloc&gt;
69186   priority_queue(const priority_queue&amp; q, const Alloc&amp; a);
69187 </pre>
69188
69189 <blockquote><p>
69190 <i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
69191 first argument and <tt>a</tt> as the second argument, 
69192 and initializes <tt>comp</tt> with <tt>q.comp</tt>.
69193 </p></blockquote>
69194
69195 </blockquote>
69196
69197 <p>
69198 Change 23.5.3.1 [stack.defn]:
69199 </p>
69200
69201 <blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
69202 class stack {
69203 public:
69204   typedef typename Container::value_type      value_type;
69205   typedef typename Container::reference       reference;
69206   typedef typename Container::const_reference const_reference;
69207   typedef typename Container::size_type       size_type;
69208   typedef Container                           container_type;
69209 protected:
69210   Container c;
69211
69212 public:
69213   explicit stack(const Container&amp;);
69214   explicit stack(Container&amp;&amp; = Container());
69215   stack(stack&amp;&amp; s);
69216
69217   template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
69218   template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
69219   template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
69220   <ins>template &lt;class Alloc&gt; stack(const stack&amp;, const Alloc&amp;);</ins>
69221   template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
69222   stack&amp; operator=(stack&amp;&amp; s);
69223
69224   bool empty() const          { return c.empty(); }
69225   ...
69226 };
69227 </pre></blockquote>
69228
69229 <p>
69230 To the new section 23.5.3.2 [stack.cons], introduced
69231 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, add:
69232 </p>
69233
69234 <blockquote>
69235
69236 <pre>template &lt;class Alloc&gt; 
69237   stack(const stack&amp; s, const Alloc&amp; a);
69238 </pre>
69239
69240 <blockquote><p>
69241 <i>Effects:</i> Initializes <tt>c</tt> with <tt>s.c</tt> as the
69242 first argument and <tt>a</tt> as the second argument.
69243 </p></blockquote>
69244 </blockquote>
69245
69246
69247
69248
69249
69250
69251 <hr>
69252 <h3><a name="1204"></a>1204. Global permission to move</h3>
69253 <p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
69254  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-12 <b>Last modified:</b> 2010-10-23</p>
69255 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
69256 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
69257 <p><b>Discussion:</b></p>
69258 <p>
69259 When a library function binds an rvalue reference parameter to an argument, the
69260 library must be able to assume that the bound argument is a temporary, and not
69261 a moved-from lvalue.  The reason for this is that the library function must be
69262 able to modify that argument without concern that such modifications will corrupt
69263 the logic of the calling code.  For example:
69264 </p>
69265
69266 <blockquote><pre>template &lt;class T, class A&gt;
69267 void
69268 vector&lt;T, A&gt;::push_back(value_type&amp;&amp; v)
69269 {
69270     <font color="#C80000">// This function should move from v, potentially modifying</font>
69271     <font color="#C80000">//   the object v is bound to.</font>
69272 }
69273 </pre></blockquote>
69274
69275 <p>
69276 If <tt>v</tt> is truly bound to a temporary, then <tt>push_back</tt> has the
69277 <em>only</em> reference to this temporary in the entire program.  Thus any
69278 modifications will be invisible to the rest of the program.
69279 </p>
69280
69281 <p>
69282 If the client supplies <tt>std::move(x)</tt> to <tt>push_back</tt>, the onus is
69283 on the client to ensure that the value of <tt>x</tt> is no longer important to
69284 the logic of his program after this statement.  I.e. the client is making a statement
69285 that <tt>push_back</tt> may treat <tt>x</tt> as a temporary.
69286 </p>
69287
69288 <blockquote><em>
69289 The above statement is the very foundation upon which move semantics is based.
69290 </em></blockquote>
69291
69292 <p>
69293 The standard is currently lacking a global statement to this effect.  I propose
69294 the following addition to 17.6.3.9 [res.on.arguments]:
69295 </p>
69296
69297 <blockquote>
69298 <p>
69299 Each of the following statements applies to all arguments to functions
69300 defined in the C++ standard library, unless explicitly stated otherwise.
69301 </p>
69302 <ul>
69303 <li>
69304 If an argument to a function has an invalid value (such as a value
69305 outside the domain of the function, or a pointer invalid for its
69306 intended use), the behavior is undefined.
69307 </li>
69308 <li>
69309 If a function argument is described as being an array, the pointer
69310 actually passed to the function shall have a value such that all address
69311 computations and accesses to objects (that would be valid if the pointer
69312 did point to the first element of such an array) are in fact valid.
69313 </li>
69314 <li><ins>
69315 If a function argument binds to an rvalue reference parameter, the C++
69316 standard library may assume that this parameter is a unique reference
69317 to this argument.  If the parameter is a generic parameter of the
69318 form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
69319 then the binding is considered to be to an lvalue reference
69320 (14.8.2.1 [temp.deduct.call]) and thus not covered by this clause.
69321 [<i>Note:</i>
69322 If a program casts an lvalue to an rvalue while passing that lvalue to
69323 a library function (e.g. <tt>move(x)</tt>), then the program is effectively
69324 asking the library to treat that lvalue as a temporary.  The library is at
69325 liberty to optimize away aliasing checks which might be needed if the argument
69326 were an lvalue.
69327 \97 <i>end note</i>]
69328 </ins></li>
69329 </ul>
69330
69331 </blockquote>
69332
69333 <p>
69334 Such a global statement will eliminate the need for piecemeal statements such as
69335 23.2.1 [container.requirements.general]/13:
69336 </p>
69337
69338 <blockquote>
69339 An object bound to an rvalue reference parameter of a member function of
69340 a container shall not be an element of that container; no diagnostic
69341 required.
69342 </blockquote>
69343
69344 <p>
69345 Additionally this clarifies that move assignment operators need not perform the
69346 traditional <tt>if (this != &amp;rhs)</tt> test commonly found (and needed) in
69347 copy assignment operators.
69348 </p>
69349
69350 <p><i>[
69351 2009-09-13 Niels adds:
69352 ]</i></p>
69353
69354
69355 <blockquote>
69356 Note: This resolution supports the change of 27.9.1.3 [filebuf.assign]/1,
69357 proposed by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>.
69358 </blockquote>
69359
69360 <p><i>[
69361 2009 Santa Cruz:
69362 ]</i></p>
69363
69364
69365 <blockquote>
69366 Move to Ready.
69367 </blockquote>
69368
69369
69370
69371 <p><b>Proposed resolution:</b></p>
69372 <p>
69373 Add a bullet to 17.6.3.9 [res.on.arguments]:
69374 </p>
69375
69376 <blockquote>
69377 <p>
69378 Each of the following statements applies to all arguments to functions
69379 defined in the C++ standard library, unless explicitly stated otherwise.
69380 </p>
69381 <ul>
69382 <li>
69383 If an argument to a function has an invalid value (such as a value
69384 outside the domain of the function, or a pointer invalid for its
69385 intended use), the behavior is undefined.
69386 </li>
69387 <li>
69388 If a function argument is described as being an array, the pointer
69389 actually passed to the function shall have a value such that all address
69390 computations and accesses to objects (that would be valid if the pointer
69391 did point to the first element of such an array) are in fact valid.
69392 </li>
69393 <li><ins>
69394 If a function argument binds to an rvalue reference parameter, the C++
69395 standard library may assume that this parameter is a unique reference
69396 to this argument.  If the parameter is a generic parameter of the
69397 form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
69398 then the binding is considered to be to an lvalue reference
69399 (14.8.2.1 [temp.deduct.call]) and thus not covered by this clause.
69400 [<i>Note:</i>
69401 If a program casts an lvalue to an rvalue while passing that lvalue to
69402 a library function (e.g. <tt>move(x)</tt>), then the program is effectively
69403 asking the library to treat that lvalue as a temporary.  The library is at
69404 liberty to optimize away aliasing checks which might be needed if the argument
69405 were an lvalue.
69406 \97 <i>end note</i>]
69407 </ins></li>
69408 </ul>
69409 </blockquote>
69410
69411 <p>
69412 Delete 23.2.1 [container.requirements.general]/13:
69413 </p>
69414
69415 <blockquote><del>
69416 An object bound to an rvalue reference parameter of a member function of
69417 a container shall not be an element of that container; no diagnostic
69418 required.
69419 </del></blockquote>
69420
69421
69422
69423
69424
69425
69426 <hr>
69427 <h3><a name="1205"></a>1205. Some algorithms could more clearly document their handling of empty ranges</h3>
69428 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
69429  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-10-23</p>
69430 <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>
69431 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
69432 <p><b>Discussion:</b></p>
69433 <p>
69434 There are a number of algorithms whose result might depend on the
69435 handling of an empty range.  In some cases the result is not clear,
69436 while in others it would help readers to clearly mention the result
69437 rather than require some subtle intuition of the supplied wording.
69438 </p>
69439
69440 <p>
69441 25.2.1 [alg.all_of]
69442 </p>
69443
69444 <blockquote>
69445 <i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>true</tt> for every
69446 iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
69447 </blockquote>
69448
69449 <p>
69450 What does this mean if the range is empty?
69451 </p>
69452
69453 <p>
69454 I believe that we intend this to be <tt>true</tt> and suggest a
69455 non-normative note to clarify:
69456 </p>
69457
69458 <p>
69459 Add to p1 25.2.1 [alg.all_of]:
69460 </p>
69461
69462 <blockquote>
69463 [<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69464 \97 <i>end note</i>]
69465 </blockquote>
69466
69467 <p>
69468 25.2.3 [alg.none_of]
69469 </p>
69470
69471 <blockquote>
69472 <i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>false</tt> for every
69473 iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
69474 </blockquote>
69475
69476 <p>
69477 What does this mean if the range empty?
69478 </p>
69479
69480 <p>
69481 I believe that we intend this to be <tt>true</tt> and suggest a
69482 non-normative note to clarify:
69483 </p>
69484
69485 <p>
69486 Add to p1 25.2.3 [alg.none_of]:
69487 </p>
69488
69489 <blockquote>
69490 [<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69491 \97 <i>end note</i>]
69492 </blockquote>
69493
69494 <p>
69495 25.2.2 [alg.any_of]
69496 </p>
69497
69498 <p>
69499 The specification for an empty range is actually fairly clear in this
69500 case, but a note wouldn't hurt and would be consistent with proposals
69501 for <tt>all_of</tt>/<tt>none_of</tt> algorithms.
69502 </p>
69503
69504 <p>
69505 Add to p1 25.2.2 [alg.any_of]:
69506 </p>
69507
69508 <blockquote>
69509 [<i>Note:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
69510 \97 <i>end note</i>]
69511 </blockquote>
69512
69513 <p>
69514 25.2.6 [alg.find.end]
69515 </p>
69516
69517 <p>
69518 what does this mean if <tt>[first2,last2)</tt> is empty?
69519 </p>
69520
69521 <p>
69522 I believe the wording suggests the algorithm should return
69523 <tt>last1</tt> in this case, but am not 100% sure. Is this in fact the
69524 correct result anyway? Surely an empty range should always match and the
69525 naive expected result would be <tt>first1</tt>?
69526 </p>
69527
69528 <p>
69529 My proposed wording is a note to clarify the current semantic:
69530 </p>
69531
69532 <p>
69533 Add to p2 25.2.6 [alg.find.end]:
69534 </p>
69535
69536 <blockquote>
69537 [<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
69538 empty. \97 <i>end note</i>]
69539 </blockquote>
69540
69541 <p>
69542 I would prefer a normative wording treating empty ranges specially, but
69543 do not believe we can change semantics at this point in the process,
69544 unless existing implementations actually yield this result:
69545 </p>
69546
69547 <p>
69548 Alternative wording: (NOT a note)
69549 </p>
69550 <p>
69551 Add to p2 25.2.6 [alg.find.end]:
69552 </p>
69553 <blockquote>
69554 Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
69555 </blockquote>
69556
69557 <p>
69558 25.2.7 [alg.find.first.of]
69559 </p>
69560
69561 <p>
69562 The phrasing seems precise when <tt>[first2, last2)</tt> is empty, but a small
69563 note to confirm the reader's understanding might still help.
69564 </p>
69565
69566 <p>
69567 Add to p2 25.2.7 [alg.find.first.of]
69568 </p>
69569 <blockquote>
69570 [<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
69571 empty. \97 <i>end note</i>]
69572 </blockquote>
69573
69574 <p>
69575 25.2.13 [alg.search]
69576 </p>
69577
69578 <p>
69579 What is the expected result if <tt>[first2, last2)</tt> is empty?
69580 </p>
69581
69582 <p>
69583 I believe the wording suggests the algorithm should return <tt>last1</tt> in this
69584 case, but am not 100% sure. Is this in fact the correct result anyway? 
69585 Surely an empty range should always match and the naive expected result
69586 would be <tt>first1</tt>?
69587 </p>
69588
69589 <p>
69590 My proposed wording is a note to clarify the current semantic:
69591 </p>
69592
69593 <p>
69594 Add to p2 25.2.13 [alg.search]:
69595 </p>
69596
69597 <blockquote>
69598 [<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
69599 empty. \97 <i>end note</i>]
69600 </blockquote>
69601
69602 <p>
69603 Again, I would prefer a normative wording treating empty ranges
69604 specially, but do not believe we can change semantics at this point in
69605 the process, unless existing implementations actually yield this result:
69606 </p>
69607
69608 <p>
69609 Alternative wording: (NOT a note)
69610 </p>
69611 <p>
69612 Add to p2 25.2.13 [alg.search]:
69613 </p>
69614
69615 <blockquote>
69616 Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
69617 </blockquote>
69618
69619 <p>
69620 25.3.13 [alg.partitions]
69621 </p>
69622
69623 <p>
69624 Is an empty range partitioned or not?
69625 </p>
69626
69627 <p>
69628 Proposed wording:
69629 </p>
69630
69631 <p>
69632 Add to p1 25.3.13 [alg.partitions]:
69633 </p>
69634
69635 <blockquote>
69636 [<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69637 \97 <i>end note</i>]
69638 </blockquote>
69639
69640 <p>
69641 25.4.5.1 [includes]
69642 </p>
69643
69644 <blockquote>
69645 <i>Returns:</i> <tt>true</tt> if every element in the range
69646 <tt>[first2,last2)</tt> is contained in the range
69647 <tt>[first1,last1)</tt>. ...
69648 </blockquote>
69649
69650 <p>
69651 I really don't know what this means if <tt>[first2,last2)</tt> is empty.
69652 I could loosely guess that this implies empty ranges always match, and
69653 my proposed wording is to clarify exactly that:
69654 </p>
69655
69656 <p>
69657 Add to p1 25.4.5.1 [includes]:
69658 </p>
69659
69660 <blockquote>
69661 [<i>Note:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty.
69662 \97 <i>end note</i>]
69663 </blockquote>
69664
69665 <p>
69666 25.4.6.2 [pop.heap]
69667 </p>
69668
69669 <p>
69670 The effects clause is invalid if the range <tt>[first,last)</tt> is empty, unlike
69671 all the other heap alogorithms.  The should be called out in the
69672 requirements.
69673 </p>
69674
69675 <p>
69676 Proposed wording:
69677 </p>
69678 <p>
69679 Revise p2 25.4.6.2 [pop.heap]
69680 </p>
69681
69682 <blockquote>
69683 <i>Requires:</i> The range <tt>[first,last)</tt> shall be a valid
69684 <ins>non-empty</ins> heap.
69685 </blockquote>
69686
69687 <p>
69688 [Editorial] Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
69689 </p>
69690
69691 <p>
69692 25.4.7 [alg.min.max]
69693 </p>
69694
69695 <p>
69696 <tt>minmax_element</tt> does not clearly specify behaviour for an empty
69697 range in the same way that <tt>min_element</tt> and <tt>max_element</tt> do.
69698 </p>
69699
69700 <p>
69701 Add to p31 25.4.7 [alg.min.max]:
69702 </p>
69703
69704 <blockquote>
69705 Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.
69706 </blockquote>
69707
69708 <p>
69709 25.4.8 [alg.lex.comparison]
69710 </p>
69711
69712 <p>
69713 The wording here seems quite clear, especially with the sample algorithm
69714 implementation.  A note is recommended purely for consistency with the
69715 rest of these issue resolutions:
69716 </p>
69717
69718 <p>
69719 Add to p1 25.4.8 [alg.lex.comparison]:
69720 </p>
69721
69722 <blockquote>
69723 [<i>Note:</i> An empty sequence is lexicographically less than any other
69724 non-empty sequence, but not to another empty sequence. \97 <i>end note</i>]
69725 </blockquote>
69726
69727 <p><i>[
69728 2009-11-11 Howard changes Notes to Remarks and changed <tt>search</tt> to
69729 return <tt>first1</tt> instead of <tt>last1</tt>.
69730 ]</i></p>
69731
69732
69733 <p><i>[
69734 2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
69735 ]</i></p>
69736
69737
69738
69739 <p><b>Proposed resolution:</b></p>
69740 <p>
69741 Add to 25.2.1 [alg.all_of]:
69742 </p>
69743 <blockquote><ins>
69744 <i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69745 </ins></blockquote>
69746
69747 <p>
69748 Add to 25.2.2 [alg.any_of]:
69749 </p>
69750
69751 <blockquote><ins>
69752 <i>Remarks:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
69753 </ins></blockquote>
69754
69755 <p>
69756 Add to 25.2.3 [alg.none_of]:
69757 </p>
69758 <blockquote><ins>
69759 <i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69760 </ins></blockquote>
69761
69762 <p>
69763 Add to 25.2.6 [alg.find.end]:
69764 </p>
69765 <blockquote><ins>
69766 <i>Remarks:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
69767 empty.
69768 </ins></blockquote>
69769
69770 <p>
69771 Add to 25.2.7 [alg.find.first.of]
69772 </p>
69773 <blockquote><ins>
69774 <i>Remarks:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
69775 empty.
69776 </ins></blockquote>
69777
69778 <p>
69779 Add to 25.2.13 [alg.search]:
69780 </p>
69781 <blockquote><ins>
69782 <i>Remarks:</i> Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is
69783 empty.
69784 </ins></blockquote>
69785
69786 <p>
69787 Add to 25.3.13 [alg.partitions]:
69788 </p>
69789 <blockquote><ins>
69790 <i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
69791 </ins></blockquote>
69792
69793 <p>
69794 Add to 25.4.5.1 [includes]:
69795 </p>
69796 <blockquote><ins>
69797 <i>Remarks:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty. 
69798 </ins></blockquote>
69799
69800 <p>
69801 Revise p2 25.4.6.2 [pop.heap]
69802 </p>
69803 <blockquote>
69804 <i>Requires:</i> The range <tt>[first,last)</tt> shall be a valid
69805 <ins>non-empty</ins> heap.
69806 </blockquote>
69807
69808 <p>
69809 [Editorial] 
69810 </p>
69811 <blockquote>
69812 Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
69813 </blockquote>
69814
69815 <p>
69816 Add to p35 25.4.7 [alg.min.max]:
69817 </p>
69818 <blockquote><pre>template&lt;class ForwardIterator, class Compare&gt;
69819   pair&lt;ForwardIterator, ForwardIterator&gt;
69820     minmax_element(ForwardIterator first, ForwardIterator last, Compare comp);
69821 </pre>
69822 <blockquote>
69823 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is the first iterator in
69824 <tt>[first,last)</tt> such that no iterator in the range refers to a smaller
69825 element, and where <tt>M</tt> is the last iterator in <tt>[first,last)</tt> such that no
69826 iterator in the range refers to a larger element. 
69827 <ins>Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.</ins>
69828 </blockquote>
69829 </blockquote>
69830
69831 <p>
69832 Add to 25.4.8 [alg.lex.comparison]:
69833 </p>
69834 <blockquote><ins>
69835 <i>Remarks:</i> An empty sequence is lexicographically less than any other
69836 non-empty sequence, but not less than another empty sequence.
69837 </ins></blockquote>
69838
69839
69840
69841
69842
69843
69844 <hr>
69845 <h3><a name="1206"></a>1206. Incorrect requires for <tt>move_backward</tt> and <tt>copy_backward</tt></h3>
69846 <p><b>Section:</b> 25.3.2 [alg.move] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
69847  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-10-23</p>
69848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
69849 <p><b>Discussion:</b></p>
69850 <p>
69851 25.3.2 [alg.move], p6 says:
69852 </p>
69853
69854 <blockquote>
69855 <pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
69856   BidirectionalIterator2
69857     move_backward(BidirectionalIterator1 first,
69858                   BidirectionalIterator1 last,
69859                   BidirectionalIterator2 result);
69860 </pre>
69861 <blockquote>
69862 <p>...</p>
69863 <p>
69864 <i>Requires:</i> <tt>result</tt> shall not be in the range
69865 <tt>[first,last)</tt>.
69866 </p>
69867 </blockquote>
69868 </blockquote>
69869
69870 <p>
69871 This is essentially an "off-by-one" error.
69872 </p>
69873
69874 <p>
69875 When <tt>result == last</tt>, which
69876 <em>is</em> allowed by this specification, then the range <tt>[first, last)</tt>
69877 is being move assigned into the range <tt>[first, last)</tt>.  The <tt>move</tt>
69878 (forward) algorithm doesn't allow self move assignment, and neither should
69879 <tt>move_backward</tt>.  So <tt>last</tt> should be included in the range which
69880 <tt>result</tt> can not be in.
69881 </p>
69882
69883 <p>
69884 Conversely, when <tt>result == first</tt>, which <em>is not</em> allowed by this
69885 specification, then the range <tt>[first, last)</tt>
69886 is being move assigned into the range <tt>[first - (last-first), first)</tt>.
69887 I.e. into a <em>non-overlapping</em> range.  Therefore <tt>first</tt> should
69888 not be included in the range which <tt>result</tt> can not be in.
69889 </p>
69890
69891 <p>
69892 The same argument applies to <tt>copy_backward</tt> though copy assigning elements
69893 to themselves (<tt>result == last</tt>) should be harmless (though is disallowed
69894 by <tt>copy</tt>).
69895 </p>
69896
69897 <p><i>[
69898 2010 Pittsburgh:  Moved to Ready.
69899 ]</i></p>
69900
69901
69902
69903
69904 <p><b>Proposed resolution:</b></p>
69905 <p>
69906 Change 25.3.2 [alg.move], p6:
69907 </p>
69908
69909 <blockquote>
69910 <pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
69911   BidirectionalIterator2
69912     move_backward(BidirectionalIterator1 first,
69913                   BidirectionalIterator1 last,
69914                   BidirectionalIterator2 result);
69915 </pre>
69916 <blockquote>
69917 <p>...</p>
69918 <p>
69919 <i>Requires:</i> <tt>result</tt> shall not be in the range
69920 <tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
69921 </p>
69922 </blockquote>
69923 </blockquote>
69924
69925 <p>
69926 Change 25.3.1 [alg.copy], p13:
69927 </p>
69928
69929 <blockquote>
69930 <pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
69931   BidirectionalIterator2
69932     copy_backward(BidirectionalIterator1 first,
69933                   BidirectionalIterator1 last,
69934                   BidirectionalIterator2 result);
69935 </pre>
69936 <blockquote>
69937 <p>...</p>
69938 <p>
69939 <i>Requires:</i> <tt>result</tt> shall not be in the range
69940 <tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
69941 </p>
69942 </blockquote>
69943 </blockquote>
69944
69945
69946
69947
69948
69949 <hr>
69950 <h3><a name="1207"></a>1207. Underspecified std::list operations?</h3>
69951 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
69952  <b>Submitter:</b> Loïc Joly <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-11-24</p>
69953 <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>
69954 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
69955 <p><b>Discussion:</b></p>
69956 <p>
69957 It looks to me like some operations of <tt>std::list</tt>
69958 (<tt>sort</tt>, <tt>reverse</tt>, <tt>remove</tt>, <tt>unique</tt> &amp;
69959 <tt>merge</tt>) do not specify the validity of iterators, pointers &amp;
69960 references to elements of the list after those operations. Is it implied
69961 by some other text in the standard?
69962 </p>
69963
69964 <p>
69965 I believe <tt>sort</tt> &amp; <tt>reverse</tt> do not invalidating
69966 anything, <tt>remove</tt> &amp; <tt>unique</tt> only invalidates what
69967 refers to erased elements, <tt>merge</tt> does not invalidate anything
69968 (with the same precision as <tt>splice</tt> for elements who changed of
69969 container). Are those assumptions correct ?
69970 </p>
69971
69972 <p><i>[
69973 2009-12-08 Jonathan Wakely adds:
69974 ]</i></p>
69975
69976
69977 <blockquote>
69978 <p>
69979 23.2.1 [container.requirements.general] paragraph 11 says iterators
69980 aren't invalidated unless specified, so I don't think it needs to be repeated on
69981 every function that doesn't invalidate iterators. <tt>list::unique</tt> says it
69982 "eliminates" elements, that should probably be "erases" because IMHO that term
69983 is used elsewhere and so makes it clearer that iterators to the erased elements
69984 are invalidated.
69985 </p>
69986
69987 <p>
69988 <tt>list::merge</tt> coud use the same wording as <tt>list::splice</tt> w.r.t
69989 iterators and references to moved elements.
69990 </p>
69991
69992 <p>
69993 Suggested resolution:
69994 </p>
69995
69996 <p>
69997 In 23.3.4.4 [list.ops] change paragraph 19
69998 </p>
69999
70000 <blockquote><pre>                                 void unique();
70001 template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
70002 </pre>
70003 <blockquote>
70004 <i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
70005 element from every consecutive group ...
70006 </blockquote>
70007 </blockquote>
70008
70009 <p>
70010 Add to the end of paragraph 23
70011 </p>
70012
70013 <blockquote><pre>void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
70014 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
70015 </pre>
70016 <blockquote>
70017 <p>...</p>
70018 <p>
70019 <i>Effects:</i> ... that is, for every iterator <tt>i</tt>, in the range other
70020 than the first, the condition <tt>comp(*i, *(i - 1)</tt> will be false.
70021 <ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
70022 those same elements but as members of <tt>*this</tt>. Iterators referring to the
70023 moved elements will continue to refer to their elements, but they now behave as
70024 iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
70025 </p>
70026 </blockquote>
70027 </blockquote>
70028 </blockquote>
70029
70030 <p><i>[
70031 2009-12-12 Loïc adds wording.
70032 ]</i></p>
70033
70034
70035 <p><i>[
70036 2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70037 ]</i></p>
70038
70039
70040 <p><i>[
70041 2010-02-10 Alisdair opens:
70042 ]</i></p>
70043
70044
70045 <blockquote>
70046 <p>
70047 I object to the current resolution of #1207.  I believe it is overly strict with
70048 regard to <tt>list</tt> end iterators, being the only mutating operations to
70049 require such stability.
70050 </p>
70051
70052 <p>
70053 More importantly, the same edits need to be applied to <tt>forward_list</tt>,
70054 which uses slightly different words to describe some of these operations so may
70055 require subtly different edits (not checked.)
70056 </p>
70057
70058 <p>
70059 I am prepared to pick up the <tt>end()</tt> iterator as a separate (new) issue,
70060 as part of the FCD ballot review (BSI might tell me 'no' first ;~) but I do want
70061 to see <tt>forward_list</tt> adjusted at the same time.
70062 </p>
70063 </blockquote>
70064
70065 <p><i>[
70066 2010-03-28 Daniel adds the first 5 bullets in an attempt to address Alisdair's
70067 concerns.
70068 ]</i></p>
70069
70070
70071
70072 <p><i>[
70073 2010 Rapperswil:
70074 ]</i></p>
70075
70076
70077 <blockquote>
70078 The wording looks good.
70079
70080 Move to Tentatively Ready.
70081 </blockquote>
70082
70083 <p><i>[
70084 Adopted at 2010-11 Batavia
70085 ]</i></p>
70086
70087
70088
70089
70090 <p><b>Proposed resolution:</b></p>
70091
70092 <ol>
70093
70094 <li>
70095 <p>
70096 Change 23.3.3.5 [forwardlist.ops]/12 as indicated:
70097 </p>
70098
70099 <blockquote><pre>void remove(const T&amp; value);
70100 template &lt;class Predicate&gt; void remove_if(Predicate pred);
70101 </pre>
70102
70103 <blockquote>
70104 12 <i>Effects:</i> Erases all the elements in the list referred by a list
70105 iterator <tt>i</tt> for which the following conditions hold: <tt>*i == value
70106 (for remove()), pred(*i)</tt> is true (<tt>for remove_if()</tt>). This operation
70107 shall be stable: the relative order of the elements that are not removed is the
70108 same as their relative order in the original list. <ins>Invalidates only the
70109 iterators and references to the erased elements.</ins>
70110 </blockquote>
70111 </blockquote>
70112 </li>
70113
70114 <li>
70115 <p>
70116 Change 23.3.3.5 [forwardlist.ops]/15 as indicated:
70117 </p>
70118
70119 <blockquote><pre>template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate pred);
70120 </pre>
70121
70122 <blockquote>
70123 15 <i>Effects:</i>: <del>Eliminates</del><ins>Erases</ins> all but the first
70124 element from every consecutive group of equal elements referred to by the
70125 iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
70126 *(i-1)</tt> (for the version with no arguments) or <tt>pred(*i, *(i - 1))</tt>
70127 (for the version with a predicate argument) holds. <ins>Invalidates only the
70128 iterators and references to the erased elements.</ins>
70129 </blockquote>
70130 </blockquote>
70131 </li>
70132
70133 <li>
70134 <p>
70135 Change 23.3.3.5 [forwardlist.ops]/19 as indicated:
70136 </p>
70137
70138 <blockquote><pre>void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
70139 template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp)
70140 </pre>
70141
70142 <blockquote>
70143 <p>
70144 [..]
70145 </p>
70146
70147 <p>
70148 19 <i>Effects:</i>: Merges <tt>x</tt> into <tt>*this</tt>. This operation shall
70149 be stable: for equivalent elements in the two lists, the elements from
70150 <tt>*this</tt> shall always precede the elements from <tt>x</tt>. <tt>x</tt> is
70151 empty after the merge. If an exception is thrown other than by a comparison
70152 there are no effects. <ins>Pointers and references to the moved elements of
70153 <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
70154 Iterators referring to the moved elements will continue to refer to their
70155 elements, but they now behave as iterators into <tt>*this</tt>, not into
70156 <tt>x</tt>.</ins>
70157 </p>
70158 </blockquote>
70159 </blockquote>
70160 </li>
70161
70162 <li>
70163 <p>
70164 Change 23.3.3.5 [forwardlist.ops]/22 as indicated:
70165 </p>
70166
70167 <blockquote><pre>void sort();
70168 template &lt;class Compare&gt; void sort(Compare comp);
70169 </pre>
70170
70171 <blockquote>
70172 <p>
70173 [..]
70174 </p>
70175
70176 <p>
70177 22 <i>Effects:</i>: Sorts the list according to the <tt>operator&lt;</tt> or the
70178 <tt>comp</tt> function object. This operation shall be stable: the relative
70179 order of the equivalent elements is preserved. If an exception is thrown the
70180 order of the elements in <tt>*this</tt> is unspecified. <ins>Does not affect the
70181 validity of iterators and references.</ins>
70182 </p>
70183 </blockquote>
70184 </blockquote>
70185 </li>
70186
70187 <li>
70188 <p>
70189 Change 23.3.3.5 [forwardlist.ops]/24 as indicated:
70190 </p>
70191
70192 <blockquote><pre>void reverse();
70193 </pre>
70194
70195 <blockquote>
70196 24 <i>Effects:</i>: Reverses the order of the elements in the list. <ins>Does
70197 not affect the validity of iterators and references.</ins>
70198 </blockquote>
70199 </blockquote>
70200 </li>
70201
70202 <li>
70203 <p>
70204 Change 23.3.4.4 [list.ops], p15:
70205 </p>
70206
70207 <blockquote><pre>                           void remove(const T&amp; value);
70208 template &lt;class Predicate&gt; void remove_if(Predicate pred);
70209 </pre>
70210 <blockquote>
70211 <i>Effects:</i> Erases all the elements in the list referred by a list iterator
70212 <tt>i</tt> for which the following conditions hold: <tt>*i == value, pred(*i) !=
70213 false</tt>.  <ins>Invalidates only the iterators and references to the erased
70214 elements.</ins>
70215 </blockquote>
70216 </blockquote>
70217 </li>
70218
70219 <li>
70220 <p>
70221 Change 23.3.4.4 [list.ops], p19:
70222 </p>
70223
70224 <blockquote><pre>                                 void unique();
70225 template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
70226 </pre>
70227 <blockquote>
70228 <i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
70229 element from every consecutive group of equal elements referred to by the
70230 iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
70231 *(i-1)</tt> (for the version of <tt>unique</tt> with no arguments) or
70232 <tt>pred(*i, *(i - 1))</tt> (for the version of <tt>unique</tt> with a predicate
70233 argument) holds. <ins>Invalidates only the iterators and references to the
70234 erased elements.</ins>
70235 </blockquote>
70236 </blockquote>
70237 </li>
70238
70239 <li>
70240 <p>
70241 Change 23.3.4.4 [list.ops], p23:
70242 </p>
70243
70244 <blockquote><pre>void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
70245 template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
70246 </pre>
70247 <blockquote>
70248 <i>Effects:</i> If <tt>(&amp;x == this)</tt> does nothing; otherwise, merges the
70249 two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
70250 The result is a range in which the elements will be sorted in non-decreasing
70251 order according to the ordering defined by <tt>comp</tt>; that is, for every
70252 iterator <tt>i</tt>, in the range other than the first, the condition
70253 <tt>comp(*i, *(i - 1)</tt> will be false.
70254 <ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
70255 those same elements but as members of <tt>*this</tt>. Iterators referring to the
70256 moved elements will continue to refer to their elements, but they now behave as
70257 iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
70258 </blockquote>
70259 </blockquote>
70260 </li>
70261
70262 <li>
70263 <p>
70264 Change 23.3.4.4 [list.ops], p26:
70265 </p>
70266
70267 <blockquote><pre>void reverse();
70268 </pre>
70269 <blockquote>
70270 <i>Effects:</i> Reverses the order of the elements in the list.
70271 <ins>Does not affect the validity of iterators and references.</ins>
70272 </blockquote>
70273 </blockquote>
70274 </li>
70275
70276 <li>
70277 <p>
70278 Change 23.3.4.4 [list.ops], p30:
70279 </p>
70280
70281 <blockquote><pre>                         void sort();
70282 template &lt;class Compare&gt; void sort(Compare comp);
70283 </pre>
70284 <blockquote>
70285 <i>Effects:</i> Sorts the list according to the <tt>operator&lt;</tt> or a
70286 <tt>Compare</tt> function object.
70287 <ins>Does not affect the validity of iterators and references.</ins>
70288 </blockquote>
70289 </blockquote>
70290 </li>
70291
70292 </ol>
70293
70294
70295
70296
70297
70298
70299 <hr>
70300 <h3><a name="1208"></a>1208. valarray initializer_list constructor has incorrect effects</h3>
70301 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70302  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-23 <b>Last modified:</b> 2010-10-23</p>
70303 <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>
70304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70305 <p><b>Discussion:</b></p>
70306 <p>
70307 26.6.2.1 [valarray.cons] says:
70308 </p>
70309
70310 <blockquote>
70311 <pre>valarray(initializer_list&lt;T&gt; il);
70312 </pre>
70313 <blockquote>
70314 <i>Effects:</i> Same as <tt>valarray(il.begin(), il.end())</tt>.
70315 </blockquote>
70316 </blockquote>
70317
70318 <p>
70319 But there is no <tt>valarray</tt> constructor taking two <tt>const T*</tt>.
70320 </p>
70321
70322 <p><i>[
70323 2009-10-29 Howard:
70324 ]</i></p>
70325
70326
70327 <blockquote>
70328 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
70329 </blockquote>
70330
70331
70332 <p><b>Proposed resolution:</b></p>
70333 <p>
70334 Change 26.6.2.1 [valarray.cons]:
70335 </p>
70336
70337 <blockquote>
70338 <pre>valarray(initializer_list&lt;T&gt; il);
70339 </pre>
70340 <blockquote>
70341 <i>Effects:</i> Same as <tt>valarray(il.begin(), il.<del>end</del><ins>size</ins>())</tt>.
70342 </blockquote>
70343 </blockquote>
70344
70345
70346
70347
70348
70349 <hr>
70350 <h3><a name="1209"></a>1209. match_results should be moveable</h3>
70351 <p><b>Section:</b> 28.10.1 [re.results.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70352  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-09-15 <b>Last modified:</b> 2010-10-23</p>
70353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70354 <p><b>Discussion:</b></p>
70355 <p>
70356 In Working Draft
70357 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
70358 <tt>match_results</tt> lacks a move constructor and move
70359 assignment operator. Because it owns dynamically allocated memory, it
70360 should be moveable.
70361 </p>
70362
70363 <p>
70364 As far as I can tell, this isn't tracked by an active issue yet; Library
70365 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a> doesn't talk about <tt>match_results</tt>.
70366 </p>
70367
70368 <p><i>[
70369 2009-09-21 Daniel provided wording.
70370 ]</i></p>
70371
70372
70373 <p><i>[
70374 2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70375 ]</i></p>
70376
70377
70378
70379 <p><b>Proposed resolution:</b></p>
70380 <ol>
70381 <li>
70382 <p>
70383 Add the following member declarations to 28.10 [re.results]/3:
70384 </p>
70385
70386 <blockquote><pre>// 28.10.1, construct/copy/destroy:
70387 explicit match_results(const Allocator&amp; a = Allocator());
70388 match_results(const match_results&amp; m);
70389 <ins>match_results(match_results&amp;&amp; m);</ins>
70390 match_results&amp; operator=(const match_results&amp; m);
70391 <ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
70392 ~match_results();
70393 </pre></blockquote>
70394 </li>
70395
70396 <li>
70397 <p>
70398 Add the following new prototype descriptions to 28.10.1 [re.results.const]
70399 using the table numbering of
70400 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
70401 (referring to the table titled "<tt>match_results</tt> assignment operator effects"):
70402 </p>
70403
70404 <blockquote>
70405 <pre>match_results(const match_results&amp; m);
70406 </pre>
70407
70408 <blockquote>
70409 4 <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a
70410 copy of <tt>m</tt>.
70411 </blockquote>
70412
70413 <pre><ins>match_results(match_results&amp;&amp; m);</ins>
70414 </pre>
70415
70416 <blockquote>
70417 <p>
70418 <ins>5 <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt>
70419 from <tt>m</tt> satisfying the same postconditions as Table 131. Additionally
70420 the stored <tt>Allocator</tt> value is move constructed from <tt>m.get_allocator()</tt>.
70421 After the initialization of <tt>*this</tt> sets <tt>m</tt> to an unspecified but valid
70422 state.</ins>
70423 </p>
70424
70425 <p>
70426 <ins>6 <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</ins>
70427 </p>
70428 </blockquote>
70429
70430 <pre>match_results&amp; operator=(const match_results&amp; m);
70431 </pre>
70432
70433 <blockquote>
70434 7 <i>Effects:</i> Assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this function are
70435 indicated in Table 131.
70436 </blockquote>
70437
70438 <pre><ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
70439 </pre>
70440
70441 <blockquote>
70442 <p>
70443 <ins>8 <i>Effects:</i> Move-assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this
70444 function are indicated in Table 131. After the assignment, <tt>m</tt> is in
70445 a valid but unspecified state.</ins>
70446 </p>
70447
70448 <p>
70449 <ins>9 <i>Throws:</i> Nothing.</ins>
70450 </p>
70451 </blockquote>
70452 </blockquote>
70453 </li>
70454
70455 </ol>
70456
70457
70458
70459
70460
70461 <hr>
70462 <h3><a name="1216"></a>1216. LWG 1066 Incomplete?</h3>
70463 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70464  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-09-25 <b>Last modified:</b> 2010-10-23</p>
70465 <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>
70466 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70467 <p><b>Discussion:</b></p>
70468 <p>
70469 LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a> adds <tt>[[noreturn]]</tt> to a bunch of things.
70470 It doesn't add it to <tt>rethrow_nested()</tt>, which seems like an obvious
70471 candidate. I've made the changes indicated in the issue, and haven't
70472 changed <tt>rethrow_nested()</tt>.
70473 </p>
70474
70475 <p><i>[
70476 2009 Santa Cruz:
70477 ]</i></p>
70478
70479
70480 <blockquote>
70481 Move to Ready.
70482 </blockquote>
70483
70484
70485
70486 <p><b>Proposed resolution:</b></p>
70487 <p>
70488 Add <tt>[[noreturn]]</tt> to <tt>rethrow_nested()</tt> in 18.8.6 [except.nested].
70489 </p>
70490
70491
70492
70493
70494
70495 <hr>
70496 <h3><a name="1218"></a>1218. mutex destructor synchronization</h3>
70497 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70498  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
70499 <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>
70500 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70501 <p><b>Discussion:</b></p>
70502 <p>
70503 If an object <tt>*o</tt> contains a mutex <tt>mu</tt> and a
70504 correctly-maintained reference count <tt>c</tt>, is the following code
70505 safe?
70506 </p>
70507
70508 <blockquote><pre>o-&gt;mu.lock();
70509 bool del = (--(o-&gt;c) == 0);
70510 o-&gt;mu.unlock();
70511 if (del) { delete o; }
70512 </pre></blockquote>
70513
70514 <p>
70515 If the implementation of <tt>mutex::unlock()</tt> can touch the mutex's
70516 memory after the moment it becomes free, this wouldn't be safe, and
70517 "Construction and destruction of an object of a Mutex type need not be
70518 thread-safe" 30.4.1 [thread.mutex.requirements] may imply that
70519 it's not safe. Still, it's useful to allow mutexes to guard reference
70520 counts, and if it's not allowed, users are likely to write bugs.
70521 </p>
70522
70523 <p><i>[
70524 2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70525 ]</i></p>
70526
70527
70528
70529 <p><b>Proposed resolution:</b></p>
70530 <ul>
70531 <li>
70532 <p>
70533 Add a new paragraph after 30.4.1.2.1 [thread.mutex.class] p1:
70534 </p>
70535 <blockquote>
70536 <p>
70537 1 The class <tt>mutex</tt> provides a non-recursive mutex ...
70538 </p>
70539 <p><ins>
70540 [<i>Note:</i> After a thread <tt>A</tt> has called <tt>unlock()</tt>, releasing
70541 the mutex, it is possible for another thread <tt>B</tt> to lock the same mutex,
70542 observe that it is no longer in use, unlock and destroy it, before thread
70543 <tt>A</tt> appears to have returned from its unlock call. Implementations are
70544 required to handle such scenarios correctly, as long as thread <tt>A</tt>
70545 doesn't access the mutex after the unlock call returns. These cases typically
70546 occur when a reference-counted object contains a mutex that is used to protect
70547 the reference count. \97 <i>end note</i>]
70548 </ins></p>
70549 </blockquote>
70550 </li>
70551
70552 </ul>
70553
70554
70555
70556
70557
70558 <hr>
70559 <h3><a name="1220"></a>1220. What does condition_variable wait on?</h3>
70560 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70561  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
70562 <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>
70563 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70564 <p><b>Discussion:</b></p>
70565 <p>
70566 "Class <tt>condition_variable</tt> provides a condition variable that can only
70567 wait on an object of type <tt>unique_lock</tt>" should say "...object of type
70568 <tt>unique_lock&lt;mutex&gt;</tt>"
70569 </p>
70570
70571 <p><i>[
70572 2009-11-06 Howard adds:
70573 ]</i></p>
70574
70575
70576 <blockquote>
70577 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70578 </blockquote>
70579
70580
70581
70582 <p><b>Proposed resolution:</b></p>
70583 <p>
70584 Change 30.5 [thread.condition], p1:
70585 </p>
70586
70587 <blockquote>
70588 Condition variables provide synchronization primitives used to block a
70589 thread until notified by some other thread that some condition is met or
70590 until a system time is reached. Class <tt>condition_variable</tt>
70591 provides a condition variable that can only wait on an object of type
70592 <tt>unique_lock<ins>&lt;mutex&gt;</ins></tt>, allowing maximum
70593 efficiency on some platforms. Class <tt>condition_variable_any</tt>
70594 provides a general condition variable that can wait on objects of
70595 user-supplied lock types.
70596 </blockquote>
70597
70598
70599
70600
70601
70602 <hr>
70603 <h3><a name="1221"></a>1221. condition_variable wording</h3>
70604 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70605  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
70606 <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>
70607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70608 <p><b>Discussion:</b></p>
70609 <p>
70610 30.5.1 [thread.condition.condvar] says:
70611 </p>
70612
70613 <blockquote>
70614 <pre>~condition_variable();
70615 </pre>
70616 <blockquote>
70617 <i>Precondition:</i> There shall be no thread blocked on <tt>*this</tt>.
70618 [<i>Note:</i> That is, all threads shall have been notified; they may
70619 subsequently block on the lock specified in the wait. Beware that
70620 destroying a <tt>condition_variable</tt> object while the corresponding
70621 predicate is <tt>false</tt> is likely to lead to undefined behavior.
70622 \97 <i>end note</i>]
70623 </blockquote>
70624 </blockquote>
70625
70626 <p>
70627 The text hasn't introduced the notion of a "corresponding predicate"
70628 yet.
70629 </p>
70630
70631 <p><i>[
70632 2010-02-11 Anthony provided wording.
70633 ]</i></p>
70634
70635
70636 <p><i>[
70637 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70638 ]</i></p>
70639
70640
70641
70642
70643 <p><b>Proposed resolution:</b></p>
70644 <p>
70645 Modify 30.5.1 [thread.condition.condvar]p4 as follows:
70646 </p>
70647
70648 <blockquote>
70649 <pre>~condition_variable();</pre>
70650 <blockquote>
70651 4 <i>Precondition:</i> There shall be no thread blocked on <tt>*this</tt>.
70652 [<i>Note:</i> That is, all threads shall have been notified; they may
70653 subsequently block on the lock specified in the wait. <del>Beware that
70654 destroying a <tt>condition_variable</tt> object while the corresponding
70655 predicate is false is likely to lead to undefined behavior.</del> <ins>The user
70656 must take care to ensure that no threads wait on <tt>*this</tt> once the
70657 destructor has been started, especially when the waiting threads are calling the
70658 wait functions in a loop or using the overloads of <tt>wait</tt>,
70659 <tt>wait_for</tt> or <tt>wait_until</tt> that take a predicate.</ins> \97
70660 <i>end note</i>]
70661 </blockquote>
70662 </blockquote>
70663
70664
70665
70666
70667
70668 <hr>
70669 <h3><a name="1222"></a>1222. condition_variable incorrect effects for exception safety</h3>
70670 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70671  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
70672 <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>
70673 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70674 <p><b>Discussion:</b></p>
70675 <p>
70676 30.5.1 [thread.condition.condvar] says:
70677 </p>
70678
70679 <blockquote>
70680 <pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
70681 </pre>
70682 <blockquote>
70683 <p>...</p>
70684 <p>
70685 <i>Effects:</i>
70686 </p>
70687 <ul>
70688 <li>...</li>
70689 <li>
70690 If the function exits via an exception, <tt>lock.unlock()</tt> shall be
70691 called prior to exiting the function scope.
70692 </li>
70693 </ul>
70694 </blockquote>
70695 </blockquote>
70696
70697 <p>
70698 Should that be <tt>lock.lock()</tt>?
70699 </p>
70700
70701 <p><i>[
70702 2009-11-17 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70703 ]</i></p>
70704
70705
70706
70707 <p><b>Proposed resolution:</b></p>
70708
70709 <p>
70710 Change 30.5.1 [thread.condition.condvar] p10:
70711 </p>
70712
70713 <blockquote>
70714 <pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
70715 </pre>
70716 <blockquote>
70717 <p>...</p>
70718 <p>
70719 <i>Effects:</i>
70720 </p>
70721 <ul>
70722 <li>...</li>
70723 <li>
70724 If the function exits via an exception, <tt>lock.<del>un</del>lock()</tt> shall be
70725 called prior to exiting the function scope.
70726 </li>
70727 </ul>
70728 </blockquote>
70729 </blockquote>
70730
70731 <p>
70732 And make a similar change in p16, and in 30.5.2 [thread.condition.condvarany],
70733 p8 and p13.
70734 </p>
70735
70736
70737
70738
70739
70740
70741 <hr>
70742 <h3><a name="1227"></a>1227. <tt>&lt;bitset&gt;</tt> synopsis overspecified</h3>
70743 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70744  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-10-05 <b>Last modified:</b> 2010-10-23</p>
70745 <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>
70746 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70747 <p><b>Discussion:</b></p>
70748 <p>
70749 The resolutions to some library defect reports, like <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>
70750 requires that <tt>#includes</tt> in each synopsis should be taken
70751 literally. This means that the <tt>&lt;bitset&gt;</tt> header now
70752 <em>must</em> include <tt>&lt;stdexcept&gt;</tt>, even though none of the
70753 exceptions are mentioned in the <tt>&lt;bitset&gt;</tt> header.
70754 </p>
70755 <p>
70756 Many other classes are required to throw exceptions like
70757 <tt>invalid_argument</tt> and <tt>out_of_range</tt>, without explicitly
70758 including <tt>&lt;stdexcept&gt;</tt> in their synopsis. It is totally
70759 possible for implementations to throw the needed exceptions from utility
70760 functions, whose implementations are not visible in the headers.
70761 </p>
70762 <p>
70763 I propose that <tt>&lt;stdexcept&gt;</tt> is removed from the
70764 <tt>&lt;bitset&gt;</tt> header.
70765 </p>
70766
70767 <p><i>[
70768 2009-10 Santa Cruz:
70769 ]</i></p>
70770
70771
70772 <blockquote>
70773 Moved to Ready.
70774 </blockquote>
70775
70776
70777
70778 <p><b>Proposed resolution:</b></p>
70779 <p>
70780 Change 20.5 [template.bitset]:
70781 </p>
70782
70783 <blockquote><pre>#include &lt;cstddef&gt;        // for size_t
70784 #include &lt;string&gt;
70785 <del>#include &lt;stdexcept&gt;      // for invalid_argument,</del>
70786                           <del>// out_of_range, overflow_error</del>
70787 #include &lt;iosfwd&gt;         // for istream, ostream
70788 namespace std {
70789 ...
70790 </pre></blockquote>
70791
70792
70793
70794
70795
70796 <hr>
70797 <h3><a name="1231"></a>1231. <tt>weak_ptr</tt> comparisons incompletely resolved</h3>
70798 <p><b>Section:</b> 20.9.10.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70799  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-10 <b>Last modified:</b> 2010-10-23</p>
70800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70801 <p><b>Discussion:</b></p>
70802 <p>
70803 The
70804 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
70805 paper suggested several updates of the ordering semantics of
70806 <tt>shared_ptr</tt>
70807 and <tt>weak_ptr</tt>, among those the explicit comparison operators of <tt>weak_ptr</tt> were
70808 removed/deleted, instead a corresponding functor <tt>owner_less</tt> was added.
70809 The problem
70810 is that
70811 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
70812 did not clearly enough specify, how the previous wording
70813 parts describing
70814 the comparison semantics of <tt>weak_ptr</tt> should be removed.
70815 </p>
70816
70817 <p><i>[
70818 2009-11-06 Howard adds:
70819 ]</i></p>
70820
70821
70822 <blockquote>
70823 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
70824 </blockquote>
70825
70826
70827
70828 <p><b>Proposed resolution:</b></p>
70829 <ol>
70830 <li>
70831 <p>
70832 Change 20.9.10.3 [util.smartptr.weak]/2 as described, the intention is to fix
70833 the now no longer valid
70834 requirement that <tt>weak_ptr</tt> is <tt>LessComparable</tt> [Note the deleted comma]:
70835 </p>
70836
70837 <blockquote>
70838 Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt><del>,</del>
70839 <ins>and</ins> <tt>CopyAssignable</tt>,
70840 <del>and <tt>LessThanComparable</tt>,</del> allowing their use in standard containers.
70841 </blockquote>
70842 </li>
70843
70844 <li>
70845 <p>
70846 In 20.9.10.3.5 [util.smartptr.weak.obs] remove the paragraphs 9-11 including prototype:
70847 </p>
70848
70849 <blockquote>
70850 <del>template&lt;class T, class U&gt; bool operator&lt;(const weak_ptr&lt;T&gt;&amp; a, const weak_ptr&lt;U&gt;&amp; b);</del>
70851
70852 <p>
70853 <del><i>Returns:</i> an unspecified value such that</del>
70854 </p>
70855 <ul>
70856 <li>
70857 <del><tt>operator&lt;</tt> is a strict weak ordering as described in 25.4;</del>
70858 </li>
70859 <li>
70860 <del>under the equivalence relation defined by <tt>operator&lt;</tt>, <tt>!(a
70861 &lt; b) &amp;&amp; !(b &lt; a)</tt>, two <tt>weak_ptr</tt> instances are
70862 equivalent if and only if they share ownership or are both empty.</del>
70863 </li>
70864 </ul>
70865
70866 <p>
70867 <del><i>Throws:</i> nothing.</del>
70868 </p>
70869
70870 <p>
70871 <del>[<i>Note:</i> Allows <tt>weak_ptr</tt> objects to be used as keys in associative
70872 containers. \97 <i>end note</i>]</del>
70873 </p>
70874 </blockquote>
70875 </li>
70876 </ol>
70877
70878
70879
70880
70881
70882 <hr>
70883 <h3><a name="1234"></a>1234. "Do the right thing" and NULL</h3>
70884 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
70885  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-10-09 <b>Last modified:</b> 2010-11-24</p>
70886 <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>
70887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
70888 <p><b>Discussion:</b></p>
70889 <p>
70890 On g++ 4.2.4 (x86_64-linux-gnu), the following file gives a compile
70891 error:
70892 </p>
70893
70894 <blockquote><pre>#include &lt;vector&gt;
70895 void foo() { std::vector&lt;int*&gt; v(500l, NULL); }
70896 </pre></blockquote>
70897
70898 <p>
70899 Is this supposed to work? 
70900 </p>
70901
70902 <p>
70903 The issue: if <tt>NULL</tt> happens to be defined as <tt>0l</tt>, this is an invocation of
70904 the constructor with two arguments of the same integral type.
70905 23.2.3 [sequence.reqmts]/14
70906 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>)
70907 says that this will behave as if the the
70908 overloaded constructor
70909 </p>
70910
70911 <blockquote><pre>X(size_type, const value_type&amp; = value_type(),
70912   const allocator_type&amp; = allocator_type())
70913 </pre></blockquote>
70914
70915 <p>
70916 were called instead, with the arguments
70917 <tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and
70918 <tt>alloc</tt>, respectively. However, it does not say whether this
70919 actually means invoking that constructor with the exact textual form of
70920 the arguments as supplied by the user, or whether the standard permits
70921 an implementation to invoke that constructor with variables of the same
70922 type and value as what the user passed in. In most cases this is a
70923 distinction without a difference. In this particular case it does make a
70924 difference, since one of those things is a null pointer constant and the
70925 other is not.
70926 </p>
70927
70928 <p>
70929 Note that an implementation based on forwarding functions will use the
70930 latter interpretation.
70931 </p>
70932
70933 <p><i>[
70934 2010 Pittsburgh:  Moved to Open.
70935 ]</i></p>
70936
70937
70938 <p><i>[
70939 2010-03-19 Daniel provides wording.
70940 ]</i></p>
70941
70942
70943 <blockquote>
70944 <ul>
70945 <li>
70946 Adapts the numbering used in the discussion to the recent working paper
70947 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>.
70948 </li>
70949
70950 <li>
70951 Proposes a resolution that requires implementations to use sfinae-like means to
70952 possibly filter away the too generic template c'tor. In fact this resolution is
70953 equivalent to that used for the <tt>pair-NULL</tt> problem (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>),
70954 the only difference is, that issue 1234 was already a C++03 problem.
70955 </li>
70956 </ul>
70957
70958 <p>
70959 This issue can be considered as a refinement of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>.
70960 </p>
70961
70962 </blockquote>
70963
70964 <p><i>[
70965 Post-Rapperswil
70966 ]</i></p>
70967
70968
70969 <p>
70970 Wording was verified to match with the most recent WP. Jonathan Wakely and Alberto Barbati observed that the current 
70971 WP has a defect that should be fixed here as well: The functions signatures <tt>fx1</tt> and <tt>fx3</tt> are 
70972 incorrectly referring to <tt>iterator</tt> instead of <tt>const_iterator</tt>.
70973 </p>
70974
70975 <blockquote>
70976 Moved to Tentatively Ready with revised wording after 7 positive votes on c++std-lib.
70977 </blockquote>
70978
70979 <p><i>[
70980 Adopted at 2010-11 Batavia
70981 ]</i></p>
70982
70983
70984
70985
70986 <p><b>Proposed resolution:</b></p>
70987
70988  
70989 <p>
70990 Change 23.2.3 [sequence.reqmts]/14+15 as indicated:
70991 </p>
70992
70993 <blockquote>
70994 <p>
70995 14 For every sequence container defined in this Clause and in Clause 21:
70996 </p>
70997
70998 <ul>
70999 <li>
71000 <p>
71001 If the constructor
71002 </p>
71003
71004 <blockquote><pre>template &lt;class InputIterator&gt;
71005 X(InputIterator first, InputIterator last,
71006   const allocator_type&amp; alloc = allocator_type())
71007
71008 </pre></blockquote>
71009
71010 <p>
71011 is called with a type <tt>InputIterator</tt> that does not qualify as an input
71012 iterator, then the constructor <ins>shall not participate in overload
71013 resolution.</ins><del>will
71014 behave as if the overloaded constructor:</del>
71015 </p>
71016
71017 <blockquote><pre><del>
71018 X(size_type, const value_type&amp; = value_type(),
71019   const allocator_type&amp; = allocator_type())
71020 </del></pre></blockquote>
71021
71022 <p>
71023 <del>were called instead, with the arguments
71024 <tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and <tt>alloc</tt>,
71025 respectively</del>.
71026 </p>
71027 </li>
71028
71029 <li>
71030
71031 <p>
71032 If the member functions of the forms:
71033 </p>
71034
71035 <blockquote><pre>template &lt;class InputIterator&gt; <i>// such as insert()</i>
71036 rt fx1(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
71037
71038 template &lt;class InputIterator&gt; <i>// such as append(), assign()</i>
71039 rt fx2(InputIterator first, InputIterator last);
71040
71041 template &lt;class InputIterator&gt; <i>// such as replace()</i>
71042 rt fx3(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, InputIterator first, InputIterator last);
71043 </pre></blockquote>
71044
71045 <p>
71046 are called with a type <tt>InputIterator</tt> that does not qualify as an input
71047 iterator, then these functions <ins>shall not participate in overload
71048 resolution.</ins><del>will behave as if the overloaded member functions:</del>
71049 </p>
71050
71051 <blockquote><pre><del>rt fx1(iterator, size_type, const value_type&amp;);</del>
71052
71053 <del>rt fx2(size_type, const value_type&amp;);</del>
71054
71055 <del>rt fx3(iterator, iterator, size_type, const value_type&amp;);</del>
71056 </pre></blockquote>
71057
71058 <p>
71059 <del>were called instead, with the same arguments.</del>
71060 </p>
71061 </li>
71062
71063 </ul>
71064
71065 <p><del>
71066 15 In the previous paragraph the alternative binding will fail if <tt>first</tt>
71067 is not implicitly convertible to <tt>X::size_type</tt> or if <tt>last</tt> is
71068 not implicitly convertible to <tt>X::value_type</tt>.
71069 </del></p>
71070 </blockquote>
71071
71072
71073
71074
71075
71076
71077 <hr>
71078 <h3><a name="1237"></a>1237. Constrained error_code/error_condition members</h3>
71079 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71080  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-14 <b>Last modified:</b> 2010-10-23</p>
71081 <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>
71082 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71083 <p><b>Discussion:</b></p>
71084 <p>
71085 I'm just reflecting on the now SFINAE-constrained constructors
71086 and assignment operators of <tt>error_code</tt> and <tt>error_condition</tt>:
71087 </p>
71088 <p>
71089 These are the <em>only</em> library components that are pro-actively
71090 announcing that they are using <tt>std::enable_if</tt> as constraining tool,
71091 which has IMO several disadvantages:
71092 </p>
71093
71094 <ol>
71095 <li>
71096 <p>
71097 With the availability of template default arguments and
71098 decltype, using <tt>enable_if</tt> in C++0x standard library, seems
71099 unnecessary restricting implementation freedom. E.g. there
71100 should be not need for a useless specification of a dummy
71101 default function argument, which only confuses the reader.
71102 A more reasonable implementation could e.g. be
71103 </p>
71104
71105 <blockquote><pre>template &lt;class ErrorCodeEnum
71106  class = typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type&gt;
71107 error_code(ErrorCodeEnum e);
71108 </pre></blockquote>
71109
71110 <p>
71111 As currently specified, the function signatures are so unreadable,
71112 that errors quite easily happen, see e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>.
71113 </p>
71114 </li>
71115
71116 <li>
71117 <p>
71118 We have a <em>lot</em> of constrained functions in other places, that
71119 now have a standard phrase that is easily understandable:
71120 </p>
71121
71122 <blockquote>
71123 <i>Remarks:</i> This constructor/function shall participate in overload
71124 resolution if and only if X.
71125 </blockquote>
71126
71127 <p>
71128 where X describes the condition. Why should these components deviate?
71129 </p>
71130 </li>
71131
71132 <li>
71133 <p>
71134 If <tt>enable_if</tt> would <em>not</em> be explicitly specified, the standard library
71135 is much better prepared for the future. It would also be possible, that
71136 libraries with partial support for not-yet-standard-concepts could provide
71137 a much better diagnostic as is possible with <tt>enable_if</tt>. This again
71138 would allow for experimental concept implementations in the wild,
71139 which as a result would make concept standardization a much more
71140 natural thing, similar to the way as templates were standardized
71141 in C++.
71142 </p>
71143
71144 <p>
71145 In summary: I consider it as a library defect that <tt>error_code</tt> and
71146 <tt>error_condition</tt> explicitly require a dependency to <tt>enable_if</tt> and
71147 do limit implementation freedom and I volunteer to prepare a
71148 corresponding resolution.
71149 </p>
71150 </li>
71151 </ol>
71152
71153 <p><i>[
71154 2009-10-18 Beman adds:
71155 ]</i></p>
71156
71157
71158 <blockquote>
71159 I support this proposed resolution, and thank Daniel for writing it up.
71160 </blockquote>
71161
71162 <p><i>[
71163 2009-10 Santa Cruz:
71164 ]</i></p>
71165
71166
71167 <blockquote>
71168 Moved to Ready.
71169 </blockquote>
71170
71171
71172
71173 <p><b>Proposed resolution:</b></p>
71174 <p><i>[
71175 Should this resolution be accepted, I recommend to resolve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a> as NAD
71176 ]</i></p>
71177
71178
71179 <ol>
71180 <li>
71181 <p>
71182 In 19.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt>,
71183 change as indicated:
71184 </p>
71185
71186 <blockquote><pre>// 19.5.2.2 constructors:
71187 error_code();
71188 error_code(int val, const error_category&amp; cat);
71189 template &lt;class ErrorCodeEnum&gt;
71190   error_code(ErrorCodeEnum e<del>,
71191     typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);
71192
71193 // 19.5.2.3 modifiers:
71194 void assign(int val, const error_category&amp; cat);
71195 template &lt;class ErrorCodeEnum&gt;
71196   <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
71197     operator=(ErrorCodeEnum e);
71198 void clear();
71199 </pre></blockquote>
71200 </li>
71201
71202 <li>
71203 <p>
71204 Change 19.5.2.2 [syserr.errcode.constructors] around the prototype before p. 7:
71205 </p>
71206
71207 <blockquote><pre>template &lt;class ErrorCodeEnum&gt;
71208 error_code(ErrorCodeEnum e<del>,
71209   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);
71210 </pre>
71211 <blockquote>
71212 <p>
71213 <ins><i>Remarks:</i> This constructor shall not participate in overload
71214 resolution, unless
71215 <tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
71216 </p>
71217 </blockquote>
71218 </blockquote>
71219 </li>
71220
71221 <li>
71222 <p>
71223 Change 19.5.2.3 [syserr.errcode.modifiers] around the prototype before p. 3:
71224 </p>
71225
71226 <blockquote><pre>template &lt;class ErrorCodeEnum&gt;
71227   <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
71228     operator=(ErrorCodeEnum e);
71229 </pre>
71230
71231 <blockquote>
71232 <ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
71233 <tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
71234 </blockquote>
71235 </blockquote>
71236 </li>
71237
71238 <li>
71239 <p>
71240 In 19.5.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>, change
71241 as indicated:
71242 </p>
71243
71244 <blockquote><pre>// 19.5.3.2 constructors:
71245 error_condition();
71246 error_condition(int val, const error_category&amp; cat);
71247 template &lt;class ErrorConditionEnum&gt;
71248   error_condition(ErrorConditionEnum e<del>,
71249     typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::type* = 0</del>);
71250
71251 // 19.5.3.3 modifiers:
71252 void assign(int val, const error_category&amp; cat);
71253 template&lt;<del>typename</del><ins>class</ins> ErrorConditionEnum&gt;
71254   <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;, error_code&gt;::type</del><ins>error_condition</ins> &amp;
71255     operator=( ErrorConditionEnum e );
71256 void clear();
71257 </pre></blockquote>
71258 </li>
71259
71260 <li>
71261 <p>
71262 Change 19.5.3.2 [syserr.errcondition.constructors] around the
71263 prototype before p. 7:
71264 </p>
71265
71266 <blockquote><pre>template &lt;class ErrorConditionEnum&gt;
71267   error_condition(ErrorConditionEnum e<del>,
71268     typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type* = 0</del>);
71269 </pre>
71270 <blockquote>
71271 <ins><i>Remarks:</i> This constructor shall not participate in overload
71272 resolution, unless
71273 <tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
71274 </blockquote>
71275 </blockquote>
71276 </li>
71277
71278 <li>
71279 <p>
71280 Change 19.5.3.3 [syserr.errcondition.modifiers] around the
71281 prototype before p. 3:
71282 </p>
71283
71284 <blockquote><pre>template &lt;class ErrorConditionEnum&gt;
71285   <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type</del><ins>error_condition</ins>&amp;
71286     operator=(ErrorConditionEnum e);
71287 </pre>
71288
71289 <blockquote>
71290 <p>
71291 <ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
71292 <tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
71293 </p>
71294
71295 <p>
71296 <i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
71297 </p>
71298
71299 <p>
71300 <ins><i>Returns:</i> <tt>*this</tt></ins>
71301 </p>
71302 </blockquote>
71303 </blockquote>
71304
71305 </li>
71306 </ol>
71307
71308
71309
71310
71311
71312
71313 <hr>
71314 <h3><a name="1240"></a>1240. Deleted comparison functions of std::function not  needed</h3>
71315 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71316  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-18 <b>Last modified:</b> 2010-11-23</p>
71317 <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>
71318 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71319 <p><b>Discussion:</b></p>
71320 <p>
71321 The class template <tt>std::function</tt> contains the following member
71322 declarations:
71323 </p>
71324
71325 <blockquote><pre>// deleted overloads close possible hole in the type system
71326 template&lt;class R2, class... ArgTypes2&gt;
71327   bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
71328 template&lt;class R2, class... ArgTypes2&gt;
71329   bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
71330 </pre></blockquote>
71331
71332 <p>
71333 The leading comment here is part of the history of <tt>std::function</tt>, which
71334 was introduced with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html#undefined_operators">N1402</a>.
71335 During that time no explicit conversion functions existed, and the
71336 "safe-bool" idiom (based on pointers-to-member) was a popular
71337 technique. The only disadvantage of this idiom was that given two
71338 objects <tt>f1</tt> and <tt>f2</tt> of type <tt>std::function</tt> the expression
71339 </p>
71340
71341 <blockquote><pre>f1 == f2;
71342 </pre></blockquote>
71343
71344 <p>
71345 was well-formed, just because the built-in <tt>operator==</tt> for pointer to member
71346 was considered after a single user-defined conversion. To fix this, an
71347 overload set of <em>undefined</em> comparison functions was added,
71348 such that overload resolution would prefer those ending up in a linkage error.
71349 The new language facility of deleted functions provided a much better
71350 diagnostic mechanism to fix this issue.
71351 </p>
71352
71353 <p>
71354 The central point of this issue is, that with the replacement of the
71355 safe-bool idiom by explicit conversion to bool the original "hole in the
71356 type system" does no longer exist and therefore the comment is wrong and
71357 the superfluous function definitions should be removed as well. An
71358 explicit conversion function is considered in direct-initialization
71359 situations only, which indirectly contain the so-called "contextual
71360 conversion to bool" (4 [conv]/3). These conversions are not considered for
71361 <tt>==</tt> or <tt>!=</tt> as defined by the core language.
71362 </p>
71363
71364 <p><i>[
71365 Post-Rapperswil
71366 ]</i></p>
71367
71368
71369 <blockquote>
71370 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71371 </blockquote>
71372
71373 <p><i>[
71374 Adopted at 2010-11 Batavia
71375 ]</i></p>
71376
71377
71378
71379
71380 <p><b>Proposed resolution:</b></p>
71381 <p>
71382 In 20.8.14.2 [func.wrap.func]/1, class function change as indicated:
71383 </p>
71384
71385 <blockquote><pre>// 20.7.15.2.3, function capacity:
71386 explicit operator bool() const;
71387
71388 <del>// deleted overloads close possible hole in the type system</del>
71389 <del>template&lt;class R2, class... ArgTypes2&gt;</del>
71390   <del>bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
71391 <del>template&lt;class R2, class... ArgTypes2&gt;</del>
71392   <del>bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
71393 </pre></blockquote>
71394
71395
71396
71397
71398
71399 <hr>
71400 <h3><a name="1241"></a>1241. unique_copy needs to require EquivalenceRelation</h3>
71401 <p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71402  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-10-17 <b>Last modified:</b> 2010-10-23</p>
71403 <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>
71404 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71405 <p><b>Discussion:</b></p>
71406 <p>
71407 A lot of fixes were silently applied during concept-time and we should
71408 not lose them again. The Requires clause of 25.3.9 [alg.unique]/5
71409 doesn't mention that <tt>==</tt> and the predicate need to satisfy an
71410 <tt>EquivalenceRelation</tt>, as it is correctly said for
71411 <tt>unique</tt>. This was intentionally fixed during conceptification,
71412 were we had:
71413 </p>
71414
71415 <blockquote><pre>template&lt;InputIterator InIter, class OutIter&gt;
71416   requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
71417         &amp;&amp; EqualityComparable&lt;InIter::value_type&gt;
71418         &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
71419         &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
71420   OutIter unique_copy(InIter first, InIter last, OutIter result);
71421
71422 template&lt;InputIterator InIter, class OutIter,
71423          EquivalenceRelation&lt;auto, InIter::value_type&gt; Pred&gt;
71424   requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
71425         &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
71426         &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
71427         &amp;&amp; CopyConstructible&lt;Pred&gt;
71428   OutIter unique_copy(InIter first, InIter last, OutIter result, Pred pred);
71429 </pre></blockquote>
71430
71431 <p>
71432 Note that EqualityComparable implied an equivalence relation.
71433 </p>
71434
71435 <p><i>[
71436 N.B. <tt>adjacent_find</tt> was also specified to require
71437 <tt>EquivalenceRelation</tt>, but that was considered as a defect in
71438 concepts, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>
71439 ]</i></p>
71440
71441
71442 <p><i>[
71443 2009-10-31 Howard adds:
71444 ]</i></p>
71445
71446
71447 <blockquote>
71448 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71449 </blockquote>
71450
71451
71452
71453 <p><b>Proposed resolution:</b></p>
71454 <p>
71455 Change 25.3.9 [alg.unique]/5 as indicated:
71456 </p>
71457
71458 <blockquote><pre>template&lt;class InputIterator, class OutputIterator&gt;
71459   OutputIterator
71460     unique_copy(InputIterator first, InputIterator last, OutputIterator result);
71461
71462 template&lt;class InputIterator, class OutputIterator, class BinaryPredicate&gt;
71463   OutputIterator
71464     unique_copy(InputIterator first, InputIterator last,
71465                 OutputIterator result, BinaryPredicate pred);
71466 </pre>
71467 <blockquote>
71468 <i>Requires:</i> <ins>The comparison function shall be an equivalence
71469 relation.</ins> The ranges <tt>[first,last)</tt> and
71470 <tt>[result,result+(last-first))</tt> shall not overlap. The expression
71471 <tt>*result = *first</tt> shall be valid. If neither
71472 <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
71473 requirements of forward iterator then the value type of
71474 <tt>InputIterator</tt> shall be <tt>CopyConstructible</tt> (34) and
71475 <tt>CopyAssignable</tt> (table 36). Otherwise <tt>CopyConstructible</tt>
71476 is not required.
71477 </blockquote>
71478 </blockquote>
71479
71480
71481
71482
71483
71484 <hr>
71485 <h3><a name="1245"></a>1245. <tt>std::hash&lt;string&gt;</tt> &amp; co</h3>
71486 <p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71487  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2009-10-22 <b>Last modified:</b> 2010-10-23</p>
71488 <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>
71489 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71490 <p><b>Discussion:</b></p>
71491 <p>
71492 In 20.8.15 [unord.hash], <tt>operator()</tt> is specified as
71493 taking the argument by value. Moreover, it is said that <tt>operator()</tt> shall
71494 not throw exceptions.
71495 </p>
71496
71497 <p>
71498 However, for the specializations for class types, like <tt>string</tt>, <tt>wstring</tt>,
71499 etc, the former requirement seems suboptimal from the performance point
71500 of view (a specific PR has been filed about this in the GCC Bugzilla)
71501 and, together with the latter requirement, hard if not impossible to
71502 fulfill. It looks like pass by const reference should be allowed in such
71503 cases.
71504 </p>
71505
71506 <p><i>[
71507 2009-11-18: Ganesh updates wording.
71508 ]</i></p>
71509
71510
71511 <blockquote>
71512 I've removed the list of types for which <tt>hash</tt> shall be instantiated
71513 because it's already explicit in the synopsis of header
71514 <tt>&lt;functional&gt;</tt> in 20.8 [function.objects]/2.
71515 </blockquote>
71516
71517 <p><i>[
71518 2009-11-18: Original wording here:
71519 ]</i></p>
71520
71521
71522 <blockquote class="note">
71523 <p>
71524 Add to 20.8.15 [unord.hash]/2:
71525 </p>
71526
71527 <blockquote>
71528 <pre>namespace std {
71529   template &lt;class T&gt;
71530   struct hash : public std::unary_function&lt;T, std::size_t&gt; {
71531     std::size_t operator()(T val) const;
71532   };
71533 }
71534 </pre>
71535
71536 <p>
71537 The return value of <tt>operator()</tt> is unspecified, except that
71538 equal arguments shall yield the same result. <tt>operator()</tt> shall
71539 not throw exceptions. <ins>It is also unspecified whether
71540 <tt>operator()</tt> of <tt>std::hash</tt> specializations for class
71541 types takes its argument by value or const reference.</ins>
71542 </p>
71543 </blockquote>
71544 </blockquote>
71545
71546 <p><i>[
71547 2009-11-19 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71548 ]</i></p>
71549
71550
71551 <p><i>[
71552 2009-11-24 Ville Opens:
71553 ]</i></p>
71554
71555
71556 <blockquote>
71557 I have received community requests to ask for this issue to be reopened.
71558 Some users feel that mandating the inheritance is overly constraining.
71559 </blockquote>
71560
71561 <p><i>[
71562 2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
71563 ]</i></p>
71564
71565
71566 <p><i>[
71567 2010-02-07 Proposed resolution updated by Beman, Daniel and Ganesh.
71568 ]</i></p>
71569
71570
71571 <p><i>[
71572 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71573 ]</i></p>
71574
71575
71576
71577
71578 <p><b>Proposed resolution:</b></p>
71579   <p><i>Insert a new subclause either before or after the current 20.2.5 [allocator.requirements]:</i></p>
71580 <blockquote>
71581
71582   <h3><tt>Hash</tt> Requirements [hash.requirements]</h3>
71583
71584   <p align="left">This subclause defines the named requirement <tt>Hash</tt>, 
71585   used in several clauses of the C++ standard library. A type <tt>H</tt> meets the <tt>Hash</tt> requirement if</p>
71586
71587   <ul>
71588     <li>
71589
71590   <p align="left">it is a function object type (20.8 [function.objects]).</p>
71591
71592     </li>
71593     <li>
71594
71595   <p align="left">it satisfies the requirements of <tt>CopyConstructible</tt>, and 
71596   <tt>Destructible</tt> (20.2.1 [utility.arg.requirements]),</p>
71597
71598     </li>
71599     <li>
71600
71601   <p align="left">the expressions shown in the following table are valid and have the 
71602   indicated semantics, and</p>
71603
71604     </li>
71605     <li>
71606
71607   <p align="left">it satisfies all other requirements of this subclause.</p>
71608
71609     </li>
71610   </ul>
71611
71612   <p align="left">Given <tt>Key</tt> is an argument type for function objects of 
71613   type <tt>H</tt>, in the table below <tt>h</tt> is a value of type (possibly <tt>const</tt>)
71614   <tt>H</tt>, <tt>u</tt> is an lvalue of type <tt>Key</tt>,&nbsp; and <tt>
71615   k</tt> 
71616   is a value of a type convertible to (possibly <tt>const</tt>) <tt>Key</tt>:</p>
71617
71618   <p align="center">Table ? - <tt>Hash</tt> requirements</p>
71619 <table border="1" cellpadding="5" cellspacing="1" style="border-collapse: collapse" bordercolor="#111111">
71620   <tbody><tr>
71621     <td>Expression</td>
71622     <td>Return type</td>
71623     <td>Requirement</td>
71624   </tr>
71625   <tr>
71626     <td valign="top"><tt>h(k)</tt></td>
71627     <td valign="top"><tt>size_t</tt></td>
71628     <td valign="top">Shall not throw exceptions. The value returned shall depend only on
71629 the argument <tt>k</tt>. [<i>Note:</i> Thus all evaluations of the expression <tt>
71630     h(k)</tt> with the 
71631     same value for <tt>k</tt> yield the same result. <i>\97 end note</i>] [<i>Note:
71632     </i>For <tt>t1</tt> and <tt>t2</tt> of different values, the probability that 
71633     <tt>h(t1)</tt> 
71634     and <tt>h(t2)</tt> compare equal should be very small, approaching <tt>(1.0/numeric_limits&lt;size_t&gt;::max())</tt>.
71635     <i>\97 end note</i>] <i><span style="background-color: #C0C0C0">Comment 
71636     (not to go in WP): The wording for the second note is based on a similar 
71637     note in 22.4.4.1.2 [locale.collate.virtuals]/3</span></i></td>
71638   </tr>
71639   <tr>
71640     <td valign="top"><tt>h(u)</tt></td>
71641     <td valign="top"><tt>size_t</tt></td>
71642     <td valign="top">Shall not modify <tt>u</tt>.</td>
71643   </tr>
71644   </tbody></table>
71645
71646 </blockquote>
71647
71648 <p><i>Change 20.8.15 [unord.hash] as indicated: </i>
71649 </p>
71650 <blockquote>
71651   <p>1 The unordered associative containers defined in Clause 23.7 [unord] use 
71652   specializations of <ins>the class template</ins> <tt>hash</tt> as the default 
71653   hash function. <ins>For all object types <tt>T</tt> for which there exists a 
71654   specialization <tt>hash&lt;T&gt;</tt>, the instantiation <tt>hash&lt;T&gt;</tt> shall:</ins></p>
71655   <ul>
71656     <li> <ins>satisfy the <tt>Hash</tt> requirements([hash.requirements]), with <tt>T</tt> as the 
71657   function call argument type, the <tt>
71658   DefaultConstructible</tt> requirements ([defaultconstructible]), the <tt>CopyAssignable</tt> 
71659   requirements ([copyassignable]), and the <tt>
71660   Swappable</tt> requirements ([swappable]),</ins>
71661   </li>
71662     <li> <ins>provide two nested types <tt>result_type</tt> and <tt>argument_type</tt> which shall 
71663     be synonyms for <tt>size_t</tt> and <tt>T</tt>, respectively,</ins></li>
71664     <li> <ins>satisfy the 
71665   requirement that if <tt>k1 == k2</tt> is <tt>true</tt>, <tt>h(k1) == h(k2)</tt> 
71666   is <tt>true</tt>, where <tt>h</tt> is an object of type <tt>hash&lt;T&gt;</tt>, and
71667   <tt>k1</tt>, <tt>k2</tt> are objects of type <tt>T</tt>.</ins></li>
71668   </ul>
71669   <p> <del>This class template is only required to be instantiable 
71670   for integer types (3.9.1 [basic.fundamental]), floating-point types (3.9.1 [basic.fundamental]), 
71671   pointer types (8.3.1 [dcl.ptr]), and <tt>std::string</tt>, <tt>std::u16string</tt>,
71672   <tt>std::u32string</tt>, <tt>std::wstring</tt>, <tt>std::error_code</tt>, <tt>
71673   std::thread::id</tt>, <tt>std::bitset</tt>, and <tt>std::vector&lt;bool&gt;</tt>.</del> </p>
71674   <blockquote>
71675     <pre><del>namespace std {
71676   template &lt;class T&gt;
71677   struct hash : public std::unary_function&lt;T, std::size_t&gt; {
71678     std::size_t operator()(T val) const;
71679   };
71680 }</del></pre>
71681   </blockquote>
71682   <p><del>2 The return value of <tt>operator()</tt> is unspecified, except that 
71683   equal arguments shall yield the same result. <tt>operator()</tt> shall not 
71684   throw exceptions. </del></p>
71685
71686 </blockquote>
71687
71688   <p><i>Change Unordered associative containers 23.2.5 [unord.req] as indicated:</i></p>
71689 <blockquote>
71690   <p>Each unordered associative container is parameterized by <tt>Key</tt>, by a 
71691   function object <ins>type</ins> <tt>Hash</tt><ins>([hash.requirements])</ins> that acts as a hash 
71692   function for <ins>argument</ins> values of type <tt>Key</tt>, 
71693   and by a binary predicate <tt>Pred</tt> that induces an equivalence relation 
71694   on values of type <tt>Key</tt>. Additionally, <tt>unordered_map</tt> and <tt>
71695   unordered_multimap</tt> associate an arbitrary mapped type <tt>T</tt> with the
71696   <tt>Key</tt>.</p>
71697   <p>A hash function is a function object that takes a single argument of type
71698   <tt>Key</tt> and returns a value of type <tt>std::size_t</tt>.</p>
71699 <p>Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered 
71700 equal if the container's equality function object returns <tt>true</tt> when passed those 
71701 values. If <tt>k1</tt> and <tt>k2</tt> are equal, the hash function shall return 
71702 the same value for both. <ins>[<i>Note:</i> Thus supplying a non-default <tt>Pred</tt> 
71703 parameter usually implies the need to supply a non-default <tt>Hash</tt> 
71704 parameter. <i>\97 end note</i>]</ins></p>
71705
71706 </blockquote>
71707
71708
71709
71710
71711
71712
71713 <hr>
71714 <h3><a name="1247"></a>1247. <tt>auto_ptr</tt> is overspecified</h3>
71715 <p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71716  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-24 <b>Last modified:</b> 2010-10-23</p>
71717 <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>
71718 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71719 <p><b>Discussion:</b></p>
71720 <p>
71721 This issue is extracted as the ongoing point-of-interest from earlier
71722 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.
71723 </p>
71724
71725 <p>
71726 <tt>auto_ptr</tt> is overspecified as the <tt>auto_ptr_ref</tt>
71727 implementation detail is formally specified, and the technique is
71728 observable so workarounds for compiler defects can  cause a working
71729 implementation of the primary <tt>auto_ptr</tt> template become
71730 non-conforming.
71731 </p>
71732
71733 <p>
71734 <tt>auto_ptr_ref</tt> is a documentation aid to describe a possible
71735 mechanism to implement the class.  It should be marked exposition only,
71736 as per similar classes, e.g., <tt>istreambuf_iterator::proxy</tt>
71737 </p>
71738
71739 <p><i>[
71740 2009-10-25 Daniel adds:
71741 ]</i></p>
71742
71743
71744 <blockquote>
71745 <p>
71746 I wonder, whether the revised wording shouldn't be as straight as
71747 for <tt>istream_buf</tt> by adding one further sentence:
71748 </p>
71749
71750 <blockquote>
71751 An implementation is permitted to provide equivalent functionality without
71752 providing a class with this name.
71753 </blockquote>
71754 </blockquote>
71755
71756 <p><i>[
71757 2009-11-06 Alisdair adds Daniel's suggestion to the proposed wording.
71758 ]</i></p>
71759
71760
71761 <p><i>[
71762 2009-11-06 Howard moves issue to Review.
71763 ]</i></p>
71764
71765
71766 <p><i>[
71767 2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71768 ]</i></p>
71769
71770
71771
71772 <p><b>Proposed resolution:</b></p>
71773 <p>
71774 Add the term "exposition only" in the following two places:
71775 </p>
71776
71777 <p>
71778 Ammend D.12.1 [auto.ptr]p2:
71779 </p>
71780
71781 <blockquote>
71782 <p>
71783 <ins>The exposition only class </ins> <del>T</del><ins>t</ins>emplate <tt>auto_ptr_ref</tt>
71784 holds a reference to an <tt>auto_ptr</tt>. It is used by the
71785 <tt>auto_ptr</tt> conversions to allow <tt>auto_ptr</tt> objects to be
71786 passed to and returned from functions.
71787 <ins>An implementation is permitted to provide equivalent functionality
71788 without providing a class with this name.</ins>
71789 </p>
71790
71791 <blockquote><pre>namespace std {
71792  template &lt;class Y&gt; struct auto_ptr_ref { }; <ins>// exposition only</ins>
71793 </pre></blockquote>
71794 </blockquote>
71795
71796
71797
71798
71799
71800 <hr>
71801 <h3><a name="1249"></a>1249. basic_ios default ctor</h3>
71802 <p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71803  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-25 <b>Last modified:</b> 2010-11-24</p>
71804 <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>
71805 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71806 <p><b>Discussion:</b></p>
71807 <p>
71808 The basic_ios default ctor is required to leave the objects members
71809 uninitialized (see below). The paragraph says the object must be
71810 initialized by calling basic_ios::init() before it's destroyed by
71811 I can't find a requirement that it be initialized before calling
71812 any of the class other member functions. Am I not looking in the
71813 right place or that an issue?
71814 </p>
71815
71816 <p><i>[
71817 2009-10-25 Daniel adds:
71818 ]</i></p>
71819
71820
71821 <blockquote>
71822 <p>
71823 I agree, that your wording makes that clearer, but suggest to write
71824 </p>
71825
71826 <blockquote>
71827 ... calling <tt>basic_ios::init<del>()</del></tt> before ...
71828 </blockquote>
71829
71830 <p>
71831 Doing so, I recommend to adapt that of <tt>ios_base();</tt> as well, where
71832 we have:
71833 </p>
71834
71835 <blockquote>
71836 <i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
71837 after construction. These members shall be initialized by calling
71838 <tt>basic_ios::init</tt>. If an <tt>ios_base</tt> object is destroyed
71839 before these initializations have taken place, the behavior is
71840 undefined.
71841 </blockquote>
71842 </blockquote>
71843
71844 <p><i>[
71845 Post-Rapperswil:
71846 ]</i></p>
71847
71848
71849 <blockquote>
71850 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71851 </blockquote>
71852
71853 <p><i>[
71854 Adopted at 2010-11 Batavia
71855 ]</i></p>
71856
71857
71858
71859
71860 <p><b>Proposed resolution:</b></p>
71861 <p>
71862 Change 27.5.2.7 [ios.base.cons] p1:
71863 </p>
71864
71865 <blockquote><pre>ios_base();
71866 </pre>
71867 <blockquote>
71868 <i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
71869 after construction. <del>These</del> <ins>The object's</ins> members shall be initialized by calling
71870 <tt>basic_ios::init</tt> <ins>before the object's first use or before
71871  it is destroyed, whichever comes first; otherwise the behavior
71872  is undefined.</ins>. <del>If an <tt>ios_base</tt> object is destroyed
71873 before these initializations have taken place, the behavior is
71874 undefined.</del>
71875 </blockquote>
71876 </blockquote>
71877
71878 <p>
71879 Change 27.5.4.1 [basic.ios.cons] p2:
71880 </p>
71881
71882 <blockquote><pre>basic_ios();
71883 </pre>
71884 <blockquote>
71885 <i>Effects:</i> Constructs an object of class <tt>basic_ios</tt>
71886 (27.5.2.7) leaving its member objects uninitialized. The object shall be
71887 initialized by calling <del>its</del>
71888 <tt><ins>basic_ios::</ins>init</tt> <ins>before its first
71889 use or before it is destroyed, whichever comes first; otherwise the
71890 behavior is undefined.</ins> <del>member function. If it is destroyed
71891 before it has been initialized the behavior is undefined.</del>
71892 </blockquote>
71893 </blockquote>
71894
71895
71896
71897
71898
71899 <hr>
71900 <h3><a name="1250"></a>1250. <tt>&lt;bitset&gt;</tt> still overspecified</h3>
71901 <p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71902  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-29 <b>Last modified:</b> 2010-10-23</p>
71903 <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>
71904 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71905 <p><b>Discussion:</b></p>
71906 <p>
71907 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a> \97 <tt>&lt;bitset&gt;</tt> synopsis overspecified makes the observation
71908 that <tt>std::bitset</tt>, and in fact the whole library, may be implemented
71909 without needing to <tt>#include &lt;stdexcept&gt;</tt> in any library header. The
71910 proposed resolution removes the <tt>#include &lt;stdexcept&gt;</tt> directive from
71911 the header.
71912 </p>
71913
71914 <p>
71915 I'd like to add that the <tt>&lt;bitset&gt;</tt> header (as well as the rest of
71916 the library) has also been implemented without #including the
71917 <tt>&lt;cstddef&gt;</tt> header in any library header. In the case of <tt>std::bitset</tt>,
71918 the template is fully usable (i.e., it may be instantiated and all
71919 its member functions may be used) without ever mentioning <tt>size_t</tt>.
71920 In addition, just like no library header except for <tt>&lt;bitset&gt;</tt>
71921 <tt>#includes &lt;stdexcept&gt;</tt> in its synopsis, no header but <tt>&lt;bitset&gt;</tt>
71922 <tt>#includes &lt;cstddef&gt;</tt> either.
71923 </p>
71924
71925 <p>
71926 Thus I suggest that the <tt>#include &lt;cstddef&gt;</tt> directive be similarly
71927 removed from the synopsis of <tt>&lt;bitset&gt;</tt>.
71928 </p>
71929
71930 <p><i>[
71931 2010-02-08 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
71932 ]</i></p>
71933
71934
71935
71936
71937 <p><b>Proposed resolution:</b></p>
71938 <p>
71939 Change 20.5 [template.bitset]:
71940 </p>
71941
71942 <blockquote><pre><del>#include &lt;cstddef&gt;        // for size_t</del>
71943 #include &lt;string&gt;
71944 #include &lt;iosfwd&gt;         // for istream, ostream
71945 namespace std {
71946 ...
71947 </pre></blockquote>
71948
71949
71950
71951
71952
71953 <hr>
71954 <h3><a name="1254"></a>1254. Misleading sentence in <tt>vector&lt;bool&gt;::flip</tt></h3>
71955 <p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
71956  <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2009-11-01 <b>Last modified:</b> 2010-10-23</p>
71957 <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>
71958 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
71959 <p><b>Discussion:</b></p>
71960 <p>
71961 The effects of <tt>vector&lt;bool&gt;::flip</tt> has the line:
71962 </p>
71963
71964 <blockquote>
71965 It is unspecified whether the function has any effect on allocated but
71966 unused bits.
71967 </blockquote>
71968
71969 <p>
71970 While this is technically true, it is misleading, as any member function
71971 in any standard container may change unused but allocated memory. Users
71972 can never observe such changes as it would also be undefined behaviour
71973 to read such memory.
71974 </p>
71975
71976 <p><i>[
71977 2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
71978 ]</i></p>
71979
71980
71981
71982 <p><b>Proposed resolution:</b></p>
71983 <p>
71984 Strike second sentence from the definition of <tt>vector&lt;bool&gt;::flip()</tt>,
71985 23.4.2 [vector.bool], paragraph 5.
71986 </p>
71987
71988 <blockquote>
71989 <i>Effects:</i> Replaces each element in the container with its complement.
71990 <del>It is unspecified whether the function has any effect on allocated
71991 but unused bits.</del>
71992 </blockquote>
71993
71994
71995
71996
71997
71998 <hr>
71999 <h3><a name="1255"></a>1255. <tt>declval</tt> should be added to the library</h3>
72000 <p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72001  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-03 <b>Last modified:</b> 2010-10-23</p>
72002 <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>
72003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72004 <p><b>Discussion:</b></p>
72005 <p>
72006 During the Santa Cruz meeting it was decided to split off the provision
72007 of the library utility <tt>value()</tt> proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2979.html">N2979</a>
72008 from the concrete request of the
72009 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2939.html#uk300">UK 300</a>
72010 comment.
72011 The provision of a new library component that allows the production of
72012 values in unevaluated expressions is considered as important
72013 to realize constrained templates in C++0x where concepts are not
72014 available.
72015 </p>
72016
72017 <p>
72018 The following proposed resolution is an improvement over that suggested in
72019 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>,
72020 because the proposed component can now be defined without loss of
72021 general usefulness and any <i>use</i> by user-code will make the program ill-formed.
72022 A possible prototype implementation that satisfies the core language
72023 requirements
72024 can be written as:
72025 </p>
72026
72027 <blockquote><pre>template&lt;class T&gt;
72028   struct declval_protector {
72029     static const bool stop = false;
72030     static typename std::add_rvalue_reference&lt;T&gt;::type delegate(); <font color="#C80000">// undefined</font>
72031   };
72032
72033 template&lt;class T&gt;
72034 typename std::add_rvalue_reference&lt;T&gt;::type declval() {
72035   static_assert(declval_protector&lt;T&gt;::stop, "declval() must not be used!");
72036   return declval_protector&lt;T&gt;::delegate();
72037 }
72038 </pre></blockquote>
72039
72040 <p>
72041 Further-on the earlier suggested name <tt>value()</tt> has been changed to <tt>declval()</tt>
72042 after discussions with committee members.
72043 </p>
72044
72045 <p>
72046 Finally the suggestion shown below demonstrates that it can simplify
72047 existing standard wording by directly using it in the library
72048 specification, and that it also improves an overlooked corner case for
72049 <tt>common_type</tt> by adding support for <tt>cv void</tt>.
72050 </p>
72051
72052 <p><i>[
72053 2009-11-19 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
72054 ]</i></p>
72055
72056
72057
72058 <p><b>Proposed resolution:</b></p>
72059 <p><i>[
72060 The proposed resolution has been updated to
72061 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
72062 numbering and wording
72063 ]</i></p>
72064
72065
72066 <ol>
72067 <li>
72068 <p>
72069 Change 20.3 [utility], header <tt>&lt;utility&gt;</tt> synopsis
72070 as indicated:
72071 </p>
72072
72073 <blockquote><pre>// 20.3.3, forward/move:
72074 template &lt;class T&gt; struct identity;
72075 template &lt;class T, class U&gt; T&amp;&amp; forward(U&amp;&amp;);
72076 template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;);
72077
72078 <ins>// 20.3.4, declval:</ins>
72079 <ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // as unevaluated operand</ins>
72080 </pre></blockquote>
72081 </li>
72082
72083 <li>
72084 <p>
72085 Immediately after the current section 20.3.3 [forward] insert a
72086 new section:
72087 </p>
72088 <p>
72089 <ins>20.3.4 Function template declval [declval]</ins>
72090 </p>
72091 <p>
72092 <ins>The library provides the function template <tt>declval</tt> to simplify
72093 the definition of expressions which occur as
72094 unevaluated operands (5 [expr]). The
72095 template parameter <tt>T</tt> of <tt>declval</tt> may
72096 be an incomplete type.</ins>
72097 </p>
72098
72099 <pre><ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // as unevaluated operand</ins>
72100 </pre>
72101
72102 <blockquote>
72103 <p>
72104 <ins><i>Remarks:</i> If this function is used according to 3.2 [basic.def.odr],
72105 the program is ill-formed.</ins>
72106 </p>
72107
72108 <p>
72109 <ins>[<i>Example:</i></ins>
72110 </p>
72111
72112 <blockquote><pre><ins>
72113 template&lt;class To, class From&gt;
72114 decltype(static_cast&lt;To&gt;(declval&lt;From&gt;())) convert(From&amp;&amp;);
72115 </ins></pre></blockquote>
72116
72117 <p>
72118 <ins>
72119 declares a function template <tt>convert</tt>, which only participates in
72120 overloading if the type <tt>From</tt> can be explicitly cast to type <tt>To</tt>.
72121 For another example see class template <tt>common_type</tt>
72122 (20.7.7.6 [meta.trans.other]).
72123 \97 <i>end example</i>]</ins>
72124 </p>
72125 </blockquote>
72126
72127 </li>
72128
72129 <li>
72130 <p>
72131 This bullet just makes clear that after applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>, the changes in 20.7.4.3 [meta.unary.prop], before
72132 table Type property queries should <em>not</em> use <tt>declval</tt>,
72133 because the well-formedness requirement of the specification of
72134 <tt>is_constructible</tt> would become more complicated, because we
72135 would need to make sure that the expression <i>CE</i> is checked in an
72136 unevaluated context.
72137 </p>
72138 </li>
72139
72140 <li>
72141 <p>
72142 Also 20.7.6 [meta.rel]/4 is not modified similar to the previous bullet,
72143 because with
72144 the stricter requirements of not using <tt>declval()</tt> the well-formedness condition
72145 would be harder to specify. The following changes are only editorial ones (e.g.
72146 the removal of the duplicate declaration of <tt>create()</tt>):
72147 </p>
72148
72149 <blockquote>
72150 <p>
72151 Given the following function prototype:
72152 </p>
72153
72154 <blockquote><pre>template &lt;class T&gt;
72155   typename add_rvalue_reference&lt;T&gt;::type create();
72156 </pre></blockquote>
72157
72158 <p>
72159 the predicate condition for a template specialization
72160 <tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied if and only
72161 if the return expression in the following code would be well-formed,
72162 including any
72163 implicit conversions to the return type of the function:
72164 </p>
72165
72166 <blockquote><pre><del>template &lt;class T&gt;
72167 typename add_rvalue_reference&lt;T&gt;::type create();</del>
72168 To test() {
72169   return create&lt;From&gt;();
72170 }
72171 </pre></blockquote>
72172 </blockquote>
72173 </li>
72174
72175 <li>
72176 <p>
72177 Change the entry in column "Comments" for <tt>common_type</tt> in Table 51 \97
72178 Other transformations (20.7.7.6 [meta.trans.other]):
72179 </p>
72180
72181 <p><i>[
72182 NB: This wording change extends the type domain of <tt>common_type</tt> for <tt>cv
72183 void =&gt; cv void</tt> transformations and thus makes <tt>common_type</tt> usable for
72184 all binary type combinations that are supported by <tt>is_convertible</tt>
72185 ]</i></p>
72186
72187
72188 <blockquote>
72189 The member typedef <tt>type</tt> shall be defined as set out below. All
72190 types in the parameter pack <tt>T</tt> shall be complete <ins>or
72191 (possibly cv-qualified) <tt>void</tt></ins>. A program may specialize
72192 this trait if at least one template parameter in the specialization is a
72193 user-defined type. [<i>Note:</i> Such specializations are needed when
72194 only explicit conversions are desired among the template arguments.
72195 \97 <i>end note</i>]
72196 </blockquote>
72197 </li>
72198
72199 <li>
72200 <p>
72201 Change 20.7.7.6 [meta.trans.other]/3 as indicated:
72202 </p>
72203
72204 <p><i>[
72205 NB: This wording change is more than an editorial simplification of
72206 the definition of <tt>common_type</tt>: It also extends its usefulness for <tt>cv
72207 void</tt> types as outlined above
72208 ]</i></p>
72209
72210
72211 <blockquote>
72212 <p>
72213 The nested typedef <tt>common_type::type</tt> shall be defined as follows:
72214 </p>
72215
72216 <blockquote>
72217 <p>
72218 [..]
72219 </p>
72220 <pre>template &lt;class T, class U&gt;
72221 struct common_type&lt;T, U&gt; {
72222 <del>private:
72223   static T&amp;&amp; __t();
72224   static U&amp;&amp; __u();
72225 public:</del>
72226   typedef decltype(true ? <del>__t</del><ins>declval&lt;T&gt;</ins>() : <del>__u</del><ins>declval&lt;U&gt;</ins>()) type;
72227 };
72228 </pre>
72229 </blockquote>
72230 </blockquote>
72231 </li>
72232
72233 <li>
72234 <p>
72235 Change X [func.ret]/1 as indicated
72236 [<i>This part solves some main aspects of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a></i>]:
72237 </p>
72238
72239 <blockquote><pre>namespace std {
72240   template &lt;class&gt; class result_of; // undefined
72241
72242   template &lt;class Fn, class... ArgTypes&gt;
72243   class result_of&lt;Fn(ArgTypes...)&gt; {
72244   public :
72245     <del>// types</del>
72246     typedef <del>see below</del><ins>decltype(declval&lt;Fn&gt;() ( declval&lt;ArgTypes&gt;()... ))</ins> type;
72247   };
72248 }
72249 </pre>
72250 <p>
72251 <del>1 Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2, ..., tN</tt> of
72252 types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt>,
72253 respectively, the <tt>type</tt> member is the result type of the expression
72254 <tt>fn(t1, t2, ...,tN)</tt>. The values <tt>ti</tt>
72255 are lvalues when the corresponding type <tt>Ti</tt> is an lvalue-reference
72256 type, and rvalues otherwise.</del>
72257 </p>
72258 </blockquote>
72259 </li>
72260 </ol>
72261
72262
72263
72264
72265
72266
72267 <hr>
72268 <h3><a name="1256"></a>1256. <tt>weak_ptr</tt> comparison functions should be removed</h3>
72269 <p><b>Section:</b> 20.9.10.3 [util.smartptr.weak] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72270  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-04 <b>Last modified:</b> 2010-10-23</p>
72271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72272 <p><b>Discussion:</b></p>
72273 <p>
72274 Additional to the necessary cleanup of the description of the the
72275 <tt>weak_ptr</tt> component from 20.9.10.3 [util.smartptr.weak]
72276 described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a> it turns out that the currently deleted
72277 comparison functions of <tt>weak_ptr</tt> are not needed at all: There
72278 is no safe-bool conversion from <tt>weak_ptr</tt>, and it won't silently
72279 chose a conversion to <tt>shared_ptr</tt>.
72280 </p>
72281
72282 <p><i>[
72283 2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72284 ]</i></p>
72285
72286
72287
72288 <p><b>Proposed resolution:</b></p>
72289 <p>
72290 Change 20.9.10.3 [util.smartptr.weak]/1 as indicated:
72291 </p>
72292
72293 <blockquote><pre>namespace std {
72294 template&lt;class T&gt; class weak_ptr {
72295 public:
72296 ...
72297   <del>// comparisons</del>
72298   <del>template&lt;class Y&gt; bool operator&lt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
72299   <del>template&lt;class Y&gt; bool operator&lt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
72300   <del>template&lt;class Y&gt; bool operator&gt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
72301   <del>template&lt;class Y&gt; bool operator&gt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
72302 };
72303 ...
72304 </pre></blockquote>
72305
72306
72307
72308
72309
72310 <hr>
72311 <h3><a name="1257"></a>1257. Header &lt;ios&gt; still contains a <code>concept_map</code></h3>
72312 <p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72313  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-11-04 <b>Last modified:</b> 2010-10-23</p>
72314 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
72315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72316 <p><b>Discussion:</b></p>
72317 <p>
72318 The current WP still contains a <tt>concept_map</tt>.
72319 </p>
72320
72321 <p><i>[
72322 2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72323 ]</i></p>
72324
72325
72326
72327 <p><b>Proposed resolution:</b></p>
72328 <p>
72329 Change Iostreams base classes 27.5 [iostreams.base], Header &lt;ios&gt; synopsis, 
72330 as indicated:
72331 </p>
72332
72333 <blockquote><pre><del>concept_map ErrorCodeEnum&lt;io_errc&gt; { };</del>
72334 <ins>template &lt;&gt; struct is_error_code_enum&lt;io_errc&gt; : true_type { }</ins>
72335 error_code make_error_code(io_errc e);
72336 error_condition make_error_condition(io_errc e);
72337 const error_category&amp; iostream_category();
72338 </pre></blockquote>
72339
72340
72341
72342
72343
72344
72345 <hr>
72346 <h3><a name="1258"></a>1258. std::function Effects clause impossible to satisfy</h3>
72347 <p><b>Section:</b> 20.8.14.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
72348  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-05 <b>Last modified:</b> 2010-11-19</p>
72349 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
72350 <p><b>Discussion:</b></p>
72351 <p>
72352 As of 20.8.14.2.2 [func.wrap.func.mod]/2+ we have the following
72353 prototype description:
72354 </p>
72355
72356 <blockquote><pre>template&lt;class F, Allocator Alloc&gt;
72357   void assign(F, const Alloc&amp;);
72358 </pre>
72359 <blockquote>
72360 <i>Effects:</i> <tt>function(f, a).swap(*this)</tt>
72361 </blockquote>
72362 </blockquote>
72363
72364 <p>
72365 Two things: First the concept debris needs to be removed, second and
72366 much more importantly, the effects clause is now impossible to satisfy,
72367 because there is no constructor that would match the parameter sequence
72368 (<tt>FunctionObject</tt>, <tt>Allocator</tt>) [plus the fact that no
72369 <tt>f</tt> and no <tt>a</tt> is part of the signature]. The most
72370 probable candidate is
72371 </p>
72372
72373 <blockquote><pre>template&lt;class F, class A&gt; function(allocator_arg_t, const A&amp;, F);
72374 </pre></blockquote>
72375
72376 <p>
72377 and the effects clause needs to be adapted to use this signature.
72378 </p>
72379
72380 <p><i>[
72381 2009-11-13 Daniel brought wording up to date.
72382 ]</i></p>
72383
72384
72385 <p><i>[
72386 2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72387 ]</i></p>
72388
72389
72390 <p><i>[
72391 2010-02-11 Moved to Tentatively NAD Editorial after 5 positive votes on
72392 c++std-lib.  It was noted that this issue was in partial conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, and the two issues were merged in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>.
72393 ]</i></p>
72394
72395
72396 <p><b>Rationale:</b></p>
72397 <p>
72398 Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>.
72399 </p>
72400
72401
72402
72403
72404 <p><b>Proposed resolution:</b></p>
72405 <p>
72406 Change in 20.8.14.2.2 [func.wrap.func.mod] the complete prototype description as
72407 indicated
72408 </p>
72409 <p><i>[
72410 Question to
72411 the editor: Shouldn't there a paragraph number in front of the Effects clause?
72412 ]</i></p>
72413
72414
72415 <blockquote><pre>template&lt;class F, <del>Allocator Alloc</del><ins>class A</ins>&gt;
72416   void assign(F <ins>f</ins>, const A<del>lloc</del>&amp; <ins>a</ins>);
72417 </pre>
72418 <blockquote>
72419 <ins>3</ins> <i>Effects:</i> <tt>function(<del>f, a</del><ins>allocator_arg, a,
72420 f</ins>).swap(*this)</tt>
72421 </blockquote>
72422 </blockquote>
72423
72424
72425
72426
72427
72428 <hr>
72429 <h3><a name="1260"></a>1260. <tt>is_constructible&lt;int*,void*&gt;</tt> reports true</h3>
72430 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
72431  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-11-07 <b>Last modified:</b> 2010-11-20</p>
72432 <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>
72433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
72434 <p><b>Discussion:</b></p>
72435 <p>
72436 The specification of <tt>is_constructible&lt;T,Args...&gt;</tt> in
72437 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
72438 uses
72439 </p>
72440
72441 <blockquote><pre>static_cast&lt;T&gt;(create&lt;Args&gt;()...)
72442 </pre></blockquote>
72443
72444 <p>
72445 for the one-argument case, but <tt>static_cast</tt> also permits
72446 unwanted conversions such as <tt>void*</tt> to <tt>T*</tt> and
72447 <tt>Base*</tt> to <tt>Derived*</tt>.
72448 </p>
72449
72450 <p><i>[
72451 Post-Rapperswil:
72452 ]</i></p>
72453
72454
72455 <blockquote>
72456 Moved to <del>NAD Editorial</del><ins>Resolved</ins>, this issue is addressed by paper 
72457 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3047.html">n3047</a>
72458 </blockquote>
72459
72460
72461
72462 <p><b>Proposed resolution:</b></p>
72463 <p>
72464 Change 20.7.4.3 [meta.unary.prop], p6:
72465 </p>
72466
72467 <blockquote>
72468 <p>
72469 the predicate condition for a template specialization
72470 <tt>is_constructible&lt;T, Args&gt;</tt> shall be satisfied, if and only
72471 if the following <del>expression <i>CE</i></del> <ins>variable
72472 definition</ins> would be well-formed:
72473 </p>
72474
72475 <ul>
72476 <li>
72477 <p>
72478 if <tt>sizeof...(Args) == <ins>0</ins> <del>1</del></tt><del>, the expression</del>:
72479 </p>
72480 <blockquote><pre><del>static_cast&lt;T&gt;(create&lt;Args&gt;()...)</del>
72481 <ins>T t;</ins>
72482 </pre></blockquote>
72483 </li>
72484 <li>
72485 <p>
72486 otherwise <del>the expression</del>:
72487 </p>
72488 <blockquote><pre>T<ins> t</ins>(create&lt;Args&gt;()...);
72489 </pre></blockquote>
72490 </li>
72491 </ul>
72492 </blockquote>
72493
72494
72495
72496
72497
72498 <hr>
72499 <h3><a name="1261"></a>1261. Insufficent overloads for <tt>to_string</tt> / <tt>to_wstring</tt></h3>
72500 <p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72501  <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2009-11-10 <b>Last modified:</b> 2010-10-23</p>
72502 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
72503 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72504 <p><b>Discussion:</b></p>
72505 <p>
72506 Reported on the gcc mailing list.
72507 </p>
72508
72509 <blockquote>
72510 The code "<tt>int i; to_string(i);</tt>" fails to compile, as
72511 '<tt>int</tt>' is ambiguous between '<tt>long long</tt>' and '<tt>long
72512 long unsigned</tt>'. It seems unreasonable to expect users to cast
72513 numbers up to a larger type just to use <tt>to_string</tt>.
72514 </blockquote>
72515
72516 <p><i>[
72517 2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72518 ]</i></p>
72519
72520
72521
72522 <p><b>Proposed resolution:</b></p>
72523 <p>
72524 21.3 [string.classes], change <tt>to_string</tt> and
72525 <tt>to_wstring</tt> to:
72526 </p>
72527
72528 <blockquote><pre><ins>string to_string(int val);</ins>
72529 <ins>string to_string(unsigned val);</ins>
72530 <ins>string to_string(long val);</ins>
72531 <ins>string to_string(unsigned long val);</ins>
72532 string to_string(long long val); 
72533 string to_string(unsigned long long val); 
72534 <ins>string to_string(float val);</ins>
72535 <ins>string to_string(double val);</ins>
72536 string to_string(long double val);
72537
72538 <ins>wstring to_wstring(int val);</ins>
72539 <ins>wstring to_wstring(unsigned val);</ins>
72540 <ins>wstring to_wstring(long val);</ins>
72541 <ins>wstring to_wstring(unsigned long val);</ins>
72542 wstring to_wstring(long long val); 
72543 wstring to_wstring(unsigned long long val); 
72544 <ins>wstring to_wstring(float val);</ins>
72545 <ins>wstring to_wstring(double val);</ins>
72546 wstring to_wstring(long double val);
72547 </pre></blockquote>
72548
72549 <p>
72550 In 21.5 [string.conversions], paragraph 7, change to:
72551 </p>
72552
72553 <blockquote><pre><ins>string to_string(int val);</ins>
72554 <ins>string to_string(unsigned val);</ins>
72555 <ins>string to_string(long val);</ins>
72556 <ins>string to_string(unsigned long val);</ins>
72557 string to_string(long long val); 
72558 string to_string(unsigned long long val); 
72559 <ins>string to_string(float val);</ins>
72560 <ins>string to_string(double val);</ins>
72561 string to_string(long double val);
72562 </pre>
72563
72564 <blockquote>
72565 7 <i>Returns:</i> each function returns a <tt>string</tt> object holding
72566 the character representation of the value of its argument that would be
72567 generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format
72568 specifier of <ins> <tt>"%d"</tt>, <tt>"%u"</tt>, <tt>"%ld"</tt>,
72569 <tt>"%lu"</tt>, </ins> <tt>"%lld"</tt>, <tt>"%llu"</tt>,
72570 <ins><tt>"%f"</tt>, <tt>"%f"</tt>,</ins> or <tt>"%Lf"</tt>, respectively,
72571 where <tt>buf</tt> designates an internal character buffer of sufficient
72572 size.
72573 </blockquote>
72574 </blockquote>
72575
72576 <p>
72577 In 21.5 [string.conversions], paragraph 14, change to:
72578 </p>
72579
72580 <blockquote><pre><ins>wstring to_wstring(int val);</ins>
72581 <ins>wstring to_wstring(unsigned val);</ins>
72582 <ins>wstring to_wstring(long val);</ins>
72583 <ins>wstring to_wstring(unsigned long val);</ins>
72584 wstring to_wstring(long long val); 
72585 wstring to_wstring(unsigned long long val); 
72586 <ins>wstring to_wstring(float val);</ins>
72587 <ins>wstring to_wstring(double val);</ins>
72588 wstring to_wstring(long double val);
72589 </pre>
72590
72591 <blockquote>
72592 14      <i>Returns:</i> Each function returns a <tt>wstring</tt> object
72593 holding the character representation of the value of its argument that
72594 would be generated by calling <tt>swprintf(buf, buffsz, fmt, val)</tt>
72595 with a format specifier of <ins> <tt>L"%d"</tt>, <tt>L"%u"</tt>,
72596 <tt>L"%ld"</tt>, <tt>L"%lu"</tt>, </ins><tt>L"%lld"</tt>,
72597 <tt>L"%llu"</tt>, <ins><tt>L"%f"</tt>, <tt>L"%f"</tt>,</ins> or
72598 <tt>L"%Lf"</tt>, respectively, where <tt>buf</tt> designates an internal
72599 character buffer of sufficient size <tt>buffsz</tt>.
72600 </blockquote>
72601 </blockquote>
72602
72603
72604
72605
72606
72607 <hr>
72608 <h3><a name="1262"></a>1262. <tt>std::less&lt;std::shared_ptr&lt;T&gt;&gt;</tt> is underspecified</h3>
72609 <p><b>Section:</b> 20.9.10.2.7 [util.smartptr.shared.cmp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72610  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-10 <b>Last modified:</b> 2010-10-23</p>
72611 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72612 <p><b>Discussion:</b></p>
72613 <p>
72614 20.9.10.2.7 [util.smartptr.shared.cmp]/5 says:
72615 </p>
72616
72617 <blockquote>
72618 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
72619 partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
72620 the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
72621 <tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
72622 <tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
72623 <tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
72624 </blockquote>
72625
72626 <p>
72627 This is necessary in order to use <tt>shared_ptr</tt> as the key in associate
72628 containers because
72629 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
72630 changed <tt>operator&lt;</tt> on <tt>shared_ptr</tt>s to be
72631 defined in terms of <tt>operator&lt;</tt> on the stored pointers (a mistake IMHO
72632 but too late now.)  By 5.9 [expr.rel]/2 the result of comparing builtin
72633 pointers is unspecified except in special cases which generally do not
72634 apply to <tt>shared_ptr</tt>.
72635 </p>
72636
72637 <p>
72638 Earlier versions of the WP
72639 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">n2798</a>,
72640 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">n2857</a>)
72641 had the following note on
72642 that paragraph:
72643 </p>
72644
72645 <blockquote>
72646 [Editor's
72647 note: It's not clear to me whether the first sentence is a requirement
72648 or a note. The second
72649 sentence seems to be a requirement, but it doesn't really belong here,
72650 under <tt>operator&lt;</tt>.]
72651 </blockquote>
72652
72653 <p>
72654 I agree completely - if partial specializations are needed they should
72655 be properly specified.
72656 </p>
72657
72658 <p>
72659 20.9.10.2.7 [util.smartptr.shared.cmp]/6 has a note saying the comparison operator
72660 allows <tt>shared_ptr</tt> objects to be used as keys in associative
72661 containers, which is misleading because something else like a
72662 <tt>std::less</tt> partial specialization is needed.  If it is not correct that
72663 note should be removed.
72664 </p>
72665
72666 <p>
72667 20.9.10.2.7 [util.smartptr.shared.cmp]/3 refers to '<tt>x</tt>' and
72668 '<tt>y</tt>' but the prototype has parameters '<tt>a</tt>' and
72669 '<tt>b</tt>' - that needs to be fixed even if the rest of the issue is
72670 NAD.
72671 </p>
72672
72673 <p>
72674 I see two ways to fix this, I prefer the first because it removes the
72675 need for any partial specializations and also fixes <tt>operator&gt;</tt> and
72676 other comparisons when defined in terms of <tt>operator&lt;</tt>.
72677 </p>
72678
72679 <ol>
72680 <li>
72681 <p>
72682 Replace 20.9.10.2.7 [util.smartptr.shared.cmp]/3 with the following and
72683 remove p5:
72684 </p>
72685
72686 <blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
72687 </pre>
72688 <blockquote>
72689 <p>
72690 3  <i>Returns:</i> <del><tt>x.get() &lt; y.get()</tt>.</del>
72691 <ins><tt>std::less&lt;V&gt;()(a.get(), b.get())</tt>, where <tt>V</tt> is the
72692 composite pointer type (5.9 [expr.rel]).</ins>
72693 </p>
72694
72695 <p>
72696 4 <i>Throws:</i> nothing.
72697 </p>
72698
72699 <p><del>
72700 5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
72701 partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
72702 the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
72703 <tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
72704 <tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
72705 <tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
72706 </del></p>
72707 <p>
72708 6 [<i>Note:</i> Defining a comparison operator allows
72709 <tt>shared_ptr</tt> objects to be used as keys in associative
72710 containers. \97 <i>end note</i>]
72711 </p>
72712 </blockquote>
72713 </blockquote>
72714 </li>
72715
72716
72717 <li>
72718 <p>
72719 Add to 20.9.10.2 [util.smartptr.shared]/1 (after the <tt>shared_ptr</tt> comparisons)
72720 </p>
72721
72722 <blockquote><pre>template&lt;class T&gt; struct greater&lt;shared_ptr&lt;T&gt;&gt;;
72723 template&lt;class T&gt; struct less&lt;shared_ptr&lt;T&gt;&gt;;
72724 template&lt;class T&gt; struct greater_equal&lt;shared_ptr&lt;T&gt;&gt;;
72725 template&lt;class T&gt; struct less_equal&lt;shared_ptr&lt;T&gt;&gt;;
72726 </pre></blockquote>
72727
72728 <p>
72729 Remove 20.9.10.2.7 [util.smartptr.shared.cmp]/5 and /6 and replace with:
72730 </p>
72731
72732 <blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
72733 </pre>
72734 <blockquote>
72735 <p>
72736 3  <i>Returns:</i> <tt><del>x</del><ins>a</ins>.get() &lt; <del>y</del><ins>b</ins>.get()</tt>.
72737 </p>
72738
72739 <p>
72740 4 <i>Throws:</i> nothing.
72741 </p>
72742
72743 <p><del>
72744 5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
72745 partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
72746 the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
72747 <tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
72748 <tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
72749 <tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
72750 </del></p>
72751 <p><del>
72752 6 [<i>Note:</i> Defining a comparison operator allows
72753 <tt>shared_ptr</tt> objects to be used as keys in associative
72754 containers. \97 <i>end note</i>]
72755 </del></p>
72756 </blockquote>
72757
72758 <pre><ins>
72759 template&lt;class T&gt; struct greater&lt;shared_ptr&lt;T&gt;&gt; :
72760 binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
72761   bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
72762 };
72763 </ins></pre>
72764
72765 <blockquote><ins>
72766 <tt>operator()</tt> returns <tt>greater&lt;T*&gt;()(a.get(), b.get())</tt>.
72767 </ins></blockquote>
72768
72769 <pre><ins>
72770 template&lt;class T&gt; struct less&lt;shared_ptr&lt;T&gt;&gt; :
72771 binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
72772   bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
72773 };
72774 </ins></pre>
72775
72776 <blockquote><ins>
72777 <tt>operator()</tt> returns <tt>less&lt;T*&gt;()(a.get(), b.get())</tt>.
72778 </ins></blockquote>
72779
72780 <pre><ins>
72781 template&lt;class T&gt; struct greater_equal&lt;shared_ptr&lt;T&gt;&gt; :
72782 binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
72783   bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
72784 };
72785 </ins></pre>
72786
72787 <blockquote><ins>
72788 <tt>operator()</tt> returns <tt>greater_equal&lt;T*&gt;()(a.get(), b.get())</tt>.
72789 </ins></blockquote>
72790
72791 <pre><ins>
72792 template&lt;class T&gt; struct less_equal&lt;shared_ptr&lt;T&gt;&gt; :
72793 binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
72794   bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
72795 };
72796 </ins></pre>
72797
72798 <blockquote><ins>
72799 <tt>operator()</tt> returns <tt>less_equal&lt;T*&gt;()(a.get(), b.get())</tt>.
72800 </ins></blockquote>
72801
72802 </blockquote>
72803 </li>
72804 </ol>
72805
72806 <p><i>[
72807 2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72808 ]</i></p>
72809
72810
72811
72812
72813 <p><b>Proposed resolution:</b></p>
72814 <p>
72815 Replace 20.9.10.2.7 [util.smartptr.shared.cmp]/3 with the following and
72816 remove p5:
72817 </p>
72818
72819 <blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
72820 </pre>
72821 <blockquote>
72822 <p>
72823 3  <i>Returns:</i> <del><tt>x.get() &lt; y.get()</tt>.</del>
72824 <ins><tt>less&lt;V&gt;()(a.get(), b.get())</tt>, where <tt>V</tt> is the
72825 composite pointer type (5.9 [expr.rel]) of <tt>T*</tt> and <tt>U*</tt>.</ins>
72826 </p>
72827
72828 <p>
72829 4 <i>Throws:</i> nothing.
72830 </p>
72831
72832 <p><del>
72833 5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
72834 partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
72835 the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
72836 <tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
72837 <tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
72838 <tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
72839 </del></p>
72840 <p>
72841 6 [<i>Note:</i> Defining a comparison operator allows
72842 <tt>shared_ptr</tt> objects to be used as keys in associative
72843 containers. \97 <i>end note</i>]
72844 </p>
72845 </blockquote>
72846 </blockquote>
72847
72848
72849
72850
72851
72852
72853 <hr>
72854 <h3><a name="1264"></a>1264. <tt>quick_exit</tt> support for freestanding implementations</h3>
72855 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72856  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-11-12 <b>Last modified:</b> 2010-10-23</p>
72857 <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>
72858 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72859 <p><b>Discussion:</b></p>
72860 <p><b>Addresses UK 172</b></p>
72861
72862 <p>
72863 This issue is a response to NB comment UK-172
72864 </p>
72865
72866 <p>
72867 The functions <tt>quick_exit</tt> and <tt>at_quick_exit</tt> should be
72868 added to the required features of <tt>&lt;cstdlib&gt;</tt> in a
72869 freestanding implementation.
72870 </p>
72871
72872 <p>
72873 This comment was rejected in Summit saying neither <tt>at_exit</tt> nor
72874 <tt>at_quick_exit</tt> should be required.  This suggests the comment was
72875 misread, as <tt>atexit</tt> is already required to be supported.  If the LWG
72876 really did wish to not require the registration functions be supported,
72877 then a separate issue should be opened to change the current standard.
72878 </p>
72879
72880 <p>
72881 Given both <tt>exit</tt> and <tt>atexit</tt> are required, the UK panel feels it is
72882 appropriate to require the new <tt>quick_exit</tt> facility is similarly
72883 supported.
72884 </p>
72885
72886 <p><i>[
72887 2009-12-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72888 ]</i></p>
72889
72890
72891
72892 <p><b>Proposed resolution:</b></p>
72893 <p>
72894 Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
72895 </p>
72896
72897 <blockquote>
72898 3 The supplied version of the header <tt>&lt;cstdlib&gt;</tt> shall
72899 declare at least the functions <tt>abort<del>()</del></tt>, <tt>atexit<del>()</del></tt>,
72900 <ins><tt>at_quick_exit</tt>,</ins> <del>and</del> <tt>exit<del>()</del></tt><ins>, and
72901 <tt>quick_exit</tt></ins>(18.5 [support.start.term]). The other
72902 headers listed in this table shall meet the same requirements as for a
72903 hosted implementation.
72904 </blockquote>
72905
72906
72907
72908
72909
72910
72911 <hr>
72912 <h3><a name="1267"></a>1267. Incorrect wording for <tt>condition_variable_any::wait_for</tt></h3>
72913 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
72914  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17 <b>Last modified:</b> 2010-10-23</p>
72915 <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>
72916 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
72917 <p><b>Discussion:</b></p>
72918 <p>
72919 30.5.2 [thread.condition.condvarany]p18 and 30.5.2 [thread.condition.condvarany]p27 specify incorrect preconditions for
72920 <tt>condition_variable_any::wait_for</tt>. The stated preconditions require that
72921 <tt>lock</tt> has a <tt>mutex()</tt> member function, and that this produces the
72922 same result for all concurrent calls to <tt>wait_for()</tt>. This is
72923 inconsistent with <tt>wait()</tt> and <tt>wait_until()</tt> which do not impose
72924 such a requirement.
72925 </p>
72926
72927 <p><i>[
72928 2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
72929 ]</i></p>
72930
72931
72932
72933 <p><b>Proposed resolution:</b></p>
72934 <p>
72935 Remove 30.5.2 [thread.condition.condvarany]p18 and 30.5.2 [thread.condition.condvarany]p27.
72936 </p>
72937 <blockquote>
72938 <pre>template &lt;class Lock, class Rep, class Period&gt;
72939   cv_status wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
72940 </pre>
72941 <blockquote>
72942 <p><del>
72943 18 <i>Precondition:</i> lock is locked by the calling thread, and either
72944 </del></p>
72945 <ul>
72946 <li><del>
72947 no other thread is waiting on this <tt>condition_variable</tt> object or
72948 </del></li>
72949 <li><del>
72950 <tt>lock.mutex()</tt> returns the same value for each of the lock arguments
72951 supplied by all concurrently waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or
72952 <tt>wait_until</tt>) threads.
72953 </del></li>
72954 </ul>
72955 </blockquote>
72956
72957 <p>...</p>
72958
72959 <pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
72960   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
72961 </pre>
72962
72963 <blockquote>
72964
72965 <p><del>
72966 27 Precondition: lock is locked by the calling thread, and either
72967 </del></p>
72968 <ul>
72969 <li><del>
72970 no other thread is waiting on this <tt>condition_variable</tt> object or
72971 </del></li>
72972 <li><del>
72973 <tt>lock.mutex()</tt> returns the same value for each of the lock arguments
72974 supplied by all concurrently waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or
72975 <tt>wait_until</tt>) threads.
72976 </del></li>
72977 </ul>
72978
72979 </blockquote>
72980
72981 </blockquote>
72982
72983
72984
72985
72986
72987
72988 <hr>
72989 <h3><a name="1268"></a>1268. The Mutex requirements in 30.4.1 and 30.4.2 are wrong</h3>
72990 <p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
72991  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17 <b>Last modified:</b> 2010-11-26</p>
72992 <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>
72993 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
72994 <p><b>Discussion:</b></p>
72995 <p>
72996 The <tt>Mutex</tt> requirements in 30.4.1 [thread.mutex.requirements] and
72997 30.4.1.3 [thread.timedmutex.requirements] confuse the requirements on the
72998 behaviour of <tt>std::mutex</tt> et al with the requirements on
72999 <tt>Lockable</tt> types for use with <tt>std::unique_lock</tt>,
73000 <tt>std::lock_guard</tt> and <tt>std::condition_variable_any</tt>.
73001 </p>
73002
73003 <p><i>[
73004 2010 Pittsburgh:
73005 ]</i></p>
73006
73007
73008 <blockquote>
73009 <p>
73010 Concepts of threads chapter and issue presentation are: Lockable &lt; Mutex &lt;
73011 TimedMutex and Lockable &lt; TimedLockable &lt; TimedMutex.
73012 </p>
73013 <p>
73014 Typo in failed deletion of Mutex in 30.4.4 p4 edits.
73015 </p>
73016 <p>
73017 Lockable requirements are too weak for condition_variable_any, but the Mutex
73018 requirements are too strong.
73019 </p>
73020 <p>
73021 Need subset of Lockable requirements for condition_variable_any that does not
73022 include try_lock. E.g. CvLockable &lt; Lockable.
73023 </p>
73024 <p>
73025 Text needs updating to recent draft changes.
73026 </p>
73027 <p>
73028 Needs to specify exception behavior in Lockable.
73029 </p>
73030 <p>
73031 The current standard is fine for what it says, but it places requirements that
73032 are too strong on authors of mutexes and locks.
73033 </p>
73034 <p>
73035 Move to open status. Suggest Anthony look at condition_variable_any
73036 requirements. Suggest Anthony refine requirements/concepts categories.
73037 </p>
73038 <p>
73039 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>
73040 </p>
73041 </blockquote>
73042
73043 <p><i>[
73044 2010-03-28 Daniel synced with N3092.
73045 ]</i></p>
73046
73047
73048 <p><i>[
73049 2010-10-25 Daniel adds:
73050 ]</i></p>
73051
73052
73053 <blockquote>
73054 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
73055 </blockquote>
73056
73057 <p><i>[
73058 2010-11 Batavia:
73059 ]</i></p>
73060
73061
73062 <blockquote>
73063 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.
73064 </blockquote>
73065
73066
73067
73068
73069 <p><b>Proposed resolution:</b></p>
73070 <p>
73071 Add a new section to 30.2 [thread.req] after 30.2.4 [thread.req.timing] as follows:
73072 </p>
73073
73074 <blockquote>
73075 <p>
73076 30.2.5 Requirements for Lockable types
73077 </p>
73078
73079 <p>
73080 The standard library templates <tt>unique_lock</tt> (30.4.2.2 [thread.lock.unique]), <tt>lock_guard</tt> (30.4.2.1 [thread.lock.guard]), <tt>lock</tt>, <tt>try_lock</tt> (30.4.3 [thread.lock.algorithm]) and <tt>condition_variable_any</tt> (30.5.2 [thread.condition.condvarany]) all operate on user-supplied
73081 <tt>Lockable</tt> objects. Such an object must support the member functions
73082 specified for either the <tt>Lockable</tt> Requirements or the
73083 <tt>TimedLockable</tt> requirements as appropriate to acquire or release
73084 ownership of a <tt>lock</tt> by a given <tt>thread</tt>. [<i>Note:</i> the
73085 nature of any lock ownership and any synchronization it may entail are not part
73086 of these requirements. \97 <i>end note</i>]
73087 </p>
73088
73089 <p>
73090 30.2.5.1  Lockable Requirements
73091 </p>
73092
73093 <p>
73094 In order to qualify as a <tt>Lockable</tt> type, the following expressions must
73095 be supported, with the specified semantics, where <tt>m</tt> denotes a value of
73096 type <tt>L</tt> that supports the <tt>Lockable</tt>:
73097 </p>
73098
73099 <p>
73100 The expression <tt>m.lock()</tt> shall be well-formed and have the following
73101 semantics:
73102 </p>
73103
73104 <dl>
73105   <dt>Effects:</dt><dd>Block until a lock can be acquired for the current thread.</dd>
73106   <dt>Return type:</dt><dd><tt>void</tt></dd>
73107 </dl>
73108
73109 <p>
73110 The expression <tt>m.try_lock()</tt> shall be well-formed and have the
73111 following semantics:
73112 </p>
73113
73114 <dl>
73115   <dt>Effects:</dt><dd>Attempt to acquire a lock for the current thread without blocking.</dd>
73116   <dt>Return type:</dt><dd><tt>bool</tt></dd>
73117   <dt>Returns:</dt><dd><tt>true</tt> if the lock was
73118   acquired, <tt>false</tt> otherwise.</dd>
73119 </dl>
73120
73121 <p>
73122 The expression <tt>m.unlock()</tt> shall be well-formed and have the
73123 following semantics:
73124 </p>
73125
73126 <dl>
73127   <dt>Effects:</dt><dd>Release a lock on <tt>m</tt> held by the current thread.</dd>
73128   <dt>Return type:</dt><dd><tt> void</tt></dd>
73129   <dt>Throws:</dt><dd> Nothing if the current thread holds a lock on <tt>m</tt>.</dd>
73130 </dl>
73131
73132 <p>
73133 30.2.5.2 <tt>TimedLockable</tt> Requirements
73134 </p>
73135
73136 <p>
73137 For a type to qualify as <tt>TimedLockable</tt> it must meet the
73138 <tt>Lockable</tt> requirements, and additionally the following
73139 expressions must be well-formed, with the specified semantics,
73140 where <tt>m</tt> is an instance of a type <tt>TL</tt> that supports
73141 the <tt>TimedLockable</tt> requirements, <tt>rel_time</tt> denotes
73142 instantiation of <tt>duration</tt> (20.11.3 [time.duration]) and <tt>abs_time</tt>
73143 denotes an instantiation of <tt>time_point</tt> (20.11.4 [time.point])
73144
73145 </p>
73146
73147 <p>
73148 The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the
73149 following semantics:
73150 </p>
73151
73152 <dl>
73153   <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
73154   thread within the specified time period.</dd>
73155   <dt>Return type:</dt><dd><tt>bool</tt></dd>
73156   <dt>Returns:</dt><dd><tt>true</tt> if the lock was
73157   acquired, <tt>false</tt> otherwise.</dd>
73158 </dl>
73159
73160 <p>
73161 The expression <tt>m.try_lock_until(abs_time)</tt> shall be well-formed and have the
73162 following semantics:
73163 </p>
73164
73165 <dl>
73166   <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
73167   thread before the specified point in time.</dd>
73168   <dt>Return type:</dt><dd><tt>bool</tt></dd>
73169   <dt>Returns:</dt><dd><tt>true</tt> if the lock was
73170   acquired, <tt>false</tt> otherwise.</dd>
73171 </dl>
73172 </blockquote>
73173
73174 <p>
73175 Replace 30.4.1 [thread.mutex.requirements] paragraph 2 with the
73176 following:
73177 </p>
73178
73179 <blockquote>
73180 2 This section describes requirements on <del>template argument types
73181 used to instantiate templates defined in</del> <ins>the mutex types
73182 supplied by</ins> the C++ standard library. <del>The template
73183 definitions in the C++ standard library refer</del> These types shall
73184 conform to the named <tt>Mutex</tt> requirements whose details are set
73185 out below.  In this description, <tt>m</tt> is an object
73186 of <del>a <tt>Mutex</tt> type</del>
73187 <ins>one of the standard library mutex types <tt>std::mutex</tt>,
73188 <tt>std::recursive_mutex</tt>, <tt>std::timed_mutex</tt> or
73189 <tt>std::recursive_timed_mutex</tt>.</ins>.
73190 </blockquote>
73191
73192 <p>
73193 Add the following paragraph after 30.4.1 [thread.mutex.requirements]
73194 paragraph 2:
73195 </p>
73196
73197 <blockquote><ins>
73198 A <tt>Mutex</tt> type shall conform to the <tt>Lockable</tt>
73199 requirements (30.2.5.1).
73200 </ins></blockquote>
73201
73202 <p>
73203 Replace 30.4.1.3 [thread.timedmutex.requirements] paragraph 1 with the
73204 following:
73205 </p>
73206
73207 <blockquote>
73208 <ins>The C++ standard library <tt>TimedMutex</tt> types <tt>std::timed_mutex</tt>
73209   and <tt>std::recursive_timed_mutex</tt> </ins>
73210 <del>A <tt>TimedMutex</tt> type</del> shall meet the requirements for
73211 a <tt>Mutex</tt> type. In addition, <del>it</del><ins>they</ins> shall
73212 meet the requirements set out <del>in this Clause 30.4.2</del><ins>below</ins>,
73213 where <tt>rel_time</tt> denotes an instantiation of <tt>duration</tt>
73214 (20.11.3 [time.duration]) and <tt>abs_time</tt> denotes an instantiation
73215 of <tt>time_point</tt> (20.11.4 [time.point]).
73216 </blockquote>
73217
73218 <p>
73219 Add the following paragraph after 30.4.1.3 [thread.timedmutex.requirements] paragraph 1:
73220 </p>
73221
73222 <blockquote><ins>
73223 A <tt>TimedMutex</tt> type shall conform to the <tt>TimedLockable</tt>
73224 requirements (30.2.5.1).
73225 </ins></blockquote>
73226
73227
73228 <p>
73229 Add the following paragraph following 30.4.2.1 [thread.lock.guard]
73230 paragraph 1:
73231 </p>
73232
73233 <blockquote><ins>
73234 The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
73235 requirements
73236 (30.2.5.1).
73237 </ins></blockquote>
73238
73239 <p>
73240 Add the following paragraph following 30.4.2.2 [thread.lock.unique]
73241 paragraph 1:
73242 </p>
73243
73244 <blockquote><ins>
73245 The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
73246 requirements
73247 (30.2.5.1). <tt>unique_lock&lt;Mutex&gt;</tt> meets the <tt>Lockable</tt>
73248 requirements. If <tt>Mutex</tt> meets the <tt>TimedLockable</tt> 
73249 requirements
73250 (30.2.5.2) then <tt>unique_lock&lt;Mutex&gt;</tt> also meets the
73251 <tt>TimedLockable</tt> requirements.
73252 </ins></blockquote>
73253
73254 <p>
73255 Replace the use of "mutex" or "mutex object" with "lockable object"
73256 throughout clause 30.4.2 [thread.lock] paragraph 1:
73257 </p>
73258
73259 <blockquote>
73260 1 A lock is an object that holds a reference to
73261 a <del>mutex</del><ins>lockable object</ins> and may unlock
73262 the <del>mutex</del><ins>lockable object</ins> during the lock's
73263 destruction (such as when leaving block scope). A thread of execution
73264 may use a lock to aid in managing <del>mutex</del> ownership <ins>of a
73265 lockable object</ins> in an exception safe manner. A lock is said to
73266 own a <del>mutex</del><ins>lockable object</ins> if it is currently
73267 managing the ownership of that <del>mutex</del><ins>lockable
73268 object</ins> for a thread of execution. A lock does not manage the
73269 lifetime of the <del>mutex</del><ins>lockable object</ins> it
73270 references.  [ Note: Locks are intended to ease the burden of
73271 unlocking the <del>mutex</del><ins>lockable object</ins> under both
73272 normal and exceptional circumstances. \97 end note ]
73273 </blockquote>
73274
73275 <p>30.4.2 [thread.lock] paragaph 2:</p>
73276
73277 <blockquote>
73278 2 Some lock constructors take tag types which describe what should be
73279 done with the <del>mutex</del><ins>lockable</ins> object during the
73280 lock's constuction.
73281 </blockquote>
73282
73283 <p>30.4.2.1 [thread.lock.guard] paragaph 1:</p>
73284
73285 <blockquote>
73286 1 An object of type <tt>lock_guard</tt> controls the ownership of a
73287   <del>mutex</del><ins>lockable</ins> object within a scope. A
73288 <tt>lock_guard</tt> object maintains ownership of
73289 a <del>mutex</del><ins>lockable</ins> object throughout
73290 the <tt>lock_guard</tt> object's lifetime. The behavior of a program
73291 is undefined if the <del>mutex</del><ins>lockable object</ins>
73292 referenced by <tt>pm</tt> does not exist for the entire lifetime (3.8)
73293 of the <tt>lock_guard</tt> object. <ins><tt>Mutex</tt> shall meet
73294   the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
73295 </blockquote>
73296
73297 <p>30.4.2.2 [thread.lock.unique] paragaph 1:</p>
73298
73299 <blockquote>
73300 1 An object of type <tt>unique_lock</tt> controls the ownership of
73301 a <del>mutex</del><ins>lockable object</ins> within a
73302 scope. <del>Mutex</del> <del>o</del><ins>O</ins>wnership <ins>of the
73303 lockable object</ins> may be acquired at construction or after
73304 construction, and may be transferred, after acquisition, to
73305 another <tt>unique_lock</tt> object. Objects of
73306 type <tt>unique_lock</tt> are not copyable but are movable. The
73307 behavior of a program is undefined if the contained
73308 pointer <tt>pm</tt> is not null and the mutex pointed to
73309 by <tt>pm</tt> does not exist for the entire remaining lifetime (3.8)
73310 of the <tt>unique_lock</tt> object. <ins><tt>Mutex</tt> shall meet
73311 the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
73312 </blockquote>
73313
73314
73315 <p>
73316 Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
73317  m,
73318 const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> in 
73319 30.4.2.2.1 [thread.lock.unique.cons] paragraph 18:
73320 </p>
73321
73322 <blockquote><pre>template &lt;class Clock, class Duration&gt;
73323   unique_lock(mutex_type&amp; m, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
73324 </pre>
73325
73326 <blockquote>
73327 18 <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex 
73328 the
73329 calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
73330 type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
73331 </blockquote>
73332 </blockquote>
73333
73334 <p>
73335 Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
73336  m,
73337 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> in 
73338 30.4.2.2.1 [thread.lock.unique.cons]
73339 paragraph 22
73340 </p>
73341
73342 <blockquote>
73343 22  <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex
73344  the
73345 calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
73346 type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
73347 </blockquote>
73348
73349 <p>
73350 Add the following as a precondition of <tt>bool try_lock_until(const
73351 chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> before
73352 30.4.2.2.2 [thread.lock.unique.locking] paragraph 8
73353 </p>
73354
73355 <blockquote><pre>template &lt;class Clock, class Duration&gt;
73356   bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
73357 </pre>
73358 <blockquote><ins>
73359 <i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
73360 <tt>TimedLockable</tt> requirements (30.2.5.2).
73361 </ins></blockquote>
73362 </blockquote>
73363
73364 <p>
73365 Add the following as a precondition of <tt>bool try_lock_for(const
73366 chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> before 
73367 30.4.2.2.2 [thread.lock.unique.locking] paragraph 12
73368 </p>
73369
73370 <blockquote><pre>template &lt;class Rep, class Period&gt;
73371   bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
73372 </pre>
73373 <blockquote><ins>
73374 <i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
73375 <tt>TimedLockable</tt> requirements (30.2.5.2).
73376 </ins></blockquote>
73377 </blockquote>
73378
73379 <p>
73380 Replace 30.4.3 [thread.lock.algorithm] p1 with the following:
73381 </p>
73382
73383 <blockquote><pre>template &lt;class L1, class L2, class... L3&gt; int try_lock(L1&amp;, L2&amp;, L3&amp;...);
73384 </pre>
73385 <blockquote>
73386 1 <i>Requires:</i> Each template parameter type shall meet the
73387 <tt><del>Mutex</del> <ins>Lockable</ins></tt> requirements
73388 <ins>(30.2.5.1).</ins><del>, except that a call to <tt>try_lock()</tt> 
73389 may throw
73390 an exception.</del> [<i>Note:</i> The <tt>unique_lock</tt> class 
73391 template meets
73392 these requirements when suitably instantiated. \97 <i>end note</i>]
73393 </blockquote>
73394 </blockquote>
73395
73396 <p>
73397 Replace 30.4.3 [thread.lock.algorithm] p4 with the following:
73398 </p>
73399
73400 <blockquote><pre>template &lt;class L1, class L2, class... L3&gt; void lock(L1&amp;, L2&amp;, L3&amp;...);
73401 </pre>
73402 <blockquote>
73403 4 <i>Requires:</i> Each template parameter type shall meet the
73404 <tt>Mutex<del>Mutex</del> <ins>Lockable</ins></tt>
73405 requirements <ins>(30.2.5.1).</ins><del>, except that a call to
73406 <tt>try_lock()</tt> may throw an exception.</del> [<i>Note:</i> The
73407 <tt>unique_lock</tt> class template meets these requirements when 
73408 suitably
73409 instantiated. \97 <i>end note</i>]
73410 </blockquote>
73411 </blockquote>
73412
73413 <p>
73414 Replace 30.5.2 [thread.condition.condvarany] paragraph 1 with:
73415 </p>
73416
73417 <blockquote>
73418 1 A <tt>Lock</tt> type shall meet the <del>requirements for a <tt>Mutex</tt>
73419 type</del> <ins><tt>Lockable</tt> requirements (30.2.5.1)</ins>, except 
73420 that
73421 <tt>try_lock</tt> is not required. [<i>Note:</i> All of the standard 
73422 mutex types
73423 meet this requirement. \97 <i>end note</i>]
73424 </blockquote>
73425
73426
73427
73428
73429
73430
73431 <hr>
73432 <h3><a name="1270"></a>1270. <tt>result_of</tt> should be moved to <tt>&lt;type_traits&gt;</tt></h3>
73433 <p><b>Section:</b> X [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73434  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-11-19 <b>Last modified:</b> 2010-10-23</p>
73435 <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>
73436 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73437 <p><b>Discussion:</b></p>
73438 <p><b>Addresses UK 198</b></p>
73439
73440 <p>
73441 NB Comment: UK-198 makes this request among others.  It refers to a more
73442 detailed issue that BSI did not manage to submit by the CD1 ballot deadline
73443 though.
73444 </p>
73445
73446 <p>
73447 <tt>result_of</tt> is essentially a metafunction to return the type of an
73448 expression, and belongs with the other library metafunctions in
73449 <tt>&lt;type_traits&gt;</tt> rather than lurking in <tt>&lt;functional&gt;</tt>.
73450  The current definition in <tt>&lt;functional&gt;</tt> made sense when
73451 <tt>result_of</tt> was nothing more than a protocol to enable several components
73452 in <tt>&lt;functional&gt;</tt> to provide their own result types, but it has
73453 become a more general tool.  For instance, <tt>result_of</tt> is now used in the
73454 threading and futures components.
73455 </p>
73456
73457 <p>
73458 Now that <tt>&lt;type_traits&gt;</tt> is a required header for free-standing
73459 implementations it will be much more noticeable (in such environments) that a
73460 particularly useful trait is missing, unless that implementation also chooses to
73461 offer <tt>&lt;functional&gt;</tt> as an extension.
73462 </p>
73463
73464 <p>
73465 The simplest proposal is to simply move the wording (editorial direction below)
73466 although a more consistent form for type_traits would reformat this as a table.
73467 </p>
73468
73469 <p>
73470 Following the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <tt>result_of</tt> now
73471 depends on the <tt>declval</tt> function template, tentatively provided
73472 in <tt>&lt;utility&gt;</tt> which is <em>not</em> (yet) required of a
73473 free-standing implementation.
73474 </p>
73475
73476 <p>
73477 This dependency is less of an issue when <tt>result_of</tt> continues to
73478 live in <tt>&lt;functional&gt;</tt>.
73479 </p>
73480
73481 <p>
73482 Personally, I would prefer to clean up the dependencies so both
73483 <tt>result_of</tt> and <tt>declval</tt> are available in a free-standing
73484 implementation, but that would require slightly more work than suggested
73485 here.  A minimal tweak would be to require <tt>&lt;utility&gt;</tt> in a
73486 free-standing implementation, although there are a couple of subtle
73487 issues with <tt>make_pair</tt>, which uses <tt>reference_wrapper</tt> in
73488 its protocol and that is much harder to separate cleanly from
73489 <tt>&lt;functional&gt;</tt>.
73490 </p>
73491
73492 <p>
73493 An alternative would be to enact the other half of
73494 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2979.html">N2979</a>
73495 and create a new minimal header for the new C++0x library facilities to
73496 be added to the freestanding requirements (plus <tt>swap</tt>.)
73497 </p>
73498
73499 <p>
73500 I have a mild preference for the latter, although there are clearly
73501 reasons to consider better library support for free-standing in general,
73502 and adding the whole of <tt>&lt;utility&gt;</tt> could be considered a step in that
73503 direction.  See NB comment
73504 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#JP23">JP-23</a>
73505 for other suggestions (<tt>array</tt>, <tt>ratio</tt>)
73506 </p>
73507
73508 <p><i>[
73509 2010-01-27 Beman updated wording.
73510 ]</i></p>
73511
73512
73513 <blockquote>
73514 <p>
73515 The original wording is preserved here:
73516 </p>
73517 <blockquote>
73518
73519 <p>
73520 Move X [func.ret] to a heading below 20.7 [meta].  Note
73521 that in principle we should not change the tag, although this is a new tag for
73522 0x.  If it has been stable since TR1 it is clearly immutable though.
73523 </p>
73524
73525 <p>
73526 This wording should obviously adopt any other changes currently in (Tentatively)
73527 Ready status that touch this wording, such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>.
73528 </p>
73529
73530 </blockquote>
73531 </blockquote>
73532
73533 <p><i>[
73534 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
73535 ]</i></p>
73536
73537
73538
73539
73540 <p><b>Proposed resolution:</b></p>
73541 <p><i>From Function objects 20.8 [function.objects], Header &lt;functional&gt; 
73542 synopsis, remove:</i></p>
73543 <blockquote>
73544   <pre>// 20.7.4 result_of:
73545 template &lt;class&gt; class result_of; <i>// undefined</i>
73546 template &lt;class F, class... Args&gt; class result_of&lt;F(ArgTypes...)&gt;;</pre>
73547 </blockquote>
73548
73549 <p><i>Remove Function object return types X [func.ret] in its entirety. 
73550 This sub-section reads:</i></p>
73551 <blockquote>
73552   <pre>namespace std {
73553   template &lt;class&gt; class result_of; <i>// undefined</i>
73554
73555   template &lt;class Fn, class... ArgTypes&gt;
73556   class result_of&lt;Fn(ArgTypes...)&gt; {
73557   public :
73558     // types
73559     typedef see below type;
73560   };
73561 }</pre>
73562   <p>Given an rvalue <code>fn</code> of type <code>Fn</code> and values <code>
73563   t1, t2, ..., tN</code> of types T1, T2, ..., TN in <code>ArgTypes</code>, 
73564   respectively, the type member is the result type of the expression <code>
73565   fn(t1, t2, ...,tN)</code>. The values <code>ti</code> are lvalues when the 
73566   corresponding type <code>Ti</code> is an lvalue-reference type, and rvalues 
73567   otherwise.</p>
73568 </blockquote>
73569 <p><i>To Header &lt;type_traits&gt; synopsis 20.7.2 [meta.type.synop], add at 
73570 the indicated location:</i></p>
73571 <blockquote>
73572   <pre>template &lt;class T&gt; struct underlying_type;
73573 <ins>template &lt;class T&gt; struct result_of; <i>// not defined
73574 </i>template &lt;class Fn, class... ArgTypes&gt; struct result_of&lt;Fn(ArgTypes...)&gt;;</ins></pre>
73575 </blockquote>
73576 <p><i>To Other transformations 20.7.7.6 [meta.trans.other], Table 51 \97 
73577 Other transformations, add:</i></p>
73578 <blockquote>
73579   <table style="border-collapse: collapse;" border="1" bordercolor="#111111" cellpadding="3" cellspacing="0">
73580     <tbody><tr>
73581       <td><b>Template</b></td>
73582       <td><b>Condition</b></td>
73583       <td><b>Comments</b></td>
73584     </tr>
73585     <tr>
73586       <td valign="top"><code>template &lt;class T&gt;<br>
73587       struct underlying_type;</code></td>
73588       <td valign="top"><code>T</code> shall be an enumeration type 
73589       (7.2)</td>
73590       <td valign="top">The member typedef <code>type</code> shall 
73591       name the underlying type of <code>T</code>.</td>
73592     </tr>
73593     <tr>
73594       <td valign="top"><ins><code>template &lt;class Fn, class... ArgTypes&gt;
73595       struct result_of&lt;Fn(ArgTypes...)&gt;;</code></ins></td>
73596       <td valign="top"><ins><code>Fn</code> shall be a function object type
73597       20.8 [function.objects], reference to function, or reference to
73598       function object type.
73599       <tt>decltype(declval&lt;Fn&gt;()(declval&lt;ArgTypes&gt;()...))</tt> shall
73600       be well formed.</ins></td>
73601       <td valign="top"><ins>The member typedef <code>type</code> 
73602       shall name the type <code>decltype(declval&lt;Fn&gt;()(declval&lt;ArgTypes&gt;()...))</code>.</ins></td>
73603     </tr>
73604   </tbody></table>
73605 </blockquote>
73606 <p>At the end of Other transformations 20.7.7.6 [meta.trans.other] add:</p>
73607
73608 <blockquote>
73609 <p>[<i>Example:</i> Given these definitions:</p>
73610
73611   <pre>typedef bool(&amp;PF1)();
73612 typedef short(*PF2)(long);
73613
73614 struct S {
73615 &nbsp; operator PF2() const;
73616 &nbsp; double operator()(char, int&amp;);
73617  };</pre>
73618 <p>the following assertions will hold:</p>
73619   <pre>static_assert(std::is_same&lt;<wbr>std::result_of&lt;S(int)&gt;::type, short&gt;::value, "Error!");
73620 static_assert(std::is_same&lt;<wbr>std::result_of&lt;S&amp;(unsigned char, int&amp;)&gt;::type, double&gt;::value, "Error!");
73621 static_assert(std::is_same&lt;<wbr>std::result_of&lt;PF1()&gt;::type, bool&gt;::value, "Error!");</pre>
73622   <p><i>&nbsp;\97 end example</i>]</p>
73623 </blockquote>
73624
73625
73626
73627
73628
73629 <hr>
73630 <h3><a name="1271"></a>1271. CR undefined in duration operators</h3>
73631 <p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73632  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-11-21 <b>Last modified:</b> 2010-10-23</p>
73633 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
73634 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73635 <p><b>Discussion:</b></p>
73636 <p>
73637 IMO <tt>CR</tt> alone is not really defined (it should be <tt>CR(Rep1,
73638 Rep2)</tt>).
73639 </p>
73640
73641 <p><i>[
73642 2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
73643 ]</i></p>
73644
73645
73646
73647 <p><b>Proposed resolution:</b></p>
73648 <p>
73649 Change 20.11.3.5 [time.duration.nonmember] paragraphs 9 and 12:
73650 </p>
73651
73652 <blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
73653   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
73654   operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
73655 </pre>
73656 <blockquote>
73657 9 <i>Returns:</i> <tt>duration&lt;CR<ins>(Rep1, Rep2)</ins>, Period&gt;(d) /= s</tt>.
73658 </blockquote>
73659
73660 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
73661   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
73662   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
73663 </pre>
73664 <blockquote>
73665 12 <i>Returns:</i> <tt>duration&lt;CR<ins>(Rep1, Rep2)</ins>, Period&gt;(d) %= s</tt>.
73666 </blockquote>
73667
73668 </blockquote>
73669
73670
73671
73672
73673
73674 <hr>
73675 <h3><a name="1276"></a>1276. <tt>forwardlist</tt> missing allocator constructors</h3>
73676 <p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73677  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-12-12 <b>Last modified:</b> 2010-10-23</p>
73678 <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>
73679 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73680 <p><b>Discussion:</b></p>
73681 <p>
73682 I found that forward_list has only
73683 </p>
73684
73685 <blockquote><pre>forward_list(const forward_list&lt;T,Allocator&gt;&amp; x);
73686 forward_list(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
73687 </pre></blockquote>
73688
73689 <p>
73690 but misses
73691 </p>
73692
73693 <blockquote><pre>forward_list(const forward_list&amp; x, const Allocator&amp;);
73694 forward_list(forward_list&amp;&amp; x, const Allocator&amp;);
73695 </pre></blockquote>
73696
73697 <p>
73698 Note to other reviewers: I also checked the container adaptors for similar
73699 inconsistencies, but as far as I can see these are already handled by the
73700 current active issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>.
73701 </p>
73702
73703 <p><i>[
73704 2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
73705 ]</i></p>
73706
73707
73708
73709 <p><b>Proposed resolution:</b></p>
73710 <p>
73711 In 23.3.3 [forwardlist]/3, class template forward_list synopsis change as
73712 indicated:
73713 </p>
73714
73715 <blockquote><pre>forward_list(const forward_list<del>&lt;T,Allocator&gt;</del>&amp; x);
73716 forward_list(forward_list<del>&lt;T,Allocator&gt;</del>&amp;&amp; x);
73717 <ins>forward_list(const forward_list&amp;, const Allocator&amp;);</ins>
73718 <ins>forward_list(forward_list&amp;&amp;, const Allocator&amp;);</ins>
73719 </pre></blockquote>
73720
73721
73722
73723
73724
73725
73726 <hr>
73727 <h3><a name="1277"></a>1277. <tt>std::thread::id</tt> should be trivially copyable</h3>
73728 <p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73729  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-24 <b>Last modified:</b> 2010-10-23</p>
73730 <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>
73731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73732 <p><b>Discussion:</b></p>
73733 <p>
73734 The class definition of <tt>std::thread::id</tt> in
73735 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
73736 is:
73737 </p>
73738
73739 <blockquote><pre>class thread::id {
73740 public:
73741   id();
73742 };
73743 </pre></blockquote>
73744
73745 <p>
73746 Typically, I expect that the internal data members will either be
73747 pointers or integers, so that in practice the class will be trivially
73748 copyable. However, I don't think the current wording guarantees it, and
73749 I think it would be useful. In particular, I can see a use for
73750 <tt>std::atomic&lt;std::thread::id&gt;</tt> to allow a <tt>thread</tt>
73751 to claim ownership of a data structure atomicly, and
73752 <tt>std::atomic&lt;T&gt;</tt> requires that <tt>T</tt> is trivially
73753 copyable.
73754 </p>
73755
73756 <p><i>[
73757 2010-02-12 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
73758 ]</i></p>
73759
73760
73761
73762
73763 <p><b>Proposed resolution:</b></p>
73764 <p>
73765 Add a new sentence to 30.3.1.1 [thread.thread.id] p1:
73766 </p>
73767
73768 <blockquote>
73769 1 An object of type <tt>thread::id</tt> provides a unique identifier for
73770 each thread of execution and a single distinct value for all
73771 <tt>thread</tt> objects that do not represent a thread of execution
73772 (30.3.1 [thread.thread.class]). Each thread of execution has an
73773 associated <tt>thread::id</tt> object that is not equal to the
73774 <tt>thread::id</tt> object of any other thread of execution and that is
73775 not equal to the <tt>thread::id</tt> object of any <tt>std::thread</tt>
73776 object that does not represent threads of execution. The library may
73777 reuse the value of a <tt>thread::id</tt> of a terminated thread that can
73778 no longer be joined. <ins><tt>thread::id</tt> shall be a trivially
73779 copyable class (9 [class]).</ins>
73780 </blockquote>
73781
73782
73783
73784
73785
73786
73787 <hr>
73788 <h3><a name="1278"></a>1278. inconsistent return values for <tt>forward_list::insert_after</tt></h3>
73789 <p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73790  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-11-25 <b>Last modified:</b> 2010-10-23</p>
73791 <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>
73792 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73793 <p><b>Discussion:</b></p>
73794 <p>
73795 After applying LDR<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <tt>forward_list</tt> now has 5
73796 overloads of <tt>insert_after</tt>, all returning an iterator.
73797 </p>
73798
73799 <p>
73800 However, two of those - inserting a single object - return "An iterator
73801 pointing to a copy of <tt>x</tt> [the inserted object]" while the other
73802 three - inserting zero or more objects - return an iterator equivalent
73803 to the position parameter, pointing before any possibly inserted
73804 objects.
73805 </p>
73806
73807 <p>
73808 Is this the intended change? 
73809 </p>
73810
73811 <p>
73812 I don't really know what <tt>insert_after(position, empty_range)</tt>
73813 should really return, but always returning <tt>position</tt> seems less
73814 than useful.
73815 </p>
73816
73817 <p><i>[
73818 2010-02-04 Howard adds:
73819 ]</i></p>
73820
73821
73822 <blockquote>
73823 <p>
73824 I agree this inconsistency will be error prone and needs to be fixed. 
73825 Additionally <tt>emplace_after</tt>'s return value is unspecified.
73826 </p>
73827 </blockquote>
73828
73829 <p><i>[
73830 2010-02-04 Nico provides wording.
73831 ]</i></p>
73832
73833
73834 <p><i>[
73835 2010 Pittsburgh:
73836 ]</i></p>
73837
73838
73839 <blockquote>
73840 We prefer to return an iterator to the last inserted element.  Modify the
73841 proposed wording and then set to Ready.
73842 </blockquote>
73843
73844 <p><i>[
73845 2010-03-15 Howard adds:
73846 ]</i></p>
73847
73848
73849 <blockquote>
73850 Wording updated and set to Ready.
73851 </blockquote>
73852
73853
73854
73855 <p><b>Proposed resolution:</b></p>
73856 <p>
73857 In <tt>forward_list</tt> modifiers 23.3.3.4 [forwardlist.modifiers]
73858 make the following modifications:
73859 </p>
73860
73861 <blockquote>
73862 <pre>iterator insert_after(const_iterator position, size_type n, const T&amp; x);
73863 </pre>
73864 <blockquote>
73865 <p>...</p>
73866 <p>
73867 10 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
73868 inserted copy of <tt>x</tt> or <tt>position</tt> if <tt>n == 0</tt>.</ins>
73869 </p>
73870 </blockquote>
73871
73872 <pre>template &lt;class InputIterator&gt;
73873   iterator insert_after(const_iterator position, InputIterator first, InputIterator last);
73874 </pre>
73875 <blockquote>
73876 <p>...</p>
73877
73878 <p>
73879 13 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
73880 inserted element or <tt>position</tt> if <tt>first == last</tt>.</ins>
73881 </p>
73882 </blockquote>
73883
73884 <pre>iterator insert_after(const_iterator position, initializer_list&lt;T&gt; il);
73885 </pre>
73886 <blockquote>
73887 <p>...</p>
73888
73889 <p>
73890 15 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
73891 inserted element or <tt>position</tt> if <tt>il</tt> is empty.</ins>
73892 </p>
73893 </blockquote>
73894
73895 <pre>template &lt;class... Args&gt;
73896   iterator emplace_after(const_iterator position, Args&amp;&amp;... args);
73897 </pre>
73898 <blockquote>
73899 <p>...</p>
73900 <p>17 ...</p>
73901
73902 <p><ins>
73903 <i>Returns:</i> An iterator pointing to the new constructed element from
73904 args.
73905 </ins></p>
73906 </blockquote>
73907
73908 </blockquote>
73909
73910
73911
73912
73913
73914
73915 <hr>
73916 <h3><a name="1280"></a>1280. initialization of stream iterators</h3>
73917 <p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.2.1 [ostream.iterator.cons.des] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
73918  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-04 <b>Last modified:</b> 2010-10-23</p>
73919 <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>
73920 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
73921 <p><b>Discussion:</b></p>
73922 <p>
73923 24.6.1.1 [istream.iterator.cons] describes the effects in terms of:
73924 </p>
73925
73926 <blockquote><pre>basic_istream&lt;charT,traits&gt;* in_stream; // exposition only
73927 </pre>
73928
73929 <p>
73930 3 <i>Effects:</i> Initializes <i>in_stream</i> with <tt>s</tt>.
73931 </p>
73932 </blockquote>
73933
73934 <p>
73935 That should be <tt>&amp;s</tt> and similarly for 24.6.2.1 [ostream.iterator.cons.des].
73936 </p>
73937
73938 <p><i>[
73939 2009-12-23 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
73940 ]</i></p>
73941
73942
73943
73944 <p><b>Proposed resolution:</b></p>
73945 <p>
73946 Change 24.6.1.1 [istream.iterator.cons] like so:
73947 </p>
73948
73949 <blockquote><pre>istream_iterator(istream_type&amp; s);
73950 </pre>
73951 <blockquote>
73952 3 <i>Effects:</i> Initializes <i>in_stream</i> with <tt><ins>&amp;</ins>s</tt>.
73953 <i>value</i> ...
73954 </blockquote>
73955 </blockquote>
73956
73957 <p>
73958 And 24.6.2.1 [ostream.iterator.cons.des] like so:
73959 </p>
73960
73961 <blockquote><pre>ostream_iterator(ostream_type&amp; s);
73962 </pre>
73963 <blockquote>
73964 1 <i>Effects:</i> Initializes <i>out_stream</i> with <tt><ins>&amp;</ins>s</tt>
73965 and <i>delim</i> with null.
73966 </blockquote>
73967
73968 <pre>ostream_iterator(ostream_type&amp; s, const charT* delimiter);
73969 </pre>
73970 <blockquote>
73971 2 <i>Effects:</i> Initializes <i>out_stream</i> with <tt><ins>&amp;</ins>s</tt>
73972 and <i>delim</i> with <tt>delimiter</tt>.
73973 </blockquote>
73974 </blockquote>
73975
73976
73977
73978
73979
73980
73981 <hr>
73982 <h3><a name="1283"></a>1283. <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> need clarification
73983 of moved-from state</h3>
73984 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
73985  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-12 <b>Last modified:</b> 2010-11-19</p>
73986 <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>
73987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
73988 <p><b>Discussion:</b></p>
73989 <p><b>Addresses UK 150</b></p>
73990
73991 <p>
73992 There is on going confusion over what one can and can not do with a moved-from
73993 object (e.g.
73994 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#UK150">UK 150</a>,
73995 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>).
73996 This issue attempts to clarify that moved-from objects are valid objects with an
73997 unknown state.
73998 </p>
73999
74000 <p><i>[
74001 2010-01-22 Wording tweaked by Beman.
74002 ]</i></p>
74003
74004
74005 <p><i>[
74006 2010-01-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74007 ]</i></p>
74008
74009
74010 <p><i>[
74011 2010-01-23 Alisdair opens:
74012 ]</i></p>
74013
74014
74015 <blockquote>
74016 <p>
74017 I'm afraid I must register an objection.
74018 </p>
74019
74020 <p>
74021 My primary objection is that I have always been opposed to this kind of a
74022 resolution as over-constraining.  My preferred example is a call implementing
74023 the pImpl idiom via <tt>unique_ptr</tt>.  Once the pImpl has been moved from, it
74024 is no longer safe to call the vast majority of the object's methods, yet I see
74025 no reason to make such a type unusable in the standard library.  I would prefer
74026 a resolution along the lines suggested in the UK comment, which only requires
74027 that the object can be safely destroyed, and serve as the target of an
74028 assignment operator (if supported.)
74029 </p>
74030
74031 <p>
74032 However, I will not hold the issue up if I am a lone dissenting voice on this
74033 (yes, that is a call to hear more support, or I will drop that objection in
74034 Pittsburgh)
74035 </p>
74036
74037 <p>
74038 With the proposed wording, I'm not clear what the term 'valid object' means.  In
74039 my example above, is a pImpl holding a null pointer 'valid'?  What about a float
74040 holding a signalling NaN?  What determines if an object is valid?  Without a
74041 definition of a valid/invalid object, I don't think this wording adds anything,
74042 and this is an objection that I do want resolved.
74043 </p>
74044
74045 <p><i>[
74046 2010-01-24 Alisdair removes his objection.
74047 ]</i></p>
74048
74049
74050 <p><i>[
74051 2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74052 ]</i></p>
74053
74054
74055 </blockquote>
74056
74057 <p><i>[
74058 2010-02-10 Reopened.  The wording here has been merged into <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>.
74059 ]</i></p>
74060
74061
74062 <p><i>[
74063 2010-02-10 Moved to Tentatively <del>NAD Editorial</del><ins>Resolved</ins> after 5 postive votes on
74064 c++std-lib.  Rationale added below.
74065 ]</i></p>
74066
74067
74068
74069
74070 <p><b>Rationale:</b></p>
74071 <p>
74072 This issue is now addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>.
74073 </p>
74074
74075
74076 <p><b>Proposed resolution:</b></p>
74077 <p>
74078 Change the follwing tables in 20.2.1 [utility.arg.requirements] as shown:
74079 </p>
74080
74081 <blockquote>
74082
74083 <table border="1">
74084 <caption>Table 33 \97 <tt>MoveConstructible</tt> requirements <b>[moveconstructible]</b></caption>
74085 <tbody><tr>
74086 <th>Expression</th>
74087 <th>Post-condition</th>
74088 </tr>
74089 <tr>
74090 <td>
74091 <tt>T t(rv)</tt>
74092 </td>
74093 <td>
74094 <tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction.
74095 </td>
74096 </tr>
74097 <tr>
74098 <td colspan="2">
74099 [<i>Note:</i>
74100 <del>There is no requirement on the value of <tt>rv</tt> after the
74101 construction.</del>
74102 <ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
74103 \97 <i>end note</i>]
74104 </td>
74105 </tr>
74106 </tbody></table>
74107
74108 </blockquote>
74109 <blockquote>
74110
74111 <table border="1">
74112 <caption>Table 35 \97 <tt>MoveAssignable</tt> requirements <b>[moveassignable]</b></caption>
74113 <tbody><tr>
74114 <th>Expression</th>
74115 <th>Return type</th>
74116 <th>Return value</th>
74117 <th>Post-condition</th>
74118 </tr>
74119 <tr>
74120 <td>
74121 <tt>t = rv</tt>
74122 </td>
74123 <td>
74124 <tt>T&amp;</tt>
74125 </td>
74126 <td>
74127 <tt>t</tt>
74128 </td>
74129 <td>
74130 <tt>t</tt> is equivalent to the value of <tt>rv</tt> before the assigment.
74131 </td>
74132 </tr>
74133 <tr>
74134 <td colspan="4">
74135 [<i>Note:</i>
74136 <del>There is no requirement on the value of <tt>rv</tt> after the
74137 assignment.</del>
74138 <ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
74139 \97 <i>end note</i>]
74140 </td>
74141 </tr>
74142 </tbody></table>
74143
74144 </blockquote>
74145
74146
74147
74148
74149
74150 <hr>
74151 <h3><a name="1284"></a>1284. <tt>vector&lt;bool&gt; initializer_list</tt> constructor missing an allocator argument</h3>
74152 <p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74153  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-12-09 <b>Last modified:</b> 2010-10-23</p>
74154 <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>
74155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74156 <p><b>Discussion:</b></p>
74157 <p>
74158 The specialization for <tt>vector&lt;bool&gt;</tt> (23.4.2 [vector.bool])
74159 has a constructor
74160 </p>
74161
74162 <blockquote><pre>vector(initializer_list&lt;bool&gt;);
74163 </pre></blockquote>
74164
74165 <p>
74166 which differs from the base template's constructor (and other containers) in
74167 that it has no <tt>allocator</tt> parameter.
74168 </p>
74169
74170 <p><i>[
74171 2009-12-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74172 ]</i></p>
74173
74174
74175
74176 <p><b>Proposed resolution:</b></p>
74177 <p>
74178 Change the signature in the synopsis of 23.4.2 [vector.bool] to 
74179 </p>
74180
74181 <blockquote><pre>vector(initializer_list&lt;bool&gt;<ins>, const Allocator&amp; = Allocator()</ins>);
74182 </pre></blockquote>
74183
74184
74185
74186
74187
74188 <hr>
74189 <h3><a name="1285"></a>1285. <tt>allocator_traits</tt> call to <tt>new</tt></h3>
74190 <p><b>Section:</b> 20.9.4.2 [allocator.traits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74191  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-10 <b>Last modified:</b> 2010-10-23</p>
74192 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.traits.members">issues</a> in [allocator.traits.members].</p>
74193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74194 <p><b>Discussion:</b></p>
74195 <p>
74196 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> added "<tt>::</tt>" to the call to <tt>new</tt>
74197 within <tt>allocator::construct</tt>.  I suspect we want to retain that fix.
74198 </p>
74199
74200 <p><i>[
74201 2009-12-13 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
74202 ]</i></p>
74203
74204
74205
74206 <p><b>Proposed resolution:</b></p>
74207 <p>
74208 Change 20.2.5 [allocator.requirements], table 40 "Allocator requirements":
74209 </p>
74210
74211 <blockquote>
74212 <table border="1">
74213 <caption>Table 40 \97 Allocator requirements</caption>
74214 <tbody><tr>
74215 <th>Expression</th>
74216 <th>Return type</th>
74217 <th>Assertion/note<br>pre-/post-condition</th>
74218 <th>Default</th>
74219 </tr>
74220 <tr>
74221 <td>
74222 <tt>a.construct(c,args)</tt>
74223 </td>
74224 <td>
74225 (not used)
74226 </td>
74227 <td>
74228 Effect: Constructs an object of type <tt>C</tt> at <tt>c</tt>
74229 </td>
74230 <td>
74231 <tt><ins>::</ins>new ((void*)c) C(forward&lt;Args&gt;(args)...)</tt>
74232 </td>
74233 </tr>
74234 </tbody></table>
74235 </blockquote>
74236
74237 <p>
74238 Change 20.9.4.2 [allocator.traits.members], p4:
74239 </p>
74240
74241 <blockquote><pre>template &lt;class T, class... Args&gt;
74242   static void construct(Alloc&amp; a, T* p, Args&amp;&amp;... args);
74243 </pre>
74244 <blockquote>
74245 4 <i>Effects:</i> calls <tt>a.construct(p,
74246 std::forward&lt;Args&gt;(args)...)</tt> if that call is well-formed; otherwise,
74247 invokes <tt><ins>::</ins>new (static_cast&lt;void*&gt;(p))
74248 T(std::forward&lt;Args&gt;(args)...)</tt>.
74249 </blockquote>
74250 </blockquote>
74251
74252
74253
74254
74255
74256 <hr>
74257 <h3><a name="1286"></a>1286. <tt>allocator_traits::select_on_container_copy_construction</tt> type-o</h3>
74258 <p><b>Section:</b> 20.9.4.2 [allocator.traits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74259  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-10 <b>Last modified:</b> 2010-10-23</p>
74260 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.traits.members">issues</a> in [allocator.traits.members].</p>
74261 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74262 <p><b>Discussion:</b></p>
74263 <p>
74264 <tt>allocator_traits::select_on_container_copy_construction</tt> refers to an
74265 unknown "<tt>a</tt>":
74266 </p>
74267
74268 <blockquote><pre>static Alloc select_on_container_copy_construction(const Alloc&amp; rhs);
74269 </pre>
74270
74271 <blockquote>
74272 7 <i>Returns:</i> <tt>rhs.select_on_container_copy_construction(a)</tt> if that
74273 expression is well-formed; otherwise, <tt>rhs</tt>.
74274 </blockquote>
74275 </blockquote>
74276
74277 <p><i>[
74278 2009-12-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74279 ]</i></p>
74280
74281
74282
74283
74284 <p><b>Proposed resolution:</b></p>
74285 <p>
74286 Change 20.9.4.2 [allocator.traits.members], p7:
74287 </p>
74288
74289 <blockquote><pre>static Alloc select_on_container_copy_construction(const Alloc&amp; rhs);
74290 </pre>
74291
74292 <blockquote>
74293 7 <i>Returns:</i>
74294 <tt>rhs.select_on_container_copy_construction(<del>a</del>)</tt> if that
74295 expression is well-formed; otherwise, <tt>rhs</tt>.
74296 </blockquote>
74297 </blockquote>
74298
74299
74300
74301
74302
74303 <hr>
74304 <h3><a name="1287"></a>1287. <tt>std::function</tt> requires <tt>CopyConstructible</tt> target object</h3>
74305 <p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74306  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-13 <b>Last modified:</b> 2010-10-23</p>
74307 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
74308 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74309 <p><b>Discussion:</b></p>
74310 <p>
74311 I think <tt>std::function</tt> should require <tt>CopyConstructible</tt> for the
74312 target object.
74313 </p>
74314
74315 <p>
74316 I initially thought that <tt>MoveConstructible</tt> was enough, but it's not. If
74317 <tt>F</tt> is move-only then function's copy constructor cannot be called, but
74318 because function uses type erasure, <tt>F</tt> is not known and so the copy
74319 constructor cannot be disabled via <tt>enable_if</tt>.  One option would be to
74320 throw an exception if you try to copy a function with a non-copyable target
74321 type, but I think that would be a terrible idea.
74322 </p>
74323
74324 <p>
74325 So although the constructors require that the target be initialised by
74326 <tt>std::move(f)</tt>, that's only an optimisation, and a copy constructor is
74327 required.
74328 </p>
74329
74330 <p><i>[
74331 2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74332 ]</i></p>
74333
74334
74335
74336
74337 <p><b>Proposed resolution:</b></p>
74338 <p>
74339 Add to 20.8.14.2.1 [func.wrap.func.con] paragraph 9:
74340 </p>
74341
74342 <blockquote><pre>template&lt;class F&gt; function(F f);
74343 template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
74344 </pre>
74345
74346 <blockquote>
74347 9  <i>Requires:</i> <ins><tt>F</tt> shall be <tt>CopyConstructible</tt>.</ins>
74348 <tt>f</tt> shall be callable for argument types <tt>ArgTypes</tt> and return
74349 type <tt>R</tt>. The copy constructor and destructor of <tt>A</tt> shall not
74350 throw exceptions.
74351 </blockquote>
74352 </blockquote>
74353
74354
74355
74356
74357
74358
74359 <hr>
74360 <h3><a name="1288"></a>1288. <tt>std::function</tt> assignment from rvalues</h3>
74361 <p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74362  <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-13 <b>Last modified:</b> 2010-10-23</p>
74363 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
74364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74365 <p><b>Discussion:</b></p>
74366 <p>
74367 In 20.8.14.2.1 [func.wrap.func.con]
74368 </p>
74369
74370 <blockquote><pre>template&lt;class F&gt; function&amp; operator=(F f);
74371 </pre>
74372 <blockquote>
74373 <p>
74374 20        <i>Effects:</i> <tt>function(f).swap(*this);</tt>
74375 </p>
74376 <p>
74377 21        <i>Returns:</i> <tt>*this</tt>
74378 </p>
74379 </blockquote>
74380 </blockquote>
74381
74382 <p>
74383 This assignment operator can be called such that <tt>F</tt> is an rvalue-reference e.g.
74384 </p>
74385
74386 <blockquote><pre>func.operator=&lt;F&amp;&amp;&gt;(f);
74387 </pre></blockquote>
74388
74389 <p>
74390 There are two issues with this.
74391 </p>
74392
74393 <ol>
74394 <li>
74395 the effects mean that <tt>f</tt> is passed as an lvalue and so there will be an
74396 unnecessary copy. The argument should be forwarded, so that the copy can be
74397 avoided.
74398 </li>
74399 <li>
74400 It should not be necessary to use that syntax to pass an rvalue. As <tt>F</tt>
74401 is a deduced context it can be made to work with either lvalues or rvalues.
74402 </li>
74403 </ol>
74404
74405 <p>
74406 The same issues apply to <tt>function::assign</tt>.
74407 </p>
74408
74409 <p>
74410 N.B. this issue is not related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a> and applies whether that
74411 issue is resolved or not. The wording below assumes the resolution of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a> has been applied.
74412 </p>
74413
74414 <p><i>[
74415 2009-12-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74416 ]</i></p>
74417
74418
74419 <p><i>[
74420 201002-11 Opened by Alisdair for the purpose of merging <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a> into
74421 this issue as there is a minor conflict.
74422 ]</i></p>
74423
74424
74425 <p><i>[
74426 2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74427 ]</i></p>
74428
74429
74430
74431
74432 <p><b>Proposed resolution:</b></p>
74433 <p>
74434 In 20.8.14.2.1 [func.wrap.func.con]
74435 </p>
74436
74437 <blockquote><pre>template&lt;class F&gt; function&amp; operator=(F<ins>&amp;&amp;</ins> f);
74438 </pre>
74439 <blockquote>
74440 <p>
74441 20 <i>Effects:</i>
74442 <tt>function(<ins>std::forward&lt;F&gt;(</ins>f<ins>)</ins>).swap(*this);</tt>
74443 </p>
74444 <p>
74445 21        <i>Returns:</i> <tt>*this</tt>
74446 </p>
74447 </blockquote>
74448 </blockquote>
74449
74450 <p>
74451 In 20.8.14.2.2 [func.wrap.func.mod]
74452 </p>
74453
74454 <blockquote><pre>template&lt;class F, <del>Allocator Alloc</del><ins>class A</ins>&gt;
74455   void assign(F<ins>&amp;&amp; f</ins>, const A<del>lloc</del>&amp; a);
74456 </pre>
74457 <blockquote>
74458 <p>
74459 <ins>3</ins> <i>Effects:</i> <tt>function(<del>f, a</del><ins>allocator_arg, a,
74460 std::forward&lt;F&gt;(f)</ins>).swap(*this);</tt>
74461 </p>
74462 </blockquote>
74463 </blockquote>
74464
74465 <p>
74466 Update member function signature for class template in 20.8.14.2 [func.wrap.func]
74467 </p>
74468
74469 <blockquote><pre>template&lt;class F&gt; function&amp; operator=(F<ins>&amp;&amp;</ins>);
74470
74471 template&lt;class F, class A&gt; void assign(F<ins>&amp;&amp;</ins>, const A&amp;);
74472 </pre></blockquote>
74473
74474
74475
74476
74477
74478
74479
74480 <hr>
74481 <h3><a name="1290"></a>1290. Don't require <tt>[u|bi]nary_function</tt> inheritance</h3>
74482 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
74483  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-12-14 <b>Last modified:</b> 2010-11-26</p>
74484 <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>
74485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
74486 <p><b>Discussion:</b></p>
74487 <p>
74488 This issue is a follow-up of the discussion on issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a> during
74489 the 2009 Santa Cruz meeting.
74490 </p>
74491
74492 <p>
74493 The class templates <tt>unary_function</tt> and <tt>binary_function</tt> are
74494 actually very simple typedef providers,
74495 </p>
74496
74497 <blockquote><pre>namespace std {
74498
74499 template &lt;class Arg, class Result&gt;
74500 struct unary_function {
74501  typedef Arg argument_type;
74502  typedef Result result_type;
74503 };
74504
74505 template &lt;class Arg1, class Arg2, class Result&gt;
74506 struct binary_function {
74507  typedef Arg1 first_argument_type;
74508  typedef Arg2 second_argument_type;
74509  typedef Result result_type;
74510 };
74511
74512 }
74513 </pre></blockquote>
74514
74515 <p>
74516 which <i>may</i> be used as base classes (similarly to the iterator template),
74517 but were originally <i>not</i> intended as a customization point. The SGI
74518 documentation introduced the concept <a href="http://www.sgi.com/tech/stl/AdaptableUnaryFunction.html">Adaptable Unary
74519 Function</a> as function objects "with nested typedefs that define its argument
74520 type and result type" and a similar definition for <a href="http://www.sgi.com/tech/stl/AdaptableBinaryFunction.html">Adaptable Binary
74521 Function</a> related to <tt>binary_function</tt>. But as of TR1 a protocol was
74522 introduced that relies on inheritance relations based on these types. 20.8.4 [refwrap]/3 b. 3 requires that a specialization of
74523 <tt>reference_wrapper&lt;T&gt;</tt> shall derive from <tt>unary_function</tt>,
74524 if type <tt>T</tt> is "a class type that is derived from
74525 <tt>std::unary_function&lt;T1, R&gt;</tt>" and a similar inheritance-based rule
74526 for <tt>binary_function</tt> exists as well.
74527 </p>
74528
74529 <p>
74530 As another disadvantage it has been pointed out in the TR1 issue list, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>
74531 (see section 10.39), that the requirements of <tt>mem_fn</tt> 20.8.13 [func.memfn]/2+3 to <em>derive</em> from
74532 <tt>std::unary_function/std::binary_function</tt> under circumstances, where the
74533 provision of corresponding typedefs would be sufficient, unnecessarily prevent
74534 implementations that take advantage of empty-base-class- optimizations.
74535 </p>
74536
74537 <p>
74538 Both requirements should be relaxed in the sense that the
74539 <tt>reference_wrapper</tt> should provide typedef's <tt>argument_type</tt>,
74540 <tt>first_argument_type</tt>, and <tt>second_argument_type</tt> based on similar
74541 rules as the <i>weak result type</i> rule (20.8.2 [func.require]/3) does
74542 specify the presence of <tt>result_type</tt> member types.
74543 </p>
74544
74545 <p>
74546 For a related issue see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>.
74547 </p>
74548
74549 <p><i>[
74550 2010-10-24 Daniel adds:
74551 ]</i></p>
74552
74553
74554 <blockquote>
74555 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3145.html">n3145</a> would resolve this issue as NAD editorial.
74556 </blockquote>
74557
74558
74559
74560 <p><i>[
74561 2010-11 Batavia: Solved by N3198
74562 ]</i></p>
74563
74564 <p>
74565 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">n3198</a>.
74566 </p>
74567
74568 <p>
74569 Previous proposed resolution:
74570
74571 </p><p><i>[
74572 The here proposed resolution is an attempt to realize the common denominator of
74573 the reflector threads c++std-lib-26011, c++std-lib-26095, and c++std-lib-26124.
74574 ]</i></p>
74575
74576
74577 <ol>
74578 <li>
74579 <p>
74580 Change X [base]/1 as indicated: <i>[The intend is to provide an
74581 alternative fix for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a> and some editorial harmonization
74582 with existing wording in the library, like 24.4.2 [iterator.basic]/1]</i>
74583 </p>
74584
74585 <blockquote>
74586 <p>
74587 1 The following class<ins> templat</ins>es are provided to simplify the
74588 <ins>definition of</ins> typedefs of the argument and result types <ins>for
74589 function objects. The behavior of a program that adds specializations for any of
74590 these templates is undefined.</ins><del>:</del>
74591 </p>
74592
74593 <blockquote><pre>namespace std {
74594  template &lt;class Arg, class Result&gt;
74595  struct unary_function {
74596    typedef Arg argument_type;
74597    typedef Result result_type;
74598  };
74599 }
74600
74601 namespace std {
74602  template &lt;class Arg1, class Arg2, class Result&gt;
74603  struct binary_function {
74604    typedef Arg1 first_argument_type;
74605    typedef Arg2 second_argument_type;
74606    typedef Result result_type;
74607  };
74608 }
74609 </pre></blockquote>
74610 </blockquote>
74611 </li>
74612
74613 <li>
74614 <p>
74615 Change 20.8.4 [refwrap], class template <tt>reference_wrapper</tt>
74616 synopsis as indicated: <i>[The intent is to remove the requirement that
74617 <tt>reference_wrapper</tt> derives from <tt>unary_function</tt> or
74618 <tt>binary_function</tt> if the situation requires the definition of the
74619 typedefs <tt>argument_type</tt>, <tt>first_argument_type</tt>, or
74620 <tt>second_argument_type</tt>. This change is suggested, because the new way of
74621 definition uses the same strategy as the <em>weak result type</em> specification
74622 applied to argument types, which provides the following advantages: It creates
74623 less potential conflicts between <tt>[u|bi]nary_function</tt> bases and typedefs
74624 in a function object and it ensures that user-defined function objects which
74625 provide typedefs but no such bases are handled as first class citizens.]</i>
74626 </p>
74627
74628 <blockquote><pre>namespace std {
74629  template &lt;class T&gt; class reference_wrapper
74630    <del>: public unary_function&lt;T1, R&gt; // <i>see below</i></del>
74631    <del>: public binary_function&lt;T1, T2, R&gt; // <i>see below</i></del>
74632  {
74633  public :
74634    // types
74635    typedef T type;
74636    typedef <i>see below</i> result_type; // not always defined
74637    <ins>typedef <i>see below</i> argument_type; // not always defined</ins>
74638    <ins>typedef <i>see below</i> first_argument_type; // not always defined</ins>
74639    <ins>typedef <i>see below</i> second_argument_type; // not always defined</ins>
74640
74641    // construct/copy/destroy
74642    ...
74643  };
74644 </pre></blockquote>
74645 </li>
74646
74647 <li>
74648 <p>
74649 Change 20.8.4 [refwrap]/3 as indicated: <i>[The intent is to remove the
74650 requirement that <tt>reference_wrapper</tt> derives from <tt>unary_function</tt>
74651 if the situation requires the definition of the typedef <tt>argument_type</tt>
74652 and <tt>result_type</tt>. Note that this clause does concentrate on
74653 <tt>argument_type</tt> alone, because the <tt>result_type</tt> is already ruled
74654 by p. 2 via the <em>weak result type</em> specification. The new way of
74655 specifying <tt>argument_type</tt> is equivalent to the <em>weak result type</em>
74656 specification]</i>
74657 </p>
74658
74659 <blockquote>
74660 <p>
74661 3 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
74662 derived from <tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>define a nested
74663 type named <tt>argument_type</tt> as a synonym for <tt>T1</tt></ins> only if the
74664 type <tt>T</tt> is any of the following:
74665 </p>
74666 <ul>
74667 <li>a function type or a pointer to function type taking one argument
74668 of type <tt>T1</tt><del> and returning <tt>R</tt></del>
74669 </li>
74670 <li>a pointer to member function <tt>R T0::f</tt> <em>cv</em> (where
74671 <em>cv</em> represents the member function's cv-qualifiers);
74672 the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
74673 </li>
74674 <li>a class type <del>that is derived from
74675 <tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>with a member type
74676 <tt>argument_type</tt>;
74677         the type <tt>T1</tt> is <tt>T::argument_type</tt></ins>
74678 </li>
74679 </ul>
74680 </blockquote>
74681 </li>
74682
74683 <li>
74684 <p>
74685 Change 20.8.4 [refwrap]/4 as indicated: <i>[The intent is to remove the
74686 requirement that <tt>reference_wrapper</tt> derives from
74687 <tt>binary_function</tt> if the situation requires the definition of the typedef
74688 <tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
74689 <tt>result_type</tt>. Note that this clause does concentrate on
74690 <tt>first_argument_type</tt> and <tt>second_argument_type</tt> alone, because
74691 the <tt>result_type</tt> is already ruled by p. 2 via the <em>weak result
74692 type</em> specification. The new way of specifying <tt>first_argument_type</tt>
74693 and <tt>second_argument_type</tt> is equivalent to the <em>weak result type</em>
74694 specification]</i>
74695 </p>
74696
74697 <blockquote>
74698 <p>
74699 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
74700 derived from <tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>define two
74701 nested types named <tt>first_argument_type</tt> and
74702 <tt>second_argument_type</tt> as a synonym for <tt>T1</tt> and <tt>T2</tt>,
74703 respectively,</ins> only if the type <tt>T</tt> is any of the following:
74704 </p>
74705 <ul>
74706 <li>a function type or a pointer to function type taking two arguments
74707 of types <tt>T1</tt> and <tt>T2</tt><del> and returning
74708 <tt>R</tt></del>
74709 </li>
74710 <li>a pointer to member function <tt>R T0::f(T2)</tt> <em>cv</em>
74711 (where <em>cv</em> represents the member function's cv-qualifiers);
74712         the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
74713 </li>
74714 <li>a class type <del>that is derived from
74715 <tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>with member
74716 types <tt>first_argument_type</tt>
74717         and <tt>second_argument_type</tt>; the type <tt>T1</tt> is
74718 <tt>T::first_argument_type</tt> and the type <tt>T2</tt> is
74719         <tt>T::second_argument_type</tt></ins>
74720 </li>
74721 </ul>
74722 </blockquote>
74723 </li>
74724
74725 <li>
74726 <p>
74727 Change 20.8.13 [func.memfn]/2+3 as indicated: <i>[The intent is to remove
74728 the requirement that mem_fn's return type has to derive
74729 from <tt>[u|bi]nary_function</tt>. The reason for suggesting the
74730 change here is to better support empty-base-class optimization
74731 choices as has been pointed out in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>]</i>
74732 </p>
74733
74734 <blockquote>
74735 <p>
74736 2 The simple call wrapper shall <del>be derived from
74737 <tt>std::unary_function&lt;<em>cv</em> T*, <i>Ret</i>&gt;</tt></del><ins>define
74738 two nested types named <tt>argument_type</tt> and <tt>result_type</tt> as a
74739 synonym for <tt><em>cv</em> T*</tt> and <tt><i>Ret</i></tt>, respectively,</ins>
74740 when <tt>pm</tt> is a pointer to member function with cv-qualifier <em>cv</em>
74741 and taking no arguments, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
74742 </p>
74743 <p>
74744 3 The simple call wrapper shall <del>be derived from
74745 <tt>std::binary_function&lt;<em>cv</em> T*, T1,
74746 <i>Ret</i>&gt;</tt></del><ins>define three nested types named
74747 <tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
74748 <tt>result_type</tt> as a synonym for <tt><em>cv</em> T*</tt>, <tt>T1</tt>, and
74749 <tt><i>Ret</i></tt>, respectively,</ins> when <tt>pm</tt> is a pointer to member
74750 function with cv-qualifier <em>cv</em> and taking one argument of type
74751 <tt>T1</tt>, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
74752 </p>
74753 </blockquote>
74754 </li>
74755
74756 </ol>
74757 <p></p>
74758
74759 <p><b>Proposed resolution:</b></p>
74760 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">n3198</a>.
74761
74762
74763
74764
74765 <hr>
74766 <h3><a name="1292"></a>1292. <tt>std::function</tt> should support all callable types</h3>
74767 <p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74768  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-12-19 <b>Last modified:</b> 2010-11-23</p>
74769 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
74770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74771 <p><b>Discussion:</b></p>
74772 <p>
74773 Some parts of the specification of <tt>std::function</tt> is unnecessarily
74774 restricted to a subset of all callable types (as defined in 20.8.1 [func.def]/3), even though the intent clearly is to be usable for
74775 <em>all</em> of them as described in 20.8.14.2 [func.wrap.func]/1. This
74776 argument becomes strengthened by the fact that current C++0x-compatible
74777 compilers work fine with them:
74778 </p>
74779
74780 <blockquote><pre>#include &lt;functional&gt;
74781 #include &lt;iostream&gt;
74782
74783 struct A
74784 {
74785   int foo(int i) const {return i+1;}
74786 };
74787
74788 struct B
74789 {
74790   int mem;
74791 };
74792
74793 int main()
74794 {
74795   std::function&lt;int(const A&amp;, int)&gt; f(&amp;A::foo);
74796   A a;
74797   std::cout &lt;&lt; f(a, 1) &lt;&lt; '\n';
74798   std::cout &lt;&lt; f.target_type().name() &lt;&lt; '\n';
74799   typedef int (A::* target_t)(int) const;
74800   target_t* p = f.target&lt;target_t&gt;();
74801   std::cout &lt;&lt; (p != 0) &lt;&lt; '\n';
74802   std::function&lt;int(B&amp;)&gt; f2(&amp;B::mem);
74803   B b = { 42 };
74804   std::cout &lt;&lt; f2(b) &lt;&lt; '\n';
74805   std::cout &lt;&lt; f2.target_type().name() &lt;&lt; '\n';
74806   typedef int (B::* target2_t);
74807   target2_t* p2 = f2.target&lt;target2_t&gt;();
74808   std::cout &lt;&lt; (p2 != 0) &lt;&lt; '\n';
74809 }
74810 </pre></blockquote>
74811
74812 <p>
74813 The problematics passages are 20.8.14.2.1 [func.wrap.func.con]/10:
74814 </p>
74815
74816 <blockquote><pre>template&lt;class F&gt; function(F f);
74817 template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
74818 </pre>
74819 <blockquote>
74820 <p>...</p>
74821 <p>
74822 10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
74823 </p>
74824 <ul>
74825 <li>
74826 <tt>f</tt> is a NULL function pointer.
74827 </li>
74828 <li>
74829 <tt>f</tt> is a NULL member function pointer.
74830 </li>
74831 <li>
74832 <tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
74833 </li>
74834 </ul>
74835 </blockquote>
74836 </blockquote>
74837
74838 <p>
74839 because it does not consider pointer to data member and all constraints based on
74840 <em>function objects</em> which like 20.8.14.2 [func.wrap.func]/2 or 20.8.14.2.5 [func.wrap.func.targ]/3. The latter two will be resolved by the proposed
74841 resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a> and are therefore not handled here.
74842 </p>
74843
74844 <p><i>[
74845 Post-Rapperswil:
74846 ]</i></p>
74847
74848
74849 <blockquote>
74850 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74851 </blockquote>
74852
74853 <p><i>[
74854 Adopted at 2010-11 Batavia
74855 ]</i></p>
74856
74857
74858
74859
74860 <p><b>Proposed resolution:</b></p>
74861 <p>
74862 Change 20.8.14.2.1 [func.wrap.func.con]/10+11 as indicated:
74863 </p>
74864
74865 <blockquote><pre>template&lt;class F&gt; function(F f);
74866 template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
74867 </pre>
74868 <blockquote>
74869 <p>...</p>
74870 <p>
74871 10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
74872 </p>
74873 <ul>
74874 <li>
74875 <tt>f</tt> is a NULL function pointer.
74876 </li>
74877 <li>
74878 <tt>f</tt> is a NULL <ins>pointer to</ins> member <del>function pointer</del>.
74879 </li>
74880 <li>
74881 <tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
74882 </li>
74883 </ul>
74884
74885 <p>
74886 11 Otherwise, <tt>*this</tt> targets a copy of <tt>f</tt> <del>or</del><ins>,
74887 initialized with</ins> <tt>std::move(f)</tt> <del>if <tt>f</tt> is not a pointer
74888 to member function, and targets a copy of <tt>mem_fn(f)</tt> if <tt>f</tt> is a
74889 pointer to member function</del>. [<i>Note:</i> implementations are encouraged
74890 to avoid the use of dynamically allocated memory for small function objects, for
74891 example, where <tt>f</tt>'s target is an object holding only a pointer or
74892 reference to an object and a member function pointer. \97 <i>end note</i>]
74893 </p>
74894
74895 </blockquote>
74896 </blockquote>
74897
74898
74899
74900
74901
74902 <hr>
74903 <h3><a name="1293"></a>1293. <tt>unique_ptr&lt;T[], D&gt;</tt> needs to get rid of <i>unspecified-pointer-type</i></h3>
74904 <p><b>Section:</b> 20.9.9.3 [unique.ptr.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
74905  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-12-20 <b>Last modified:</b> 2010-11-19</p>
74906 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
74907 <p><b>Discussion:</b></p>
74908 <p><b>Addresses UK 211</b></p>
74909
74910 <p>
74911 As a response to UK 211 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a> has replaced the
74912 <i>unspecified-pointer-type</i> by <tt>nullptr_t</tt> to allow assignment of
74913 type-safe null-pointer literals in the non-array form of
74914 <tt>unique_ptr::operator=</tt>, but did not the same for the specialization for
74915 arrays of runtime length. But without this parallel change of the signature we
74916 have a status quo, where <tt>unique_ptr&lt;T[], D&gt;</tt> declares a member
74917 function which is completely unspecified.
74918 </p>
74919
74920 <p><i>[
74921 2009-12-21 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
74922 ]</i></p>
74923
74924
74925 <p><i>[
74926 2010-03-14 Howard adds:
74927 ]</i></p>
74928
74929
74930 <blockquote>
74931 We moved
74932 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
74933 to the formal motions page in Pittsburgh which should obsolete this issue.  I've
74934 moved this issue to NAD Editorial, solved by N3073.
74935 </blockquote>
74936
74937
74938
74939 <p><b>Rationale:</b></p>
74940 <p>
74941 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
74942 </p>
74943
74944
74945 <p><b>Proposed resolution:</b></p>
74946 <p>
74947 In 20.9.9.3 [unique.ptr.runtime], class template <tt>unique_ptr&lt;T[],
74948 D&gt;</tt> synopsis, change as indicated:
74949 </p>
74950
74951 <blockquote><pre>// assignment
74952 unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
74953 unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del><ins>nullptr_t</ins>);
74954 </pre></blockquote>
74955
74956
74957
74958
74959
74960
74961 <hr>
74962 <h3><a name="1294"></a>1294. Difference between callable wrapper and forwarding  call wrapper unclear</h3>
74963 <p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
74964  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-12-21 <b>Last modified:</b> 2010-11-23</p>
74965 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
74966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
74967 <p><b>Discussion:</b></p>
74968 <p>
74969 The current wording in the standard makes it hard to discriminate the difference
74970 between a "call wrapper" as defined in 20.8.1 [func.def]/5+6:
74971 </p>
74972
74973 <blockquote>
74974 <p>
74975 5 A <i>call wrapper type</i> is a type that holds a callable object and supports
74976 a call operation that forwards to that object.
74977 </p>
74978 <p>
74979 6 A <i>call wrapper</i> is an object of a call wrapper type.
74980 </p>
74981 </blockquote>
74982
74983 <p>
74984 and a "forwarding call wrapper" as defined in 20.8.2 [func.require]/4:
74985 </p>
74986
74987 <blockquote>
74988 <p>
74989 4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
74990 with an argument list. [<i>Note:</i> in a typical implementation forwarding call
74991 wrappers have an overloaded function call operator of the form
74992 </p>
74993
74994 <blockquote><pre>template&lt;class... ArgTypes&gt;
74995 R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
74996 </pre></blockquote>
74997
74998 <p>
74999 \97 <i>end note</i>]
75000 </p>
75001 </blockquote>
75002
75003 <p>
75004 Reason for this lack of clear difference seems to be that the wording adaption
75005 to variadics and rvalues that were applied after it's original proposal in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#call%20wrapper">N1673</a>:
75006 </p>
75007
75008 <blockquote>
75009 <p>
75010 [..] A <b>forwarding call wrapper</b> is a call wrapper that can be called
75011 with an argument list <tt>t1, t2, ..., tN</tt> where each <tt>ti</tt> is an lvalue.
75012 The effect of calling a forwarding call wrapper with one or more
75013 arguments that are rvalues is implementation defined. [<i>Note:</i> in
75014 a typical implementation forwarding call wrappers have overloaded
75015 function call operators of the form
75016 </p>
75017
75018 <blockquote><pre>template&lt;class T1, class T2, ..., class TN&gt;
75019 R operator()(T1&amp; t1, T2&amp; t2, ..., TN&amp; tN) <i>cv-qual</i>;
75020 </pre></blockquote>
75021
75022 <p>
75023 \97 <i>end note</i>]
75024 </p>
75025 </blockquote>
75026
75027 <p>
75028 combined with the fact that the word "forward" has two different meanings in
75029 this context. This issue attempts to clarify the difference better.
75030 </p>
75031
75032 <p><i>[
75033 2010-09-14 Daniel provides improved wording and verified that it is correct against N3126. Previous resolution is shown here:
75034 ]</i></p>
75035
75036
75037 <blockquote>
75038 <p>
75039 4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
75040 with an <ins>arbitrary</ins> argument list<ins> and uses perfect forwarding to
75041 deliver the arguments to the wrapped callable object</ins>. [<i>Note:</i> in a
75042 typical implementation forwarding call wrappers have an overloaded function call
75043 operator of the form
75044 </p>
75045
75046 <blockquote><pre>template&lt;class... ArgTypes&gt;
75047 R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
75048 </pre></blockquote>
75049
75050 <p>
75051 \97 <i>end note</i>]
75052 </p>
75053 </blockquote>
75054
75055 <p><i>[
75056 Adopted at 2010-11 Batavia
75057 ]</i></p>
75058
75059
75060
75061
75062 <p><b>Proposed resolution:</b></p>
75063 <p>
75064 Change 20.8.2 [func.require]/4 as indicated:
75065 </p>
75066
75067 <blockquote><p>
75068 [..] A <em>forwarding call wrapper</em> is a call wrapper that can be called with an <ins>arbitrary</ins> argument 
75069 list <ins>and delivers the arguments as references to the wrapped callable object. This forwarding step shall ensure
75070 that rvalue arguments are delivered as rvalue-references and lvalue arguments are delivered as lvalue-references</ins>. 
75071 [<em>Note</em>: in a typical implementation forwarding call wrappers have an overloaded function call operator of the 
75072 form
75073 </p>
75074
75075 <blockquote><pre>template&lt;class... UnBoundArgs&gt;
75076 R operator()(UnBoundArgs&amp;&amp;... unbound_args) <em>cv-qual</em>;
75077 </pre></blockquote>
75078 <p>
75079 \97 <em>end note</em> ]
75080 </p>
75081 </blockquote>
75082
75083
75084
75085
75086
75087
75088 <hr>
75089 <h3><a name="1295"></a>1295. Contradictory call wrapper requirements</h3>
75090 <p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75091  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-12-22 <b>Last modified:</b> 2010-11-23</p>
75092 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
75093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75094 <p><b>Discussion:</b></p>
75095 <p>
75096 20.8.2 [func.require]/3 b 1 says
75097 </p>
75098
75099 <blockquote>
75100 <p>
75101 3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
75102 type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
75103 the wrapper's target object (20.8.1 [func.def]):
75104 </p>
75105
75106 <ul>
75107 <li>
75108 if <tt>T</tt> is a function, reference to function, or pointer to function type,
75109 <tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>;
75110 </li>
75111 <li>
75112 [..]
75113 </li>
75114 </ul>
75115 </blockquote>
75116
75117 <p>
75118 The first two enumerated types (function and reference to function)
75119 can never be valid types for <tt>T</tt>, because
75120 </p>
75121
75122 <p>
75123 20.8.1 [func.def]/7
75124 </p>
75125
75126 <blockquote>
75127 7 A <i>target object</i> is the callable object held by a call wrapper.
75128 </blockquote>
75129
75130 <p>
75131 and 20.8.1 [func.def]/3
75132 </p>
75133
75134 <blockquote>
75135 3 A <i>callable type</i> is a pointer to function, a pointer to member function,
75136 a pointer to member data, or a class type whose objects can appear immediately
75137 to the left of a function call operator.
75138 </blockquote>
75139
75140 <p>
75141 exclude functions and references to function as "target objects".
75142 </p>
75143
75144 <p><i>[
75145 Post-Rapperswil:
75146 ]</i></p>
75147
75148
75149 <blockquote>
75150 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75151 </blockquote>
75152
75153 <p><i>[
75154 Adopted at 2010-11 Batavia
75155 ]</i></p>
75156
75157
75158
75159
75160 <p><b>Proposed resolution:</b></p>
75161 <p>
75162 Change 20.8.2 [func.require]/3 b 1 as indicated:
75163 </p>
75164
75165 <blockquote>
75166 <p>
75167 3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
75168 type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
75169 the wrapper's target object (20.8.1 [func.def]):
75170 </p>
75171
75172 <ul>
75173 <li>
75174 if <tt>T</tt> is a <del>function, reference to function, or</del> pointer to
75175 function type, <tt>result_type</tt> shall be a synonym for the return type of
75176 <tt>T</tt>;
75177 </li>
75178 <li>
75179 [..]
75180 </li>
75181 </ul>
75182 </blockquote>
75183
75184
75185
75186
75187
75188
75189 <hr>
75190 <h3><a name="1298"></a>1298. Missing specialization of <tt>ctype_byname&lt;char&gt;</tt></h3>
75191 <p><b>Section:</b> 22.2 [locale.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75192  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-12-25 <b>Last modified:</b> 2010-10-23</p>
75193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75194 <p><b>Discussion:</b></p>
75195 <p>
75196 The <tt>&lt;locale&gt;</tt> synopsis in 22.2 [locale.syn] calls out an
75197 explicit specialization for <tt>ctype_byname&lt;char&gt;</tt>, however no such
75198 specialization is defined in the standard.  The only reference I can find to
75199 <tt>ctype_byname&lt;char&gt;</tt> is 22.3.1.1.2 [locale.facet]:Table 77
75200 \97 Required specializations (for facets) which also refers to
75201 <tt>ctype_byname&lt;wchar_t&gt;</tt> which has no special consideration.
75202 </p>
75203
75204 <p>
75205 Is the intent an explicit <em>instantiation</em> which would use a slightly
75206 different syntax? Should the explicit specialization simply be struck?
75207 </p>
75208
75209 <p><i>[
75210 2010-01-31 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75211 ]</i></p>
75212
75213
75214
75215
75216 <p><b>Proposed resolution:</b></p>
75217 <p>
75218 22.2 [locale.syn]
75219 </p>
75220
75221 <blockquote>
75222 <p>
75223 Strike the explicit specialization for <tt>ctype_byname&lt;char&gt;</tt> from
75224 the <tt>&lt;locale&gt;</tt> synopsis
75225 </p>
75226 <blockquote><pre>...
75227 template &lt;class charT&gt; class ctype_byname;
75228 <del>template &lt;&gt;            class ctype_byname&lt;char&gt;;  // <i>specialization</i></del>
75229 ...
75230 </pre></blockquote>
75231 </blockquote>
75232
75233
75234
75235
75236
75237 <hr>
75238 <h3><a name="1299"></a>1299. Confusing typo in specification for <tt>get_time</tt></h3>
75239 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75240  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-12-25 <b>Last modified:</b> 2010-10-23</p>
75241 <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>
75242 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75243 <p><b>Discussion:</b></p>
75244 <p>
75245 Extended Manipulators 27.7.4 [ext.manip] p8 defines the semantics of
75246 <tt>get_time</tt> in terms of a function <tt>f</tt>.
75247 </p>
75248
75249 <blockquote><pre>template &lt;class charT, class traits&gt;
75250 void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm* tmb, const charT* fmt) {
75251    typedef istreambuf_iterator&lt;charT, traits&gt; Iter;
75252    typedef time_get&lt;charT, Iter&gt; TimeGet;
75253
75254    ios_base::iostate err = ios_base::goodbit;
75255    const TimeGet&amp; tg = use_facet&lt;TimeGet&gt;(str.getloc());
75256
75257    tm.get(Iter(str.rdbuf()), Iter(), str, err, tmb, fmt, fmt + traits::length(fmt));
75258
75259    if (err != ios_base::goodbit)
75260        str.setstate(err):
75261 }
75262 </pre></blockquote>
75263
75264 <p>
75265 Note the call to <tt>tm.get</tt>.  This is clearly an error, as <tt>tm</tt> is a
75266 type and not an object.  I believe this should be <tt>tg.get</tt>, rather than
75267 <tt>tm</tt>, but this is not my area of expertise.
75268 </p>
75269
75270 <p><i>[
75271 2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75272 ]</i></p>
75273
75274
75275
75276 <p><b>Proposed resolution:</b></p>
75277 <p>
75278 Change 27.7.4 [ext.manip] p8:
75279 </p>
75280
75281 <blockquote><pre>template &lt;class charT, class traits&gt;
75282 void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm* tmb, const charT* fmt) {
75283    typedef istreambuf_iterator&lt;charT, traits&gt; Iter;
75284    typedef time_get&lt;charT, Iter&gt; TimeGet;
75285
75286    ios_base::iostate err = ios_base::goodbit;
75287    const TimeGet&amp; tg = use_facet&lt;TimeGet&gt;(str.getloc());
75288
75289    t<ins>g</ins><del>m</del>.get(Iter(str.rdbuf()), Iter(), str, err, tmb, fmt, fmt + traits::length(fmt));
75290
75291    if (err != ios_base::goodbit)
75292        str.setstate(err):
75293 }
75294 </pre></blockquote>
75295
75296
75297
75298
75299
75300 <hr>
75301 <h3><a name="1303"></a>1303. <tt>shared_ptr</tt>, <tt>unique_ptr</tt>, and rvalue references v2</h3>
75302 <p><b>Section:</b> 20.9.9.2 [unique.ptr.single], 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75303  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2010-01-23 <b>Last modified:</b> 2010-10-23</p>
75304 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
75305 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75306 <p><b>Discussion:</b></p>
75307 <p>
75308 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
75309 20.9.10.2 [util.smartptr.shared]/1 still says:
75310 </p>
75311
75312 <blockquote><pre>template &lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;
75313 template &lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;
75314 </pre></blockquote>
75315
75316 <p>
75317 I believe that this is unnecessary now that "rvalue references v2"
75318 prevents rvalue references from binding to lvalues, and I didn't
75319 see a Library Issue tracking this.
75320 </p>
75321
75322 <p><i>[
75323 2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75324 ]</i></p>
75325
75326
75327
75328
75329 <p><b>Proposed resolution:</b></p>
75330
75331 <p>
75332 Strike from 20.9.9.2 [unique.ptr.single]:
75333 </p>
75334
75335 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
75336   ...
75337   unique_ptr(const unique_ptr&amp;) = delete;
75338   <del>template &lt;class U, class E&gt; unique_ptr(const unique_ptr&lt;U, E&gt;&amp;) = delete;</del>
75339   unique_ptr&amp; operator=(const unique_ptr&amp;) = delete;
75340   <del>template &lt;class U, class E&gt; unique_ptr&amp; operator=(const unique_ptr&lt;U, E&gt;&amp;) = delete;</del>
75341 };
75342 </pre></blockquote>
75343
75344 <p>
75345 Strike from 20.9.10.2 [util.smartptr.shared]:
75346 </p>
75347
75348 <blockquote><pre>template&lt;class T&gt; class shared_ptr {
75349   ...
75350   <del>template &lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;</del>
75351   ...
75352   <del>template &lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;</del>
75353   ...
75354 };
75355 </pre></blockquote>
75356
75357
75358
75359
75360
75361
75362 <hr>
75363 <h3><a name="1306"></a>1306. <tt>pointer</tt> and <tt>const_pointer</tt> for <tt>&lt;array&gt;</tt></h3>
75364 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75365  <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-01-24 <b>Last modified:</b> 2010-10-23</p>
75366 <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>
75367 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75368 <p><b>Discussion:</b></p>
75369 <p>
75370 Class <tt>&lt;array&gt;</tt> is the only sequence container class that has no
75371 types <tt>pointer</tt> and <tt>const_pointer</tt> defined. You might argue that
75372 this makes no sense because there is no allocator support, but on the other
75373 hand, types <tt>reference</tt> and <tt>const_reference</tt> are defined for
75374 <tt>array</tt>.
75375 </p>
75376
75377 <p><i>[
75378 2010-02-11 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
75379 ]</i></p>
75380
75381
75382
75383
75384 <p><b>Proposed resolution:</b></p>
75385 <p>
75386 Add to Class template array 23.3.1 [array]:
75387 </p>
75388
75389 <blockquote><pre>namespace std {
75390   template &lt;class T, size_t N &gt;
75391   struct array {
75392     ...
75393     typedef T value_type;
75394     <ins>typedef T * pointer;</ins>
75395     <ins>typedef const T * const_pointer;</ins>
75396     ...
75397   };
75398 }
75399 </pre></blockquote>
75400
75401
75402
75403
75404
75405 <hr>
75406 <h3><a name="1307"></a>1307. <tt>exception_ptr</tt> and <tt>allocator</tt> pointers don't understand !=</h3>
75407 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
75408  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-01-26 <b>Last modified:</b> 2010-11-19</p>
75409 <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>
75410 <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>
75411 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
75412 <p><b>Discussion:</b></p>
75413 <p>
75414 The current requirements for a conforming implementation of
75415 <tt>std::exception_ptr</tt> (18.8.5 [propagation]/1-6) does not clarify
75416 whether the expression
75417 </p>
75418
75419 <blockquote><pre>e1 != e2
75420 e1 != nullptr
75421 </pre></blockquote>
75422
75423 <p>
75424 with <tt>e1</tt> and <tt>e2</tt> being two values of type
75425 <tt>std::exception_ptr</tt> are supported or not. Reason for this oddity is that
75426 the concept <tt>EqualityComparable</tt> does not provide operator <tt>!=</tt>.
75427 </p>
75428
75429 <p>
75430 For the same reason programmers working against the types <tt>X::pointer</tt>,
75431 <tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and
75432 <tt>X::const_void_pointer</tt> of any allocator concept <tt>X</tt> (20.2.5 [allocator.requirements]/4 + Table 40) in a generic context can not rely
75433 on the availability of the != operation, which is rather unnatural and
75434 error-prone.
75435 </p>
75436
75437 <p><i>[
75438 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
75439 ]</i></p>
75440
75441
75442
75443
75444 <p><b>Rationale:</b></p>
75445 <p>
75446 Solved by
75447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
75448 </p>
75449
75450
75451 <p><b>Proposed resolution:</b></p>
75452
75453
75454
75455
75456
75457 <hr>
75458 <h3><a name="1309"></a>1309. Missing expressions for <tt>Move/CopyConstructible</tt></h3>
75459 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75460  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-02-03 <b>Last modified:</b> 2010-10-23</p>
75461 <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>
75462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75463 <p><b>Discussion:</b></p>
75464 <p>
75465 Table 33 \97 MoveConstructible requirements [moveconstructible] and
75466 Table 34 \97 CopyConstructible requirements [copyconstructible] support
75467 solely the following expression:
75468 </p>
75469
75470 <blockquote><pre>T t(rv)
75471 </pre></blockquote>
75472
75473 <p>
75474 where <tt>rv</tt> is defined to be as "non-const rvalue of type <tt>T</tt>"  and
75475 <tt>t</tt> as a "modifiable lvalue of type <tt>T</tt>" in 20.2.1 [utility.arg.requirements]/1.
75476 </p>
75477
75478 <p>
75479 This causes two different defects:
75480 </p>
75481
75482 <ol type="a">
75483 <li>
75484 <p>
75485 We cannot move/copy-initialize a <em>const</em> lvalue of type <tt>T</tt> as in:
75486 </p>
75487
75488 <blockquote><pre>int get_i();
75489
75490 const int i1(get_i());
75491 </pre></blockquote>
75492
75493 <p>
75494 both in Table 33 and in Table 34.
75495 </p>
75496 </li>
75497
75498 <li>
75499 <p>
75500 The single support for
75501 </p>
75502
75503 <blockquote><pre>T t(rv)
75504 </pre></blockquote>
75505
75506 <p>
75507 in case of <tt>CopyConstructible</tt> means that we cannot provide an
75508 lvalue as a source of a copy as in
75509 </p>
75510
75511 <blockquote><pre>const int&amp; get_lri();
75512
75513 int i2(get_lri());
75514 </pre></blockquote>
75515 </li>
75516 </ol>
75517
75518 <p>
75519 I believe this second defect is due to the fact that this single
75520 expression supported <em>both</em> initialization situations according
75521 to the old (implicit) lvalue reference -&gt; rvalue reference
75522 conversion rules.
75523 </p>
75524
75525 <p>
75526 Finally [copyconstructible] refers to some name <tt>u</tt> which is not part of
75527 the expression, and both [copyconstructible] and [moveconstructible] should
75528 support construction expressions from temporaries - this would be a stylistic
75529 consequence in the light of the new <tt>DefaultConstructible</tt> requirements
75530 and compared with existing requirements (see e.g. Container requirements or the
75531 output/forward iterator requirements)..
75532 </p>
75533
75534 <p><i>[
75535 2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75536 ]</i></p>
75537
75538
75539 <p><i>[
75540 2010-02-10 Reopened. The proposed wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a> has been
75541 merged here.
75542 ]</i></p>
75543
75544
75545 <p><i>[
75546 2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75547 ]</i></p>
75548
75549
75550
75551
75552 <p><b>Proposed resolution:</b></p>
75553
75554 <ol>
75555
75556 <li>
75557 <p>
75558 Change 20.2.1 [utility.arg.requirements]/1 as indicated: <i>[This change
75559 suggestion is motivated to make type descriptions clearer: First, <tt>a</tt>,
75560 <tt>b</tt>, and <tt>c</tt> <em>may</em> also be non-<tt>const T</tt>. Second, <tt>u</tt>
75561 is described in a manner consistent with the container requirements tables.]</i>
75562 </p>
75563
75564 <blockquote>
75565 1 The template definitions in the C++ standard library refer to various named
75566 requirements whose details are set out in tables 31-38. In these tables,
75567 <tt>T</tt> is a<ins>n object or reference</ins> type to be supplied by a C++
75568 program instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
75569 values of type <ins>(possibly</ins> <tt>const<ins>)</ins> T</tt>; <tt>s</tt> and
75570 <tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> <ins>denotes an
75571 identifier;</ins> <del>is a value of type (possibly <tt>const</tt>) <tt>T</tt>;
75572 and</del> <tt>rv</tt> is a<ins>n</ins> <del>non-const</del> rvalue of type
75573 <tt>T</tt><ins>; and <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>)
75574 <tt>T</tt> or an rvalue of type <tt>const T</tt></ins>.
75575 </blockquote>
75576 </li>
75577
75578 <li>
75579 <p>
75580 In 20.2.1 [utility.arg.requirements] Table 33 ([moveconstructible])
75581 change as indicated <i>[Note: The symbol <tt>u</tt> is defined to be either a
75582 const or a non-const value and is the right one we need here]</i>:
75583 </p>
75584
75585 <blockquote>
75586 <table border="1">
75587 <caption>Table 33 \97 <tt>MoveConstructible</tt> requirements [moveconstructible]</caption>
75588
75589 <tbody><tr>
75590 <th>Expression</th>
75591 <th>Post-condition</th>
75592 </tr>
75593
75594 <tr>
75595 <td>
75596 <tt>T <del>t</del><ins>u</ins>(rv)<ins>;</ins></tt>
75597 </td>
75598 <td>
75599 <tt><del>t</del><ins>u</ins></tt> is equivalent
75600 to the value of <tt>rv</tt> before the construction
75601 </td>
75602 </tr>
75603
75604 <tr>
75605 <td><ins><tt>T(rv)</tt></ins></td>
75606 <td><ins><tt>T(rv)</tt> is equivalent to the value of <tt>rv</tt> before the
75607 construction</ins></td>
75608 </tr>
75609
75610 <tr>
75611 <td colspan="2">[<i>Note:</i>
75612 <del>There is no requirement on the value of <tt>rv</tt> after the
75613 construction.</del>
75614 <ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
75615 \97 <i>end note</i>]</td>
75616 </tr>
75617 </tbody></table>
75618 </blockquote>
75619 </li>
75620
75621 <li>
75622 <p>
75623 In 20.2.1 [utility.arg.requirements] Table 34 ([copyconstructible])
75624 change as indicated <i>[Note: The symbol <tt>u</tt> is defined to be either a
75625 const or a non-const value and is the right one we need here. The expressions
75626 using <tt>a</tt> are recommended to ensure that lvalues are supported as sources
75627 of the copy expression]</i>:
75628 </p>
75629
75630 <blockquote>
75631 <table border="1">
75632 <caption>Table 34 \97 <tt>CopyConstructible</tt> requirements [copyconstructible]<br>
75633 <ins>(in addition to <tt>MoveConstructible</tt>)</ins></caption>
75634
75635 <tbody><tr>
75636 <th>Expression</th>
75637 <th>Post-condition</th>
75638 </tr>
75639
75640 <tr>
75641 <td>
75642 <tt>T <del>t</del><ins>u</ins>(<del>r</del>v)<ins>;</ins></tt>
75643 </td>
75644 <td>
75645 the value of <tt><del>u</del><ins>v</ins></tt>
75646 is unchanged and is equivalent to <tt><del>t</del><ins>u</ins></tt>
75647 </td>
75648 </tr>
75649
75650 <tr>
75651 <td>
75652 <ins><tt>T(v)</tt></ins>
75653 </td>
75654 <td><ins>the value of <tt>v</tt> is unchanged and is equivalent to <tt>T(v)</tt></ins>
75655 </td>
75656 </tr>
75657
75658 <tr>
75659 <td colspan="2"><del>[<i>Note:</i> A type that satisfies the
75660 <tt>CopyConstructible</tt> requirements also satisfies the <tt>MoveConstructible</tt>
75661 requirements. \97 <i>end note</i>]</del></td>
75662 </tr>
75663
75664 </tbody></table>
75665 </blockquote>
75666
75667 </li>
75668
75669 <li>
75670 <p>
75671 In Table 35 \97 MoveAssignable requirements [moveassignable] change as
75672 indicated:
75673 </p>
75674
75675 <blockquote>
75676
75677 <table border="1">
75678 <caption>Table 35 \97 <tt>MoveAssignable</tt> requirements <b>[moveassignable]</b></caption>
75679 <tbody><tr>
75680 <th>Expression</th>
75681 <th>Return type</th>
75682 <th>Return value</th>
75683 <th>Post-condition</th>
75684 </tr>
75685 <tr>
75686 <td>
75687 <tt>t = rv</tt>
75688 </td>
75689 <td>
75690 <tt>T&amp;</tt>
75691 </td>
75692 <td>
75693 <tt>t</tt>
75694 </td>
75695 <td>
75696 <tt>t</tt> is equivalent to the value of <tt>rv</tt> before the assigment.
75697 </td>
75698 </tr>
75699 <tr>
75700 <td colspan="4">
75701 [<i>Note:</i>
75702 <del>There is no requirement on the value of <tt>rv</tt> after the
75703 assignment.</del>
75704 <ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
75705 \97 <i>end note</i>]
75706 </td>
75707 </tr>
75708 </tbody></table>
75709
75710 </blockquote>
75711 </li>
75712
75713 <li>
75714 <p>
75715 In 20.2.1 [utility.arg.requirements] change Table 36 as indicated:
75716 </p>
75717
75718 <blockquote>
75719 <table border="1">
75720 <caption>Table 36 \97 <tt>CopyAssignable</tt> requirements
75721 [copyassignable]<br><ins>(in addition to <tt>MoveAssignable</tt>)</ins></caption>
75722
75723 <tbody><tr>
75724 <th>Expression</th>
75725 <th>Return type</th>
75726 <th>Return value</th>
75727 <th>Post-condition</th>
75728 </tr>
75729
75730 <tr>
75731 <td><tt>t = <del>u</del><ins>v</ins></tt></td>
75732 <td><tt>T&amp;</tt></td>
75733 <td><tt>t</tt></td>
75734 <td><tt>t</tt> is equivalent to <tt><del>u</del><ins>v</ins></tt>, the value of
75735 <tt><del>u</del><ins>v</ins></tt> is unchanged</td>
75736 </tr>
75737
75738 <tr>
75739 <td colspan="4"><del>[<i>Note:</i> A type that satisfies the <tt>CopyAssignable</tt>
75740 requirements also satisfies the <tt>MoveAssignable</tt> requirements. \97
75741 <i>end note</i>]</del></td>
75742 </tr>
75743
75744 </tbody></table>
75745 </blockquote>
75746 </li>
75747 </ol>
75748
75749
75750
75751
75752
75753
75754 <hr>
75755 <h3><a name="1312"></a>1312. <tt>vector::data</tt> no longer returns a raw pointer</h3>
75756 <p><b>Section:</b> 23.4.1.3 [vector.data] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75757  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-07 <b>Last modified:</b> 2010-10-23</p>
75758 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75759 <p><b>Discussion:</b></p>
75760 <p>
75761 The original intent of <tt>vector::data</tt> was to match <tt>array::data</tt>
75762 in providing a simple API with direct access to the contiguous buffer of
75763 elements that could be passed to a "classic" C API.  At some point, the return
75764 type became the '<tt>pointer</tt>' typedef, which is not derived from the
75765 <tt>allocator</tt> via allocator traits - it is no longer specified to precisely
75766 <tt>T *</tt>.  The return type of this function should be corrected to no longer
75767 use the typedef.
75768 </p>
75769
75770 <p><i>[
75771 2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75772 ]</i></p>
75773
75774
75775
75776
75777 <p><b>Proposed resolution:</b></p>
75778 <p>
75779 23.4.1 [vector]
75780 </p>
75781
75782 <p>
75783 Update the class definition in p2:
75784 </p>
75785
75786 <blockquote><pre>// 23.3.6.3 data access
75787 <del>pointer</del><ins>T *</ins> data();
75788 <del>const_pointer</del><ins>const T *</ins> data() const;
75789 </pre></blockquote>
75790
75791 <p>
75792 23.4.1.3 [vector.data]
75793 </p>
75794
75795 <p>
75796 Adjust signatures:
75797 </p>
75798
75799 <blockquote><pre><del>pointer</del><ins>T *</ins> data();
75800 <del>const_pointer</del><ins>const T *</ins> data() const;
75801 </pre></blockquote>
75802
75803
75804
75805
75806
75807 <hr>
75808 <h3><a name="1316"></a>1316. <tt>scoped_allocator_adaptor operator==</tt> has no definition</h3>
75809 <p><b>Section:</b> 20.10 [allocator.adaptor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75810  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-02-11 <b>Last modified:</b> 2010-11-24</p>
75811 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.adaptor">issues</a> in [allocator.adaptor].</p>
75812 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75813 <p><b>Discussion:</b></p>
75814 <p>
75815 The WP 
75816 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>)
75817 contains these declarations:
75818 </p>
75819
75820 <blockquote>
75821 <pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
75822   bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
75823                   const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);
75824 template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
75825   bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
75826                   const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>
75827 </blockquote>
75828
75829 <p>
75830 But does not define what the behavior of these operators are.
75831 </p>
75832
75833 <p><i>[
75834 Post-Rapperswil:
75835 ]</i></p>
75836
75837
75838 <blockquote>
75839 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
75840 </blockquote>
75841
75842 <p><i>[
75843 Adopted at 2010-11 Batavia
75844 ]</i></p>
75845
75846
75847
75848
75849 <p><b>Proposed resolution:</b></p>
75850 <p>
75851 Add a new section after 20.10.3 [allocator.adaptor.members]:
75852 </p>
75853
75854 <blockquote>
75855 <p><b>Scoped allocator operators  [scoped.adaptor.operators]</b></p>
75856
75857 <pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
75858   bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
75859                   const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>
75860
75861 <blockquote>
75862 <i>Returns:</i> <code>a.outer_allocator() == b.outer_allocator()</code>
75863 if <code>sizeof...(InnerAllocs)</code> is zero; otherwise,
75864 <code>a.outer_allocator() == b.outer_allocator() &amp;&amp;
75865 a.inner_allocator() == b.inner_allocator()</code>.
75866 </blockquote>
75867
75868 <pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
75869   bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
75870                   const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>
75871
75872 <blockquote>
75873 <i>Returns:</i> <code>!(a == b)</code>.
75874 </blockquote>
75875
75876 </blockquote>
75877
75878
75879
75880
75881
75882
75883 <hr>
75884 <h3><a name="1319"></a>1319. Containers should require an iterator that is at least a Forward Iterator</h3>
75885 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
75886  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-24</p>
75887 <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>
75888 <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>
75889 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
75890 <p><b>Discussion:</b></p>
75891 <p>
75892 The requirements on container iterators are spelled out in
75893 23.2.1 [container.requirements.general], table 91.
75894 </p>
75895
75896 <blockquote>
75897 <table border="1">
75898 <caption>Table 91 \97 Container requirements</caption>
75899
75900 <tbody><tr>
75901 <th>Expression</th>
75902 <th>Return type</th>
75903 <th>Operational semantics</th>
75904 <th>Assertion/note<br>pre-/post-condition</th>
75905 <th>Complexity</th>
75906 </tr>
75907
75908 <tr>
75909 <td colspan="5"><center>...</center></td>
75910 </tr>
75911
75912 <tr>
75913 <td><tt>X::iterator</tt></td>
75914 <td>iterator type whose value type is <tt>T</tt></td>
75915 <td></td>
75916 <td>any iterator category except output iterator. Convertible to
75917 <tt>X::const_iterator</tt>.</td>
75918 <td>compile time</td>
75919 </tr>
75920
75921 <tr>
75922 <td><tt>X::const_iterator</tt></td>
75923 <td>constant iterator type whose value type is <tt>T</tt></td>
75924 <td></td>
75925 <td>any iterator category except output iterator</td>
75926 <td>compile time</td>
75927 </tr>
75928
75929 <tr>
75930 <td colspan="5"><center>...</center></td>
75931 </tr>
75932
75933 </tbody></table>
75934 </blockquote>
75935
75936 <p>
75937 As input iterators do not have the multi-pass guarantee, they are not suitable
75938 for iterating over a container.  For example, taking two calls to
75939 <tt>begin()</tt>, incrementing either iterator might invalidate the other. 
75940 While data structures might be imagined where this behaviour produces
75941 interesting and useful results, it is very unlikely to meet the full set of
75942 requirements for a standard container.
75943 </p>
75944
75945 <p><i>[
75946 Post-Rapperswil:
75947 ]</i></p>
75948
75949
75950 <p>
75951 Daniel notes: I changed the currently suggested P/R slightly, because it is not robust in regard to new fundamental iterator
75952 catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
75953 iterator requirements.
75954 </p>
75955
75956 <blockquote>
75957 Moved to Tentatively Ready with revised wording after 5 positive votes on c++std-lib.
75958 </blockquote>
75959
75960 <p><i>[
75961 Adopted at 2010-11 Batavia
75962 ]</i></p>
75963
75964
75965
75966
75967 <p><b>Proposed resolution:</b></p>
75968
75969 <ol>
75970 <li>Change Table 93 \97 Container requirements in [container.requirements.general] as indicated:
75971 <blockquote>
75972 <table border="1">
75973 <caption>Table 93 \97 Container requirements</caption>
75974
75975 <tbody>
75976 <tr>
75977 <th>Expression</th>
75978 <th>Return type</th>
75979 <th>Operational<br>semantics</th>
75980 <th>Assertion/note<br>pre-/post-condition</th>
75981 <th>Complexity</th>
75982 </tr>
75983
75984 <tr>
75985 <td colspan="5" align="center"><tt>...</tt></td>
75986 </tr>
75987
75988 <tr>
75989 <td><tt>X::iterator</tt></td>
75990 <td>iterator type<br>whose value<br>type is <tt>T</tt></td>
75991 <td></td>
75992 <td>any iterator category<br><del>except output iterator</del><ins><br>that meets the forward iterator requirements</ins>. convertible<br>to<br><tt>X::const_iterator</tt></td>
75993 <td>compile time</td>
75994 </tr>
75995
75996 <tr>
75997 <td><tt>X::const_iterator</tt></td>
75998 <td>constant iterator type<br>whose value<br>type is <tt>T</tt></td>
75999 <td></td>
76000 <td>any iterator category<br><del>except output iterator</del><ins><br>that meets the forward iterator requirements</ins>.</td>
76001 <td>compile time</td>
76002 </tr>
76003
76004 <tr>
76005 <td colspan="5" align="center"><tt>...</tt></td>
76006 </tr>
76007
76008 </tbody></table>
76009 </blockquote>
76010
76011 </li>
76012 </ol>
76013
76014
76015
76016
76017
76018
76019 <hr>
76020 <h3><a name="1321"></a>1321. <tt>scoped_allocator_adaptor construct</tt> and <tt>destroy</tt> don't
76021 use <tt>allocator_traits</tt></h3>
76022 <p><b>Section:</b> 20.10.3 [allocator.adaptor.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
76023  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-20</p>
76024 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
76025 <p><b>Discussion:</b></p>
76026 <p>
76027 20.10.3 [allocator.adaptor.members] p8-9 says:
76028 </p>
76029
76030 <blockquote>
76031
76032 <pre>template &lt;class T, class... Args&gt;
76033   void construct(T* p, Args&amp;&amp;... args);
76034 </pre>
76035 <blockquote>
76036 <p>
76037 8 <i>Effects:</i> let <tt><i>OUTERMOST</i>(x)</tt> be <tt>x</tt> if <tt>x</tt>
76038 does not have an <tt>outer_allocator()</tt> function and
76039 <tt><i>OUTERMOST</i>(x.outer_allocator())</tt> otherwise.
76040 </p>
76041
76042 <ul>
76043 <li>
76044 If <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76045 <tt>false</tt> and <tt>is_constructible&lt;T, Args...&gt;::value</tt> is
76046 <tt>true</tt>, calls <tt><i>OUTERMOST</i>(*this).construct(p,
76047 std::forward&lt;Args&gt;(args)...)</tt>.
76048 </li>
76049
76050 <li>
76051 Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76052 <tt>true</tt> and <tt>is_constructible&lt;T, allocator_arg_t,
76053 inner_allocator_type, Args...&gt;::value</tt> is <tt>true</tt>, calls
76054 <tt><i>OUTERMOST</i>(*this).construct(p, allocator_arg,
76055 inner_allocator(),std::forward&lt;Args&gt;(args)...)</tt>.
76056 </li>
76057
76058 <li>
76059 Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76060 <tt>true</tt> and <tt>is_constructible&lt;T, Args...,
76061 inner_allocator_type&gt;::value</tt> is <tt>true</tt>, calls
76062 <tt><i>OUTERMOST</i>(*this).construct(p, std::forward&lt;Args&gt;(args)...,
76063 inner_allocator())</tt>.
76064 </li>
76065
76066 <li>
76067 Otherwise, the program is ill-formed. [<i>Note:</i> an error will result if
76068 <tt>uses_allocator</tt> evaluates to <tt>true</tt> but the specific constructor
76069 does not take an allocator. This definition prevents a silent failure to pass an
76070 inner allocator to a contained element. \97 <i>end note</i>]
76071 </li>
76072 </ul>
76073
76074 </blockquote>
76075
76076 <pre>template &lt;class T&gt;
76077   void destroy(T* p);
76078 </pre>
76079 <blockquote>
76080 9 <i>Effects:</i> calls <tt>outer_allocator().destroy(p)</tt>.
76081 </blockquote>
76082
76083 </blockquote>
76084
76085 <p>
76086 In all other calls where applicable <tt>scoped_allocator_adaptor</tt> does not
76087 call members of an allocator directly, but rather does so indirectly via
76088 <tt>allocator_traits</tt>.  For example:
76089 </p>
76090
76091 <blockquote>
76092 <pre>size_type max_size() const;
76093 </pre>
76094 <blockquote>
76095 7 <i>Returns:</i>
76096 <tt><b>allocator_traits&lt;OuterAlloc&gt;::</b>max_size(outer_allocator())</tt>.
76097 </blockquote>
76098 </blockquote>
76099
76100 <p>
76101 Indeed, without the indirection through <tt>allocator_traits</tt> the
76102 definitions for <tt>construct</tt> and <tt>destroy</tt> are likely to fail at
76103 compile time since the <tt>outer_allocator()</tt> may not have the members
76104 <tt>construct</tt> and <tt>destroy</tt>.
76105 </p>
76106
76107 <p><i>[
76108 The proposed wording is a product of Pablo, Daniel and Howard.
76109 ]</i></p>
76110
76111
76112 <p><i>[
76113 2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
76114 ]</i></p>
76115
76116
76117
76118
76119 <p><b>Rationale:</b></p>
76120 <p>
76121 Solved by
76122 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3059.pdf">N3059</a>.
76123 </p>
76124
76125
76126 <p><b>Proposed resolution:</b></p>
76127 <p>
76128 In 20.10.3 [allocator.adaptor.members] move and change p8
76129 as indicated, and change p9 as indicated:
76130 </p>
76131
76132 <blockquote>
76133
76134 <p>
76135 <ins>Let <tt><i>OUTERMOST(x)</i></tt> be <tt><i>x</i></tt> if <tt><i>x</i></tt>
76136 does not have an <tt>outer_allocator()</tt> <ins>member</ins> function and
76137 <tt><i>OUTERMOST(x.outer_allocator())</i></tt> otherwise. Let
76138 <tt><i>OUTERMOST_ALLOC_TRAITS(x)</i></tt> be
76139 <tt>allocator_traits&lt;decltype(<i>OUTERMOST(x)</i>)&gt;</tt>.
76140 [<i>Note:</i> <tt><i>OUTERMOST(x)</i></tt> and
76141 <tt><i>OUTERMOST_ALLOC_TRAITS(x)</i></tt> are recursive operations.  It is
76142 incumbent upon the definition of <tt>outer_allocator()</tt> to ensure that the
76143 recursion terminates.  It <em>will</em> terminate for all instantiations
76144 of <tt>scoped_allocator_adaptor</tt>. \97 <i>end note</i>]
76145 </ins>
76146 </p>
76147
76148 <pre>template &lt;class T, class... Args&gt;
76149   void construct(T* p, Args&amp;&amp;... args);
76150 </pre>
76151 <blockquote>
76152
76153 <p>
76154 8 <i>Effects:</i> <del>let <tt><i>OUTERMOST(x)</i></tt> be <tt><i>x</i></tt> if
76155 <tt><i>x</i></tt> does not have an <tt>outer_allocator()</tt> function and
76156 <tt><i>OUTERMOST(x.outer_allocator())</i></tt> otherwise.</del>
76157 </p>
76158
76159 <ul>
76160 <li>
76161 If <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76162 <tt>false</tt> and <tt>is_constructible&lt;T, Args...&gt;::value</tt> is
76163 <tt>true</tt>, calls <tt><del><i>OUTERMOST(*this)</i>.</del>
76164 <ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
76165 <ins><i>OUTERMOST(outer_allocator())</i>,</ins> p,
76166 std::forward&lt;Args&gt;(args)... )</tt>.
76167 </li>
76168
76169 <li>
76170 Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76171 <tt>true</tt> and <tt>is_constructible&lt;T, allocator_arg_t,
76172 inner_allocator_type, Args...&gt;::value</tt> is <tt>true</tt>, calls
76173 <tt><del><i>OUTERMOST(*this)</i>.</del>
76174 <ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
76175 <ins><i>OUTERMOST(outer_allocator())</i>,</ins> p, allocator_arg,
76176 inner_allocator(), std::forward&lt;Args&gt;(args)... )</tt>.
76177 </li>
76178
76179 <li>
76180 Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
76181 <tt>true</tt> and <tt>is_constructible&lt;T, Args...,
76182 inner_allocator_type&gt;::value</tt> is <tt>true</tt>, calls
76183 <tt><del><i>OUTERMOST(*this)</i>.</del>
76184 <ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
76185 <ins><i>OUTERMOST(outer_allocator())</i>,</ins> p,
76186 std::forward&lt;Args&gt;(args)..., inner_allocator() )</tt>.
76187 </li>
76188
76189 <li>
76190 Otherwise, the program is ill-formed. [<i>Note:</i> an error will result if
76191 <tt>uses_allocator</tt> evaluates to <tt>true</tt> but the specific constructor
76192 does not take an allocator. This definition prevents a silent failure to pass an
76193 inner allocator to a contained element. \97 <i>end note</i>]
76194 </li>
76195 </ul>
76196
76197 </blockquote>
76198
76199 <pre>template &lt;class T&gt;
76200   void destroy(T* p);
76201 </pre>
76202 <blockquote>
76203 9 <i>Effects:</i> calls <tt><del>outer_allocator().</del>
76204 <ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>destroy(
76205 <ins><i>OUTERMOST(outer_allocator())</i>,</ins> p)</tt>.
76206 </blockquote>
76207
76208 </blockquote>
76209
76210
76211
76212
76213
76214
76215 <hr>
76216 <h3><a name="1322"></a>1322. Explicit <tt>CopyConstructible</tt> requirements are insufficient</h3>
76217 <p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
76218  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-23</p>
76219 <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>
76220 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
76221 <p><b>Discussion:</b></p>
76222 <p>
76223 With the acceptance of library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a> only
76224 direct-initialization is supported, and not copy-initialization in the
76225 requirement sets <tt>MoveConstructible</tt> and <tt>CopyConstructible</tt>. This
76226 is usually a good thing, if only the library implementation needs to obey these
76227 restrictions, but the Empire strikes back quickly:
76228 </p>
76229
76230 <ol>
76231 <li>
76232 <p>
76233 <em>Affects user-code</em>: <tt>std::exception_ptr</tt> is defined purely via
76234 requirements, among them <tt>CopyConstructible</tt>. A strict reading of the
76235 standard would make implementations conforming where <tt>std::exception_ptr</tt>
76236 has an explicit copy-c'tor and user-code must code defensively. This is a very
76237 unwanted effect for such an important component like
76238 <tt>std::exception_ptr</tt>.
76239 </p>
76240 </li>
76241
76242 <li>
76243 <p>
76244 <em>Wrong re-use</em>: Recently proposed requirement sets
76245 (<tt>NullablePointer</tt> as of
76246 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3025.html">N3025</a>,
76247 Hash) or cleanup of existing requirement sets (e.g. iterator requirements as of
76248 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3046.html">N3046</a>)
76249 tend to reuse existing requirement sets, so reusing <tt>CopyConstructible</tt>
76250 is attempting, even in cases, where the intend is to support copy-initialization
76251 as well.
76252 </p>
76253 </li>
76254
76255 <li>
76256 <p>
76257 <em>Inconsistency</em>: The current iterator requirements set Table 102 (output
76258 iterator requirements) and Table 103 (forward iterator requirements) demonstrate
76259 quite clearly a strong divergence of copy-semantics: The specified semantics of
76260 </p>
76261
76262 <blockquote><pre>X u(a);
76263 X u = a;
76264 </pre></blockquote>
76265
76266 <p>
76267 are underspecified compared to the most recent clarifications of the
76268 <tt>CopyConstructible</tt> requirements, c.f. issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a> which is
76269 very unsatisfactory. This will become worse for each further issue that involves
76270 the <tt>CopyConstructible</tt> specification (for possible directions see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>).
76271 </p>
76272 </li>
76273 </ol>
76274
76275 <p>
76276 The suggested resolution is to define two further requirements
76277 <tt>implicit-MoveConstructible</tt> and <tt>implicit-CopyConstructible</tt> (or
76278 any other reasonable name like <tt>MoveConvertible</tt> and
76279 <tt>CopyConvertible</tt>) each with a very succinct but precise meaning solving
76280 all three problems mentioned above.
76281 </p>
76282
76283 <p><i>[Batavia: Resolved by accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3215.html">n3215</a>.]</i></p>
76284
76285
76286
76287
76288
76289
76290
76291 <p><b>Proposed resolution:</b></p>
76292 <ol>
76293 <li>
76294 <p>
76295 Add the following new table ?? after Table 34 \97 <tt>MoveConstructible</tt>
76296 requirements [moveconstructible]:
76297 </p>
76298
76299 <blockquote>
76300
76301 <table border="1">
76302 <caption><ins>Table ?? \97 <tt>Implicit MoveConstructible</tt> requirements
76303 [implicit.moveconstructible] (in addition to
76304 <tt>MoveConstructible</tt>)</ins></caption>
76305
76306 <tbody><tr>
76307 <th><ins>Expression</ins></th>
76308 <th><ins>Operational Semantics</ins></th>
76309 </tr>
76310
76311 <tr>
76312 <td><ins><tt>T u = rv;</tt></ins></td>
76313 <td><ins>Equivalent to: <tt>T u(rv);</tt></ins></td>
76314 </tr>
76315
76316 </tbody></table>
76317 </blockquote>
76318
76319 </li>
76320
76321 <li>
76322 <p>
76323 Add the following new table ?? after Table 35 \97 <tt>CopyConstructible</tt>
76324 requirements [copyconstructible]:
76325 </p>
76326
76327 <blockquote>
76328
76329 <table border="1">
76330 <caption><ins>Table ?? \97 <tt>Implicit CopyConstructible</tt> requirements
76331 [implicit.copyconstructible] (in addition to
76332 <tt>CopyConstructible</tt>)</ins></caption>
76333
76334 <tbody><tr>
76335 <th><ins>Expression</ins></th>
76336 <th><ins>Operational Semantics</ins></th>
76337 </tr>
76338
76339 <tr>
76340 <td><ins><tt>T u = v;</tt></ins></td>
76341 <td><ins>Equivalent to: <tt>T u(v);</tt></ins></td>
76342 </tr>
76343
76344 </tbody></table>
76345 </blockquote>
76346
76347 </li>
76348
76349 <li>
76350 <p>
76351 Change 20.2.3 [nullablepointer.requirements]/1 as follows:
76352 </p>
76353
76354 <blockquote>
76355 <p>
76356 A <tt>NullablePointer</tt> type is a pointer-like type that supports null
76357 values. A type <tt>P</tt> meets the requirements of <tt>NullablePointer</tt> if:
76358 </p>
76359
76360 <ul>
76361 <li>
76362 <tt>P</tt> satisfies the requirements of <tt>EqualityComparable</tt>,
76363 <tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
76364 <tt>CopyAssignable</tt>, and <tt>Destructible</tt>,
76365 </li>
76366
76367 <li>[..]</li>
76368 </ul>
76369 </blockquote>
76370 </li>
76371
76372 <li>
76373 <p>
76374 Change 20.2.4 [hash.requirements]/1 as indicated: <i>[explicit
76375 copy-constructible functors could not be provided as arguments
76376 to any algorithm that takes these by value. Also a typo is fixed.]</i>
76377 </p>
76378
76379 <blockquote>
76380 <p>
76381 1 A type <tt>H</tt> meets the <i>Hash</i> requirements if:
76382 </p>
76383 <ul>
76384 <li>
76385 it is a function object type (20.8),
76386 </li>
76387 <li>
76388 it satis<ins>fies</ins><del>ifes</del> the requirements of
76389 <tt><ins>implicit</ins> CopyConstructible</tt> and <tt>Destructible</tt>
76390 (20.2.1),
76391 </li>
76392 <li>
76393 [..]
76394 </li>
76395 </ul>
76396
76397 </blockquote>
76398
76399 </li>
76400
76401 <li>
76402 <p>
76403 Change 20.7.1 [meta.rqmts]/1+2 as indicated:
76404 </p>
76405
76406 <blockquote>
76407 <p>
76408 1 A <i>UnaryTypeTrait</i> describes a property of a type. It shall be a class
76409 template that takes one template type argument and, optionally, additional
76410 arguments that help define the property being described. It shall be
76411 <tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
76412 [..]
76413 </p>
76414
76415 <p>
76416 2 A <tt>BinaryTypeTrait</tt> describes a relationship between two types. It
76417 shall be a class template that takes two template type arguments and,
76418 optionally, additional arguments that help define the relationship being
76419 described. It shall be <tt>DefaultConstructible</tt>,
76420 <tt><ins>implicit </ins>CopyConstructible</tt>, and [..]
76421 </p>
76422
76423 </blockquote>
76424
76425 </li>
76426
76427 <li>
76428 <p>
76429 Change 20.8.2 [func.require]/4 as indicated: <i>[explicit
76430 copy-constructible functors could not be provided as arguments to any algorithm
76431 that takes these by value]</i>
76432 </p>
76433
76434 <blockquote>
76435 4 Every call wrapper (20.8.1) shall be <tt><ins>implicit</ins>
76436 MoveConstructible</tt>. A simple call wrapper is a call wrapper that is
76437 <tt><ins>implicit</ins> CopyConstructible</tt> and <tt>CopyAssignable</tt> and
76438 whose copy constructor, move constructor, and assignment operator do not throw
76439 exceptions. [..]
76440 </blockquote>
76441 </li>
76442
76443 <li>
76444 <p>
76445 Change 20.8.4 [refwrap]/1 as indicated:
76446 </p>
76447
76448 <blockquote>
76449 1 <tt>reference_wrapper&lt;T&gt;</tt> is a<ins>n <tt>implicit</tt></ins>
76450 <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> wrapper around a
76451 reference to an object or function of type <tt>T</tt>.
76452 </blockquote>
76453 </li>
76454
76455 <li>
76456 <p>
76457 Change 20.8.10.1.2 [func.bind.bind]/5+9 as indicated:
76458 </p>
76459
76460 <blockquote>
76461 <p>
76462 5 <i>Remarks:</i> The return type shall satisfy the requirements of
76463 <tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
76464 <tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
76465 return type shall satisfy the requirements of <tt><ins>implicit</ins>
76466 CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
76467 <tt>TiD</tt> are <tt>MoveConstructible</tt>. \97 <i>end note</i>]
76468 </p>
76469
76470 <p>
76471 [..]
76472 </p>
76473
76474 <p>
76475 9 <i>Remarks:</i> The return type shall satisfy the requirements of
76476 <tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
76477 <tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
76478 return type shall satisfy the requirements of <tt><ins>implicit</ins>
76479 CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
76480 <tt>TiD</tt> are <tt>MoveConstructible</tt>. \97 <i>end note</i>]
76481 </p>
76482 </blockquote>
76483
76484 </li>
76485
76486 <li>
76487 <p>
76488 Change 20.8.10.1.3 [func.bind.place] as indicated:
76489 </p>
76490
76491 <blockquote>
76492 1 All placeholder types shall be <tt>DefaultConstructible</tt> and
76493 <tt><ins>implicit</ins> CopyConstructible</tt>, and [..]
76494 </blockquote>
76495 </li>
76496
76497 <li>
76498 <p>
76499 Change 20.9.9 [unique.ptr]/5 as indicated:
76500 </p>
76501
76502 <blockquote>
76503 5 Each object of a type <tt>U</tt> instantiated form the <tt>unique_ptr</tt>
76504 template specified in this subclause has the strict ownership semantics,
76505 specified above, of a unique pointer. In partial satisfaction of these
76506 semantics, each such <tt>U</tt> is <tt><ins>implicit</ins>
76507 MoveConstructible</tt> and <tt>MoveAssignable</tt>, but is not
76508 <tt>CopyConstructible</tt> nor <tt>CopyAssignable</tt>. The template parameter
76509 <tt>T</tt> of <tt>unique_ptr</tt> may be an incomplete type.
76510 </blockquote>
76511 </li>
76512
76513 <li>
76514 <p>
76515 Change 20.9.10.2 [util.smartptr.shared]/2 as indicated:
76516 </p>
76517
76518 <blockquote>
76519 2 Specializations of <tt>shared_ptr</tt> shall be
76520 <tt><ins>implicit</ins> CopyConstructible</tt>, <tt>CopyAssignable</tt>, and
76521 <tt>LessThanComparable</tt>, [..]
76522 </blockquote>
76523 </li>
76524
76525 <li>
76526 <p>
76527 Change 20.9.10.3 [util.smartptr.weak]/2 as indicated:
76528 </p>
76529
76530 <blockquote>
76531 2 Specializations of <tt>weak_ptr</tt> shall be <tt><ins>implicit</ins>
76532 CopyConstructible</tt> and <tt>CopyAssignable</tt>, allowing their use in
76533 standard containers. The template parameter <tt>T</tt> of <tt>weak_ptr</tt> may
76534 be an incomplete type.
76535 </blockquote>
76536 </li>
76537
76538 <li>
76539 <p>
76540 Change 24.2.2 [iterator.iterators]/2 as indicated: <i>[This fixes a
76541 defect in the Iterator requirements. None of the usual algorithms accepting
76542 iterators would be usable with iterators with explicit copy-constructors]</i>
76543 </p>
76544
76545 <blockquote>
76546 <p>
76547 2 A type <tt>X</tt> satisfies the Iterator requirements if:
76548 </p>
76549
76550 <ul>
76551 <li>
76552 <tt>X</tt> satisfies the <tt><ins>implicit</ins> CopyConstructible</tt>,
76553 <tt>CopyAssignable</tt>, and <tt>Destructible</tt> requirements (20.2.1)
76554 and lvalues of type <tt>X</tt> are swappable (20.2.2), and [..]
76555 </li>
76556 <li>...</li>
76557 </ul>
76558
76559 </blockquote>
76560
76561 </li>
76562
76563 <li>
76564 <p>
76565 Change D.12.1 [auto.ptr]/3 as indicated:
76566 </p>
76567
76568 <blockquote>
76569 3 [..] Instances of <tt>auto_ptr</tt> meet the requirements of
76570 <tt><ins>implicit</ins> MoveConstructible</tt> and <tt>MoveAssignable</tt>, but
76571 do not meet the requirements of <tt>CopyConstructible</tt> and
76572 <tt>CopyAssignable</tt>. \97 <i>end note</i>]
76573 </blockquote>
76574 </li>
76575
76576 </ol>
76577
76578
76579
76580
76581
76582
76583 <hr>
76584 <h3><a name="1323"></a>1323. <tt>basic_string::replace</tt> should use <tt>const_iterator</tt></h3>
76585 <p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
76586  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-02-19 <b>Last modified:</b> 2010-11-24</p>
76587 <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>
76588 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
76589 <p><b>Discussion:</b></p>
76590
76591 <p>
76592 In contrast to all library usages of purely positional iterator values several
76593 overloads of <tt>std::basic_string::replace</tt> still use iterator instead of
76594 <tt>const_iterator</tt> arguments. The paper
76595 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3021.pdf">N3021</a>
76596 quite nicely visualizes the purely positional responsibilities of the function
76597 arguments.
76598 </p>
76599
76600 <p>
76601 This should be fixed to make the library consistent, the proposed changes are
76602 quite mechanic.
76603 </p>
76604
76605 <p><i>[
76606 Post-Rapperswil:
76607 ]</i></p>
76608
76609
76610 <blockquote>
76611 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
76612 </blockquote>
76613
76614 <p><i>[
76615 Adopted at 2010-11 Batavia
76616 ]</i></p>
76617
76618
76619
76620
76621 <p><b>Proposed resolution:</b></p>
76622 <ol>
76623
76624 <li>
76625 <p>
76626 In 21.4 [basic.string], class template <tt>basic_string</tt> synopsis
76627 change as indicated:
76628 </p>
76629
76630 <blockquote><pre>// 21.4.6 modifiers:
76631 ...
76632 basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76633                       const basic_string&amp; str);
76634 basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76635                       const charT* s, size_type n);
76636 basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76637                       const charT* s);
76638 basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76639                       size_type n, charT c);
76640 template&lt;class InputIterator&gt;
76641   basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76642                         InputIterator j1, InputIterator j2);
76643 basic_string&amp; replace(<ins>const_</ins>iterator, <ins>const_</ins>iterator,
76644                       initializer_list&lt;charT&gt;);
76645 </pre></blockquote>
76646 </li>
76647
76648 <li>
76649 <p>
76650 In 21.4.6.6 [string::replace] before p.18, change the following signatures
76651 as indicated:
76652 </p>
76653
76654 <blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const basic_string&amp; str);
76655 </pre></blockquote>
76656 </li>
76657
76658 <li>
76659 <p>
76660 In 21.4.6.6 [string::replace] before p.21, change the following signatures
76661 as indicated:
76662 </p>
76663
76664 <blockquote><pre>basic_string&amp;
76665   replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s, size_type n);
76666 </pre></blockquote>
76667 </li>
76668
76669 <li>
76670 <p>
76671 In 21.4.6.6 [string::replace] before p.24, change the following signatures
76672 as indicated:
76673 </p>
76674
76675 <blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s);
76676 </pre></blockquote>
76677 </li>
76678
76679 <li>
76680 <p>
76681 In 21.4.6.6 [string::replace] before p.27, change the following signatures
76682 as indicated:
76683 </p>
76684
76685 <blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, size_type n,
76686                       charT c);
76687 </pre></blockquote>
76688 </li>
76689
76690 <li>
76691 <p>
76692 In 21.4.6.6 [string::replace] before p.30, change the following signatures
76693 as indicated:
76694 </p>
76695
76696 <blockquote><pre>template&lt;class InputIterator&gt;
76697   basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76698                         InputIterator j1, InputIterator j2);
76699 </pre></blockquote>
76700 </li>
76701
76702 <li>
76703 <p>
76704 In 21.4.6.6 [string::replace] before p.33, change the following signatures
76705 as indicated:
76706 </p>
76707
76708 <blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
76709                       initializer_list&lt;charT&gt; il);
76710 </pre></blockquote>
76711 </li>
76712
76713 </ol>
76714
76715
76716
76717
76718
76719
76720 <hr>
76721 <h3><a name="1324"></a>1324. Still too many implicit conversions for <tt>pair</tt> and  <tt>tuple</tt></h3>
76722 <p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
76723  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-03-20 <b>Last modified:</b> 2010-11-26</p>
76724 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
76725 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
76726 <p><b>Discussion:</b></p>
76727 <p>
76728 In analogy to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <tt>tuple</tt>'s variadic
76729 constructor
76730 </p>
76731
76732 <blockquote><pre>template &lt;class... UTypes&gt;
76733 explicit tuple(UTypes&amp;&amp;... u);
76734 </pre></blockquote>
76735
76736 <p>
76737 creates the same problem as pair:
76738 </p>
76739
76740 <blockquote><pre>#include &lt;tuple&gt;
76741
76742 int main()
76743 {
76744   std::tuple&lt;char*&gt; p(0);
76745 }
76746 </pre></blockquote>
76747
76748 <p>
76749 produces a similar compile error for a recent gcc implementation.
76750 </p>
76751
76752 <p>
76753 I suggest to follow the same resolution path as has been applied to
76754 <tt>pair</tt>'s corresponding c'tor, that is require that these c'tors should
76755 not participate in overload resolution, if the arguments are not implicitly
76756 convertible to the element types.
76757 </p>
76758
76759 <p>
76760 Further-on both <tt>pair</tt> and <tt>tuple</tt> provide converting constructors
76761 from different <tt>pairs</tt>/<tt>tuples</tt> that should be not available, if
76762 the corresponding element types are not implicitly convertible. It seems
76763 astonishing that in the following example
76764 </p>
76765
76766 <blockquote><pre>struct A {
76767   explicit A(int);
76768 };
76769
76770 A  a = 1; <font color="#C80000">// Error</font>
76771
76772 std::tuple&lt;A&gt; ta = std::make_tuple(1); <font color="#C80000">// # OK?</font>
76773 </pre></blockquote>
76774
76775 <p>
76776 the initialization marked with # could be well-formed.
76777 </p>
76778
76779 <p><i>[
76780 Only constraints on constructors are suggested. Adding similar constraints on
76781 assignment operators is considered as QoI, because the assigments wouldn't be
76782 well-formed anyway.
76783 ]</i></p>
76784
76785
76786 <ol>
76787
76788 <li>
76789 <p>
76790 Following 20.3.5.2 [pairs.pair]/5 add a new Remarks element:
76791 </p>
76792
76793 <blockquote><pre>template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
76794 </pre>
76795
76796 <blockquote>
76797 <p>
76798 5 <i>Effects:</i> Initializes members from the corresponding members of the
76799 argument<del>, performing implicit conversions as needed</del>.
76800 </p>
76801
76802 <p>
76803 <ins><i>Remarks:</i> This constructor shall not participate in overload
76804 resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
76805 and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
76806 </p>
76807 </blockquote>
76808 </blockquote>
76809
76810 </li>
76811
76812 <li>
76813 <p>
76814 Following 20.3.5.2 [pairs.pair]/6 add a new Remarks element:
76815 </p>
76816
76817 <blockquote><pre>template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
76818 </pre>
76819
76820 <blockquote>
76821 <p>
76822 6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
76823 <tt>std::move(p.first)</tt> and second with <tt>std::move(p.second)</tt>.
76824 </p>
76825
76826 <p>
76827 <ins><i>Remarks:</i> This constructor shall not participate in overload
76828 resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
76829 and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
76830 </p>
76831 </blockquote>
76832 </blockquote>
76833 </li>
76834
76835 <li>
76836 <p>
76837 Following 20.4.2.1 [tuple.cnstr]/7 add a new Remarks element:
76838 </p>
76839
76840 <blockquote><pre>template &lt;class... UTypes&gt;
76841 explicit tuple(UTypes&amp;&amp;... u);
76842 </pre>
76843
76844 <blockquote>
76845 <p>
76846 6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
76847 <tt>MoveConstructible</tt> (Table 33) from the corresponding type in
76848 <tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
76849 </p>
76850
76851 <p>
76852 7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
76853 corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
76854 </p>
76855
76856 <p>
76857 <ins><i>Remarks:</i> This constructor shall not participate in overload
76858 resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
76859 corresponding type in <tt>Types</tt>.</ins>
76860 </p>
76861 </blockquote>
76862 </blockquote>
76863 </li>
76864
76865 <li>
76866 <p>
76867 Following 20.4.2.1 [tuple.cnstr]/13 add a new Remarks element:
76868 </p>
76869
76870 <blockquote><pre>template &lt;class... UTypes&gt; tuple(const tuple&lt;UTypes...&gt;&amp; u);
76871 </pre>
76872
76873 <blockquote>
76874 <p>
76875 12 <i>Requires:</i> Each type in <tt>Types</tt> shall be constructible from the
76876 corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
76877 sizeof...(UTypes)</tt>.
76878 </p>
76879
76880 <p>
76881 13 <i>Effects:</i> Constructs each element of <tt>*this</tt> with the
76882 corresponding element of <tt>u</tt>.
76883 </p>
76884
76885 <p>
76886 <ins><i>Remarks:</i> This constructor shall not participate in overload
76887 resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
76888 corresponding type in <tt>Types</tt>.</ins>
76889 </p>
76890
76891 <p>
76892 14 [<i>Note:</i> <tt>enable_if</tt> can be used to make the converting
76893 constructor and assignment operator exist only in the cases where the source and
76894 target have the same number of elements. \97 <i>end note</i>]
76895 </p>
76896 </blockquote>
76897 </blockquote>
76898 </li>
76899
76900 <li>
76901 <p>
76902 Following 20.4.2.1 [tuple.cnstr]/16 add a new Remarks element:
76903 </p>
76904
76905 <blockquote><pre>template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
76906 </pre>
76907
76908 <blockquote>
76909 <p>
76910 15 <i>Requires:</i> Each type in <tt>Types</tt> shall shall satisfy the
76911 requirements of <tt>MoveConstructible</tt> (Table 33) from the corresponding
76912 type in <tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
76913 </p>
76914
76915 <p>
76916 16 <i>Effects:</i> Move-constructs each element of <tt>*this</tt> with the
76917 corresponding element of <tt>u</tt>.
76918 </p>
76919
76920 <p>
76921 <ins><i>Remarks:</i> This constructor shall not participate in overload
76922 resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
76923 corresponding type in <tt>Types</tt>.</ins>
76924 </p>
76925
76926 <p>
76927 [<i>Note:</i> <tt>enable_if</tt> can be used to make the converting constructor
76928 and assignment operator exist only in the cases where the source and target have
76929 the same number of elements. \97 <i>end note</i>]
76930 </p>
76931 </blockquote>
76932 </blockquote>
76933 </li>
76934
76935 <li>
76936 <p>
76937 Following 20.4.2.1 [tuple.cnstr]/18 add a new Remarks element:
76938 </p>
76939
76940 <blockquote><pre>template &lt;class U1, class U2&gt; tuple(const pair&lt;U1, U2&gt;&amp; u);
76941 </pre>
76942
76943 <blockquote>
76944 <p>
76945 17 <i>Requires:</i> The first type in <tt>Types</tt> shall be constructible from
76946 <tt>U1</tt> and the second type in <tt>Types</tt> shall be constructible from
76947 <tt>U2</tt>. <tt>sizeof...(Types) == 2</tt>.
76948 </p>
76949
76950 <p>
76951 18 <i>Effects:</i> Constructs the first element with <tt>u.first</tt> and the
76952 second element with <tt>u.second</tt>.
76953 </p>
76954
76955 <p>
76956 <ins><i>Remarks:</i> This constructor shall not participate in overload
76957 resolution unless <tt>U1</tt> is implicitly convertible to the first type in
76958 <tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
76959 <tt>Types</tt>.</ins>
76960 </p>
76961 </blockquote>
76962 </blockquote>
76963 </li>
76964
76965 <li>
76966 <p>
76967 Following 20.4.2.1 [tuple.cnstr]/20 add a new Remarks element:
76968 </p>
76969
76970 <blockquote><pre>template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
76971 </pre>
76972
76973 <blockquote>
76974 <p>
76975 19 <i>Requires:</i> The first type in <tt>Types</tt> shall shall satisfy the
76976 requirements of <tt>MoveConstructible</tt>(Table 33) from <tt>U1</tt> and the
76977 second type in <tt>Types</tt> shall be move-constructible from <tt>U2</tt>.
76978 <tt>sizeof...(Types) == 2</tt>.
76979 </p>
76980
76981 <p>
76982 20 <i>Effects:</i> Constructs the first element with <tt>std::move(u.first)</tt>
76983 and the second element with <tt>std::move(u.second)</tt>
76984 </p>
76985
76986 <p>
76987 <ins><i>Remarks:</i> This constructor shall not participate in overload
76988 resolution unless <tt>U1</tt> is implicitly convertible to the first type in
76989 <tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
76990 <tt>Types</tt>.</ins>
76991 </p>
76992 </blockquote>
76993 </blockquote>
76994 </li>
76995
76996 </ol>
76997 <p><i>[
76998 2010-10-24 Daniel adds:
76999 ]</i></p>
77000
77001
77002 <blockquote>
77003 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
77004 </blockquote>
77005
77006
77007 <p><b>Proposed resolution:</b></p>
77008 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
77009
77010
77011
77012
77013
77014
77015 <hr>
77016 <h3><a name="1325"></a>1325. bitset</h3>
77017 <p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
77018  <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-23</p>
77019 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
77020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
77021 <p><b>Discussion:</b></p>
77022 <p>
77023 As mentioned on the boost mailing list:
77024 </p>
77025
77026 <p>
77027 The following code, valid in C++03, is broken in C++0x due to ambiguity
77028 between the "<tt>unsigned long long</tt>" and "<tt>char*</tt>"
77029 constructors.
77030 </p>
77031
77032 <blockquote><pre>#include &lt;bitset&gt;
77033 std::bitset&lt;10&gt; b(0);
77034 </pre></blockquote>
77035
77036 <p><i>[
77037 The proposed resolution has been reviewed by Stephan T. Lavavej.
77038 ]</i></p>
77039
77040
77041 <p><i>[
77042 Post-Rapperswil
77043 ]</i></p>
77044
77045
77046 <p>
77047 The proposed resolution has two problems:
77048 </p>
77049 <ul>
77050 <li>
77051 <p>it fails to provide support for non-terminated strings, which
77052 could be easily added and constitutes an important use-case. For
77053 example, the following code would invoke UB with the current
77054 P/R:</p>
77055 <blockquote>
77056 <pre>char s[4] = { '0', '1', '0', '1' }; // notice: not null-terminated!
77057 bitset&lt;4&gt; b(s, 0, 4);
77058 </pre></blockquote>
77059 because it requires the evaluation (under the as-if rule, to be fair,
77060 but it doesn't matter) of <tt>basic_string&lt;char&gt;(s)</tt>
77061 </li>
77062 <li>
77063 <p>it promotes a consistency between the two <tt>bitset</tt>
77064 constructors that take a <tt>const std::string&amp;</tt> and a
77065 <tt>const char*</tt>, respectively, while practice established by
77066 <tt>std::basic_string</tt> would recommend a different set of
77067 parameters. In particular, the constructor of
77068 <tt>std::basic_string</tt> that takes a <tt>const char*</tt> does
77069 not have a <tt>pos</tt> parameter</p>
77070 </li>
77071 </ul>
77072
77073 <blockquote>
77074 Moved to Tentatively Ready with revised wording provided by Alberto Ganesh Babati after 5 positive votes on c++std-lib.
77075 </blockquote>
77076
77077 <p><i>[
77078 Adopted at 2010-11 Batavia
77079 ]</i></p>
77080
77081
77082
77083
77084 <p><b>Proposed resolution:</b></p>
77085
77086
77087 <ol>
77088 <li>In the synopsis of header <tt>&lt;bitset&gt;</tt> in
77089 20.5 [template.bitset]/1, replace the fourth bitset constructor:
77090 <blockquote>
77091 <pre><del>explicit bitset(const char *str);</del>
77092 <ins>template &lt;class charT&gt;
77093   explicit bitset(
77094     const charT *str,
77095     typename basic_string&lt;charT&gt;::size_type n = basic_string&lt;charT&gt;::npos,
77096     charT zero = charT('0'), charT one = charT('1'));</ins>
77097 </pre></blockquote>
77098 </li>
77099 <li>In 20.5.1 [bitset.cons]/8:
77100 <blockquote>
77101 <pre><del>explicit bitset(const char *str);</del>
77102 <ins>template &lt;class charT&gt;
77103 explicit
77104 bitset(const charT *str,
77105        typename basic_string&lt;charT&gt;::size_type n = basic_string&lt;charT&gt;::npos,
77106        charT zero = charT('0'), charT one = charT('1'));</ins>
77107 </pre></blockquote>
77108 Effects: Constructs an object of class
77109 <tt>bitset&lt;N&gt;</tt> as if by
77110 <del>bitset(string(str)).</del>
77111 <blockquote><pre><ins>
77112 bitset(
77113   n == basic_string&lt;charT&gt;::npos
77114     ? basic_string&lt;charT&gt;(str)
77115     : basic_string&lt;charT&gt;(str, n),
77116   0, n, zero, one)
77117 </ins></pre></blockquote>
77118 </li>
77119 </ol>
77120
77121
77122
77123
77124
77125
77126 <hr>
77127 <h3><a name="1326"></a>1326. Missing/wrong preconditions for <tt>pair</tt> and <tt>tuple</tt> functions</h3>
77128 <p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
77129  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-26</p>
77130 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
77131 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
77132 <p><b>Discussion:</b></p>
77133 <p>
77134 There are several constructors and creation functions of std::tuple
77135 that impose requirements on it's arguments, that are unnecessary
77136 restrictive and don't match the intention for the supported argument
77137 types. This is related to the fact that tuple is supposed to accept both
77138 object types and lvalue-references and the usual MoveConstructible and
77139 CopyConstructible requirements are bad descriptions for non-const
77140 references. Some examples:
77141 </p>
77142
77143 <ol type="a">
77144 <li>
77145 <p>
77146 20.4.2.1 [tuple.cnstr] before p.4 and p.8, resp.:
77147 </p>
77148
77149 <blockquote><pre>explicit tuple(const Types&amp;...);
77150 </pre>
77151 <blockquote>
77152 4 <i>Requires:</i> Each type in <tt>Types</tt> shall be copy constructible.
77153 </blockquote>
77154
77155 <pre>tuple(const tuple&amp; u) = default;
77156 </pre>
77157 <blockquote>
77158 8 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
77159 <tt>CopyConstructible</tt> (Table 34).
77160
77161 </blockquote>
77162 </blockquote>
77163
77164 <p>
77165 A tuple that contains lvalue-references to non-const can never
77166 satisfy the <tt>CopyConstructible</tt> requirements. <tt>CopyConstructible</tt>
77167 requirements <i>refine</i> the <tt>MoveConstructible</tt> requirements and
77168 this would require that these lvalue-references could bind
77169 rvalues. But the core language does not allow that. Even, if we
77170 would interpret that requirement as referring to the underlying
77171 non-reference type, this requirement would be wrong as well,
77172 because there is no reason to disallow a type such as
77173 </p>
77174
77175 <blockquote><pre>struct NoMoveNoCopy {
77176   NoMoveNoCopy(NoMoveNoCopy&amp;&amp;) = delete;
77177   NoMoveNoCopy(const NoMoveNoCopy&amp;) = delete;
77178   ...
77179 }:
77180 </pre></blockquote>
77181
77182 <p>
77183 for the instantiation of <tt>std::tuple&lt;NoMoveNoCopy&amp;&gt;</tt> and
77184 that of it's copy constructor.
77185 </p>
77186
77187 <p>
77188 A more reasonable requirement for this example would be to require that
77189 "<tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall
77190 evaluate to true for all <tt>Ti</tt> in <tt>Types</tt>". In this case
77191 the special reference-folding and const-merging rules of references
77192 would make this well-formed in all cases. We could also add the further
77193 constraint "if <tt>Ti</tt> is an object type, it shall satisfy the
77194 <tt>CopyConstructible</tt> requirements", but this additional
77195 requirement seems not really to help here. Ignoring it would only mean
77196 that if a user would provide a curious object type <tt>C</tt> that
77197 satisfies the <tt>std::is_constructible&lt;C, const C&amp;&gt;</tt>
77198 test, but not the "<tt>C</tt> is <tt>CopyConstructible</tt>" test would
77199 produce a <tt>tuple&lt;C&gt;</tt> that does not satisfy the
77200 <tt>CopyConstructible</tt> requirements as well.
77201 </p>
77202 </li>
77203
77204 <li>
77205 <p>
77206 20.4.2.1 [tuple.cnstr] before p.6 and p.10, resp.:
77207 </p>
77208
77209 <blockquote><pre>template &lt;class... UTypes&gt;
77210 explicit tuple(UTypes&amp;&amp;... u);
77211 </pre>
77212
77213 <blockquote>
77214 6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the
77215 requirements of <tt>MoveConstructible</tt> (Table 33) from the
77216 corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
77217 sizeof...(UTypes)</tt>.
77218 </blockquote>
77219
77220 <pre>tuple(tuple&amp;&amp; u);
77221 </pre>
77222 <blockquote>
77223 10 <i>Requires:</i> Each <tt>type</tt> in <tt>Types</tt> shall shall
77224 satisfy the requirements of <tt>MoveConstructible</tt> (Table 33).
77225 </blockquote>
77226 </blockquote>
77227
77228 <p>
77229 We have a similar problem as in (a): Non-const lvalue-references
77230 are intended template arguments for <tt>std::tuple</tt>, but cannot satisfy
77231 the <tt>MoveConstructible</tt> requirements. In this case the correct
77232 requirements would be
77233 </p>
77234
77235 <blockquote>
77236 <tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall evaluate to true
77237 for all <tt>Ti</tt> in <tt>Types</tt> and for all <tt>Ui</tt> in
77238 <tt>UTypes</tt>
77239 </blockquote>
77240
77241 <p>
77242 and
77243 </p>
77244
77245 <blockquote>
77246 <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall evaluate to true
77247 for all <tt>Ti</tt> in <tt>Types</tt>
77248 </blockquote>
77249
77250 <p>
77251 respectively.
77252 </p>
77253 </li>
77254 </ol>
77255
77256 <p>
77257 Many <tt>std::pair</tt> member functions do not add proper requirements, e.g.
77258 the default c'tor does not require anything. This is corrected within the
77259 suggested resolution. Further-on the P/R has been adapted to the FCD numbering.
77260 </p>
77261
77262 <p><i>[
77263 2010-03-25 Daniel updated wording:
77264 ]</i></p>
77265
77266
77267 <blockquote>
77268 The issue became updated to fix some minor inconsistencies and to ensure a
77269 similarly required fix for <tt>std::pair</tt>, which has the same specification
77270 problem as <tt>std::tuple</tt>, since <tt>pair</tt> became extended to support
77271 reference members as well.
77272 </blockquote>
77273
77274 <p><i>[Original proposed resolution:]</i></p>
77275
77276 <ol>
77277
77278 <li>
77279 <p>
77280 Change 20.3.5.2 [pairs.pair]/1 as indicated <i>[The changes for the effects
77281 elements are not normative changes, they just ensure
77282 harmonization with existing wording style]</i>:
77283 </p>
77284
77285 <blockquote><pre>constexpr pair();
77286 </pre>
77287
77288 <blockquote>
77289 <p>
77290 <ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
77291 the <tt>DefaultConstructible</tt> requirements.</ins>
77292 </p>
77293
77294 <p>
77295 1 <i>Effects:</i> <ins>Value-initializes <tt>first</tt> and
77296 <tt>second</tt>.</ins><del>Initializes its members as if implemented: <tt>pair()
77297 : first(), second() { }</tt>.</del>
77298 </p>
77299
77300 </blockquote>
77301 </blockquote>
77302
77303 </li>
77304
77305 <li>
77306 <p>
77307 Change 20.3.5.2 [pairs.pair]/2 as indicated:
77308 </p>
77309
77310 <blockquote><pre>pair(const T1&amp; x, const T2&amp; y);
77311 </pre>
77312
77313 <blockquote>
77314 <p>
77315 <ins><i>Requires:</i> <tt>is_constructible&lt;T1, const T1&amp;&gt;::value</tt>
77316 is <tt>true</tt> and <tt>is_constructible&lt;T2, const T2&amp;&gt;::value</tt>
77317 is <tt>true</tt>.</ins>
77318 </p>
77319
77320 <p>
77321 2 <i>Effects:</i> The constructor initializes <tt>first</tt> with <tt>x</tt> and
77322 <tt>second</tt> with <tt>y</tt>.
77323 </p>
77324
77325 </blockquote>
77326 </blockquote>
77327
77328 </li>
77329
77330 <li>
77331 <p>
77332 Change 20.3.5.2 [pairs.pair]/3 as indicated:
77333 </p>
77334
77335 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
77336 </pre>
77337
77338 <blockquote>
77339 <p>
77340 <ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
77341 <tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
77342 <tt>true</tt>.</ins>
77343 </p>
77344
77345 <p>
77346 3 <i>Effects:</i> The constructor initializes <tt>first</tt> with
77347 <tt>std::forward&lt;U&gt;(x)</tt> and <tt>second</tt> with
77348 <tt>std::forward&lt;V&gt;(y)</tt>.
77349 </p>
77350
77351 <p>
77352 4 <i>Remarks:</i> If <tt>U</tt> is not implicitly convertible to
77353 <tt>first_type</tt> or <tt>V</tt> is not implicitly convertible to
77354 <tt>second_type</tt> this constructor shall not participate in overload
77355 resolution.
77356 </p>
77357
77358 </blockquote>
77359 </blockquote>
77360
77361 </li>
77362
77363 <li>
77364 <p>
77365 Change 20.3.5.2 [pairs.pair]/5 as indicated <i>[The change in the effects
77366 element should be non-normatively and is in compatible to the change suggestion
77367 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>]</i>:
77368 </p>
77369
77370 <blockquote><pre>template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
77371 </pre>
77372
77373 <blockquote>
77374 <p>
77375 <ins><i>Requires:</i> <tt>is_constructible&lt;first_type, const
77376 U&amp;&gt;::value</tt> is <tt>true</tt> and <tt>is_constructible&lt;second_type,
77377 const V&amp;&gt;::value</tt> is <tt>true</tt>.</ins>
77378 </p>
77379
77380 <p>
77381 5 <i>Effects:</i> Initializes members from the corresponding members of the
77382 argument<del>, performing implicit conversions as needed</del>.
77383 </p>
77384
77385 </blockquote>
77386 </blockquote>
77387
77388 </li>
77389
77390 <li>
77391 <p>
77392 Change 20.3.5.2 [pairs.pair]/6 as indicated:
77393 </p>
77394
77395 <blockquote><pre>template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
77396 </pre>
77397
77398 <blockquote>
77399 <p>
77400 <ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
77401 <tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
77402 <tt>true</tt>.</ins>
77403 </p>
77404
77405 <p>
77406 6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
77407 <tt>std::<del>move</del><ins>forward&lt;U&gt;</ins>(p.first)</tt> and
77408 <tt>second</tt> with
77409 <tt>std::<del>move</del><ins>forward&lt;V&gt;</ins>(p.second)</tt>.
77410 </p>
77411 </blockquote>
77412 </blockquote>
77413 </li>
77414
77415 <li>
77416 <p>
77417 Change 20.3.5.2 [pairs.pair]/7+8 as indicated [The deletion in the effects
77418 element should be non-normatively]:
77419 </p>
77420
77421 <blockquote><pre>template&lt;class... Args1, class... Args2&gt;
77422   pair(piecewise_construct_t,
77423        tuple&lt;Args1...&gt; first_args, tuple&lt;Args2...&gt; second_args);
77424 </pre>
77425
77426 <blockquote>
77427 <p>
77428 7 <i>Requires:</i> <ins><tt>is_constructible&lt;first_type,
77429 Args1...&gt;::value</tt> is <tt>true</tt> and
77430 <tt>is_constructible&lt;second_type, Args2...&gt;::value</tt> is
77431 <tt>true</tt>.</ins> <del>All the types in <tt>Args1</tt> and <tt>Args2</tt>
77432 shall be <tt>CopyConstructible</tt> (Table 35). <tt>T1</tt> shall be
77433 constructible from <tt>Args1</tt>. <tt>T2</tt> shall be constructible from
77434 <tt>Args2</tt>.</del>
77435 </p>
77436
77437 <p>
77438 8 <i>Effects:</i> The constructor initializes <tt>first</tt> with arguments of
77439 types <tt>Args1...</tt> obtained by forwarding the elements of
77440 <tt>first_args</tt> and initializes <tt>second</tt> with arguments of types
77441 <tt>Args2...</tt> obtained by forwarding the elements of <tt>second_args</tt>.
77442 <del>(Here, forwarding an element <tt>x</tt> of type <tt>U</tt> within a
77443 <tt>tuple</tt> object means calling <tt>std::forward&lt;U&gt;(x)</tt>.)</del>
77444 This form of construction, whereby constructor arguments for <tt>first</tt> and
77445 <tt>second</tt> are each provided in a separate <tt>tuple</tt> object, is called
77446 piecewise construction.
77447 </p>
77448
77449 </blockquote>
77450 </blockquote>
77451
77452 </li>
77453
77454 <li>
77455 <p>
77456 Change 20.3.5.2 [pairs.pair] before 12 as indicated:
77457 </p>
77458
77459 <blockquote><pre>pair&amp; operator=(pair&amp;&amp; p);
77460 </pre>
77461
77462 <blockquote>
77463 <p>
77464 <ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
77465 the <tt>MoveAssignable</tt> requirements.</ins>
77466 </p>
77467
77468 <p>
77469 12 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
77470 and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
77471 </p>
77472
77473 <p>
77474 13 <i>Returns:</i> <tt>*this</tt>.
77475 </p>
77476
77477 </blockquote>
77478 </blockquote>
77479
77480 </li>
77481
77482 <li>
77483 <p>
77484 Change [pairs.pair] before 14 as indicated: [The heterogeneous usage
77485 of MoveAssignable is actually not defined,
77486 but the library uses it at several places, so we follow this tradition
77487 until a better term has been agreed on. One
77488 alternative could be to write "first_type shall be assignable from an
77489 rvalue of U [..]"]
77490 </p>
77491
77492 <blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(pair&lt;U, V&gt;&amp;&amp; p);
77493 </pre>
77494
77495 <blockquote>
77496
77497 <p>
77498 <ins><i>Requires:</i> <tt>first_type</tt> shall be <tt>MoveAssignable</tt> from
77499 <tt>U</tt> and <tt>second_type</tt> shall be <tt>MoveAssignable</tt> from
77500 <tt>V</tt>.</ins>
77501 </p>
77502
77503 <p>
77504 14 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
77505 and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
77506 </p>
77507
77508 <p>
77509 15 <i>Returns:</i> <tt>*this</tt>.
77510 </p>
77511
77512 </blockquote>
77513 </blockquote>
77514
77515 </li>
77516
77517 <li>
77518 <p>
77519 Change 20.4.2.1 [tuple.cnstr]/4+5 as indicated:
77520 </p>
77521
77522 <blockquote><pre>explicit tuple(const Types&amp;...);
77523 </pre>
77524
77525 <blockquote>
77526 <p>
77527 4 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
77528 Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
77529 <ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall be copy
77530 constructible</del>.
77531 </p>
77532
77533 <p>
77534 5 <i>Effects:</i> <del>Copy i</del><ins>I</ins>nitializes each element with the
77535 value of the corresponding parameter.
77536 </p>
77537
77538 </blockquote>
77539 </blockquote>
77540
77541 </li>
77542
77543 <li>
77544 <p>
77545 Change 20.4.2.1 [tuple.cnstr]/6 as indicated:
77546 </p>
77547
77548 <blockquote><pre>template &lt;class... UTypes&gt;
77549 explicit tuple(UTypes&amp;&amp;... u);
77550 </pre>
77551
77552 <blockquote>
77553 <p>
77554 6 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, Ui&gt;::value ==
77555 true</tt> for e</ins><del>E</del>ach type <ins><tt>Ti</tt></ins> in
77556 <tt>Types</tt> <del>shall satisfy the requirements of
77557 <tt>MoveConstructible</tt> (Table 33) from</del><ins>and for</ins> the
77558 corresponding type <ins><tt>Ui</tt></ins> in <tt>UTypes</tt>.
77559 <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
77560 </p>
77561
77562 <p>
77563 7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
77564 corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
77565 </p>
77566
77567 </blockquote>
77568 </blockquote>
77569 </li>
77570
77571 <li>
77572 <p>
77573 Change 20.4.2.1 [tuple.cnstr]/8+9 as indicated:
77574 </p>
77575
77576 <blockquote><pre>tuple(const tuple&amp; u) = default;
77577 </pre>
77578
77579 <blockquote>
77580 <p>
77581 8 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
77582 Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
77583 <ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall satisfy the
77584 requirements of <tt>CopyConstructible</tt>(Table 34)</del>.
77585 </p>
77586
77587 <p>
77588 9 <i>Effects:</i> <ins>Initializes</ins><del>Copy constructs</del> each element
77589 of <tt>*this</tt> with the corresponding element of <tt>u</tt>.
77590 </p>
77591
77592 </blockquote>
77593 </blockquote>
77594 </li>
77595
77596 <li>
77597 <p>
77598 Change 20.4.2.1 [tuple.cnstr]/10+11 as indicated:
77599 </p>
77600
77601 <blockquote><pre>tuple(tuple&amp;&amp; u);
77602 </pre>
77603
77604 <blockquote>
77605 <p>
77606 10 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt> and
77607 let <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>.
77608 Then <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for
77609 all <tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
77610 requirements of <tt>MoveConstructible</tt> (Table 34)</del>.
77611 </p>
77612
77613 <p>
77614 11 <i>Effects:</i> <ins>For each <tt>Ti</tt> in <tt>Types</tt>, initializes the
77615 <tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
77616 <tt>*this</tt> with <del>the corresponding element of</del>
77617 <ins><tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
77618 </p>
77619 </blockquote>
77620 </blockquote>
77621 </li>
77622
77623 <li>
77624 <p>
77625 Change 20.4.2.1 [tuple.cnstr]/15+16 as indicated:
77626 </p>
77627
77628 <blockquote><pre>template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
77629 </pre>
77630
77631 <blockquote>
77632 <p>
77633 15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt>,
77634 <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>, and
77635 <tt>Ui</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>. Then
77636 <tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall be <tt>true</tt> for all
77637 <tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
77638 requirements of <tt>MoveConstructible</tt> (Table 34) from the corresponding
77639 type in <tt>UTypes</tt></del>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
77640 </p>
77641
77642 <p>
77643 16 <i>Effects:</i> <ins>For each type <tt>Ti</tt>, initializes the
77644 <tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
77645 <tt>*this</tt> with <del>the corresponding element of</del>
77646 <ins><tt>std::forward&lt;Ui&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
77647 </p>
77648
77649 </blockquote>
77650 </blockquote>
77651
77652 </li>
77653
77654 <li>
77655 <p>
77656 Change 20.4.2.1 [tuple.cnstr]/19+20 as indicated:
77657 </p>
77658
77659 <blockquote><pre>template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
77660 </pre>
77661
77662 <blockquote>
77663 <p>
77664 19 <i>Requires:</i> <ins><tt>is_constructible&lt;T1, U1&gt;::value ==
77665 true</tt> for <tt>t</tt></ins><del><tt>T</tt></del>he first type
77666 <ins><tt>T1</tt></ins> in <tt>Types</tt> <del>shall shall satisfy the
77667 requirements of <tt>MoveConstructible</tt>(Table 33) from
77668 <tt>U1</tt></del> and <ins><tt>is_constructible&lt;T2, U2&gt;::value ==
77669 true</tt> for</ins> the second type <ins><tt>T2</tt></ins> in
77670 <tt>Types</tt> <del>shall be move-constructible from <tt>U2</tt></del>.
77671 <tt>sizeof...(Types) == 2</tt>.
77672 </p>
77673
77674 <p>
77675 20 <i>Effects:</i> <ins>Initializes</ins><del>Constructs</del> the first
77676 element with
77677 <tt>std::<ins>forward&lt;U1&gt;</ins><del>move</del>(u.first)</tt> and
77678 the second element with
77679 <tt>std::<ins>forward&lt;U2&gt;</ins><del>move</del>(u.second)</tt>.
77680 </p>
77681
77682 </blockquote>
77683 </blockquote>
77684 </li>
77685
77686 <li>
77687 <p>
77688 Change 20.4.2.4 [tuple.creation]/9-16 as indicated:
77689 </p>
77690
77691 <blockquote><pre>template &lt;class... TTypes, class... UTypes&gt;
77692 tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
77693 </pre>
77694
77695 <blockquote>
77696 <p>
77697 9 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
77698 Ti&amp;&gt;::value == true</tt> for each type <tt>Ti</tt></ins><del>All
77699 the types</del> in <tt>TTypes</tt> <del>shall be
77700 <tt>CopyConstructible</tt> (Table 34)</del>.
77701 <ins><tt>is_constructible&lt;Ui, const Ui&amp;&gt;::value == true</tt>
77702 for each type <tt>Ui</tt></ins><del>All the types</del> in
77703 <tt>UTypes</tt> <del>shall be <tt>CopyConstructible</tt> (Table
77704 34)</del>.
77705 </p>
77706
77707 <p>
77708 10 <i>Returns:</i> A <tt>tuple</tt> object constructed by
77709 <ins>initializing</ins><del>copy constructing</del> its first
77710 <tt>sizeof...(TTypes)</tt> elements from the corresponding elements of
77711 <tt>t</tt> and <ins>initializing</ins><del>copy constructing</del> its
77712 last <tt>sizeof...(UTypes)</tt> elements from the corresponding elements
77713 of <tt>u</tt>.
77714 </p>
77715 </blockquote>
77716
77717 <pre>template &lt;class... TTypes, class... UTypes&gt;
77718 tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
77719 </pre>
77720
77721 <blockquote>
77722 <p>
77723 11 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
77724 <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
77725 <tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
77726 <tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
77727 <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
77728 type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, const Uj&amp;&gt;::value</tt>
77729 shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
77730 <tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
77731 <tt>UTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35)</del>.
77732 </p>
77733
77734 <p>
77735 12 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
77736 <tt>i</tt><sup><i>th</i></sup> element with
77737 <tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for all <tt>Ti</tt> in
77738 <tt>TTypes</tt> and initializing the
77739 <tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
77740 <tt>get&lt;j&gt;(u)</tt> for all <tt>Uj</tt> in <tt>UTypes</tt>.</ins> <del>move
77741 constructing its first <tt>sizeof...(TTypes)</tt> elements from the
77742 corresponding elements of <tt>t</tt> and copy constructing its last
77743 <tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
77744 <tt>u</tt></del>.
77745 </p>
77746 </blockquote>
77747
77748 <pre>template &lt;class... TTypes, class... UTypes&gt;
77749 tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
77750 </pre>
77751
77752 <blockquote>
77753 <p>
77754 13 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
77755 <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
77756 <tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
77757 <tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
77758 <tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall be <tt>true</tt>
77759 for each type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt>
77760 shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
77761 <tt>TTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35). All the types in
77762 <tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
77763 </p>
77764
77765 <p>
77766 14 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
77767 <tt>i</tt><sup><i>th</i></sup> element with <tt>get&lt;i&gt;(t)</tt> for each
77768 type <tt>Ti</tt> and initializing the
77769 <tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
77770 <tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
77771 <del>copy constructing its first <tt>sizeof...(TTypes)</tt> elements from the
77772 corresponding elements of <tt>t</tt> and move constructing its last
77773 <tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
77774 <tt>u</tt></del>.
77775 </p>
77776 </blockquote>
77777
77778 <pre>template &lt;class... TTypes, class... UTypes&gt;
77779 tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
77780 </pre>
77781
77782 <blockquote>
77783 <p>
77784 15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
77785 <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
77786 <tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
77787 <tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
77788 <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
77789 type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt> shall be
77790 <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
77791 <tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
77792 <tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
77793 </p>
77794
77795 <p>
77796 16 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
77797 <tt>i</tt><sup><i>th</i></sup> element with
77798 <tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for each type <tt>Ti</tt> and
77799 initializing the <tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
77800 <tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
77801 <del>move constructing its first <tt>sizeof...(TTypes)</tt> elements from the
77802 corresponding elements of <tt>t</tt> and move constructing its last
77803 <tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
77804 <tt>u</tt></del>.
77805 </p>
77806 </blockquote>
77807 </blockquote>
77808 </li>
77809 </ol>
77810
77811
77812 <p><i>[
77813 2010-10-24 Daniel adds:
77814 ]</i></p>
77815
77816
77817 <blockquote>
77818 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
77819 </blockquote>
77820
77821
77822 <p><b>Proposed resolution:</b></p>
77823 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
77824
77825
77826
77827
77828
77829
77830 <hr>
77831 <h3><a name="1327"></a>1327. templates defined in <tt>&lt;cmath&gt;</tt> replacing C macros with the same name</h3>
77832 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
77833  <b>Submitter:</b> Michael Wong <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-29</p>
77834 <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>
77835 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
77836 <p><b>Discussion:</b></p>
77837 <p>
77838 In 26.8 [c.math]p12
77839 The templates defined in <tt>&lt;cmath&gt;</tt> replace the C99 macros
77840 with the same names. The templates have the following declarations:
77841 </p>
77842
77843 <blockquote><pre>namespace std {
77844 template &lt;class T&gt; bool signbit(T x);
77845 template &lt;class T&gt; int fpclassify(T x);
77846 template &lt;class T&gt; bool isfinite(T x);
77847 template &lt;class T&gt; bool isinf(T x);
77848 template &lt;class T&gt; bool isnan(T x);
77849 template &lt;class T&gt; bool isnormal(T x);
77850 template &lt;class T&gt; bool isgreater(T x, T y);
77851 template &lt;class T&gt; bool isgreaterequal(T x, T y);
77852 template &lt;class T&gt; bool isless(T x, T y);
77853 template &lt;class T&gt; bool islessequal(T x, T y);
77854 template &lt;class T&gt; bool islessgreater(T x, T y);
77855 template &lt;class T&gt; bool isunordered(T x, T y);
77856 }
77857 </pre></blockquote>
77858
77859 <p>
77860 and p13:
77861 </p>
77862
77863 <blockquote>
77864 13 The templates behave the same as the C99 macros with corresponding
77865 names defined in C99 7.12.3, Classification macros, and C99 7.12.14,
77866 Comparison macros in the C standard.
77867 </blockquote>
77868
77869 <p>
77870 The C Std versions look like this:
77871 </p>
77872
77873 <blockquote>
77874 <p>
77875 7.12.14.1/p1:
77876 </p>
77877 <blockquote>
77878 <p>
77879 Synopsis
77880 </p>
77881 <p>
77882 1 <tt>#include &lt;math.h&gt;</tt>
77883 </p>
77884 <pre>int isgreaterequal(real-floating x, real-floating y);
77885 </pre>
77886 </blockquote>
77887 </blockquote>
77888
77889 <p>
77890 which is not necessarily the same types as is required by C++ since the
77891 two parameters may be different. Would it not be better if it were truly
77892 aligned with C?
77893 </p>
77894
77895 <p><i>[
77896 2010 Pittsburgh:  Bill to ask WG-14 if heterogeneous support for the
77897 two-parameter macros is intended.
77898 ]</i></p>
77899
77900
77901 <p><i>[
77902 2010-09-13 Daniel comments:
77903 ]</i></p>
77904
77905
77906 <blockquote>
77907 I recommend to resolve this issue as NAD Editorial because
77908 the accepted resolution for NB comment <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3162.html#US136">US-136</a>
77909 by motion 27 does address this.
77910 </blockquote>
77911
77912 <p><i>[
77913 2010-09-14 Bill comments:
77914 ]</i></p>
77915
77916
77917 <blockquote>
77918 Motion 27 directly addresses LWG 1327 and solves the problem
77919 presented there. Moreover, the solution has been aired before
77920 WG14 with no dissent. These functions now behave the same for
77921 mixed-mode calls in both C and C++
77922 </blockquote>
77923
77924
77925
77926 <p><b>Proposed resolution:</b></p>
77927 Apply proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3162.html#US136">US-136</a>
77928
77929
77930
77931
77932
77933 <hr>
77934 <h3><a name="1328"></a>1328. istream extractors not setting failbit if eofbit is already set</h3>
77935 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
77936  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2010-02-17 <b>Last modified:</b> 2010-11-26</p>
77937 <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>
77938 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
77939 <p><b>Discussion:</b></p>
77940 <p>
77941 basing on the recent discussion on the library reflector, see c++std-lib-27728
77942 and follow ups, I hereby formally ask for LWG 419 to be re-opened, the rationale
77943 being that according to the current specifications, per
77944 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">n3000</a>,
77945 it seems actually impossible to seek away from end of file, contrary to the
77946 rationale which led <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> to its closure as NAD. My request is also
77947 supported by Martin Sebor, and I'd like also to add, as tentative proposed
77948 resolution for the re-opened issue, the wording suggested by Sebor, thus, change
77949 the beginning of 27.7.1.1.3 [istream::sentry]/2, to:
77950 </p>
77951
77952 <blockquote>
77953 2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
77954 <tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
77955 Otherwise prepares for formatted or unformatted input. ...
77956 </blockquote>
77957
77958 <p><i>[
77959 2010-10 Batavia"
77960 ]</i></p>
77961
77962 <p>
77963 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.
77964 </p>
77965
77966 <p>
77967 Previous proposed resolution:
77968 </p><p>
77969 Change 27.7.1.1.3 [istream::sentry]/2:
77970 </p>
77971
77972 <blockquote>
77973 2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
77974 <tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
77975 Otherwise prepares for formatted or unformatted input. ...
77976 </blockquote>
77977
77978
77979
77980 <p></p>
77981
77982
77983 <p><b>Proposed resolution:</b></p>
77984 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.
77985
77986
77987
77988
77989
77990 <hr>
77991 <h3><a name="1333"></a>1333. Missing forwarding during std::function invocation</h3>
77992 <p><b>Section:</b> 20.8.14.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
77993  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-03-26 <b>Last modified:</b> 2010-11-23</p>
77994 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.inv">issues</a> in [func.wrap.func.inv].</p>
77995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
77996 <p><b>Discussion:</b></p>
77997 <p>
77998 The current wording of 20.8.14.2.4 [func.wrap.func.inv]/1:
77999 </p>
78000
78001 <blockquote><pre>R operator()(ArgTypes... args) const
78002 </pre>
78003
78004 <blockquote>
78005 <i>Effects:</i> <tt><i>INVOKE</i>(f, t1, t2, ..., tN, R)</tt> (20.8.2), where
78006 <tt>f</tt> is the target object (20.8.1) of <tt>*this</tt> and <tt>t1, t2, ...,
78007 tN</tt> are the values in <tt>args...</tt>.
78008 </blockquote>
78009 </blockquote>
78010
78011 <p>
78012 uses an unclear relation between the actual args and the used variables
78013 <tt>ti</tt>. It should be made clear, that <tt>std::forward</tt> has to be used
78014 to conserve the expression lvalueness.
78015 </p>
78016
78017 <p><i>[
78018 Post-Rapperswil:
78019 ]</i></p>
78020
78021
78022 <blockquote>
78023 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
78024 </blockquote>
78025
78026 <p><i>[
78027 Adopted at 2010-11 Batavia
78028 ]</i></p>
78029
78030
78031
78032
78033 <p><b>Proposed resolution:</b></p>
78034 <p>
78035 Change 20.8.14.2.4 [func.wrap.func.inv]/1+2 as indicated:
78036 </p>
78037
78038 <blockquote><pre>R operator()(ArgTypes... args) const
78039 </pre>
78040
78041 <blockquote>
78042 <p>
78043 1 <i>Effects:</i>: <tt><i>INVOKE</i>(f,
78044 <ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
78045 R)</tt> (20.8.2), where <tt>f</tt> is the target object (20.8.1) of
78046 <tt>*this</tt> <del>and <tt>t1, t2, ..., tN</tt> are the values in
78047 <tt>args...</tt></del>.
78048 </p>
78049
78050 <p>
78051 2 <i>Returns:</i> Nothing if <tt>R</tt> is <tt>void</tt>, otherwise the return
78052 value of <tt><i>INVOKE</i>(f,
78053 <ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
78054 R)</tt>.
78055 </p>
78056
78057 <p>
78058 3 <i>Throws:</i> <tt>bad_function_call</tt> if <tt>!*this</tt>; otherwise, any
78059 exception thrown by the wrapped callable object.
78060 </p>
78061 </blockquote>
78062 </blockquote>
78063
78064
78065
78066
78067
78068
78069 <hr>
78070 <h3><a name="1334"></a>1334. Insert iterators are broken for some proxy  containers compared to C++03</h3>
78071 <p><b>Section:</b> 24.5.2.2.2 [back.insert.iter.op=], 24.5.2.4.2 [front.insert.iter.op=], X [insert.insert.iter.op=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78072  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-03-28 <b>Last modified:</b> 2010-11-24</p>
78073 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78074 <p><b>Discussion:</b></p>
78075 <p>
78076 In C++03 this was valid code:
78077 </p>
78078
78079 <blockquote><pre>#include &lt;vector&gt;
78080 #include &lt;iterator&gt;
78081
78082 int main() {
78083   typedef std::vector&lt;bool&gt; Cont;
78084   Cont c;
78085   std::back_insert_iterator&lt;Cont&gt; it = std::back_inserter(c);
78086   *it = true;
78087 }
78088 </pre></blockquote>
78089
78090 <p>
78091 In C++0x this code does no longer compile because of an ambiguity error for this
78092 <tt>operator=</tt> overload pair:
78093 </p>
78094
78095 <blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
78096 operator=(typename Container::const_reference value);
78097
78098 back_insert_iterator&lt;Container&gt;&amp;
78099 operator=(typename Container::value_type&amp;&amp; value);
78100 </pre></blockquote>
78101
78102 <p>
78103 This is so, because for proxy-containers like <tt>std::vector&lt;bool&gt;</tt>
78104 the <tt>const_reference</tt> usually is a non-reference type and in this case
78105 it's identical to <tt>Container::value_type</tt>, thus forming the ambiguous
78106 overload pair
78107 </p>
78108
78109 <blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
78110 operator=(bool value);
78111
78112 back_insert_iterator&lt;Container&gt;&amp;
78113 operator=(bool&amp;&amp; value);
78114 </pre></blockquote>
78115
78116 <p>
78117 The same problem exists for <tt>std::back_insert_iterator</tt>,
78118 <tt>std::front_insert_iterator</tt>, and <tt>std::insert_iterator</tt>.
78119 </p>
78120
78121 <p>
78122 One possible fix would be to require that <tt>const_reference</tt> of a proxy
78123 container must not be the same as the <tt>value_type</tt>, but this would break
78124 earlier valid code. The alternative would be to change the first signature to
78125 </p>
78126
78127 <blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
78128 operator=(const typename Container::const_reference&amp; value);
78129 </pre></blockquote>
78130
78131 <p>
78132 This would have the effect that this signature <em>always</em> expects an lvalue
78133 or rvalue, but it would not create an ambiguity relative to the second form with
78134 rvalue-references. [For all non-proxy containers the signature will be the same
78135 as before due to reference-collapsing and const folding rules]
78136 </p>
78137
78138
78139 <p><i>[
78140 Post-Rapperswil
78141 ]</i></p>
78142
78143
78144 <p>
78145 This problem is not restricted to the unspeakable <tt>vector&lt;bool&gt;</tt>, but is already existing for other proxy 
78146 containers like gcc's <tt>rope</tt> class. The following code does no longer work ([Bug libstdc++/44963]):
78147 </p>
78148 <blockquote><pre>#include &lt;iostream&gt;
78149 #include &lt;ext/rope&gt;
78150
78151 using namespace std;
78152
78153 int main()
78154 {
78155      __gnu_cxx::crope line("test");
78156      auto ii(back_inserter(line));
78157
78158      *ii++ = 'm'; // #1
78159      *ii++ = 'e'; // #2
78160
78161      cout &lt;&lt; line &lt;&lt; endl;
78162 }
78163 </pre></blockquote>
78164 <p>
78165 Both lines marked with #1 and #2 issue now an error because the library has properly implemented the current
78166 wording state (Thanks to Paolo Calini for making me aware of this real-life example).
78167 </p>
78168 <p>
78169 The following P/R is a revision of the orignal P/R and was initially suggested by Howard 
78170 Hinnant. Paolo verified that the approach works in gcc.
78171 </p>
78172
78173 <blockquote>
78174 Moved to Tentatively Ready with revised wording after 6 positive votes on c++std-lib.
78175 </blockquote>
78176
78177 <p><i>[
78178 Adopted at 2010-11 Batavia
78179 ]</i></p>
78180
78181
78182
78183
78184 <p><b>Proposed resolution:</b></p>
78185 <p><i>The wording refers to N3126.</i></p>
78186
78187 <ol>
78188 <li>Change [back.insert.iterator], class <tt>back_insert_iterator</tt> synopsis as indicated:
78189 <blockquote><pre>template &lt;class Container&gt;
78190 class back_insert_iterator :
78191  public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
78192 protected:
78193  Container* container;
78194 public:
78195  [..]
78196  back_insert_iterator&lt;Container&gt;&amp;
78197    operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78198  back_insert_iterator&lt;Container&gt;&amp;
78199    operator=(typename Container::value_type&amp;&amp; value);
78200  [..]
78201 };
78202 </pre></blockquote>
78203 </li>
78204 <li>Change [back.insert.iter.op=] before p. 1 as indicated:
78205 <blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
78206    operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78207 </pre>
78208 <blockquote>
78209 1 <em>Effects</em>: <tt>container-&gt;push_back(value)</tt>;<br>
78210 2 <em>Returns</em>: <tt>*this</tt>.
78211 </blockquote></blockquote>
78212 </li>
78213 <li>Change [front.insert.iterator], class <tt>front_insert_iterator</tt> synposis as indicated:
78214 <blockquote><pre>template &lt;class Container&gt;
78215 class front_insert_iterator :
78216  public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
78217 protected:
78218  Container* container;
78219 public:
78220  [..]
78221  front_insert_iterator&lt;Container&gt;&amp;
78222    operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78223  front_insert_iterator&lt;Container&gt;&amp;
78224    operator=(typename Container::value_type&amp;&amp; value);
78225  [..]
78226 };
78227 </pre></blockquote>
78228 </li>
78229 <li>Change [front.insert.iter.op=] before p.1 as indicated:
78230 <blockquote><pre>front_insert_iterator&lt;Container&gt;&amp;
78231    operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78232 </pre>
78233 <blockquote>
78234 1 <em>Effects</em>: <tt>container-&gt;push_front(value)</tt>;<br>
78235 2 <em>Returns</em>: <tt>*this</tt>.
78236 </blockquote></blockquote>
78237 </li>
78238 <li>Change [insert.iterator], class insert_iterator synopsis as indicated:
78239 <blockquote><pre>template &lt;class Container&gt;
78240    class insert_iterator :
78241      public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
78242    protected:
78243      Container* container;
78244      typename Container::iterator iter;
78245    public:
78246      [..]
78247      insert_iterator&lt;Container&gt;&amp;
78248        operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78249      insert_iterator&lt;Container&gt;&amp;
78250        operator=(typename Container::value_type&amp;&amp; value);
78251      [..]
78252    };
78253 </pre></blockquote>
78254 </li>
78255 <li>Change [insert.iter.op=] before p. 1 as indicated:
78256 <blockquote><pre>insert_iterator&lt;Container&gt;&amp;
78257     operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
78258 </pre>
78259 <blockquote>
78260 1 <em>Effects</em>: 
78261 <blockquote><pre>  iter = container-&gt;insert(iter, value);
78262   ++iter;
78263 </pre></blockquote>
78264 2 <em>Returns</em>: <tt>*this</tt>.
78265 </blockquote></blockquote>
78266 </li>
78267 </ol>
78268
78269
78270
78271
78272
78273
78274 <hr>
78275 <h3><a name="1335"></a>1335. Insufficient requirements for <tt>tuple::operator&lt;()</tt></h3>
78276 <p><b>Section:</b> 20.4.2.7 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78277  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2010-05-15 <b>Last modified:</b> 2010-11-23</p>
78278 <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>
78279 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78280 <p><b>Discussion:</b></p>
78281 <p>
78282 The requirements section for <tt>std::tuple</tt> says the following: 
78283 </p>
78284
78285 <blockquote>
78286 <i>Requires:</i> For all <tt>i</tt>, where <tt>0 &lt;= i and i &lt;
78287 sizeof...(Types)</tt>, <tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> is a valid
78288 expression returning a type that is convertible to <tt>bool</tt>.
78289 <tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
78290 </blockquote>
78291
78292 <p>
78293 This is necessary but not sufficient, as the algorithm for comparing
78294 <tt>tuple</tt>s also computes <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt>
78295 (note the order)
78296 </p>
78297
78298 <p><i>[
78299 Post-Rapperswil
78300 ]</i></p>
78301
78302
78303 <blockquote>
78304 Moved to Tentatively Ready with updated wording correcting change-bars after 6 positive votes on c++std-lib.
78305 </blockquote>
78306
78307 <p><i>[
78308 Adopted at 2010-11 Batavia
78309 ]</i></p>
78310
78311
78312
78313
78314 <p><b>Proposed resolution:</b></p>
78315
78316 <ol>
78317 <li>Change [tuple.rel] before p. 4 as indicated [<strong>Remark to the editor: This paragraph doesn't have a number yet,
78318 but it seems to me as if it should have one</strong>]:
78319 <blockquote><pre>template&lt;class... TTypes, class... UTypes&gt;
78320 bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
78321 </pre>
78322 <blockquote>
78323 <em>Requires</em>: For all <tt>i</tt>, where <tt>0 &lt;= i</tt> and <tt>i &lt; sizeof...(Types)</tt>, 
78324 <tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> <ins>and <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt></ins><del>is 
78325 a valid expression returning a type that is</del><ins> are valid expressions returning types that 
78326 are</ins> convertible to <tt>bool</tt>. <tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
78327 </blockquote></blockquote>
78328 </li>
78329 </ol>
78330
78331
78332
78333
78334
78335
78336 <hr>
78337 <h3><a name="1337"></a>1337. Swapped arguments in <tt>regex_traits::isctype</tt></h3>
78338 <p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78339  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-21 <b>Last modified:</b> 2010-11-24</p>
78340 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.traits">issues</a> in [re.traits].</p>
78341 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78342 <p><b>Discussion:</b></p>
78343 <p>
78344 28.7 [re.traits]/12 describes <tt>regex_traits::isctype</tt> in terms
78345 of <tt>ctype::is(c, m)</tt>, where <tt>c</tt> is a <tt>charT</tt> and <tt>m</tt>
78346 is a <tt>ctype_base::mask</tt>.  Unfortunately 22.4.1.1.1 [locale.ctype.members]
78347 specifies this function as <tt>ctype::is(m, c)</tt>
78348 </p>
78349
78350 <p><i>[
78351 Post-Rapperswil:
78352 ]</i></p>
78353
78354
78355 <blockquote>
78356 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
78357 </blockquote>
78358
78359 <p><i>[
78360 Adopted at 2010-11 Batavia
78361 ]</i></p>
78362
78363
78364
78365
78366 <p><b>Proposed resolution:</b></p>
78367 <p>
78368 Change 28.7 [re.traits]/12:
78369 </p>
78370
78371 <blockquote><pre>bool isctype(charT c, char_class_type f) const;
78372 </pre>
78373 <blockquote>
78374 <p>
78375 11 ...
78376 </p>
78377 <p>
78378 12 <i>Returns:</i> Converts <tt>f</tt> into a value <tt>m</tt> of type
78379 <tt>std::ctype_base::mask</tt> in an unspecified manner, and returns
78380 <tt>true</tt> if <tt>use_facet&lt;ctype&lt;charT&gt;
78381 &gt;(getloc()).is(<del>c</del><ins>m</ins>, <del>m</del><ins>c</ins>)</tt> is
78382 <tt>true</tt>. Otherwise returns <tt>true</tt> if <tt>f</tt> bitwise or'ed with
78383 the result of calling <tt>lookup_classname</tt> with an iterator pair that
78384 designates the character sequence <tt>"w"</tt> is not equal to 0 and <tt>c ==
78385 '_'</tt>, or if <tt>f</tt> bitwise or'ed with the result of calling
78386 <tt>lookup_classname</tt> with an iterator pair that designates the character
78387 sequence <tt>"blank"</tt> is not equal to 0 and <tt>c</tt> is one of an
78388 implementation-defined subset of the characters for which <tt>isspace(c,
78389 getloc())</tt> returns <tt>true</tt>, otherwise returns <tt>false</tt>.
78390 </p>
78391 </blockquote>
78392 </blockquote>
78393
78394
78395
78396
78397
78398 <hr>
78399 <h3><a name="1338"></a>1338. LWG 1205 incorrectly applied</h3>
78400 <p><b>Section:</b> 25.2.13 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78401  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-25 <b>Last modified:</b> 2010-11-24</p>
78402 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
78403 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78404 <p><b>Discussion:</b></p>
78405 <p>
78406 LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a> (currently in WP) clarified the return value of several
78407 algorithms when dealing with empty ranges.  In particular it recommended for
78408 25.2.13 [alg.search]:
78409 </p>
78410
78411 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
78412   ForwardIterator1
78413     search(ForwardIterator1 first1, ForwardIterator1 last1,
78414            ForwardIterator2 first2, ForwardIterator2 last2);
78415
78416 template&lt;class ForwardIterator1, class ForwardIterator2,
78417          class BinaryPredicate&gt;
78418   ForwardIterator1
78419     search(ForwardIterator1 first1, ForwardIterator1 last1,
78420            ForwardIterator2 first2, ForwardIterator2 last2,
78421            BinaryPredicate pred);
78422 </pre>
78423 <blockquote>
78424 <p>
78425 1 <i>Effects:</i> ...
78426 </p>
78427 <p>
78428 2 <i>Returns:</i> ... Returns <tt>last1</tt> if no such iterator is found.
78429 </p>
78430 <p><ins>
78431 3 <i>Remarks:</i> Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
78432 </ins></p>
78433 </blockquote>
78434 </blockquote>
78435
78436 <p>
78437 Unfortunately this got translated to an incorrect specification for what gets
78438 returned when no such iterator is found (N3092):
78439 </p>
78440
78441 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
78442   ForwardIterator1
78443     search(ForwardIterator1 first1, ForwardIterator1 last1,
78444            ForwardIterator2 first2, ForwardIterator2 last2);
78445
78446 template&lt;class ForwardIterator1, class ForwardIterator2,
78447          class BinaryPredicate&gt;
78448   ForwardIterator1
78449     search(ForwardIterator1 first1, ForwardIterator1 last1,
78450            ForwardIterator2 first2, ForwardIterator2 last2,
78451            BinaryPredicate pred);
78452 </pre>
78453 <blockquote>
78454 <p>
78455 1 <i>Effects:</i> ...
78456 </p>
78457 <p>
78458 2 <i>Returns:</i> ... Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is
78459 empty or if no such iterator is found.
78460 </p>
78461 </blockquote>
78462 </blockquote>
78463
78464 <p>
78465 LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a> is correct and N3092 is not equivalent nor correct.
78466 </p>
78467
78468 <p>
78469 I have not reviewed the other 10 recommendations of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>.
78470 </p>
78471
78472 <p><i>[
78473 Post-Rapperswil
78474 ]</i></p>
78475
78476
78477 <blockquote>
78478 It was verified that none of the remaining possibly affected algorithms does have any similar problems and a concrete P/R was added
78479 that used a similar style as has been applied to the other cases.
78480 </blockquote>
78481
78482 <blockquote>
78483 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
78484 </blockquote>
78485
78486 <p><i>[
78487 Adopted at 2010-11 Batavia
78488 ]</i></p>
78489
78490
78491
78492
78493 <p><b>Proposed resolution:</b></p>
78494 <ol>
78495 <li>Change [alg.search]/2 as indicated:
78496 <blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
78497   ForwardIterator1
78498     search(ForwardIterator1 first1, ForwardIterator1 last1,
78499            ForwardIterator2 first2, ForwardIterator2 last2);
78500
78501 template&lt;class ForwardIterator1, class ForwardIterator2,
78502             class BinaryPredicate&gt;
78503   ForwardIterator1
78504     search(ForwardIterator1 first1, ForwardIterator1 last1,
78505            ForwardIterator2 first2, ForwardIterator2 last2,
78506            BinaryPredicate pred);
78507 </pre>
78508 <blockquote><p>
78509 1 - [...]
78510 </p>
78511 2 - <em>Returns</em>: The first iterator <tt>i</tt> in the range <tt>[first1,last1 - (last2-first2))</tt> such that for any nonnegative
78512 integer <tt>n</tt> less than <tt>last2 - first2</tt> the following corresponding conditions hold: <tt>*(i + n) == *(first2 + n)</tt>, 
78513 <tt>pred(*(i + n), *(first2 + n)) != false</tt>. Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty <del>or</del><ins>, otherwise
78514         returns <tt>last1</tt></ins> if no such iterator is found.
78515 </blockquote></blockquote>
78516 </li>
78517 </ol>
78518
78519
78520
78521
78522
78523 <hr>
78524 <h3><a name="1339"></a>1339. <tt>uninitialized_fill_n</tt> should return the end of its range</h3>
78525 <p><b>Section:</b> 20.9.8.4 [uninitialized.fill.n] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78526  <b>Submitter:</b> Jared Hoberock <b>Opened:</b> 2010-07-14 <b>Last modified:</b> 2010-11-23</p>
78527 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78528 <p><b>Discussion:</b></p>
78529 <p>
78530 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092's</a>
78531 specification of <tt>uninitialized_fill_n</tt> discards useful information and
78532 is inconsistent with other algorithms such as <tt>fill_n</tt> which accept an
78533 iterator and a size.  As currently specified, <tt>unintialized_fill_n</tt>
78534 requires an additional linear traversal to find the end of the range.
78535 </p>
78536
78537 <p>
78538 Instead of returning <tt>void</tt>, <tt>unintialized_fill_n</tt> should return
78539 one past the last iterator it dereferenced.
78540 </p>
78541
78542 <p><i>[
78543 Post-Rapperswil:
78544 ]</i></p>
78545
78546
78547 <blockquote>
78548 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
78549 </blockquote>
78550
78551 <p><i>[
78552 Adopted at 2010-11 Batavia
78553 ]</i></p>
78554
78555
78556
78557
78558 <p><b>Proposed resolution:</b></p>
78559 <p>
78560 In section 20.9 [memory] change:,
78561 </p>
78562
78563 <blockquote><pre>template &lt;class ForwardIterator, class Size, class T&gt;
78564   <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
78565 </pre></blockquote>
78566
78567
78568 <p>
78569 In section 20.9.8.4 [uninitialized.fill.n] change,
78570 </p>
78571
78572 <blockquote><pre>template &lt;class ForwardIterator, class Size, class T&gt;
78573   <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
78574 </pre>
78575 <blockquote>
78576 <p>
78577 1 <i>Effects:</i>
78578 </p>
78579 <blockquote><pre>for (; n--; ++first)
78580   ::new (static_cast&lt;void*&gt;(&amp;*first))
78581     typename iterator_traits&lt;ForwardIterator&gt;::value_type(x);
78582 <ins>return first;</ins>
78583 </pre></blockquote>
78584 </blockquote>
78585 </blockquote>
78586
78587
78588
78589
78590
78591
78592 <hr>
78593 <h3><a name="1340"></a>1340. Why does <tt>forward_list::resize</tt> take the object to be copied by value?</h3>
78594 <p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78595  <b>Submitter:</b>              
78596 James McNellis <b>Opened:</b> 2010-07-16 <b>Last modified:</b> 2010-11-24</p>
78597 <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>
78598 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78599 <p><b>Discussion:</b></p>
78600 <p>
78601 In
78602 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>
78603 23.3.3.4 [forwardlist.modifiers], the <tt>resize()</tt> member function is 
78604 declared as:
78605 </p>
78606
78607 <blockquote><pre>void resize(size_type sz, value_type c); 
78608 </pre></blockquote>
78609
78610 <p>
78611 The other sequence containers (<tt>list</tt>, <tt>deque</tt>, and
78612 <tt>vector</tt>) take <tt>'c'</tt> by const reference.
78613 </p>
78614
78615 <p>
78616 Is there a reason for this difference?  If not, then <tt>resize()</tt> should 
78617 be declared as: 
78618 </p>
78619
78620 <blockquote><pre>void resize(size_type sz, const value_type&amp; c); 
78621 </pre></blockquote>
78622
78623 <p>
78624 The declaration would need to be changed both at its declaration in the class
78625 definition at 23.3.3 [forwardlist]/3 and where its behavior is specified
78626 at 23.3.3.4 [forwardlist.modifiers]/22.
78627 </p>
78628
78629 <p>
78630 This would make <tt>forward_list</tt> consistent with the CD1 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>.
78631 </p>
78632
78633 <p><i>[
78634 Post-Rapperswil
78635 ]</i></p>
78636
78637
78638 <p>
78639 Daniel changed the P/R slightly, because one paragraph number has been changed since the issue
78640 had been submitted. He also added a similar Requires element that exists in all other containers with
78641 a <tt>resize</tt> member function. He deliberately did not touch the wrong usage of "default-constructed" because that
78642 will be taken care of by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>.
78643 </p>
78644
78645 <blockquote>
78646 Moved to Tentatively Ready with revised wording after 5 positive votes on c++std-lib.
78647 </blockquote>
78648
78649 <p><i>[
78650 Adopted at 2010-11 Batavia
78651 ]</i></p>
78652
78653
78654
78655
78656 <p><b>Proposed resolution:</b></p>
78657
78658
78659 <ol>
78660 <li>Change [forwardlist]/3, class template <tt>forward_list</tt> synopsis, as indicated:
78661 <blockquote><pre>...
78662 void resize(size_type sz);
78663 void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
78664 void clear();
78665 ...
78666 </pre></blockquote>
78667 </li>
78668 <li>Change [forwardlist.modifiers]/27 as indicated: 
78669 <blockquote><pre>       
78670 void resize(size_type sz);
78671 void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
78672 </pre>
78673 <blockquote>
78674 27 <em>Effects</em>: If <tt>sz &lt; distance(begin(), end())</tt>, erases the last <tt>distance(begin(), end()) - sz</tt> elements
78675 from the list. Otherwise, inserts <tt>sz - distance(begin(), end())</tt> elements at the end of the list. For the first 
78676 signature the inserted elements are default constructed, and for the second signature they are copies of <tt>c</tt>.
78677 <p>
78678 <ins>28 - <em>Requires</em>: <tt>T</tt> shall be <tt>DefaultConstructible</tt> for the first form and   it shall be <tt>CopyConstructible</tt> 
78679         for the second form.</ins></p>
78680 </blockquote></blockquote>
78681 </li>
78682 </ol>
78683
78684
78685
78686
78687
78688
78689 <hr>
78690 <h3><a name="1344"></a>1344. [FCD] Replace <tt>throw()</tt> with <tt>noexcept</tt></h3>
78691 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
78692  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
78693 <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>
78694 <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>
78695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
78696 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a></p>
78697 <p><b>Discussion:</b></p>
78698 <p><b>Addresses GB-60, CH-16</b></p>
78699 <p>
78700 Dynamic exception specifications are deprecated; the
78701 library should recognise this by replacing all non-throwing
78702 exception specifications of the form <tt>throw()</tt> with the
78703 <tt>noexcept</tt> form.
78704 </p>
78705
78706 <p><i>[
78707 Resolution proposed by ballot comment:
78708 ]</i></p>
78709
78710 <p>
78711 Replace all non-throwing exception specifications
78712 of the form 'throw()' with the 'noexcept' form.
78713 </p>
78714
78715 <p><i>[
78716 2010-10-31 Daniel comments:
78717 ]</i></p>
78718
78719
78720 <blockquote>
78721 The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>
78722 would satisfy this request.
78723 </blockquote>
78724
78725 <p><i>[
78726 2010-Batavia:
78727 ]</i></p>
78728
78729 <blockquote>
78730 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>.
78731 </blockquote>
78732
78733
78734
78735 <p><b>Proposed resolution:</b></p>
78736 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>
78737 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a>
78738 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">n3195</a>
78739 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>
78740 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>
78741
78742
78743
78744
78745
78746 <hr>
78747 <h3><a name="1346"></a>1346. [FCD] Apply <tt>noexcept</tt> where library specification does not permit exceptions</h3>
78748 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
78749  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
78750 <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>
78751 <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>
78752 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
78753 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a></p>
78754 <p><b>Discussion:</b></p>
78755 <p><b>Addresses GB-62, CH-17</b></p>
78756 <p>
78757 Issues with efficiency and unsatisfactory semantics mean
78758 many library functions document they do not throw
78759 exceptions with a Throws: Nothing clause, but do not
78760 advertise it with an exception specification. The semantic
78761 issues are largely resolved with the new 'noexcept'
78762 specifications, and the noexcept operator means we will
78763 want to detect these guarantees programatically in order
78764 to construct programs taking advantage of the guarantee.
78765 </p>
78766
78767 <p><i>[
78768 Resolution proposed by ballot comment:
78769 ]</i></p>
78770
78771 <p>
78772 Add a <tt>noexcept</tt> exception specification on each
78773 libary API that offers an unconditional <i>Throws</i>:
78774 Nothing guarantee. Where the guarantee is
78775 conditional, add the appropriate
78776 <tt>noexcept(<i>constant-expression</i>)</tt> if an appropriate
78777 constant expression exists.
78778 </p>
78779
78780 <p><i>[
78781 2010-10-31 Daniel comments:
78782 ]</i></p>
78783
78784
78785 <blockquote>
78786 The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html">n3149</a>
78787 would satisfy this request.
78788 </blockquote>
78789
78790 <p><i>[
78791 2010-Batavia:
78792 ]</i></p>
78793
78794 <blockquote>
78795 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html">n3149</a>.
78796 </blockquote>
78797
78798
78799
78800 <p><b>Proposed resolution:</b></p>
78801 This issue is resolved by the adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">n3195</a>
78802
78803
78804
78805
78806
78807 <hr>
78808 <h3><a name="1347"></a>1347. [FCD] Apply <tt>noexcept</tt> judiciously throughout the library</h3>
78809 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
78810  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
78811 <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>
78812 <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>
78813 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
78814 <p><b>Discussion:</b></p>
78815 <p><b>Addresses GB-63, US-80</b></p>
78816 <p>
78817 Since the newly introduced operator <tt>noexcept</tt> makes it
78818 easy (easier than previously) to detect whether or not a
78819 function has been declared with the empty exception
78820 specification (including <tt>noexcept</tt>) library functions that
78821 cannot throw should be decorated with the empty
78822 exception specification. Failing to do so and leaving it as a
78823 matter of QoI would be detrimental to portability and
78824 efficiency.
78825 </p>
78826
78827 <p><i>[
78828 Resolution proposed by ballot comment
78829 ]</i></p>
78830
78831 <p>
78832 Review the whole library, and apply the <tt>noexcept</tt>
78833 specification where it is appropriate.
78834 </p>
78835
78836 <p><i>[
78837 2010-10-31 Daniel comments:
78838 ]</i></p>
78839
78840
78841 <blockquote>
78842 The proposed resolution of the combination of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>,
78843 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>,
78844 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3157.html">n3157</a>,
78845 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3167.html">n3167</a>
78846 would satisfy this request. The paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a> is related
78847 to this as well.
78848 </blockquote>
78849
78850 <p><i>[
78851 2010 Batavia:
78852 ]</i></p>
78853
78854 <p>
78855 While the LWG expects to see further papers in this area, sufficient action was taken in Batavia to close the issue as Resolved by the listed papers.
78856 </p>
78857
78858
78859
78860 <p><b>Proposed resolution:</b></p>
78861 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>,
78862 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>,
78863 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3157.html">n3157</a>,
78864 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3167.html">n3167</a> and remotely
78865 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a>
78866
78867
78868
78869
78870
78871 <hr>
78872 <h3><a name="1354"></a>1354. [FCD] The definition of deadlock excludes cases involving a single thread</h3>
78873 <p><b>Section:</b> 17.3.8 [defns.deadlock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
78874  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
78875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
78876 <p><b>Discussion:</b></p>
78877 <p><b>Addresses GB-52</b></p>
78878 <p>
78879 The definition of deadlock in 17.3.7 excludes cases
78880 involving a single thread making it incorrect.
78881 </p>
78882
78883 <p><i>[
78884 Resolution proposed by ballot comment
78885 ]</i></p>
78886
78887 <p>
78888 The definition should be corrected.
78889 </p>
78890
78891 <p><i>[
78892 2010 Batavia Concurrency group provides a Proposed Resolution
78893 ]</i></p>
78894
78895
78896 <p><i>[
78897 Adopted at 2010-11 Batavia
78898 ]</i></p>
78899
78900
78901
78902
78903 <p><b>Proposed resolution:</b></p>
78904 Change 17.3.8 [defns.deadlock] as indicated:
78905 <blockquote>
78906 <b>deadlock</b>
78907 <p>
78908 <del>two</del><ins>one</ins> or more threads are unable to continue execution because each is blocked waiting for one or more of the
78909 others to satisfy some condition.
78910 </p></blockquote>
78911
78912
78913
78914
78915
78916 <hr>
78917 <h3><a name="1355"></a>1355. [FCD] The definition of move-assignment operator is redundant</h3>
78918 <p><b>Section:</b> 17.3.16 [defns.move.assign.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
78919  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
78920 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
78921 <p><b>Discussion:</b></p>
78922 <p><b>Addresses GB-50</b></p>
78923 <p>
78924 This definition of move-assignment operator is redundant
78925 and confusing now that the term move-assignment
78926 operator is defined by the core language in subclause
78927 12.8p21.
78928 </p>
78929
78930 <p><i>[
78931 2010-10-24 Daniel adds:
78932 ]</i></p>
78933
78934
78935 <blockquote>
78936 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> provides a superior resolution.
78937 </blockquote>
78938
78939 <p><i>[
78940 Resolution proposed by ballot comment
78941 ]</i></p>
78942
78943 <p>
78944 Strike subclause 17.3.16 [defns.move.assign.op].
78945 Add a cross-reference to (12.8) to 17.3.12.
78946 </p>
78947
78948
78949
78950 <p><b>Proposed resolution:</b></p>
78951 Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
78952
78953
78954
78955
78956
78957 <hr>
78958 <h3><a name="1356"></a>1356. [FCD] The definition of move-constructor is redundant</h3>
78959 <p><b>Section:</b> 17.3.17 [defns.move.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
78960  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
78961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
78962 <p><b>Discussion:</b></p>
78963 <p><b>Addresses GB-51</b></p>
78964 <p>
78965 This definition of move-constructor is redundant and
78966 confusing now that the term constructor is defined by the
78967 core language in subclause 12.8p3.
78968 </p>
78969
78970 <p><i>[
78971 2010-10-24 Daniel adds:
78972 ]</i></p>
78973
78974
78975 <blockquote>
78976 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> provides a superior resolution.
78977 </blockquote>
78978
78979 <p><i>[
78980 2010 Batavia: resolved as NAD Editorial by adopting paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
78981 ]</i></p>
78982
78983 <p>
78984 Original proposed resolution preserved for reference:
78985 </p>
78986 <blockquote>
78987 <p>
78988 Strike subclause 17.3.14, [defns.move.ctor]
78989 </p>
78990
78991 <blockquote><del>
78992 <b>17.3.14      [defns.move.ctor]</b><br>
78993 move constructor a constructor which accepts only an rvalue argument of the type being constructed and might modify the argument as a side effect during construction.
78994 </del></blockquote>
78995 </blockquote>
78996
78997
78998
78999 <p><b>Proposed resolution:</b></p>
79000 Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
79001
79002
79003
79004
79005
79006 <hr>
79007 <h3><a name="1357"></a>1357. [FCD] Library bitmask types to not satisfy the bimask type requirements</h3>
79008 <p><b>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79009  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
79010 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitmask.types">issues</a> in [bitmask.types].</p>
79011 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79012 <p><b>Discussion:</b></p>
79013 <p><b>Addresses GB-53</b></p>
79014 <p>
79015 The bitmask types defined in 27.5.2 and 28.5 contradict
79016 the bitmask type requirements in 17.5.2.1.3, and have
79017 missing or incorrectly defined operators.
79018 </p>
79019
79020 <p><i>[
79021 Resolution proposed by ballot comment
79022 ]</i></p>
79023
79024 <p>
79025 See Appendix 1 - Additional Details
79026 </p>
79027
79028 <p><i>[
79029 2010 - Rapperswil
79030 ]</i></p>
79031
79032 <p>
79033 The paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>
79034 was made available during the meeting to resolve this comment, but withdrawn from formal motions
79035 to give others time to review the document.  There was no technical objection, and it is expected
79036 that this paper will go forward at the next meeting. 
79037 </p>
79038
79039
79040
79041 <p><b>Proposed resolution:</b></p>
79042 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.
79043
79044
79045
79046
79047
79048 <hr>
79049 <h3><a name="1360"></a>1360. [FCD] Add <tt>&lt;atomic&gt;</tt> to free-standing implementations</h3>
79050 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79051  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
79052 <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>
79053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79054 <p><b>Discussion:</b></p>
79055 <p><b>Addresses GB-57</b></p>
79056 <p>
79057 The atomic operations facility is closely tied to clause 1
79058 and the memory model. It is not easily supplied as an
79059 after-market extension, and should be trivial to implement
79060 of a single-threaded serial machine. The consequence of
79061 not having this facility will be poor interoperability with
79062 future C++ libraries that memory model concerns
79063 seriously, and attempt to treat them in a portable way.
79064 </p>
79065
79066 <p><i>[
79067 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79068 ]</i></p>
79069
79070
79071
79072
79073 <p><b>Proposed resolution:</b></p>
79074 Add <tt>&lt;atomic&gt;</tt> to table 15, headers required for a
79075 free-standing implementation.
79076
79077
79078
79079
79080
79081 <hr>
79082 <h3><a name="1362"></a>1362. [FCD] Description of binding to rvalue-references should use the new 'xvalue' vocabulary</h3>
79083 <p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79084  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
79085 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
79086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79087 <p><b>Discussion:</b></p>
79088 <p><b>Addresses US-82</b></p>
79089 <p>
79090 17.6.3.9 [res.on.arguments] p.1. b.3: The second Note can benefit by adopting recent nomenclature.
79091 </p>
79092
79093
79094 <p><i>[
79095 Resolution proposed by the ballot comment:
79096 ]</i></p>
79097
79098 <p>
79099 Rephrase the Note in terms of xvalue.
79100 </p>
79101
79102 <p><i>[
79103 Pre-Batavia:
79104 ]</i></p>
79105
79106 <p>
79107 Walter Brown provides wording.
79108 </p>
79109
79110 <p><i>[Batavia: Immediate]</i></p>
79111
79112
79113 <p><i>[
79114 Adopted at 2010-11 Batavia
79115 ]</i></p>
79116
79117
79118 <p><b>Proposed resolution:</b></p>
79119
79120 <p>
79121 Amend the note in 17.6.3.9 [res.on.arguments] p1 bullet 3.
79122 </p>
79123 <blockquote>
79124 [ <i>Note</i>: If a program casts an lvalue to an <del>rvalue</del><ins>xvalue</ins> while passing that lvalue to a library function (e.g. by calling the function with the argument <tt>move(x)</tt>), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was anlvalue. <i>—endnote</i>]
79125 </blockquote>
79126
79127
79128
79129
79130
79131
79132 <hr>
79133 <h3><a name="1363"></a>1363. [FCD] <tt>offsetof</tt> should be marked <tt>noexcept</tt></h3>
79134 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79135  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
79136 <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>
79137 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79138 <p><b>Discussion:</b></p>
79139 <p><b>Addresses GB-68</b></p>
79140 <p>
79141 There is no reason for the offsetof macro to invoke
79142 potentially throwing operations, so the result of
79143 noexcept(offsetof(type,member-designator)) should be
79144 true.
79145 </p>
79146
79147 <p><i>[
79148 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79149 ]</i></p>
79150
79151
79152
79153
79154 <p><b>Proposed resolution:</b></p>
79155 <p>Add to the end of 18.2p4:</p>
79156 <blockquote><ins>
79157 No operation invoked by the offsetof macro shall
79158 throw an exception, and
79159 <tt>noexcept(offsetof(type,member-designator))</tt> shall
79160 be true.</ins>
79161 </blockquote>
79162
79163
79164
79165
79166
79167 <hr>
79168 <h3><a name="1365"></a>1365. [FCD] Thread-safety of handler functions</h3>
79169 <p><b>Section:</b> 18.6.2 [alloc.errors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79170  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
79171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79172 <p><b>Discussion:</b></p>
79173 <p><b>Addresses GB-71</b></p>
79174 <p>
79175 The thread safety of <tt>std::set_new_handler()</tt>,
79176 <tt>std::set_unexpected()</tt>, <tt>std::set_terminate()</tt>, is
79177 unspecified making the the functions impossible to use in a thread
79178 safe manner.
79179 </p>
79180
79181 <p><i>[
79182 Resolution proposed by ballot comment:
79183 ]</i></p>
79184
79185 <blockquote>
79186 The thread safety guarantees for the functions
79187 must be specified and new interfaces should be
79188 provided to make it possible to query and install
79189 handlers in a thread safe way.
79190 </blockquote>
79191
79192 <p><i>[
79193 2010-10-31 Daniel comments:
79194 ]</i></p>
79195
79196
79197 <blockquote>
79198 The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3122.html">n3122</a>
79199 partially addresses this request. This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>.
79200 </blockquote>
79201
79202
79203 <p><i>[
79204 2010-Batavia:
79205 ]</i></p>
79206
79207 <blockquote>
79208 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
79209 </blockquote>
79210
79211
79212
79213 <p><b>Proposed resolution:</b></p>
79214 Resolved in Batavia by accepting  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
79215
79216
79217
79218
79219
79220 <hr>
79221 <h3><a name="1366"></a>1366. [FCD] New-handler and data races</h3>
79222 <p><b>Section:</b> 18.6.1.4 [new.delete.dataraces] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79223  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
79224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79225 <p><b>Discussion:</b></p>
79226 <p><b>Addresses DE-14</b></p>
79227 <p>
79228 It is unclear how a user replacement function can
79229 simultaneously satisfy the race-free conditions imposed in
79230 this clause and query the new-handler in case of a failed
79231 allocation with the only available, mutating interface
79232 <tt>std::set_new_handler</tt>.
79233 </p>
79234
79235 <p><i>[
79236 Resolution proposed by ballot comment:
79237 ]</i></p>
79238
79239 <p>
79240 Offer a non-mutating interface to query the current new-handler.
79241 </p>
79242
79243 <p><i>[
79244 2010-10-24 Daniel adds:
79245 ]</i></p>
79246
79247
79248 <blockquote>
79249 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3122.html">n3122</a> would solve this issue.
79250 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>.
79251 </blockquote>
79252
79253 <p><i>[
79254 2010-Batavia:
79255 ]</i></p>
79256
79257 <blockquote>
79258 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
79259 </blockquote>
79260
79261
79262
79263 <p><b>Proposed resolution:</b></p>
79264 Resolved in Batavia by accepting  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
79265
79266
79267
79268
79269
79270 <hr>
79271 <h3><a name="1367"></a>1367. [FCD] Deprecate library support for checking dynamic exception specifications</h3>
79272 <p><b>Section:</b> D.13 [exception.unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79273  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
79274 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79275 <p><b>Discussion:</b></p>
79276 <p><b>Addresses GB-72</b></p>
79277 <p>
79278 Dynamic exception specifications are deprecated, so
79279 clause 18.8.2 that describes library support for this facility
79280 should move to Annex D, with the exception of the
79281 <tt>bad_exception</tt> class which is retained to indicate other
79282 failures in the exception dispatch mechanism (e.g. calling
79283 <tt>current_exception()</tt>).
79284 </p>
79285
79286 <p><i>[
79287 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79288 ]</i></p>
79289
79290
79291
79292
79293 <p><b>Proposed resolution:</b></p>
79294 With the exception of 18.8.2.1 [bad.exception],
79295 move clause 18.8.2 diectly to Annex D.
79296 [bad.exception] should simply become the new
79297 18.8.2.
79298
79299
79300
79301
79302
79303 <hr>
79304 <h3><a name="1368"></a>1368. [FCD] Thread safety of <tt>std::uncaught_exception()</tt></h3>
79305 <p><b>Section:</b> 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79306  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
79307 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79308 <p><b>Discussion:</b></p>
79309 <p><b>Addresses GB-73</b></p>
79310 <p>
79311 The thread safety <tt>std::uncaught_exception()</tt> and the
79312 result of the function when multiple threads throw
79313 exceptions at the same time are unspecified. To make the
79314 function safe to use in the presence of exceptions in
79315 multiple threads the specification needs to be updated.
79316 </p>
79317
79318 <p><i>[
79319 Resolution proposed by ballot comment
79320 ]</i></p>
79321
79322 <p>
79323 Update this clause to support safe calls from
79324 multiple threads without placing synchronization
79325 requirements on the user.
79326 </p>
79327
79328 <p><i>[
79329 2010 Batavia Concurrency group provides a Proposed Resolution
79330 ]</i></p>
79331
79332
79333 <p><i>[
79334 Adopted at 2010-11 Batavia
79335 ]</i></p>
79336
79337
79338
79339
79340 <p><b>Proposed resolution:</b></p>
79341 <p>Change 18.8.4 [uncaught] p. 1 as follows:</p>
79342 <p>
79343 <i>Returns</i>: <tt>true</tt> after <ins> the current thread has initialized </ins><del>initializing</del>
79344  an exception object (15.1) until a handler for the exception (including <tt>unexpected()</tt> or <tt>terminate()</tt>) 
79345  is activated (15.3). [ <i>Note</i>: This includes stack unwinding (15.2). \97 <i>end note</i> ]
79346 </p>
79347
79348
79349
79350
79351
79352
79353 <hr>
79354 <h3><a name="1370"></a>1370. [FCD] <tt>throw_with_nested</tt> should not use perfect forwarding</h3>
79355 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79356  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
79357 <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>
79358 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79359 <p><b>Discussion:</b></p>
79360 <p><b>Addresses US-84</b></p>
79361 <p>
79362 The <tt>throw_with_nested</tt> specification passes in its argument as
79363 <tt>T&amp;&amp;</tt> (perfect forwarding pattern), but then discusses
79364 requirements on <tt>T</tt> without taking into account that <tt>T</tt>
79365 may be an lvalue-reference type. It is also not clear in the spec that
79366 <tt>t</tt> is intended to be perfectly forwarded.
79367 </p>
79368
79369 <p><i>[
79370 Resolution proposed by ballot comment
79371 ]</i></p>
79372
79373 <p>
79374 Patch [except.nested] p6-7 to match the intent with regards to
79375 requirements on <tt>T</tt> and the use of
79376 <tt>std::forward&lt;T&gt;(t)</tt>.
79377 </p>
79378
79379 <p><i>[
79380 2010-10-24 Daniel adds:
79381 ]</i></p>
79382
79383
79384 <blockquote>
79385 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3144.html">n3144</a> would solve this issue.
79386 </blockquote>
79387
79388 <p><i>[2010-11-10 Batavia: LWG accepts Howard's updated wording with
79389 corrected boo boos reported by Sebastian Gesemann and Pete Becker,
79390 which is approved for Immediate adoption this meeting.]</i></p>
79391
79392
79393 <p><i>[
79394 Adopted at 2010-11 Batavia
79395 ]</i></p>
79396
79397
79398
79399
79400 <p><b>Proposed resolution:</b></p> 
79401 <p><i>Change 18.8.7 nested_exception [except.nested] as indicated:</i></p>
79402 <blockquote>
79403   <pre>[[noreturn]] template &lt;class T&gt; void throw_with_nested(T&amp;&amp; t);
79404 </pre>
79405   <blockquote>
79406     <p><ins>Let <tt>U</tt> be <tt>remove_reference&lt;T&gt;::type</tt> </ins></p>
79407     <p>6 <i>Requires:</i> <tt><del>T</del> <ins>U</ins></tt> shall be <tt>
79408     CopyConstructible</tt>. </p>
79409     <p>7 <i>Throws:</i> If <tt><del>T</del> <ins>U</ins></tt> is a non-union 
79410     class type not derived from <tt>nested_exception</tt>, an exception of 
79411     unspecified type that is publicly derived from both <tt><del>T</del> <ins>U</ins></tt> 
79412     and <tt>nested_exception</tt> <ins>and constructed from <tt>std::forward&lt;T&gt;(t)</tt></ins>, 
79413     otherwise <ins>throws</ins> <tt><ins>std::forward&lt;T&gt;(</ins>t<ins>)</ins></tt>.
79414     </p>
79415   </blockquote>
79416 </blockquote>
79417
79418
79419
79420
79421
79422 <hr>
79423 <h3><a name="1372"></a>1372. [FCD] Adopt recommended practice for standard error categories</h3>
79424 <p><b>Section:</b> 19.5.1.5 [syserr.errcat.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79425  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
79426 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79427 <p><b>Discussion:</b></p>
79428 <p><b>Addresses GB-76</b></p>
79429 <p>
79430 The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users
79431 create a single <tt>error_category</tt> object for each user defined error
79432 category and specifies <tt>error_category</tt> equality comparsions based on
79433 equality of addresses (19.5.1.3). The Draft apparently ignores this
79434 when specifying standard error category objects in section 19.5.1.5,
79435 by allowing the <tt>generic_category()</tt> and <tt>system_category()</tt>
79436 functions to return distinct objects for each invocation.
79437 </p>
79438 <p><i>[
79439 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79440 ]</i></p>
79441
79442
79443
79444
79445 <p><b>Proposed resolution:</b></p>
79446 <p>
79447 Append a new sentence to 19.5.1.5 [syserr.errcat.objects]/1, and append
79448 the same sentence to 19.5.1.5/3.
79449 </p>
79450 <blockquote><ins>
79451 All calls of this function return references to the same object.
79452 </ins></blockquote>
79453
79454
79455
79456
79457
79458 <hr>
79459 <h3><a name="1377"></a>1377. [FCD] The revised <tt>forward</tt> is not compatible with access-control</h3>
79460 <p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79461  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
79462 <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>
79463 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79464 <p><b>Discussion:</b></p>
79465 <p><b>Addresses US-90</b></p>
79466 <p>
79467 In n3090, at variance with previous iterations of the idea
79468 discussed in papers and incorporated in WDs,
79469 <tt>std::forward</tt> is constrained via <tt>std::is_convertible</tt>,
79470 thus is not robust wrt access control. This causes problems in
79471 normal uses as implementation detail of member
79472 functions. For example, the following snippet leads to a
79473 compile time failure, whereas that was not the case for an
79474 implementation along the lines of n2835 (using <tt>enable_if</tt>s
79475 instead of concepts for the constraining, of course)
79476 </p>
79477 <pre>#include &lt;utility&gt;
79478 struct Base { Base(Base&amp;&amp;); };
79479
79480 struct Derived
79481   : private Base
79482 {
79483   Derived(Derived&amp;&amp; d)
79484     : Base(std::forward&lt;Base&gt;(d)) { }
79485 };
79486 </pre>
79487 <p>
79488 In other terms, LWG 1054 can be resolved in a better
79489 way, the present status is not acceptable.
79490 </p>
79491
79492 <p><i>[
79493 2010-10-24 Daniel adds:
79494 ]</i></p>
79495
79496
79497 <blockquote>
79498 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">n3143</a> would solve this issue.
79499 </blockquote>
79500
79501
79502
79503 <p><b>Proposed resolution:</b></p>
79504 Resolved as NAD Editorial by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">n3143</a>.
79505
79506
79507
79508
79509
79510 <hr>
79511 <h3><a name="1378"></a>1378. [FCD] <tt>pair</tt> and <tt>tuple</tt> have too many conversions</h3>
79512 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79513  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79514 <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>
79515 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79516 <p><b>Discussion:</b></p>
79517 <p><b>Addresses DE-15</b></p>
79518 <p>
79519 Several function templates of <tt>pair</tt> and <tt>tuple</tt> allow for too
79520 many implicit conversions, for example:
79521 </p>
79522 <pre>#include &lt;tuple&gt;
79523 std::tuple&lt;char*&gt; p(0); // Error?
79524
79525 struct A { explicit A(int){} };
79526 A a = 1; // Error
79527 std::tuple&lt;A&gt; ta = std::make_tuple(1); // OK?
79528 </pre>
79529
79530 <p><i>[
79531 Resolution proposed by ballot comment
79532 ]</i></p>
79533
79534 <p>
79535 Consider to add wording to constrain these function templates.
79536 </p>
79537
79538 <p><i>[
79539 2010-10-24 Daniel adds:
79540 ]</i></p>
79541
79542
79543 <blockquote>
79544 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
79545 </blockquote>
79546
79547
79548
79549
79550 <p><b>Proposed resolution:</b></p>
79551 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79552
79553
79554
79555
79556
79557 <hr>
79558 <h3><a name="1379"></a>1379. [FCD] <tt>pair</tt> copy-assignment not consistent for references</h3>
79559 <p><b>Section:</b> 20.3.5.2 [pairs.pair] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79560  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79561 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
79562 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79563 <p><b>Discussion:</b></p>
79564 <p><b>Addresses US-95</b></p>
79565 <p>
79566 Copy-assignment for <tt>pair</tt> is defaulted and does not work
79567 for pairs with reference members. This is inconsistent with
79568 conversion-assignment, which deliberately succeeds even
79569 if one or both elements are reference types, just as for
79570 <tt>tuple</tt>. The copy-assignment operator should be
79571 consistent with the conversion-assignment operator and
79572 with <tt>tuple</tt>'s assignment operators.
79573 </p>
79574
79575 <p><i>[
79576 2010-10-24 Daniel adds:
79577 ]</i></p>
79578
79579
79580 <blockquote>
79581 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would provide a superior resolution,
79582 because <tt>pair</tt> does not depend on the semantic requirements of <tt>CopyAssignable</tt>.
79583 </blockquote>
79584
79585 <p><i>[
79586 2010-11 Batavia
79587 ]</i></p>
79588
79589 <p>
79590 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79591 </p>
79592
79593
79594
79595 <p><b>Proposed resolution:</b></p>
79596 Add to <tt>pair</tt> synopsis:
79597 <blockquote>
79598 <tt>pair&amp; operator=(const pair&amp; p);</tt>
79599 </blockquote>
79600 <p>
79601 Add before paragraph 9:
79602 </p>
79603 <blockquote>
79604 <tt>pair&amp; operator=(const pair&amp; p);</tt>
79605 <blockquote>
79606 <p>
79607 <i>Requires</i>: <tt>T1</tt> and <tt>T2</tt> shall satisfy the
79608 requirements of <tt>CopyAssignable</tt>.
79609 </p>
79610 <p>
79611 <i>Effects</i>: Assigns <tt>p.first</tt> to <tt>first</tt> and <tt>p.second</tt> to
79612 <tt>second</tt>.
79613 <i>Returns</i>: <tt>*this</tt>.
79614 </p>
79615 </blockquote>
79616 </blockquote>
79617
79618
79619
79620
79621
79622 <hr>
79623 <h3><a name="1380"></a>1380. [FCD] <tt>pair</tt> and <tt>tuple</tt> of references need to better specify move-semantics</h3>
79624 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79625  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79626 <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>
79627 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79628 <p><b>Discussion:</b></p>
79629 <p><b>Addresses DE-16</b></p>
79630 <p>
79631 Several <tt>pair</tt> and <tt>tuple</tt> functions in regard to move
79632 operations are incorrectly specified if the member types
79633 are references, because the result of a <tt>std::move</tt> cannot
79634 be assigned to lvalue-references. In this context the usage
79635 of the requirement sets <tt>MoveConstructible</tt> and
79636 <tt>CopyConstructible</tt> also doesn't make sense, because
79637 non-const lvalue-references cannot satisfy these requirements.
79638 </p>
79639
79640 <p><i>[
79641 Resolution proposed by ballot comment
79642 ]</i></p>
79643
79644 <p>
79645 Replace the usage of <tt>std::move</tt> by that of
79646 <tt>std::forward</tt> and replace <tt>MoveConstructible</tt> and
79647 <tt>CopyConstructible</tt> requirements by other requirements.
79648 </p>
79649
79650 <p><i>[
79651 2010-10-24 Daniel adds:
79652 ]</i></p>
79653
79654
79655 <blockquote>
79656 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
79657 </blockquote>
79658
79659 <p><i>[
79660 2010-11 Batavia:
79661 ]</i></p>
79662
79663
79664 <blockquote>
79665 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79666 </blockquote>
79667
79668
79669
79670 <p><b>Proposed resolution:</b></p>
79671 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79672
79673
79674
79675
79676
79677 <hr>
79678 <h3><a name="1381"></a>1381. [FCD] Ballot Comment GB-85</h3>
79679 <p><b>Section:</b> X [pair.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79680  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
79681 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79682 <p><b>Discussion:</b></p>
79683 <p><b>Addresses GB-85</b></p>
79684 <p>
79685 While <tt>std::pair</tt> may happen to hold a pair of iterators
79686 forming a valid range, this is more likely a coincidence
79687 than a feature guaranteed by the semantics of the <tt>pair</tt>
79688 template. A distinct range-type should be supplied to
79689 enable the new for-loop syntax rather than overloading an
79690 existing type with a different semantic.
79691 </p>
79692
79693 <p>
79694 If a replacement facility is required for C++0x,
79695 consider n2995.
79696 </p>
79697
79698 <p><i>[
79699 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79700 ]</i></p>
79701
79702
79703
79704
79705 <p><b>Proposed resolution:</b></p>
79706 Strike 20.3.5.4 and the matching declarations in
79707 20.3 header synopsis.
79708
79709
79710
79711
79712
79713 <hr>
79714 <h3><a name="1382"></a>1382. [FCD] <tt>pair</tt> and <tt>tuple</tt> constructors should <tt>forward</tt> arguments</h3>
79715 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79716  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79717 <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>
79718 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79719 <p><b>Discussion:</b></p>
79720 <p><b>Addresses US-96</b></p>
79721 <p>
79722 <tt>pair</tt> and <tt>tuple</tt> constructors and assignment operators use
79723 <tt>std::move</tt> when they should use <tt>std::forward</tt>. This
79724 causes lvalue references to be erroneously converted to
79725 rvalue references. Related requirements clauses are also
79726 wrong.
79727 </p>
79728
79729 <p><i>[
79730 Resolution proposed by ballot comment
79731 ]</i></p>
79732
79733 <blockquote>
79734 See Appendix 1 - Additional Details
79735 </blockquote>
79736
79737 <p><i>[
79738 2010-10-24 Daniel adds:
79739 ]</i></p>
79740
79741
79742 <blockquote>
79743 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
79744 </blockquote>
79745
79746 <p><i>[
79747 2010-11 Batavia
79748 ]</i></p>
79749
79750 <p>
79751 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79752 </p>
79753
79754
79755
79756 <p><b>Proposed resolution:</b></p>
79757 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79758
79759
79760
79761
79762
79763 <hr>
79764 <h3><a name="1383"></a>1383. [FCD] Inconsistent defaulted move/copy members in <tt>pair</tt> and <tt>tuple</tt></h3>
79765 <p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79766  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79767 <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>
79768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79769 <p><b>Discussion:</b></p>
79770 <p><b>Addresses US-97</b></p>
79771 <p>
79772 <tt>pair</tt>'s class definition in N3092 20.3.5.2 [pairs.pair]
79773 contains "<tt>pair(const pair&amp;) = default;</tt>" and 
79774 "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>". The latter is described by
79775 20.3.5.2 [pairs.pair] p.12-13.
79776 </p>
79777 "<tt>pair(const pair&amp;) = default;</tt>" is a user-declared explicitly defaulted
79778 copy constructor. According to 12.8 [class.copy]/10, this inhibits 
79779 the implicitly-declared move constructor. <tt>pair</tt> should be move constructible. 
79780 (12.8 [class.copy]/7 explains that "<tt>pair(pair&lt;U, V&gt;&amp;&amp; p)</tt>" 
79781 will never be instantiated to move <tt>pair&lt;T1, T2&gt;</tt> to <tt>pair&lt;T1, T2&gt;</tt>.)<br>
79782 "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" is a user-provided move
79783 assignment operator (according to 8.4.2 [dcl.fct.def.default]/4: "A 
79784 special member function is user-provided if it is user-declared and not explicitly defaulted
79785 on its first declaration."). According to 12.8 [class.copy]/20, this inhibits
79786 the implicitly-declared copy assignment operator. <tt>pair</tt>
79787 should be copy assignable, and was in C++98/03. (Again,
79788 12.8 [class.copy]/7 explains that "<tt>operator=(const pair&lt;U, V&gt;&amp; p)</tt>" 
79789 will never be instantiated to copy <tt>pair&lt;T1, T2&gt;</tt> to <tt>pair&lt;T1, T2&gt;</tt>.)<br>
79790 Additionally, "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" is
79791 unconditionally defined, whereas according to 12.8 [class.copy]/25,
79792 defaulted copy/move assignment operators are defined as
79793 deleted in several situations, such as when non-static data
79794 members of reference type are present.
79795 <p>
79796 If "<tt>pair(const pair&amp;) = default;</tt>" and "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" 
79797 were removed from <tt>pair</tt>'s class definition in 20.3.5.2 [pairs.pair] and from 
79798 20.3.5.2 [pairs.pair]/12-13, <tt>pair</tt> would
79799 receive implicitly-declared copy/move constructors and
79800 copy/move assignment operators, and 12.8 [class.copy]/25 would
79801 apply. The implicitly-declared copy/move constructors
79802 would be trivial when <tt>T1</tt> and <tt>T2</tt> have trivial copy/move
79803 constructors, according to 12.8 [class.copy]/13, and similarly for the
79804 assignment operators, according to12.8 [class.copy]/27. Notes could
79805 be added as a reminder that these functions would be
79806 implicitly-declared, but such notes would not be necessary
79807 (the Standard Library specification already assumes a
79808 high level of familiarity with the Core Language, and
79809 casual readers will simply assume that <tt>pair</tt> is copyable
79810 and movable).
79811 </p><p>
79812 Alternatively, <tt>pair</tt> could be given explicitly-defaulted
79813 copy/move constructors and copy/move assignment
79814 operators. This is a matter of style.
79815 </p><p>
79816 <tt>tuple</tt> is also affected. <tt>tuple</tt>'s class definition in 20.4 [tuple] contains:
79817 </p><pre>tuple(const tuple&amp;) = default;
79818 tuple(tuple&amp;&amp;);
79819 tuple&amp; operator=(const tuple&amp;);
79820 tuple&amp; operator=(tuple&amp;&amp;);
79821 </pre>
79822 They should all be removed or all be explicitly-defaulted,
79823 to be consistent with <tt>pair</tt>. Additionally, 20.4.2.1 [tuple.cnstr]/8-9 specifies the 
79824 behavior of an explicitly defaulted function, which is currently inconsistent with
79825 <tt>pair</tt>.
79826
79827 <p><i>[
79828 Resolution proposed by ballot comment:
79829 ]</i></p>
79830
79831 <blockquote>
79832 Either remove "<tt>pair(const pair&amp;) = default;</tt>" and
79833 "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" from <tt>pair</tt>'s class
79834 definition in  20.3.5.2 [pairs.pair] and from  20.3.5.2 [pairs.pair] p.12-13, or
79835 give pair explicitly-defaulted copy/move constructors and copy/move assignment operators.<br>
79836 Change <tt>tuple</tt> to match.
79837 </blockquote>
79838
79839 <p><i>[
79840 2010-10-24 Daniel adds:
79841 ]</i></p>
79842
79843
79844 <blockquote>
79845 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue:
79846 The move/copy constructor will be defaulted, but the corresponding assignment operators need a non-default implementation
79847 because they are supposed to work for references as well.
79848 </blockquote>
79849
79850
79851
79852 <p><b>Proposed resolution:</b></p>
79853 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
79854
79855
79856
79857
79858
79859 <hr>
79860 <h3><a name="1384"></a>1384. [FCD] Ballot Comment US-98</h3>
79861 <p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79862  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
79863 <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>
79864 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79865 <p><b>Discussion:</b></p>
79866 <p><b>Addresses US-98</b></p>
79867 <p>
79868 pack_arguments is poorly named. It does not reflect the
79869 fact that it is a tuple creation function and that it forwards
79870 arguments.
79871 </p>
79872
79873 <p><i>[
79874 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79875 ]</i></p>
79876
79877
79878
79879
79880 <p><b>Proposed resolution:</b></p>
79881 Rename pack_arguments to forward_as_tuple
79882 throughout the standard.
79883
79884
79885
79886
79887
79888 <hr>
79889 <h3><a name="1386"></a>1386. FCD Ballot Comment US-99</h3>
79890 <p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79891  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
79892 <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>
79893 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79894 <p><b>Discussion:</b></p>
79895 <p><b>Addresses US-99</b></p>
79896 <p>
79897 pack_arguments is overly complex.
79898 </p>
79899
79900 <p><i>[
79901 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79902 ]</i></p>
79903
79904
79905
79906
79907 <p><b>Proposed resolution:</b></p>
79908 This issue resulted from a lack of understanding of
79909 how references are forwarded. The definition of
79910 pack_arguments should be simply:<br>
79911 template &lt;class... Types&gt;
79912 tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>&gt;
79913 pack_arguments(Types&amp;&amp;...t);<br>
79914 <del>Types:Let Ti be each type in Types....</del><br>
79915 Effects: ...<br>
79916 Returns:<br>
79917 tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>...&gt;(std::forward&lt;Types&gt;(t)...)<br>
79918 The synopsis should also change to reflect this
79919 simpler signature.
79920
79921
79922
79923
79924
79925 <hr>
79926 <h3><a name="1387"></a>1387. [FCD] Ballot Comment GB-87</h3>
79927 <p><b>Section:</b> X [tuple.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79928  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
79929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79930 <p><b>Discussion:</b></p>
79931 <p><b>Addresses GB-87</b></p>
79932 <p>
79933 There is no compelling reason to assume a
79934 heterogeneous tuple of two elements holds a pair of
79935 iterators forming a valid range. Unlike std::pair, there are
79936 no functions in the standard library using this as a return
79937 type with a valid range, so there is even less reason to try
79938 to adapt this type for the new for-loop syntax.
79939 </p>
79940
79941 <p><i>[
79942 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79943 ]</i></p>
79944
79945
79946
79947
79948 <p><b>Proposed resolution:</b></p>
79949 Strike 20.4.2.10 and the matching declarations in
79950 the header synopsis in 20.4.
79951
79952
79953
79954
79955
79956 <hr>
79957 <h3><a name="1388"></a>1388. FCD Ballot Comment US-100</h3>
79958 <p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
79959  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
79960 <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>
79961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
79962 <p><b>Discussion:</b></p>
79963 <p><b>Addresses US-100</b></p>
79964 <p>
79965 LWG 1281 was discussed in Pittsburgh, and the decision
79966 there was to accept the typedef as proposed and move to
79967 Review. Unfortunately the issue was accidentally applied
79968 to the FCD, and incorrectly. The FCD version of the
79969 typedef refers to ratio&lt;N, D&gt;, but the typedef is intended
79970 to refer to ratio&lt;num, den&gt; which in general is not the
79971 same type.
79972 </p>
79973
79974 <p><i>[
79975 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
79976 ]</i></p>
79977
79978
79979
79980
79981 <p><b>Proposed resolution:</b></p>
79982 Accept the current proposed wording of LWG
79983 1281 which adds:<br>
79984 typedef ratio&lt;num, den&gt; type;
79985
79986
79987
79988
79989
79990 <hr>
79991 <h3><a name="1389"></a>1389. [FCD] Compile-time rational arithmetic and overflow</h3>
79992 <p><b>Section:</b> 20.6.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
79993  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
79994 <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>
79995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
79996 <p><b>Discussion:</b></p>
79997 <p><b>Addresses GB-89</b></p>
79998 <p>
79999 The alias representations of the <tt>ratio</tt> arithmetic templates
80000 do not allow implementations to avoid overflow, since they
80001 explicitly specify the form of the aliased template
80002 instantiation. For example
80003 <tt>ratio_multiply</tt>, <tt>ratio&lt;2, LLONG_MAX&gt;</tt> is <em>required</em> to
80004 alias <tt>ratio&lt;2*LLONG_MAX, LLONG_MAX*2&gt;</tt>, which
80005 overflows, so is ill-formed. However, this is trivially equal
80006 to <tt>ratio&lt;1, 1&gt;</tt>. It also contradicts the opening statement of
80007 20.6.2 [ratio.arithmetic] p. 1 "implementations may use other algorithms to
80008 compute these values".
80009 </p>
80010
80011 <p><i>[
80012 2010-10-25 Daniel adds:
80013 ]</i></p>
80014
80015
80016 <blockquote>
80017 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3131.html">n3131</a> would solve this issue.
80018 </blockquote>
80019
80020 <p><i>[Batavia: Resoved by accepting
80021 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3210.html">n3210</a>.]</i></p>
80022
80023
80024
80025
80026 <p><b>Proposed resolution:</b></p>
80027 Change the wording in 20.6.2 [ratio.arithmetic] p. 2-5 as follows:
80028 <p>
80029 </p><blockquote><pre>template &lt;class R1, class R2&gt; using ratio_add = <em>see below</em>;
80030 </pre><blockquote>
80031 2 The type <tt>ratio_add&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
80032 <ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
80033 are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
80034 arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> 
80035 and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
80036 and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
80037 </blockquote></blockquote>
80038 <blockquote><pre>template &lt;class R1, class R2&gt; using ratio_subtract = <em>see below</em>;
80039 </pre><blockquote>
80040 3 The type <tt>ratio_subtract&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
80041 <ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
80042 are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
80043 arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> 
80044 and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
80045 and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
80046 </blockquote></blockquote>
80047 <blockquote><pre>template &lt;class R1, class R2&gt; using ratio_multiply = <em>see below</em>;
80048 </pre><blockquote>
80049 4 The type <tt>ratio_multiply&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
80050 <ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
80051 are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
80052 arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> 
80053 has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
80054 and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
80055 </blockquote></blockquote>
80056 <blockquote><pre>template &lt;class R1, class R2&gt; using ratio_divide = <em>see below</em>;
80057 </pre><blockquote>
80058 5 The type <tt>ratio_divide&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
80059 <ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
80060 are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
80061 arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> 
80062 has the value <tt>R1::den * R2::num</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
80063 and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
80064 </blockquote></blockquote>
80065
80066
80067
80068
80069
80070 <hr>
80071 <h3><a name="1390"></a>1390. [FCD] Limit speculative compilation for constructible/convertible traits</h3>
80072 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80073  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
80074 <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>
80075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80076 <p><b>Discussion:</b></p>
80077 <p><b>Addresses DE-17</b></p>
80078 <p>
80079 Speculative compilation for <tt>std::is_constructible</tt> and
80080 <tt>std::is_convertible</tt> should be limited, similar to the core
80081 language (see 14.8.2 paragraph 8).
80082 </p>
80083
80084 <p><i>[
80085 2010-10-24 Daniel adds:
80086 ]</i></p>
80087
80088
80089 <blockquote>
80090 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
80091 </blockquote>
80092
80093
80094
80095 <p><b>Proposed resolution:</b></p>
80096 Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
80097
80098
80099
80100
80101
80102 <hr>
80103 <h3><a name="1391"></a>1391. [FCD] constructible/convertible traits and access control</h3>
80104 <p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80105  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
80106 <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>
80107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80108 <p><b>Discussion:</b></p>
80109 <p><b>Addresses DE-18</b></p>
80110 <p>
80111 Several type traits require compiler support, e.g.
80112 <tt>std::is_constructible</tt> or <tt>std::is_convertible</tt>.
80113 Their current specification seems to imply, that the corresponding
80114 test expressions should be well-formed, even in absense of access:
80115 </p>
80116 <pre>class X { X(int){} };
80117 constexpr bool test = std::is_constructible&lt;X, int&gt;::value;
80118 </pre>
80119 <p>
80120 The specification does not clarify the context of this test
80121 and because it already goes beyond normal language
80122 rules, it's hard to argue by means of normal language
80123 rules what the context and outcome of the test should be.
80124 </p>
80125
80126 <p><i>[
80127 Resolution proposed by ballot comment
80128 ]</i></p>
80129
80130 <p>
80131 Specify that <tt>std::is_constructible</tt> and
80132 <tt>std::is_convertible</tt> will return <tt>true</tt> only for
80133 public constructors/conversion functions.
80134 </p>
80135
80136 <p><i>[
80137 2010-10-24 Daniel adds:
80138 ]</i></p>
80139
80140
80141 <blockquote>
80142 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
80143 </blockquote>
80144
80145
80146
80147 <p><b>Proposed resolution:</b></p>
80148 Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
80149
80150
80151
80152
80153
80154 <hr>
80155 <h3><a name="1392"></a>1392. [FCD] <tt>result_of</tt> should support pointer-to-data-member</h3>
80156 <p><b>Section:</b> 20.7.4 [meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80157  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
80158 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary">issues</a> in [meta.unary].</p>
80159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80160 <p><b>Discussion:</b></p>
80161 <p><b>Addresses US-102</b></p>
80162 <p>
80163 Despite Library Issue 520's ("<tt>result_of</tt> and pointers to
80164 data members") resolution of CD1, the FCD's <tt>result_of</tt>
80165 supports neither pointers to member functions nor
80166 pointers to data members. It should.
80167 </p>
80168
80169 <p><i>[
80170 Resolution proposed by ballot comment
80171 ]</i></p>
80172
80173 <p>
80174 Ensure <tt>result_of</tt> supports pointers to member
80175 functions and pointers to data members.
80176 </p>
80177
80178 <p><i>[
80179 2010-10-24 Daniel adds:
80180 ]</i></p>
80181
80182
80183 <blockquote>
80184 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">n3123</a> would solve this issue.
80185 </blockquote>
80186
80187
80188
80189 <p><b>Proposed resolution:</b></p>
80190 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">n3123</a>.
80191
80192
80193
80194
80195
80196 <hr>
80197 <h3><a name="1393"></a>1393. [FCD] Trivial traits imply noexcept</h3>
80198 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80199  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
80200 <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>
80201 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80202 <p><b>Discussion:</b></p>
80203 <p><b>Addresses GB-92</b></p>
80204 <p>
80205 Trivial functions implicitly declare a <tt>noexcept</tt> exception
80206 specification, so the references to <tt>has_trivial_*</tt> traits in the
80207 <tt>has_nothrow_*</tt> traits are redundant, and should be struck for clarity.
80208 </p>
80209
80210 <p><i>[
80211 Resolution proposed by ballot comment
80212 ]</i></p>
80213
80214 <p>
80215 For each of the <tt>has_nothrow_<i>something</i></tt> traits,
80216 remove all references to the matching
80217 <tt>has_trivial_<i>something</i></tt> traits.
80218 </p>
80219
80220 <p><i>[
80221 2010-10-24 Daniel adds:
80222 ]</i></p>
80223
80224
80225 <blockquote>
80226 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
80227 </blockquote>
80228
80229
80230
80231 <p><b>Proposed resolution:</b></p>
80232 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
80233
80234
80235
80236
80237
80238 <hr>
80239 <h3><a name="1394"></a>1394. [FCD] Ballot Comment DE-19</h3>
80240 <p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80241  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
80242 <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>
80243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80244 <p><b>Discussion:</b></p>
80245 <p><b>Addresses DE-19</b></p>
80246 <p>
80247 The fundamental trait is_constructible reports false
80248 positives, e.g.
80249 </p>
80250 <pre>is_constructible&lt;char*, void*&gt;::value
80251 </pre>
80252 evaluates to true, even though a corresponding variable
80253 initialization would be ill-formed.
80254
80255 <p><i>[
80256 Resolved in Rapperswil by paper N3047.
80257 ]</i></p>
80258
80259
80260
80261
80262 <p><b>Proposed resolution:</b></p>
80263 Remove all false positives from the domain of
80264 is_constructible.
80265
80266
80267
80268
80269
80270 <hr>
80271 <h3><a name="1397"></a>1397. [FCD] Deprecate '98 binders</h3>
80272 <p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80273  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
80274 <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>
80275 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80276 <p><b>Discussion:</b></p>
80277 <p><b>Addresses GB-95</b></p>
80278 <p>
80279 The adaptable function protocol supported by
80280 <tt>unary_function</tt>/<tt>binary_function</tt> has been superceded by
80281 lambda expressions and <tt>std::bind</tt>. Despite the name, the
80282 protocol is not very adaptable as it requires intrusive
80283 support in the adaptable types, rather than offering an
80284 external traits-like adaption mechanism. This protocol and
80285 related support functions should be deprecated, and we
80286 should not make onerous requirements for the
80287 specification to support this protocol for callable types
80288 introduced in this standard revision, including those
80289 adopted from TR1. It is expected that high-quality
80290 implementations will provide such support, but we should
80291 not have to write robust standard specifications mixing this
80292 restricted support with more general components such as
80293 <tt>function</tt>, <tt>bind</tt> and <tt>reference_wrapper</tt>.
80294 </p>
80295
80296 <p><i>[
80297 Resolution proposed by ballot comment
80298 ]</i></p>
80299
80300 <p>
80301 Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12
80302 to Annex D.
80303 </p>
80304 <p>
80305 Remove the requirements to conditionally derive from
80306 <tt>unary</tt>/<tt>binary_function</tt> from <tt>function</tt>,
80307 <tt>reference_wrapper</tt>, and the results of calling <tt>mem_fn</tt>
80308 and <tt>bind</tt>.
80309 </p>
80310
80311 <p><i>[
80312 2010-10-24 Daniel adds:
80313 ]</i></p>
80314
80315
80316 <blockquote>
80317 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3145.html">n3145</a> would solve this issue.
80318 </blockquote>
80319
80320
80321
80322 <p><b>Proposed resolution:</b></p>
80323 Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">N3198</a>.
80324
80325
80326
80327
80328
80329 <hr>
80330 <h3><a name="1399"></a>1399. [FCD] <tt>function</tt> does not need an <tt>explicit</tt> default constructor</h3>
80331 <p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80332  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
80333 <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>
80334 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80335 <p><b>Discussion:</b></p>
80336 <p><b>Addresses JP-3</b></p>
80337 <p>
80338 <tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
80339 Although it is allowed according to 12.3.1, it seems
80340 unnecessary to qualify the constructor as <tt>explicit</tt>.
80341 If it is <tt>explicit</tt>, there will be a limitation in <tt>initializer_list</tt>.
80342 </p>
80343
80344 <p><i>[
80345 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80346 ]</i></p>
80347
80348
80349
80350
80351 <p><b>Proposed resolution:</b></p>
80352 Remove <tt>explicit</tt>.
80353 <pre>namespace std {
80354 template&lt;class&gt; class function;
80355 // undefined
80356 template&lt;class R, class... ArgTypes&gt;
80357 class function&lt;R(ArgTypes...)&gt;
80358 : public unary_function&lt;T1, R&gt;
80359 // iff sizeof...(ArgTypes) == 1 and ArgTypes contains T1
80360 : public binary_function&lt;T1, T2, R&gt;
80361 // iff sizeof...(ArgTypes) == 2 and ArgTypes contains T1 andT2
80362 {
80363 public:typedef R result_type;
80364 // 20.8.14.2.1, construct/copy/destroy:
80365   <del>explicit</del> function();
80366 </pre>
80367
80368
80369
80370
80371
80372 <hr>
80373 <h3><a name="1400"></a>1400. FCD <tt>function</tt> does not need an <tt>explicit</tt> default constructor</h3>
80374 <p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80375  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
80376 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
80377 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80378 <p><b>Discussion:</b></p>
80379 <p><b>Addresses JP-4</b></p>
80380 <p>
80381 Really does the <tt>function</tt> require that default constructor is <tt>explicit</tt>?
80382 </p>
80383
80384 <p><i>[
80385 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80386 ]</i></p>
80387
80388
80389
80390
80391 <p><b>Proposed resolution:</b></p>
80392 Remove explicit.
80393 <pre>function();
80394 template &lt;class A&gt;
80395 function(allocator_arg_t, const A&amp; a);
80396 </pre>
80397
80398
80399
80400
80401
80402 <hr>
80403 <h3><a name="1402"></a>1402. [FCD] <tt>nullptr</tt> constructors for smart pointers should be <tt>constexpr</tt></h3>
80404 <p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80405  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
80406 <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>
80407 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80408 <p><b>Discussion:</b></p>
80409 <p><b>Addresses GB-100</b></p>
80410
80411 The <tt>unique_ptr</tt> and <tt>shared_ptr</tt> constructors taking
80412 <tt>nullptr_t</tt> delegate to a <tt>constexpr</tt> constructor, and could be
80413 <tt>constexpr</tt> themselves.
80414
80415 <p><i>[
80416 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80417 ]</i></p>
80418
80419
80420
80421
80422 <p><b>Proposed resolution:</b></p>
80423 In the 20.9.10.2 [unique.ptr.single] synopsis add
80424 "constexpr" to unique_ptr(nullptr_t).<br>
80425 In the 20.9.10.3 [unique.ptr.runtime] synopsis add
80426 "constexpr" to unique_ptr(nullptr_t).<br>
80427 In the 20.9.11.2 [util.smartptr.shared] synopsis
80428 add "constexpr" to shared_ptr(nullptr_t).
80429
80430
80431
80432
80433
80434 <hr>
80435 <h3><a name="1403"></a>1403. [FCD] Inconsistent definitions for <tt>allocator_arg</tt></h3>
80436 <p><b>Section:</b> 20.9.1 [allocator.tag] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80437  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
80438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80439 <p><b>Discussion:</b></p>
80440 <p><b>Addresses JP-85</b></p>
80441 <p>
80442 There are inconsistent definitions for <tt>allocator_arg</tt>.
80443 In 20.9 [memory] paragraph 1,
80444 </p>
80445 <pre>constexpr allocator_arg_t allocator_arg = allocator_arg_t();
80446 </pre>
80447 and in 20.9.1,
80448 <pre>const allocator_arg_t allocator_arg = allocator_arg_t();
80449 </pre>
80450
80451 <p><i>[
80452 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80453 ]</i></p>
80454
80455
80456
80457
80458 <p><b>Proposed resolution:</b></p>
80459 Change "const" to "constexpr" in 20.9.1 as
80460 follows.
80461 <pre>constexpr allocator_arg_t allocator_arg = allocator_arg_t();
80462 </pre>
80463
80464
80465
80466
80467
80468 <hr>
80469 <h3><a name="1404"></a>1404. [FCD] <tt>pointer_traits</tt> should have a <tt>size_type</tt> member</h3>
80470 <p><b>Section:</b> 20.9.3 [pointer.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80471  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
80472 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80473 <p><b>Discussion:</b></p>
80474 <p><b>Addresses US-106</b></p>
80475 <p>
80476 <tt>pointer_traits</tt> should have a <tt>size_type</tt> member for completeness.
80477 </p>
80478 <p>
80479 Add <tt>typedef <i>see below</i> size_type;</tt> to the generic
80480 <tt>pointer_traits</tt> template and <tt>typedef size_t
80481 size_type;</tt> to <tt>pointer_traits&lt;T*&gt;</tt>. Use
80482 <tt>pointer_traits::size_type</tt> and
80483 <tt>pointer_traits::difference_type</tt> as the defaults for
80484 <tt>allocator_traits::size_type</tt> and
80485 <tt>allocator_traits::difference_type</tt>.
80486 </p>
80487 <p>
80488 See Appendix 1 - Additional Details
80489 </p>
80490
80491 <p><i>[
80492 Post-Rapperswil, Pablo provided wording:
80493 ]</i></p>
80494
80495
80496 <p>
80497 The original ballot comment reads simply: "<tt>pointer_traits</tt> should have a 
80498 <tt>size_type</tt> for completeness."  The additional details reveal, however,
80499 that the desire for a <tt>size_type</tt> is actually driven by the needs
80500 of <tt>allocator_traits</tt>.  The <tt>allocator_traits</tt> template should get its
80501 default <tt>difference_type</tt> from <tt>pointer_traits</tt> but if it did,
80502 it should get its <tt>size_type</tt> from the same source.  Unfortunately,
80503 there is no obvious meaning for <tt>size_type</tt> in <tt>pointer_traits</tt>.
80504 </p>
80505 <p>
80506 Alisdair suggested, however, that the natural relationship between
80507 <tt>difference_type</tt> and <tt>size_type</tt> can be expressed simply by the
80508 <tt>std::make_unsigned&lt;T&gt;</tt> metafunction.  Using this metafunction,
80509 we can easily define <tt>size_type</tt> for <tt>allocator_traits</tt> without
80510 artificially adding <tt>size_type</tt> to <tt>pointer_traits</tt>.
80511 </p>
80512
80513 <blockquote>
80514 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
80515 </blockquote>
80516
80517 <p><i>[
80518 Adopted at 2010-11 Batavia
80519 ]</i></p>
80520
80521
80522
80523
80524
80525 <p><b>Proposed resolution:</b></p>
80526 <p>
80527 In [allocator.requirements], Table 42, change two rows as follows:
80528 </p>
80529 <blockquote>
80530 <table border="1">
80531   <tbody><tr>
80532     <td><tt>X::size_type</tt></td>
80533     <td>unsigned integral type</td>
80534     <td>a type that can represent the size of the largest object in the
80535     allocation model</td>
80536     <td><tt>
80537       <del>size_t</del>
80538       <ins>make_unsigned&lt;X::difference_type&gt;::type</ins>
80539     </tt></td>
80540   </tr>
80541   <tr>
80542     <td><tt>X::difference_type</tt></td>
80543     <td>signed integral type</td>
80544     <td>a type that can represent the difference between any two pointers in
80545     the allocation model</td>
80546     <td><tt>
80547       <del>ptrdiff_t</del>
80548       <ins>pointer_traits&lt;X::pointer&gt;::difference_type</ins>
80549     </tt></td>
80550   </tr>
80551 </tbody></table>
80552 </blockquote>
80553 <p>
80554 In [allocator.traits.types], Change the definition of difference_type and
80555 size_type as follows:
80556 </p>
80557 <blockquote>
80558   <tt>typedef</tt> <i>see below</i> <tt>difference_type;</tt>
80559   <blockquote>
80560     <i>Type:</i> <tt>Alloc::difference_type</tt> if such a type exists,
80561     else <tt><del>ptrdiff_t</del>
80562     <ins>pointer_traits&lt;pointer&gt;::difference_type</ins></tt>.
80563   </blockquote>
80564
80565   <tt>typedef</tt> <i>see below</i> <tt>size_type;</tt>
80566   <blockquote>
80567     <i>Type:</i> <tt>Alloc::size_type</tt> if such a type exists,
80568     else <tt><del>size_t</del>
80569     <ins>make_unsigned&lt;difference_type&gt;::type</ins></tt>.
80570   </blockquote>
80571 </blockquote>
80572
80573
80574
80575
80576
80577 <hr>
80578 <h3><a name="1405"></a>1405. [FCD] Ballot Comment US-107</h3>
80579 <p><b>Section:</b> 20.10 [allocator.adaptor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80580  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
80581 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.adaptor">issues</a> in [allocator.adaptor].</p>
80582 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80583 <p><b>Discussion:</b></p>
80584 <p><b>Addresses US-107</b></p>
80585
80586 scoped_allocator_adaptor should have its own header.
80587
80588 <p><i>[
80589 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80590 ]</i></p>
80591
80592
80593
80594
80595 <p><b>Proposed resolution:</b></p>
80596 See Appendix 1 - Additional Details
80597
80598
80599
80600
80601
80602 <hr>
80603 <h3><a name="1407"></a>1407. [FCD] Synch <tt>shared_ptr</tt> constructors taking movable types</h3>
80604 <p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80605  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
80606 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
80607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80608 <p><b>Discussion:</b></p>
80609 <p><b>Addresses US-108</b></p>
80610
80611 <tt>shared_ptr</tt> should have the same policy for constructing
80612 from <tt>auto_ptr</tt> as <tt>unique_ptr</tt>. Currently it does not.
80613
80614 <p><i>[
80615 Resolved in Rapperswil by paper N3109.
80616 ]</i></p>
80617
80618
80619
80620
80621 <p><b>Proposed resolution:</b></p>
80622 Add \93template &lt;class Y&gt; explicit
80623 shared_ptr(auto_ptr&lt;Y&gt;&amp;); to
80624 [util.smartptr.shared.const] (and to the synopsis).
80625
80626
80627
80628
80629
80630 <hr>
80631 <h3><a name="1409"></a>1409. [FCD] Specify whether <tt>monotonic_clock</tt> is a distinct type or a typedef</h3>
80632 <p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80633  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
80634 <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>
80635 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80636 <p><b>Discussion:</b></p>
80637 <p><b>Addresses US-111</b></p>
80638 <p>
80639 What it means for <tt>monotonic_clock</tt> to be a synonym is
80640 undefined. If it may or may not be a typedef, then certain
80641 classes of programs become unportable.
80642 </p>
80643
80644 <p><i>[
80645 Resolution proposed in ballot comment:
80646 ]</i></p>
80647
80648 <p>
80649 Require that it be a distinct class type.
80650 </p>
80651
80652 <p><i>[
80653 2010-11-01 Daniel comments:
80654 ]</i></p>
80655
80656 <blockquote>
80657 Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
80658 this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is not a typedef.
80659 </blockquote>
80660
80661
80662
80663 <p><b>Proposed resolution:</b></p>
80664 This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
80665
80666
80667
80668
80669
80670 <hr>
80671 <h3><a name="1410"></a>1410. [FCD] Add a feature-detect macro for <tt>monotonic_clock</tt></h3>
80672 <p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80673  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
80674 <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>
80675 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80676 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a></p>
80677 <p><b>Discussion:</b></p>
80678 <p><b>Addresses GB-107, DE-20</b></p>
80679 <p>
80680 1.4 [intro.compliance] p.9 states that which conditionally
80681 supported constructs are available should be provided in the 
80682 documentation for the implementation. This doesn't help programmers trying
80683 to write portable code, as they must then rely on
80684 implementation-specific means to determine the
80685 availability of such constructs. In particular, the presence
80686 or absence of <tt>std::chrono::monotonic_clock</tt> may require
80687 different code paths to be selected. This is the only
80688 conditionally-supported library facility, and differs from the
80689 conditionally-supported language facilities in that it has
80690 standard-defined semantics rather than implementation-defined
80691 semantics.
80692 </p>
80693
80694 <p><i>[
80695 Resolution proposed in ballot comment:
80696 ]</i></p>
80697
80698 <p>
80699 Provide feature test macro for determining the
80700 presence of <tt>std::chrono::monotonic_clock</tt>. Add
80701 <tt>_STDCPP_HAS_MONOTONIC_CLOCK</tt> to the
80702 <tt>&lt;chrono&gt;</tt> header, which is defined if
80703 <tt>monotonic_clock</tt> is present, and not defined if it is
80704 not present.
80705 </p>
80706
80707 <p><i>[
80708 2010-11-01 Daniel comments:
80709 ]</i></p>
80710
80711 <blockquote>
80712 Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
80713 this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is not conditionally supported,
80714 so there is no need to detect it.
80715 </blockquote>
80716
80717
80718
80719 <p><b>Proposed resolution:</b></p>
80720 This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
80721
80722
80723
80724
80725
80726 <hr>
80727 <h3><a name="1412"></a>1412. [FCD] Make monotonic clocks mandatory</h3>
80728 <p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
80729  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
80730 <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>
80731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
80732 <p><b>Discussion:</b></p>
80733 <p><b>Addresses CH-21</b></p>
80734 <p>
80735 Monotonic clocks are generally easy to provide on all
80736 systems and are implicitely required by some of the library
80737 facilities anyway.
80738 </p>
80739
80740 <p><i>[
80741 2010-11-01 Daniel comments:
80742 ]</i></p>
80743
80744 <blockquote>
80745 Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
80746 this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is mandatory.
80747 </blockquote>
80748
80749 <p><i>[
80750 2010-11-13 Batavia meeting:
80751 ]</i></p>
80752
80753 <p>
80754 This is resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
80755 The original resolution is preserved for reference:
80756 </p>
80757 <blockquote>
80758 <p>Make monotonic clocks mandatory.</p>
80759 <p>Strike X [time.clock.monotonic] p.2</p>
80760 <blockquote>
80761 <tt>2</tt> <del>The class <tt>monotonic_clock</tt> is conditionally supported.</del>
80762 </blockquote>
80763
80764 <p>Change 30.2.4 [thread.req.timing] p.2 accordingly</p>
80765 <blockquote>
80766 The member functions whose names end in <tt>_for</tt> take an argument that
80767 specifies a relative time. Implementations should use a monotonic clock to
80768 measure time for these functions. <del>[ <em>Note</em>: Implementations are not
80769 required to use a monotonic clock because such a clock may not be available.
80770 \97 <em>end note</em> ]</del>
80771 </blockquote>
80772 </blockquote>
80773
80774
80775
80776 <p><b>Proposed resolution:</b></p>
80777 This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
80778
80779
80780
80781
80782
80783 <hr>
80784 <h3><a name="1414"></a>1414. [FCD] Fixing remaining dead links to <tt>POS_T</tt> and <tt>OFF_T</tt></h3>
80785 <p><b>Section:</b> 21.2.3.2 [char.traits.specializations.char16_t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80786  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
80787 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80788 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1444">1444</a></p>
80789 <p><b>Discussion:</b></p>
80790 <p><b>Addresses GB-109, GB-123</b></p>
80791
80792 <p>
80793 It is not clear what the specification means for
80794 u16streampos, u32streampos or wstreampos when they
80795 refer to the requirements for POS_T in 21.2.2, as there
80796 are no longer any such requirements. Similarly the annex
80797 D.7 refers to the requirements of type POS_T in 27.3 that
80798 no longer exist either.
80799 </p>
80800 <p>
80801 Clarify the meaning of all cross-reference to the
80802 removed type POS_T.
80803 </p>
80804
80805
80806 <p><i>[
80807 Post-Rapperswil, Daniel provides the wording.
80808 ]</i></p>
80809
80810
80811 <p>
80812 When preparing the wording for this issue I first thought about adding both <tt>u16streampos</tt> and <tt>u32streampos</tt>
80813 to the [iostream.forward] header <tt>&lt;iosfwd&gt;</tt> synopsis similar to <tt>streampos</tt> and <tt>wstreampos</tt>,
80814 but decided not to do so, because the IO library does not yet actively support the <tt>char16_t</tt> and <tt>char32_t</tt> 
80815 character types. Adding those would misleadingly imply that they would be part of the iostreams. Also, the addition
80816 would make them also similarly equal to a typedef to <tt>fpos&lt;mbstate_t&gt;</tt>, as for <tt>streampos</tt> and 
80817 <tt>wstreampos</tt>, so there is no loss for users that would like to use the proper <tt>fpos</tt> instantiation for
80818 these character types.
80819 </p>
80820 <p>
80821 Additionally the way of referencing was chosen to follow the style suggested by NB comment 
80822 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB108">GB 108</a>.
80823 </p>
80824
80825 <blockquote>
80826 Moved to Tentatively Ready with proposed wording after 5 positive votes on c++std-lib.
80827 </blockquote>
80828
80829 <p><i>[
80830 Adopted at 2010-11 Batavia
80831 ]</i></p>
80832
80833
80834
80835
80836 <p><b>Proposed resolution:</b></p>
80837 <p>
80838 <i>The following wording changes are against N3126.</i>
80839 </p>
80840
80841 <ol>
80842 <li>Change [char.traits.specializations.char16_t]/1 as indicated:
80843 <blockquote><p>
80844 1 - The type <tt>u16streampos</tt> shall be an implementation-defined type that satisfies the requirements 
80845 for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
80846 </p></blockquote>
80847 </li>
80848 <li>Change [char.traits.specializations.char32_t]/1 as indicated:
80849 <blockquote><p>
80850 1 - The type <tt>u32streampos</tt> shall be an implementation-defined type that satisfies the requirements 
80851 for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
80852 </p></blockquote>
80853 </li>
80854 <li>Change [char.traits.specializations.wchar.t]/2 as indicated:
80855 <blockquote><p>
80856 2 - The type <tt>wstreampos</tt> shall be an implementation-defined type that satisfies the requirements 
80857 for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
80858 </p></blockquote>
80859 </li>
80860 <li>Change [fpos.operations], Table 124 \97 Position type requirements as indicated:
80861 <blockquote><p>
80862 </p><table border="1">
80863 <caption>Table 124 \97 Position type requirements</caption>
80864
80865 <tbody>
80866 <tr>
80867 <th>Expression</th>
80868 <th>Return type</th>
80869 <th><tt>...</tt></th>
80870 </tr>
80871
80872 <tr>
80873 <td><tt>...</tt></td>
80874 <td><tt>...</tt></td>
80875 <td><tt>...</tt></td>
80876 </tr>
80877 <tr>
80878 <td><tt>O(p)</tt></td>
80879 <td><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
80880 <td>...</td>
80881 </tr>
80882 <tr>
80883 <td><tt>...</tt></td>
80884 <td><tt>...</tt></td>
80885 <td><tt>...</tt></td>
80886 </tr>
80887 <tr>
80888 <td><tt>o = p - q</tt></td>
80889 <td><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
80890 <td><tt>...</tt></td>
80891 </tr>
80892 <tr>
80893 <td><tt>streamsize(o)</tt><br><tt>O(sz)</tt></td>
80894 <td><tt>streamsize</tt><br><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
80895 <td><tt>...</tt></td>
80896 </tr>
80897
80898 </tbody></table>
80899 <p></p></blockquote>
80900 </li>
80901 <li>Change [depr.ios.members]/1 as indicated:
80902 <p>
80903 </p><blockquote><pre>namespace std {
80904  class ios_base {
80905  public:
80906    typedef T1 io_state;
80907    typedef T2 open_mode;
80908    typedef T3 seek_dir;
80909    typedef <del>OFF_T</del><ins><em>implementation-defined</em></ins> streamoff;
80910    typedef <del>POS_T</del><ins><em>implementation-defined</em></ins> streampos;
80911    // remainder unchanged
80912  };
80913 }
80914 </pre></blockquote>
80915 <p></p>
80916 </li>
80917 <li>Change [depr.ios.members]/5+6 as indicated:
80918 <blockquote><p>
80919 5 - The type <tt>streamoff</tt> is an implementation-defined type that satisfies the requirements 
80920 of <del>type <tt>OFF_T</tt> (27.5.1)</del><ins><tt>off_type</tt> in [iostreams.limits.pos]</ins>.
80921 </p>
80922 <p>
80923 6 - The type <tt>streampos</tt> is an implementation-defined type that satisfies the requirements 
80924 of <del>type <tt>POS_T</tt> (27.3)</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
80925 </p></blockquote>
80926 </li>
80927 </ol>
80928
80929
80930
80931
80932
80933
80934 <hr>
80935 <h3><a name="1416"></a>1416. [FCD] <tt>forward_list::erase_after</tt> should not be allowed to throw</h3>
80936 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80937  <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
80938 <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>
80939 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80940 <p><b>Discussion:</b></p>
80941 <p><b>Addresses DE-21</b></p>
80942
80943 23.2.1/11 provides a general no-throw guarantee for
80944 erase() container functions, exceptions from this are
80945 explicitly mentioned for individual containers. Because of
80946 its different name, forward_list's erase_after() function is
80947 not ruled by this but should so.
80948
80949 <p><i>[
80950 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80951 ]</i></p>
80952
80953
80954
80955
80956 <p><b>Proposed resolution:</b></p>
80957 <p>
80958 Add a "<i>Throws</i>: Nothing" clause to both
80959 <tt>erase_after</tt> overloads in 23.3.3.4, [forwardlist.modifiers].
80960 </p>
80961
80962
80963
80964
80965
80966 <hr>
80967 <h3><a name="1417"></a>1417. [FCD] <tt>front</tt>/<tt>back</tt> on a zero-sized
80968 <tt>array</tt> should be undefined</h3>
80969 <p><b>Section:</b> 23.3.1.7 [array.zero] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80970  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-26</p>
80971 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
80972 <p><b>Discussion:</b></p>
80973 <p><b>Addresses GB-112</b></p>
80974 <p>
80975 Should the effect of calling <tt>front</tt>/<tt>back</tt> on a zero-sized
80976 <tt>array</tt> really be implementation defined i.e. require the
80977 implementor to define behaviour?
80978 </p>
80979
80980 <p><i>[
80981 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
80982 ]</i></p>
80983
80984
80985
80986
80987 <p><b>Proposed resolution:</b></p>
80988 Change "implementation defined" to "undefined"
80989
80990
80991
80992
80993
80994 <hr>
80995 <h3><a name="1423"></a>1423. [FCD] Ballot Comment JP-6</h3>
80996 <p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
80997  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
80998 <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>
80999 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81000 <p><b>Discussion:</b></p>
81001 <p><b>Addresses JP-6</b></p>
81002
81003 Constructor accepting an allocator as a single parameter
81004 should be qualified as explicit.
81005 <pre>namespace std {
81006 template &lt;class Key, class T, class Compare =
81007 less&lt;Key&gt;,
81008 class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
81009 class map {
81010 public:
81011 ...
81012 map(const Allocator&amp;);
81013 </pre>
81014
81015 <p><i>[
81016 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81017 ]</i></p>
81018
81019
81020
81021
81022 <p><b>Proposed resolution:</b></p>
81023 Add explicit.
81024 <pre>namespace std {
81025 template &lt;class Key, class T, class Compare =
81026 less&lt;Key&gt;,
81027 class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
81028 class map {
81029 public:
81030 ...
81031 explicit map(const Allocator&amp;);
81032 </pre>
81033
81034
81035
81036
81037
81038 <hr>
81039 <h3><a name="1424"></a>1424. [FCD] Ballot Comment JP-7</h3>
81040 <p><b>Section:</b> 23.6.2 [multimap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81041  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81042 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81043 <p><b>Discussion:</b></p>
81044 Constructor accepting an allocator as a single parameter
81045 should be qualified as explicit.
81046
81047 <p><i>[
81048 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81049 ]</i></p>
81050
81051
81052
81053
81054 <p><b>Proposed resolution:</b></p>
81055 Add explicit.
81056 <pre>namespace std {
81057 template &lt;class Key, class T, class Compare =
81058 less&lt;Key&gt;,
81059 class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
81060 class multimap {
81061 public:
81062 ...
81063 explicit multimap(const Allocator&amp;);
81064 </pre>
81065
81066
81067
81068
81069
81070 <hr>
81071 <h3><a name="1425"></a>1425. [FCD] Ballot Comment JP-8</h3>
81072 <p><b>Section:</b> 23.6.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81073  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81074 <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>
81075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81076 <p><b>Discussion:</b></p>
81077 <p><b>Addresses JP-8</b></p>
81078 Constructor accepting an allocator as a single parameter
81079 should be qualified as explicit.
81080
81081 <p><i>[
81082 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81083 ]</i></p>
81084
81085
81086
81087
81088 <p><b>Proposed resolution:</b></p>
81089 Add explicit.
81090 <pre>namespace std {
81091 template &lt;class Key, class Compare = less&lt;Key&gt;,
81092 class Allocator = allocator&lt;Key&gt; &gt;
81093 class set {
81094 public:
81095 ...
81096 explicit set(const Allocator&amp;);
81097 </pre>
81098
81099
81100
81101
81102
81103 <hr>
81104 <h3><a name="1426"></a>1426. [FCD] Ballot Comment JP-9</h3>
81105 <p><b>Section:</b> 23.6.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81106  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81108 <p><b>Discussion:</b></p>
81109 <p><b>Addresses JP-9</b></p>
81110
81111 Constructor accepting an allocator as a single parameter
81112 should be qualified as explicit.
81113
81114 <p><i>[
81115 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81116 ]</i></p>
81117
81118
81119
81120
81121 <p><b>Proposed resolution:</b></p>
81122 Add explicit.
81123 <pre>namespace std {
81124 template &lt;class Key, class Compare = less&lt;Key&gt;,
81125 class Allocator = allocator&lt;Key&gt; &gt;
81126 class multiset {
81127 public:
81128 ...
81129 explicit multiset(const Allocator&amp;);
81130 </pre>
81131
81132
81133
81134
81135
81136 <hr>
81137 <h3><a name="1427"></a>1427. [FCD] Ballot Comment JP-10</h3>
81138 <p><b>Section:</b> 23.7.1 [unord.map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81139  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81140 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.map">issues</a> in [unord.map].</p>
81141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81142 <p><b>Discussion:</b></p>
81143 <p><b>Addresses JP-10</b></p>
81144
81145 Constructor accepting an allocator as a single parameter
81146 should be qualified as explicit.
81147
81148 <p><i>[
81149 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81150 ]</i></p>
81151
81152
81153
81154
81155 <p><b>Proposed resolution:</b></p>
81156 Add explicit.
81157 <pre>namespace std {
81158 template &lt;class Key,
81159 template &lt;class Key,
81160 class T,
81161 class Hash = hash&lt;Key&gt;,
81162 class Pred = std::equal_to&lt;Key&gt;,
81163 class Alloc = std::allocator&lt;std::pair&lt;const Key,
81164 T&gt; &gt; &gt;
81165 class unordered_map
81166 {
81167 public:
81168 ...
81169 explicit unordered_map(const Allocator&amp;);
81170 </pre>
81171
81172
81173
81174
81175
81176 <hr>
81177 <h3><a name="1428"></a>1428. [FCD] Ballot Comment JP-11</h3>
81178 <p><b>Section:</b> 23.7.2 [unord.multimap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81179  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81180 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81181 <p><b>Discussion:</b></p>
81182 <p><b>Addresses JP-11</b></p>
81183
81184 Constructor accepting an allocator as a single parameter
81185 should be qualified as explicit.
81186
81187 <p><i>[
81188 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81189 ]</i></p>
81190
81191
81192
81193
81194 <p><b>Proposed resolution:</b></p>
81195 Add explicit.
81196 <pre>namespace std {
81197 template &lt;class Key,
81198 class T,
81199 class Hash = hash&lt;Key&gt;,
81200 class Pred = std::equal_to&lt;Key&gt;,
81201 class Alloc = std::allocator&lt;std::pair&lt;const Key,
81202 T&gt; &gt; &gt;
81203 class unordered_multimap
81204 {
81205 public:
81206 ...
81207 explicit unordered_multimap(const Allocator&amp;);
81208 </pre>
81209
81210
81211
81212
81213
81214 <hr>
81215 <h3><a name="1429"></a>1429. [FCD] Ballot Comment JP-12</h3>
81216 <p><b>Section:</b> 23.7.3 [unord.set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81217  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81218 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81219 <p><b>Discussion:</b></p>
81220 <p><b>Addresses JP-12</b></p>
81221
81222 Constructor accepting an allocator as a single parameter
81223 should be qualified as explicit.
81224
81225 <p><i>[
81226 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81227 ]</i></p>
81228
81229
81230
81231
81232 <p><b>Proposed resolution:</b></p>
81233 Add explicit.
81234 <pre>namespace std {
81235 template &lt;class Key,
81236 class Hash = hash&lt;Key&gt;,
81237 class Pred = std::equal_to&lt;Key&gt;,
81238 class Alloc = std::allocator&lt;Key&gt; &gt;
81239 class unordered_set
81240 {
81241 public:
81242 ...
81243 explicit unordered_set(const Allocator&amp;);
81244 </pre>
81245
81246
81247
81248
81249
81250 <hr>
81251 <h3><a name="1430"></a>1430. [FCD] Ballot Comment JP-13</h3>
81252 <p><b>Section:</b> 23.7.4 [unord.multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81253  <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
81254 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81255 <p><b>Discussion:</b></p>
81256 <p><b>Addresses JP-13</b></p>
81257
81258 Constructor accepting an allocator as a single parameter
81259 should be qualified as explicit.
81260
81261 <p><i>[
81262 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81263 ]</i></p>
81264
81265
81266
81267
81268 <p><b>Proposed resolution:</b></p>
81269 Add explicit.
81270 <pre>namespace std {
81271 template &lt;class Key,
81272 class Hash = hash&lt;Key&gt;,
81273 class Pred = std::equal_to&lt;Key&gt;,
81274 class Alloc = std::allocator&lt;Key&gt; &gt;
81275 class unordered_multiset
81276 {
81277 public:
81278 ...
81279 explicit unordered_multiset(const Allocator&amp;);
81280 </pre>
81281
81282
81283
81284
81285
81286 <hr>
81287 <h3><a name="1431"></a>1431. [FCD] Ballot Comment US-120</h3>
81288 <p><b>Section:</b> 25.2.12 [alg.is_permutation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81289  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
81290 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81291 <p><b>Discussion:</b></p>
81292 <p><b>Addresses US-120</b></p>
81293
81294 is_permutation is underspecified for anything but the
81295 simple case where both ranges have the same value type
81296 and the comparison function is an equivalence relation.
81297
81298 <p><i>[
81299 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81300 ]</i></p>
81301
81302
81303
81304
81305 <p><b>Proposed resolution:</b></p>
81306 Restrict is_permutation to the case where it is well
81307 specified. See Appendix 1 - Additional Details
81308
81309
81310
81311
81312
81313 <hr>
81314 <h3><a name="1432"></a>1432. [FCD] random_shuffle signatures</h3>
81315 <p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81316  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81317 <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>
81318 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81319 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1433">1433</a></p>
81320 <p><b>Discussion:</b></p>
81321
81322 <p><b>Addresses US-121, GB-119</b></p>
81323
81324 <p>
81325 <tt>random_shuffle</tt> and <tt>shuffle</tt> should be consistent in how
81326 they accept their source of randomness: either both by
81327 rvalue reference or both by lvalue reference.
81328 </p>
81329
81330 <p><i>[
81331 Post-Rapperswil, Daniel provided wording
81332 ]</i></p>
81333
81334
81335 <p>
81336 The signatures of the <tt>shuffle</tt> and <tt>random_shuffle</tt> algorithms are different
81337 in regard to the support of rvalues and lvalues of the provided generator:
81338 </p>
81339
81340 <p>
81341 </p><blockquote><pre>template&lt;class RandomAccessIterator, class RandomNumberGenerator&gt;
81342 void random_shuffle(RandomAccessIterator first,
81343 RandomAccessIterator last,
81344 RandomNumberGenerator<b>&amp;&amp;</b> rand);
81345 </pre></blockquote>
81346 <p></p>
81347
81348 <p>
81349 </p><blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
81350 void shuffle(RandomAccessIterator first,
81351 RandomAccessIterator last,
81352 UniformRandomNumberGenerator<b>&amp;</b> g);
81353 </pre></blockquote>
81354 <p></p>
81355
81356 <p>
81357 The first form uses the perfect forwarding signature and that change compared to
81358 <tt>C++03</tt> was done intentionally as shown in the first rvalue proposal 
81359 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20random_shuffle">papers</a>.
81360 </p>
81361
81362 <p>
81363 While it is true, that random generators are excellent examples of stateful
81364 functors, there still exist good reasons to support rvalues as arguments:
81365 </p>
81366
81367 <p>
81368 </p><ol>
81369 <li>If one of the shuffle algorithms is called with the intention to shuffle items with a reproducible ordering 
81370         from a given generator class, it makes sense to create a generator exactly at the call point.
81371 </li>
81372 <li>Other algorithms with similar need for stateful functors (like <tt>std::generate</tt> and <tt>std::generate_n</tt>) 
81373         accept both rvalues and lvalues as well.
81374 </li>
81375 <li>Given the deduction rules for perfect forwarding it is hard for a user to produce code that does the wrong thing 
81376 unintentionally. Any lvalue generator will deduce an lvalue-reference and behave as in <tt>C++03</tt>. In the specific 
81377 cases, where rvalues are provided, the argument will be accepted instead of being rejected.
81378 </li>
81379 </ol>
81380 <p></p>
81381
81382 <p>
81383 Arguments have been raised that accepting rvalues is error-prone or even fundamentally wrong. The author of this 
81384 proposal disagrees with that position for two additional reasons:
81385 </p>
81386
81387 <p>
81388 </p><ol>
81389 <li>Enforcing lvalues as arguments won't prevent user code to enforce what they
81390 want. So given
81391 <blockquote><pre>my_generator get_generator(int size);
81392 </pre></blockquote>
81393 instead of writing
81394 <blockquote><pre>std::vector&lt;int&gt; v = ...;
81395 std::shuffle(v.begin(), v.end(), get_generator(v.size()));
81396 </pre></blockquote>
81397 they will just write
81398 <blockquote><pre>std::vector&lt;int&gt; v = ...;
81399 auto gen = get_generator(v.size());
81400 std::shuffle(v.begin(), v.end(), gen);
81401 </pre></blockquote>
81402 and feel annoyed about the need for it.
81403 </li>
81404 <li>Generators may be copyable and movable, and random number engines are <em>required</em> to be <tt>CopyConstructible</tt> 
81405 and this is obviously a generally useful property for such objects. It is also useful and sometimes necessary to start a 
81406 generator with exactly a specific seed again and again and thus to provide a new generator (or a copy) for each call. The 
81407 <tt>CopyConstructible</tt> requirements allow providing rvalues of generators and thus this idiom must be useful as well. 
81408 Therefore preventing <tt>[random_]shuffle</tt> to accept rvalues is an unnecessary restriction which doesn't prevent any 
81409 user-error, if there would exist one.
81410 </li>
81411 </ol>
81412 <p></p>
81413
81414 <p>
81415 Thus this proposal recommends to make both <tt>shuffle</tt> functions consistent and perfectly forward-able.
81416 </p>
81417
81418 <blockquote>
81419 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
81420 </blockquote>
81421
81422 <p><i>[
81423 Adopted at 2010-11 Batavia
81424 ]</i></p>
81425
81426
81427
81428
81429 <p><b>Proposed resolution:</b></p>
81430
81431 <ol>
81432 <li>Change [algorithms.general], header <tt>&lt;algorithm&gt;</tt> synopsis as indicated:
81433 <blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
81434 void shuffle(RandomAccessIterator first, RandomAccessIterator last,
81435 UniformRandomNumberGenerator&amp;<ins>&amp;</ins> rand);
81436 </pre></blockquote>
81437 </li>
81438 <li>Change the prototype description of [alg.random.shuffle] as indicated:
81439 <blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
81440 void shuffle(RandomAccessIterator first, RandomAccessIterator last,
81441 UniformRandomNumberGenerator&amp;<ins>&amp;</ins> rand);
81442 </pre></blockquote>
81443 </li>
81444 </ol>
81445
81446
81447
81448
81449
81450
81451 <hr>
81452 <h3><a name="1435"></a>1435. [FCD] Unclear returns specifications for C99 complex number functions</h3>
81453 <p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81454  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81455 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
81456 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81457 <p><b>Discussion:</b></p>
81458 <p><b>Addresses GB-120</b></p>
81459
81460 The complex number functions added for compatibility
81461 with the C99 standard library are defined purely as a
81462 cross-reference, with no hint of what they should return.
81463 This is distinct from the style of documentation for the
81464 functions in the earlier standard. In the case of the
81465 inverse-trigonometric and hyperbolic functions, a
81466 reasonable guess of the functionality may be made from
81467 the name, this is not true of the cproj function, which
81468 apparently returns the projection on the Reimann Sphere.
81469 A single line description of each function, associated with
81470 the cross-reference, will greatly improve clarity.
81471
81472 <p><i>[2010-11-06 Beman provides proposed resolution wording.]</i></p>
81473
81474
81475 <p><i>[
81476 2010 Batavia: The working group concurred with the issue's Proposed Resolution
81477 ]</i></p>
81478
81479
81480 <p><i>[
81481 Adopted at 2010-11 Batavia
81482 ]</i></p>
81483
81484
81485
81486
81487 <p><b>Proposed resolution:</b></p>
81488
81489 <p><i>Change 26.4.7 complex value operations [complex.value.ops] as indicated:</i></p>
81490 <blockquote>
81491   <p><tt>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);</tt></p>
81492   <blockquote>
81493     <p><ins><i>Returns:</i> the projection of <tt>x</tt> onto the Riemann 
81494     sphere.</ins></p>
81495     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cproj</tt>, 
81496     defined in 7.3.9.4.</p>
81497   </blockquote>
81498 </blockquote>
81499
81500 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81501 <blockquote>
81502   <p><tt>template&lt;class T&gt; complex&lt;T&gt; acos(const complex&lt;T&gt;&amp; x);</tt></p>
81503   <blockquote>
81504     <p><ins><i>Returns:</i>&nbsp; the complex arc cosine  of <tt>x</tt>.</ins></p>
81505     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacos</tt>, 
81506     defined in 7.3.5.1.</p>
81507   </blockquote>
81508 </blockquote>
81509
81510 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81511 <blockquote>
81512   <p><tt>template&lt;class T&gt; complex&lt;T&gt; asin(const complex&lt;T&gt;&amp; x);</tt></p>
81513   <blockquote>
81514     <p><ins><i>Returns:</i>&nbsp; the complex arc sine  of <tt>x</tt>.</ins></p>
81515     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casin</tt>, 
81516     defined in 7.3.5.2.</p>
81517   </blockquote>
81518 </blockquote>
81519
81520 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81521 <blockquote>
81522   <p><tt>template&lt;class T&gt; complex&lt;T&gt; atan(const complex&lt;T&gt;&amp; x);</tt></p>
81523   <blockquote>
81524     <p><ins><i>Returns:</i>&nbsp; the complex arc tangent  of <tt>x</tt>.</ins></p>
81525     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catan</tt>, 
81526     defined in 7.3.5.3.</p>
81527   </blockquote>
81528 </blockquote>
81529
81530 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81531 <blockquote>
81532   <p><tt>template&lt;class T&gt; complex&lt;T&gt; acosh(const complex&lt;T&gt;&amp; x);</tt></p>
81533   <blockquote>
81534     <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic cosine of
81535     <tt>x</tt>.</ins></p>
81536     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacosh</tt>, 
81537     defined in 7.3.6.1.</p>
81538   </blockquote>
81539 </blockquote>
81540
81541 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81542 <blockquote>
81543   <p><tt>template&lt;class T&gt; complex&lt;T&gt; asinh(const complex&lt;T&gt;&amp; x);</tt></p>
81544   <blockquote>
81545     <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic sine  of <tt>
81546     x</tt>.</ins></p>
81547     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casinh</tt>, 
81548     defined in 7.3.6.2.</p>
81549   </blockquote>
81550 </blockquote>
81551
81552 <p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
81553 <blockquote>
81554   <p><tt>template&lt;class T&gt; complex&lt;T&gt; atanh(const complex&lt;T&gt;&amp; x);</tt></p>
81555   <blockquote>
81556     <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic tangent  of
81557     <tt>x</tt>.</ins></p>
81558     <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catanh</tt>, 
81559     defined in 7.3.6.2.</p>
81560   </blockquote>
81561 </blockquote>
81562
81563
81564
81565
81566
81567
81568
81569 <hr>
81570 <h3><a name="1436"></a>1436. [FCD] Random number engine constructor concerns</h3>
81571 <p><b>Section:</b> 26.5.3 [rand.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81572  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81573 <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>
81574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81575 <p><b>Discussion:</b></p>
81576 <p><b>Addresses GB-121</b></p>
81577
81578 All the random number engine types in this clause have a
81579 constructor taking an unsigned integer type, and a
81580 constructor template for seed sequences. This means that
81581 an attempt to create a random number engine seeded by
81582 an integer literal must remember to add the appropriate
81583 unsigned suffix to the literal, as a signed integer will
81584 attempt to use the seed sequence template, yielding
81585 undefined behaviour, as per 26.5.1.1p1a. It would be
81586 helpful if at least these anticipated cases produced a
81587 defined behaviour, either an erroneous program with
81588 diagnostic, or a conversion to unsigned int forwarding to
81589 the appropriate constructor.
81590
81591 <p><i>[
81592 2010-11-03 Daniel comments and provides a proposed resolution:
81593 ]</i></p>
81594
81595
81596 <p>
81597 I suggest to apply a similar solution as recently suggested for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>.
81598 It is basically a requirement for an implementation to constrain the template.
81599 </p>
81600
81601 <p><i>[
81602 2010-11-04 Howard suggests to use <tt>!is_convertible&lt;Sseq, result_type&gt;::value</tt>
81603 as minimum requirement instead of the originally proposed <tt>!is_scalar&lt;Sseq&gt;::value</tt>.
81604 This would allow for a user-defined type <tt>BigNum</tt>, that is convertible to <tt>result_type</tt>,
81605 to be used as argument for a seed instead of a seed sequence. The wording has been updated to 
81606 reflect this suggestion.
81607 ]</i></p>
81608
81609
81610 <p><i>[
81611 2010 Batavia: There were some initial concerns regarding the portability and reproducibility of results 
81612 when seeded with a negative signed value, but these concerns were allayed after discussion. Thus, after
81613 reviewing the issue, the working group concurred with the issue's Proposed Resolution. 
81614 ]</i></p>
81615
81616
81617 <p><i>[
81618 Adopted at 2010-11 Batavia
81619 ]</i></p>
81620
81621
81622
81623
81624 <p><b>Proposed resolution:</b></p>
81625 Add the following paragraph at the end of 26.5.3 [rand.eng]:
81626 <blockquote>
81627 <blockquote>
81628 5 Each template specified in this section [rand.eng] requires one or more relationships, involving the value(s) of
81629 its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
81630 any such required relationship fails to hold.
81631 </blockquote>
81632
81633 <blockquote>
81634 <ins>? For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this sub-clause 
81635 [rand.eng] and in sub-clause [rand.adapt]:</ins>
81636 <ul>
81637 <li><ins>If the constructor</ins>
81638 <blockquote><pre><ins>template&lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
81639 </pre></blockquote>
81640 <ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor 
81641 shall not participate in overload resolution.
81642 </ins>
81643 </li>
81644 <li><ins>If the member function</ins>
81645 <blockquote><pre><ins>template&lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
81646 </pre></blockquote>
81647 <ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function 
81648 shall not participate in overload resolution.
81649 </ins>
81650 </li>
81651 </ul>
81652 <ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
81653 except that as a minimum a type shall not qualify as seed sequence, if it is implicitly convertible
81654 to <tt>X::result_type</tt>.</ins>
81655 </blockquote>
81656
81657 </blockquote>
81658
81659
81660
81661
81662
81663 <hr>
81664 <h3><a name="1437"></a>1437. [FCD] Mersenne twister meaningless for word sizes less than two</h3>
81665 <p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81666  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81667 <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>
81668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81669 <p><b>Discussion:</b></p>
81670 <p><b>Addresses US-124</b></p>
81671
81672 The Mersenne twister algorithm is meaningless for word
81673 sizes less than two, as there are then insufficient bits
81674 available to be \93twisted\94.
81675
81676 <p><i>[
81677 Resolution proposed by ballot comment:
81678 ]</i></p>
81679
81680 <blockquote>
81681 Insert the following among the relations that are required to hold: <tt>2u &lt; w</tt>.
81682 </blockquote>
81683
81684 <p><i>[
81685 2010 Batavia: The working group concurred with the issue's Proposed Resolution
81686 ]</i></p>
81687
81688
81689 <p><i>[
81690 Adopted at 2010-11 Batavia
81691 ]</i></p>
81692
81693
81694
81695
81696 <p><b>Proposed resolution:</b></p>
81697 Change 26.5.3.2 [rand.eng.mers] p. 4 as indicated:
81698 <p>
81699 </p><blockquote>
81700 4 The following relations shall hold: <tt>0 &lt; m</tt>, <tt>m &lt;= n</tt>, <ins><tt>2u &lt; w</tt>,</ins>
81701 <tt>r &lt;= w</tt>, <tt>u &lt;= w</tt>, <tt>s &lt;= w</tt>, <tt>t &lt;= w</tt>, 
81702 <tt>l &lt;= w</tt>, <tt>w &lt;= numeric_limits&lt;UIntType&gt;::digits</tt>, 
81703 <tt>a &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>b &lt;= (1u&lt;&lt;w) - 1u</tt>, 
81704 <tt>c &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>d &lt;= (1u&lt;&lt;w) - 1u</tt>, 
81705 and <tt>f &lt;= (1u&lt;&lt;w) - 1u</tt>.
81706 </blockquote>
81707
81708
81709
81710
81711
81712 <hr>
81713 <h3><a name="1439"></a>1439. [FCD] Return from <tt>densities()</tt> functions?</h3>
81714 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81715  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81716 <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>
81717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81718 <p><b>Discussion:</b></p>
81719 <p><b>Addresses US-134</b></p>
81720
81721 These two distributions have a member function called
81722 <tt>densities()</tt> which returns a <tt>vector&lt;double&gt;</tt>. The
81723 distribution is templated on <tt>RealType</tt>. The distribution
81724 also has another member called <tt>intervals()</tt> which returns
81725 a <tt>vector&lt;RealType&gt;</tt>. Why doesn't densities return
81726 <tt>vector&lt;RealType&gt;</tt> as well? If <tt>RealType</tt> is <tt>long double</tt>,
81727 the computed densities property isn't being computed to
81728 the precision the client desires. If <tt>RealType</tt> is <tt>float</tt>, the
81729 densities vector is taking up twice as much space as the client desires.
81730
81731 <p><i>[
81732 Resolution proposed by ballot comment:
81733 ]</i></p>
81734
81735 <blockquote>
81736 Change the piecewise constant and linear
81737 distributions to hold / return the densities in a
81738 <tt>vector&lt;result_type&gt;</tt>.
81739 <p>
81740 If this is not done, at least correct 26.5.8.5.2 [rand.dist.samp.pconst] p. 13 which describes
81741 the return of densities as a <tt>vector&lt;result_type&gt;</tt>.
81742 </p></blockquote>
81743
81744 <p><i>[
81745 Batavia 2010: After reviewing this issue, the working group concurred with the first of the 
81746 suggestions proposed by the NB comment: "Change the piecewise constant and linear distributions 
81747 to hold / return the densities in a vector. "
81748 ]</i></p>
81749
81750
81751 <p><i>[
81752 Adopted at 2010-11 Batavia
81753 ]</i></p>
81754
81755
81756
81757
81758 <p><b>Proposed resolution:</b></p>
81759 <ol>
81760 <li>Change 26.5.8.5.2 [rand.dist.samp.pconst] p. 2, class template <tt>piecewise_constant_distribution</tt> synopsis
81761 and the prototype description 26.5.8.5.2 [rand.dist.samp.pconst] before p. 13 as indicated:
81762 <blockquote><pre>vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
81763 </pre></blockquote>
81764 </li>
81765
81766 <li>Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 2, class template <tt>piecewise_linear_distribution</tt> synopsis
81767 and the prototype description 26.5.8.5.3 [rand.dist.samp.plinear] before p. 13 as indicated:
81768 <blockquote><pre>vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
81769 </pre></blockquote>
81770 </li>
81771 </ol>
81772
81773
81774
81775
81776
81777 <hr>
81778 <h3><a name="1440"></a>1440. [FCD] Incorrect specification for rand.dist.samp.plinear</h3>
81779 <p><b>Section:</b> 26.5.8.5.3 [rand.dist.samp.plinear] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81780  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81781 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81782 <p><b>Discussion:</b></p>
81783 <p><b>Addresses US-135</b></p>
81784
81785 This paragraph says: Let bk = xmin+k·&#948; for k = 0,...,n,
81786 and wk = fw(bk +&#948;) for k = 0,...,n.
81787 However I believe that fw(bk) would be far more desirable.
81788 I strongly suspect that this is nothing but a type-o.
81789
81790 <p><i>[
81791 Resolution proposed by ballot comment:
81792 ]</i></p>
81793
81794 <blockquote>
81795 Change p. 10 to read:<br>
81796 Let bk = xmin+k·&#948; for k = 0,...,n, and wk = fw(bk)
81797 for k = 0,...,n.
81798 </blockquote>
81799
81800 <p><i>[
81801 2010-11-02 Daniel translates into a proposed resolution
81802 ]</i></p>
81803
81804
81805 <p><i>[
81806 2010 Batavia: The working group concurred with the issue's Proposed Resolution
81807 ]</i></p>
81808
81809
81810 <p><i>[
81811 Adopted at 2010-11 Batavia
81812 ]</i></p>
81813
81814
81815
81816
81817 <p><b>Proposed resolution:</b></p>
81818 Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 10 as indicated:
81819 <blockquote>
81820 10 <em>Effects</em>: Constructs a <tt>piecewise_linear_distribution</tt> object with parameters taken or calculated
81821 from the following values: Let <tt><em>b<sub>k</sub></em> = xmin+<em>k</em>·&#948;</tt> for 
81822 <tt><em>k</em> = 0, . . . , <em>n</em></tt>, and <tt><em>w<sub>k</sub></em> = fw(<em>b</em><sub><em>k</em></sub><del> +&#948;</del>)</tt> 
81823 for <tt><em>k</em> = 0, . . . , <em>n</em></tt>.</blockquote>
81824
81825
81826
81827
81828
81829 <hr>
81830 <h3><a name="1441"></a>1441. [FCD] Floating-point test functions are incorrectly specified</h3>
81831 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81832  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
81833 <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>
81834 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81835 <p><b>Discussion:</b></p>
81836 <p><b>Addresses US-136</b></p>
81837
81838 Floating-point test functions are incorrectly specified.
81839
81840 <p><i>[
81841 Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
81842 ]</i></p>
81843
81844
81845
81846
81847 <p><b>Proposed resolution:</b></p>
81848 See Appendix 1 - Additional Details
81849
81850
81851
81852
81853
81854 <hr>
81855 <h3><a name="1445"></a>1445. [FCD] Several iostreams member functions incorrectly specified</h3>
81856 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
81857  <b>Submitter:</b> INCITS/PJ Plauger <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
81858 <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>
81859 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
81860 <p><b>Discussion:</b></p>
81861 <p><b>Addresses US-137</b></p>
81862
81863 Several iostreams member functions are incorrectly
81864 specified.
81865
81866 <p><i>[
81867 Resolution proposed by ballot comment:
81868 ]</i></p>
81869
81870 <p>
81871 See Appendix 1 - Additional Details
81872 </p>
81873
81874 <p><i>[
81875 2010-10-24 Daniel adds:
81876 ]</i></p>
81877
81878
81879 <blockquote>
81880 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a> would solve this issue.
81881 </blockquote>
81882
81883
81884
81885 <p><b>Proposed resolution:</b></p>
81886 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.
81887
81888
81889
81890
81891
81892 <hr>
81893 <h3><a name="1447"></a>1447. [FCD] Request to resolve issue LWG 1328</h3>
81894 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
81895  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
81896 <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>
81897 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
81898 <p><b>Discussion:</b></p>
81899 <p><b>Addresses US-139</b></p>
81900
81901 Resolve issue LWG 1328 one way or the other, but
81902 preferably in the direction outlined in the proposed
81903 resolution, which, however, is not complete as-is: in any
81904 case, the sentry must not set ok_ = false if is.good() ==
81905 false, otherwise istream::seekg, being an unformatted
81906 input function, does not take any action because the
81907 sentry object returns false when converted to type bool.
81908 Thus, it remains impossible to seek away from end of file.
81909
81910
81911 <p><b>Proposed resolution:</b></p>
81912 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.
81913
81914
81915
81916
81917
81918 <hr>
81919 <h3><a name="1449"></a>1449. [FCD] Incomplete specification of header <tt>&lt;cinttypes&gt;</tt></h3>
81920 <p><b>Section:</b> 27.8.2 [istringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
81921  <b>Submitter:</b> Canada <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
81922 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
81923 <p><b>Discussion:</b></p>
81924 <p><b>Addresses CA-4</b></p>
81925
81926 Subclause 27.9.2 [c.files] specifies that &lt;cinttypes&gt; has
81927 declarations for abs() and div(); however, the signatures
81928 are not present in this subclause. The signatures
81929 proposed under TR1 ([tr.c99.inttypes]) are not present in
81930 FCD (unless if intmax_t happened to be long long). It is
81931 unclear as to which, if any of the abs() and div() functions
81932 in [c.math] are meant to be declared by &lt;cinttypes&gt;. This
81933 subclause mentions imaxabs() and imaxdiv(). These
81934 functions, among other things, are not specified in FCD to
81935 be the functions from Subclause 7.8 of the C Standard.
81936 Finally, &lt;cinttypes&gt; is not specified in FCD to include
81937 &lt;cstdint&gt; (whereas &lt;inttypes.h&gt; includes &lt;stdint.h&gt; in C).
81938
81939 <p><i>[
81940 Post-Rapperswil, Daniel provides wording
81941 ]</i></p>
81942
81943
81944 <p>
81945 Subclause [c.files] specifies that <tt>&lt;cinttypes&gt;</tt> has declarations for <tt>abs()</tt> and <tt>div()</tt>; 
81946 however, the signatures are not present in this subclause. The signatures proposed under TR1 ([tr.c99.inttypes]) are not 
81947 present in FCD (unless if <tt>intmax_t</tt> happened to be <tt>long long</tt>). It is unclear as to which, if any of the 
81948 <tt>abs()</tt> and <tt>div()</tt> functions in [c.math] are meant to be declared by <tt>&lt;cinttypes&gt;</tt>. This
81949 subclause mentions <tt>imaxabs()</tt> and <tt>imaxdiv()</tt>. These functions, among other things, are not specified in 
81950 FCD to be the functions from subclause 7.8 of the <tt>C</tt> Standard. Finally, <tt>&lt;cinttypes&gt;</tt> is not specified 
81951 in FCD to include <tt>&lt;cstdint&gt;</tt> (whereas <tt>&lt;inttypes.h&gt;</tt> includes <tt>&lt;stdint.h&gt;</tt> in <tt>C</tt>).
81952 </p>
81953
81954 <blockquote>
81955 Moved to Tentatively Ready with proposed wording after 5 positive votes on c++std-lib.
81956 </blockquote>
81957
81958 <p><i>[
81959 Adopted at 2010-11 Batavia
81960 ]</i></p>
81961
81962
81963
81964
81965 <p><b>Proposed resolution:</b></p>
81966 <p>
81967 <i>The wording refers to N3126.</i>
81968 </p>
81969 <ol>
81970 <li>Add the following series of new paragraphs following [c.files] p.1:
81971 <blockquote>
81972 Table 132 describes header <tt>&lt;cinttypes&gt;</tt>. [<em>Note</em>: The macros defined by <tt>&lt;cinttypes&gt;</tt> are provided unconditionally.
81973 In particular, the symbol <tt>__STDC_FORMAT_MACROS</tt>, mentioned in footnote 182 of the <tt>C</tt> standard, plays no role in <tt>C++</tt>. 
81974 \97 <em>end note</em> ]
81975 <p>
81976 <ins>2 - The contents of header <tt>&lt;cinttypes&gt;</tt> are the same as the Standard <tt>C</tt> library header <tt>&lt;inttypes.h&gt;</tt>, 
81977 with the following changes:</ins>
81978 </p>
81979 <p>
81980 <ins>3 - The header <tt>&lt;cinttypes&gt;</tt> includes the header <tt>&lt;cstdint&gt;</tt> instead of <tt>&lt;stdint.h&gt;</tt>.</ins>
81981 </p>
81982 <p>
81983 <ins>4 - If and only if the type <tt>intmax_t</tt> designates an extended integer type ([basic.fundamental]), the following function 
81984 signatures are added:
81985 </ins></p><blockquote><pre><ins>intmax_t abs(intmax_t);</ins>
81986 <ins>imaxdiv_t div(intmax_t, intmax_t);</ins>
81987 </pre></blockquote>
81988 <ins>which shall have the same semantics as the function signatures <tt>intmax_t imaxabs(intmax_t)</tt> and 
81989 <tt>imaxdiv_t imaxdiv(intmax_t, intmax_t)</tt>, respectively.</ins>
81990
81991 <p></p>
81992 </blockquote>
81993 </li>
81994 </ol>
81995
81996
81997
81998
81999
82000 <hr>
82001 <h3><a name="1453"></a>1453. [FCD] Default constructed match_results behavior for certain operations </h3>
82002 <p><b>Section:</b> 28.10.4 [re.results.acc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82003  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82004 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results.acc">issues</a> in [re.results.acc].</p>
82005 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82006 <p><b>Discussion:</b></p>
82007 <p><b>Addresses GB-126</b></p>
82008
82009 It's unclear how match_results should behave if it has
82010 been default-constructed. The sub_match objects
82011 returned by operator[], prefix and suffix cannot point to the
82012 end of the sequence that was searched if no search was
82013 done. The iterators held by unmatched sub_match objects
82014 might be singular.
82015
82016 <p><i>[
82017 Resolution proposed by ballot comment:
82018 ]</i></p>
82019
82020
82021 <blockquote>
82022 Add to match_results::operator[],
82023 match_results::prefix and match_results::suffix:<br>
82024 Requires: !empty()
82025 </blockquote>
82026
82027 <p><i>[
82028 2010-10-24 Daniel adds:
82029 ]</i></p>
82030
82031
82032 <blockquote>
82033 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a> would solve this issue.
82034 </blockquote>
82035
82036
82037
82038 <p><b>Proposed resolution:</b></p>
82039 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a>.
82040
82041
82042
82043
82044
82045 <hr>
82046 <h3><a name="1455"></a>1455. [FCD] C language compatibility for atomics</h3>
82047 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82048  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82049 <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>
82050 <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>
82051 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82052 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a></p>
82053 <p><b>Discussion:</b></p>
82054 <p><b>Addresses CH-22, GB-128</b></p>
82055 <p>
82056 WG14 currently plans to introduce atomic facilities that are
82057 intended to be compatible with the facilities of clause 29.
82058 They should be compatible.
82059 </p>
82060
82061 <p><i>[
82062 Resolution proposed by ballot comment
82063 ]</i></p>
82064
82065 <p>
82066 Make sure the headers in clause 29 are defined in
82067 a way that is compatible with the planned C
82068 standard.
82069 </p>
82070
82071 <p><i>[
82072 2010 Batavia
82073 ]</i></p>
82074
82075 <p>
82076 Resolved by adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82077 </p>
82078
82079
82080 <p><b>Proposed resolution:</b></p>
82081 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82082
82083
82084
82085
82086
82087 <hr>
82088 <h3><a name="1462"></a>1462. [FCD] Ambiguous value assignment to <tt>atomic_bool</tt></h3>
82089 <p><b>Section:</b> 29.5.1 [atomics.types.integral] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82090  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82091 <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>
82092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82093 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a></p>
82094 <p><b>Discussion:</b></p>
82095 <p><b>Addresses GB-132, US-157</b></p>
82096
82097 The <tt>atomic_<em>itype</em></tt> types and <tt>atomic_address</tt> have two
82098 overloads of <tt>operator=</tt>; one is <tt>volatile</tt> qualified, and the
82099 other is not. <tt>atomic_bool</tt> only has the <tt>volatile</tt> qualified
82100 version:
82101 <pre><blockquote>
82102 bool operator=(bool) volatile;
82103 </blockquote></pre>
82104 On a non-<tt>volatile</tt>-qualified object this is ambiguous with
82105 the deleted copy-assignment operator
82106 <pre><blockquote>
82107 atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
82108 </blockquote></pre>
82109 due to the need for a single standard conversion in each
82110 case when assigning a bool to an <tt>atomic_bool</tt> as in:
82111 <pre><blockquote>
82112 atomic_bool b;
82113 b = true;
82114 </blockquote></pre>
82115 The conversions are: 
82116 <pre><blockquote>
82117 atomic_bool&amp; &#8594; atomic_bool volatile&amp;
82118 </blockquote></pre>
82119  vs 
82120 <pre><blockquote>
82121 bool &#8594; atomic_bool
82122 </blockquote></pre>
82123
82124 <p><i>[
82125 Proposed resolution as of NB comment:
82126 ]</i></p>
82127
82128
82129 <p>
82130 Change 29.5.1 [atomics.types.integral] as indicated:
82131
82132 </p><blockquote><pre>namespace std {
82133   typedef struct atomic_bool {
82134     [..]
82135     bool operator=(bool) volatile;
82136     <ins>bool operator=(bool);</ins>
82137   } atomic_bool;
82138   [..]
82139 }
82140 </pre></blockquote>
82141 <p></p>
82142
82143 <p><i>[
82144 2010-10-27 Daniel adds:
82145 ]</i></p>
82146
82147
82148 <blockquote>
82149 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue
82150 by replacing <tt>atomic_bool</tt> by <tt>atomic&lt;bool&gt;</tt>.
82151 </blockquote>
82152
82153 <p><i>[
82154 2010 Batavia
82155 ]</i></p>
82156
82157 <p>
82158 Resolved by adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82159 </p>
82160
82161
82162 <p><b>Proposed resolution:</b></p>
82163 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82164
82165
82166
82167
82168
82169 <hr>
82170 <h3><a name="1464"></a>1464. [FCD] Underspecified typedefs for atomic integral types</h3>
82171 <p><b>Section:</b> 29.5.1 [atomics.types.integral] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82172  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82173 <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>
82174 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82175 <p><b>Discussion:</b></p>
82176 <p><b>Addresses US-160</b></p>
82177
82178 The last sentence of 29.5.1 [atomics.types.integral] p.1 says:
82179 <blockquote><p>
82180 Table 143 shows typedefs to atomic integral classes and the corresponding <tt>&lt;cstdint&gt;</tt> typedefs.
82181 </p></blockquote>
82182 That's nice, but nothing says these are supposed to be part of the implementation, and
82183 they are not listed in the synopsis.
82184
82185 <p><i>[
82186 Proposed resolution as of NB comment
82187 ]</i></p>
82188
82189
82190 <p>
82191 </p><ol>
82192 <li>Remove Table 143 \97 Atomics for standard typedef types.
82193 <p>
82194 </p>
82195 </li>
82196 <li>Change 29.5.1 [atomics.types.integral] p.1 as indicated:
82197 <blockquote><p>
82198 1 The name <tt>atomic_<em>itype</em></tt> and the functions operating on it in the preceding synopsis are placeholders for a
82199 set of classes and functions. Throughout the preceding synopsis, <tt>atomic_<em>itype</em></tt> should be replaced by each
82200 of the class names in Table 142 and integral should be replaced by the integral type corresponding to the
82201 class name. <del>Table 143 shows typedefs to atomic integral classes and the corresponding <tt>&lt;cstdint&gt;</tt> typedefs.</del>
82202 </p></blockquote>
82203 </li>
82204 </ol>
82205 <p></p>
82206
82207 <p><i>[
82208 2010-10-27 Daniel adds:
82209 ]</i></p>
82210
82211
82212 <blockquote>
82213 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue.
82214 </blockquote>
82215
82216 <p><i>[
82217 2010-11 Batavia
82218 ]</i></p>
82219
82220 <p>
82221 Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82222 </p>
82223
82224
82225
82226 <p><b>Proposed resolution:</b></p>
82227 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82228
82229
82230
82231
82232
82233 <hr>
82234 <h3><a name="1465"></a>1465. [FCD] Missing arithmetic operators for <tt>atomic_address</tt></h3>
82235 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82236  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82237 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
82238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82239 <p><b>Discussion:</b></p>
82240 <p><b>Addresses US-161</b></p>
82241
82242 <tt>atomic_address</tt> has <tt>operator+=</tt> and <tt>operator-=</tt>, but no
82243 <tt>operator++</tt> or <tt>operator--</tt>. The template specialization
82244 <tt>atomic&lt;Ty*&gt;</tt> has all of them.
82245
82246 <p><i>[
82247 2010-10-27 Daniel adds:
82248 ]</i></p>
82249
82250
82251 <blockquote>
82252 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
82253 replacing <tt>atomic_address</tt> by <tt>atomic&lt;void*&gt;</tt>.
82254 </blockquote>
82255
82256 <p><i>[
82257 Resolved in Batavia by accepting 
82258 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82259 ]</i></p>
82260
82261
82262
82263
82264 <p><b>Proposed resolution:</b></p>
82265 <p>Change 29.5.2 [atomics.types.address], class <tt>atomic_address</tt> synopsis, as indicated:
82266 </p><blockquote><pre>namespace std {
82267   typedef struct atomic_address {
82268     [..]
82269     void* operator=(const void*) volatile;
82270     void* operator=(const void*);
82271     <ins>void* operator++(int) volatile;</ins>
82272     <ins>void* operator++(int);</ins>
82273     <ins>void* operator--(int) volatile;</ins>
82274     <ins>void* operator--(int);</ins>
82275     <ins>void* operator++() volatile;</ins>
82276     <ins>void* operator++();</ins>
82277     <ins>void* operator--() volatile;</ins>
82278     <ins>void* operator--();</ins>
82279     void* operator+=(ptrdiff_t) volatile;
82280     void* operator+=(ptrdiff_t);
82281     void* operator-=(ptrdiff_t) volatile;
82282     void* operator-=(ptrdiff_t);
82283   } atomic_address;
82284   [..]
82285 }
82286 </pre></blockquote>
82287 <p></p>
82288
82289
82290
82291
82292
82293
82294 <hr>
82295 <h3><a name="1466"></a>1466. [FCD] Silent <tt>const</tt> breakage by <tt>compare_exchange_*</tt> member functions</h3>
82296 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82297  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82298 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
82299 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82300 <p><b>Discussion:</b></p>
82301 <p><b>Addresses US-162</b></p>
82302
82303 The <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> member functions that take
82304 <tt>const void*</tt> arguments lead to a silent removal of <tt>const</tt>, because the <tt>load</tt> 
82305 member function and other acessors return the stored value as a <tt>void*</tt>.
82306
82307 <p><i>[
82308 Proposed resolution as of NB comment:
82309 ]</i></p>
82310
82311
82312 <p>
82313 Change 29.5.2 [atomics.types.address], class <tt>atomic_address</tt> synopsis, as indicated:
82314
82315 </p><blockquote><pre>namespace std {
82316   typedef struct atomic_address {
82317     [..]
82318     <del>bool compare_exchange_weak(const void*&amp;, const void*,
82319       memory_order, memory_order) volatile;</del>
82320     <del>bool compare_exchange_weak(const void*&amp;, const void*,
82321       memory_order, memory_order);</del>
82322     <del>bool compare_exchange_strong(const void*&amp;, const void*,
82323       memory_order, memory_order) volatile;</del>
82324     <del>bool compare_exchange_strong(const void*&amp;, const void*,
82325       memory_order, memory_order);</del>
82326     <del>bool compare_exchange_weak(const void*&amp;, const void*,
82327       memory_order = memory_order_seq_cst) volatile;</del>
82328     <del>bool compare_exchange_weak(const void*&amp;, const void*,
82329       memory_order = memory_order_seq_cst);</del>
82330     <del>bool compare_exchange_strong(const void*&amp;, const void*,
82331       memory_order = memory_order_seq_cst) volatile;</del>
82332     <del>bool compare_exchange_strong(const void*&amp;, const void*,
82333       memory_order = memory_order_seq_cst);</del>
82334     [..]
82335   } atomic_address;
82336   [..]
82337 }
82338 </pre></blockquote>
82339
82340 <p></p>
82341
82342 <p><i>[
82343 2010-10-27 Daniel adds:
82344 ]</i></p>
82345
82346
82347 <blockquote>
82348 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> 
82349 would solve this issue by replacing <tt>atomic_address</tt> by <tt>atomic&lt;void*&gt;</tt>.
82350 </blockquote>
82351
82352 <p><i>[
82353 Resolved in Batavia by accepting 
82354 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82355 ]</i></p>
82356
82357
82358
82359
82360 <p><b>Proposed resolution:</b></p>
82361 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82362
82363
82364
82365
82366
82367 <hr>
82368 <h3><a name="1467"></a>1467. [FCD] Deriving <tt>atomic&lt;T*&gt;</tt> from <tt>atomic_address</tt> breaks type safety</h3>
82369 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82370  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82371 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
82372 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82373 <p><b>Discussion:</b></p>
82374 <p><b>Addresses US-163</b></p>
82375
82376 Requiring <tt>atomic&lt;T*&gt;</tt> to be derived from <tt>atomic_address</tt> breaks type safety:
82377 <blockquote><pre>atomic&lt;double*&gt; ip;
82378 char ch;
82379 atomic_store(&amp;ip, &amp;ch);
82380 *ip.load() = 3.14159;
82381 </pre></blockquote>
82382 The last line overwrites <tt>ch</tt> with a value of type <tt>double</tt>.
82383
82384 <p><i>[
82385 2010-10-27 Daniel adds:
82386 ]</i></p>
82387
82388
82389 <blockquote>
82390 <p>
82391 Resolving this issue will also solve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>
82392 </p>
82393 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
82394 removing <tt>atomic_address</tt>.
82395 </blockquote>
82396 <p><i>[
82397 Resolved in Batavia by accepting 
82398 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82399 ]</i></p>
82400
82401
82402
82403 <p><b>Proposed resolution:</b></p>
82404 <ol>
82405 <li>Change 29.5 [atomics.types.generic], class template specialization <tt>atomic&lt;T*&gt;</tt> synopsis, as indicated:
82406 <blockquote><pre>namespace std {
82407   template &lt;class T&gt; struct atomic&lt;T*&gt; <del>: atomic_address</del> {
82408     [..]
82409   };
82410   [..]
82411 }
82412 </pre></blockquote>
82413 </li>
82414 <li>Change 29.5 [atomics.types.generic] p. 4 as indicated:
82415 <p></p><blockquote>
82416 4 There are pointer partial specializations on the <tt>atomic</tt> class template. <del>These specializations shall be publicly
82417 derived from <tt>atomic_address</tt>.</del> The unit of addition/subtraction for these specializations shall be the size
82418 of the referenced type. These specializations shall have trivial default constructors and trivial destructors.
82419 </blockquote><p></p>
82420 </li>
82421 </ol>
82422
82423
82424
82425
82426
82427
82428 <hr>
82429 <h3><a name="1468"></a>1468. [FCD] <tt>atomic_address::compare_exchange_*</tt> member functions should match <tt>atomic_compare_exchange_*</tt> free functions</h3>
82430 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82431  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82432 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
82433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82434 <p><b>Discussion:</b></p>
82435 <p><b>Addresses US-164</b></p>
82436
82437 <tt>atomic_address</tt> has member functions <tt>compare_exchange_weak</tt> and
82438 <tt>compare_exchange_strong</tt> that take arguments of type <tt>const void*</tt>, 
82439 in addition to the <tt>void*</tt> versions. If these member functions survive, 
82440 there should be corresponding free functions.
82441
82442 <p><i>[
82443 2010-10-27 Daniel adds:
82444 ]</i></p>
82445
82446
82447 <blockquote>
82448 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue 
82449 differently by removing the overloads with <tt>const void*</tt> arguments, because they break type-safety.
82450 </blockquote>
82451 <p><i>[
82452 Resolved in Batavia by accepting 
82453 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82454 ]</i></p>
82455
82456
82457
82458 <p><b>Proposed resolution:</b></p>
82459 Extend the synopsis around <tt>atomic_address</tt> in 29.5.2 [atomics.types.address]
82460 as indicated:
82461 <blockquote><pre>namespace std {
82462   [..]
82463   bool atomic_compare_exchange_weak(volatile atomic_address*, void**, void*);
82464   bool atomic_compare_exchange_weak(atomic_address*, void**, void*);
82465   bool atomic_compare_exchange_strong(volatile atomic_address*, void**, void*);
82466   bool atomic_compare_exchange_strong(atomic_address*, void**, void*);
82467   bool atomic_compare_exchange_weak_explicit(volatile atomic_address*, void**, void*,
82468     memory_order, memory_order);
82469   bool atomic_compare_exchange_weak_explicit(atomic_address*, void**, void*,
82470     memory_order, memory_order);
82471   bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, void**, void*,
82472     memory_order, memory_order);
82473   bool atomic_compare_exchange_strong_explicit(atomic_address*, void**, void*,
82474     memory_order, memory_order);
82475   <ins>bool atomic_compare_exchange_weak(volatile atomic_address*, const void**, const void*);</ins>
82476   <ins>bool atomic_compare_exchange_weak(atomic_address*, const void**, const void*);</ins>
82477   <ins>bool atomic_compare_exchange_strong(volatile atomic_address*, const void**, const void*);</ins>
82478   <ins>bool atomic_compare_exchange_strong(atomic_address*, const void**, const void*);</ins>
82479   <ins>bool atomic_compare_exchange_weak_explicit(volatile atomic_address*, const void**, const void*,
82480     memory_order, memory_order);</ins>
82481   <ins>bool atomic_compare_exchange_weak_explicit(atomic_address*, const void**, const void*,
82482     memory_order, memory_order);</ins>
82483   <ins>bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, const void**, const void*,
82484     memory_order, memory_order);</ins>
82485   <ins>bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, const void**, const void*,
82486     memory_order, memory_order);</ins>
82487   <ins>bool atomic_compare_exchange_strong_explicit(atomic_address*, const void**, const void*,
82488     memory_order, memory_order);</ins>
82489   [..]
82490 }
82491 </pre></blockquote>
82492
82493
82494
82495
82496
82497
82498 <hr>
82499 <h3><a name="1469"></a>1469. [FCD] <tt>atomic&lt;T*&gt;</tt> inheritance from <tt>atomic_address</tt> breaks type safety</h3>
82500 <p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82501  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82502 <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>
82503 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82504 <p><b>Discussion:</b></p>
82505 <p><b>Addresses GB-133</b></p>
82506
82507 The free functions that operate on <tt>atomic_address</tt> can be
82508 used to store a pointer to an unrelated type in an <tt>atomic&lt;T*&gt;</tt> 
82509 without a cast. e.g.
82510 <blockquote><pre>int i;
82511 atomic&lt;int*&gt; ai(&amp;i);
82512 string s;
82513 atomic_store(&amp;ai,&amp;s);
82514 </pre></blockquote>
82515 Overload the <tt>atomic_store</tt>, <tt>atomic_exchange</tt> and
82516 <tt>atomic_compare_exchange_[weak/strong]</tt> operations for 
82517 <tt>atomic&lt;T*&gt;</tt> to allow storing only pointers to <tt>T</tt>.
82518
82519 <p><i>[
82520 2010-10-27 Daniel adds:
82521 ]</i></p>
82522
82523
82524 <blockquote>
82525 <p>
82526 Resolving this issue will also solve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>
82527 </p>
82528 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
82529 removing <tt>atomic_address</tt>.
82530 </blockquote>
82531
82532 <p><i>[Resolved in Batavia by accepting
82533 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
82534 ]</i></p>
82535
82536
82537
82538 <p><b>Proposed resolution:</b></p>
82539 <p>Add the following overloads to 29.5 [atomics.types.generic], the synopsis around the specialization
82540 <tt>atomic&lt;T*&gt;</tt>, as indicated:
82541 </p><blockquote><pre>namespace std {
82542   [..]
82543   template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
82544     [..]
82545   };
82546
82547   <ins>template&lt;typename T&gt;</ins>
82548   <ins>void atomic_store(atomic&lt;T*&gt;&amp;,T*);</ins>
82549   <ins>template&lt;typename T&gt;</ins>
82550   <ins>void atomic_store(atomic&lt;T*&gt;&amp;,void*) = delete;</ins>
82551   <ins>template&lt;typename T&gt;</ins>
82552   <ins>void atomic_store_explicit(atomic&lt;T*&gt;&amp;,T*,memory_order);</ins>
82553   <ins>template&lt;typename T&gt;</ins>
82554   <ins>void atomic_store_explicit(atomic&lt;T*&gt;&amp;,void*,memory_order) = delete;</ins>
82555   <ins>template&lt;typename T&gt;</ins>
82556   <ins>T* atomic_exchange(atomic&lt;T*&gt;&amp;,T*);</ins>
82557   <ins>template&lt;typename T&gt;</ins>
82558   <ins>T* atomic_exchange(atomic&lt;T*&gt;&amp;,void*) = delete;</ins>
82559   <ins>template&lt;typename T&gt;</ins>
82560   <ins>T* atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,T*,memory_order);</ins>
82561   <ins>template&lt;typename T&gt;</ins>
82562   <ins>T* atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,void*,memory_order) = delete;</ins>
82563   <ins>template&lt;typename T&gt;</ins>
82564   <ins>T* atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,T**,T*);</ins>
82565   <ins>template&lt;typename T&gt;</ins>
82566   <ins>T* atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,void**,void*) = delete;</ins>
82567   <ins>template&lt;typename T&gt;</ins>
82568   <ins>T* atomic_compare_exchange_weak_explicit(atomic&lt;T*&gt;&amp;,T**,T*,memory_order);</ins>
82569   <ins>template&lt;typename T&gt;</ins>
82570   <ins>T* atomic_compare_exchange_weak_explicit(atomic&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;</ins>
82571   <ins>template&lt;typename T&gt;</ins>
82572   <ins>T* atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,T**,T*);</ins>
82573   <ins>template&lt;typename T&gt;</ins>
82574   <ins>T* atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,void**,void*) = delete;</ins>
82575   <ins>template&lt;typename T&gt;</ins>
82576   <ins>T* atomic_compare_exchange_strong_explicit(atomic&lt;T*&gt;&amp;,T**,T*,memory_order);</ins>
82577   <ins>template&lt;typename T&gt;</ins>
82578   <ins>T* atomic_compare_exchange_strong_explicit(atomic&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;</ins>
82579
82580 }
82581 </pre></blockquote>
82582 <p></p>
82583
82584
82585
82586
82587
82588 <hr>
82589 <h3><a name="1481"></a>1481. [FCD] Missing Lockable requirements</h3>
82590 <p><b>Section:</b> 30.2 [thread.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82591  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82592 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82593 <p><b>Discussion:</b></p>
82594 <p><b>Addresses GB-138</b></p>
82595
82596 The FCD combines the requirements for lockable objects
82597 with those for the standard mutex objects. These should
82598 be separate. This is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>.
82599
82600 <p><i>[
82601 Resolution proposed by ballot comment:
82602 ]</i></p>
82603
82604 <blockquote>
82605 See attached Appendix 1 - Additional Details
82606 </blockquote>
82607
82608 <p><i>[
82609 2010-11-01 Daniel comments:
82610 ]</i></p>
82611
82612 <blockquote>
82613 Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> addresses
82614 this issue.
82615 </blockquote>
82616
82617
82618
82619 <p><b>Proposed resolution:</b></p>
82620 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.
82621
82622
82623
82624
82625
82626 <hr>
82627 <h3><a name="1482"></a>1482. [FCD] Timeout operations are under-specified</h3>
82628 <p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82629  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82630 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.req.timing">issues</a> in [thread.req.timing].</p>
82631 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82632 <p><b>Discussion:</b></p>
82633 <p><b>Addresses US-181</b></p>
82634
82635 The timeout operations are under-specified.
82636
82637 <p><i>[
82638 Resolution proposed by ballot comment:
82639 ]</i></p>
82640
82641
82642 <blockquote>
82643 Define precise semantics for <tt>timeout_until</tt> and <tt>timeout_for</tt>. See 
82644 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> page 193 - Appendix 1 - Additional Details
82645 </blockquote>
82646
82647 <p><i>[
82648 2010-11-01 Daniel comments:
82649 ]</i></p>
82650
82651
82652 <blockquote>
82653 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> would solve this issue.
82654 </blockquote>
82655
82656
82657 <p><b>Proposed resolution:</b></p>
82658 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3191</a>.
82659
82660
82661
82662
82663
82664 <hr>
82665 <h3><a name="1490"></a>1490. [FCD] Mutex requirements too stringent</h3>
82666 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82667  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82668 <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>
82669 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82670 <p><b>Discussion:</b></p>
82671 <p><b>Addresses CH-27</b></p>
82672
82673 The mutex requirements force <tt>try_lock</tt> to be
82674 <tt>noexcept(true)</tt>. However, where they are used by the
82675 generic algorithms, those relax this requirement and say
82676 that <tt>try_lock</tt> may throw. This means the requirement is
82677 too stringent, also a non-throwing <tt>try_lock</tt> does not allow
82678 for a diagnostic such as <tt>system_error</tt> that <tt>lock()</tt> 
82679 will give us.
82680
82681 <p><i>[
82682 Resolution proposed by ballot comment:
82683 ]</i></p>
82684
82685 <blockquote>
82686 delete p18, adjust 30.4.4 p1 and p4 accordingly
82687 </blockquote>
82688
82689 <p><i>[
82690 2010-11-01 Daniel comments:
82691 ]</i></p>
82692
82693
82694 <blockquote>
82695 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
82696 </blockquote>
82697
82698
82699 <p><b>Proposed resolution:</b></p>
82700 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.
82701
82702
82703
82704
82705
82706 <hr>
82707 <h3><a name="1491"></a>1491. [FCD] <tt>try_lock</tt> does not guarantee forward progress</h3>
82708 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82709  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
82710 <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>
82711 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82712 <p><b>Discussion:</b></p>
82713 <p><b>Addresses US-186</b></p>
82714
82715 <tt>try_lock</tt> does not provide a guarantee of forward progress
82716 because it is allowed to spuriously fail.
82717
82718 <p><i>[
82719 Resolution proposed by ballot comment:
82720 ]</i></p>
82721
82722 <blockquote>
82723 The standard mutex types must not fail spuriously
82724 in <tt>try_lock</tt>. See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> page 205 - Appendix 1 - Additional Details
82725 </blockquote>
82726
82727 <p><i>[
82728 2010-11-01 Daniel comments:
82729 ]</i></p>
82730
82731 <blockquote>
82732 Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3152.html">n3152</a> addresses
82733 this issue.
82734 </blockquote>
82735
82736
82737
82738 <p><b>Proposed resolution:</b></p>
82739 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3209.html">n3209</a>.
82740
82741
82742
82743
82744
82745 <hr>
82746 <h3><a name="1492"></a>1492. [FCD] Mutex requirements should not be bound to threads</h3>
82747 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82748  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82749 <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>
82750 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82751 <p><b>Discussion:</b></p>
82752 <p><b>Addresses US-188</b></p>
82753
82754 Mutex requirements should not be bound to threads
82755
82756 <p><i>[
82757 Resolution proposed by ballot comment:
82758 ]</i></p>
82759
82760 <blockquote>
82761 See Appendix 1 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> - Additional Details, p. 208.
82762 </blockquote>
82763
82764 <p><i>[
82765 2010-10-24 Daniel adds:
82766 ]</i></p>
82767
82768
82769 <blockquote>
82770 Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
82771 </blockquote>
82772
82773
82774 <p><b>Proposed resolution:</b></p>
82775 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.
82776
82777
82778
82779
82780
82781 <hr>
82782 <h3><a name="1498"></a>1498. [FCD] Unclear specification for [thread.condition]</h3>
82783 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82784  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
82785 <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>
82786 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82787 <p><b>Discussion:</b></p>
82788 <p><b>Addresses CH-29</b></p>
82789
82790 It is unclear if a spurious wake-up during the loop and reentering
82791 of the blocked state due to a repeated execution
82792 of the loop will adjust the timer of the blocking with the
82793 respect to the previously specified rel_time value.
82794
82795 <p><i>[
82796 Resolution proposed by ballot comment:
82797 ]</i></p>
82798
82799
82800 <blockquote>
82801 Make it clear (e.g. by a note) that when reexecuting
82802 the loop the waiting time when blocked
82803 will be adjusted with respect to the elapsed time of
82804 the previous loop executions.
82805 </blockquote>
82806
82807 <p><i>[
82808 2010-08-13 Peter Sommerlad comments and provides wording:
82809 ]</i></p>
82810
82811
82812 <blockquote>
82813 Problem: It is unclear if a spurious wake-up during the loop and re-entering of the blocked state due 
82814 to a repeated execution of the loop will adjust the timer of the blocking with the respect to the 
82815 previously specified <tt>rel_time</tt> value.
82816 <p>
82817 Proposed Resolution from CH29:
82818 </p><p>
82819 Make it clear (e.g. by a note) that when re-executing the loop the waiting time when blocked will be 
82820 adjusted with respect to the elapsed time of the previous loop executions.
82821 </p><p>
82822 Discussion in Rapperswil:
82823 </p><p>
82824 Assuming the introduction of a mandatory <tt>steady_clock</tt> proposed by US-181 to the FCD the 
82825 specification of <tt>condition_variable::wait_for</tt> can be defined in terms of <tt>wait_until</tt> 
82826 using the <tt>steady_clock</tt>. This is also interleaving with US-181, because that touches the 
82827 same paragraph (30.5.1 p 25, p34 and 30.5.2 p 20, p 28 in n3092.pdf)
82828 </p><p>
82829 (The "as if" in the proposed solutions should be confirmed by the standardization terminology experts)
82830 </p></blockquote>
82831
82832 <p><i>[
82833 2010-11 Batavia: Resolved by applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>
82834 ]</i></p>
82835
82836
82837 <blockquote>
82838 <ol>
82839 <li>Change 30.5.1 [thread.condition.condvar] paragraph 25, <tt>wait_for</tt> <i>Effects</i> as indicated:
82840 <blockquote><pre>template &lt;class Rep, class Period&gt;
82841 cv_status wait_for(unique_lock&lt;mutex&gt;&amp; lock,
82842   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
82843 </pre></blockquote>
82844 <blockquote>
82845 [..]
82846 <p>
82847 25 <i>Effects</i>: <ins>as if</ins>
82848 </p><blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time);</ins>
82849 </pre></blockquote>
82850 <ul>
82851 <li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.</del>
82852 </li>
82853 <li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock), then returns.</del>
82854 </li>
82855 <li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
82856 by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.</del>
82857 </li>
82858 <li><del>If the function exits via an exception, <tt>lock.lock()</tt> shall be called prior to exiting the function scope.</del>
82859 </li>
82860 </ul>
82861 </blockquote>
82862 </li>
82863 <li>Change 30.5.1 [thread.condition.condvar] paragraph 34, <tt>wait_for</tt> with predicate <i>Effects</i> as indicated:
82864 <blockquote><pre>template &lt;class Rep, class Period, class Predicate&gt;
82865 bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
82866   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
82867   Predicate pred);
82868 </pre></blockquote>
82869 <blockquote>
82870 [..]
82871 <p>
82872 34 <i>Effects</i>: <ins>as if</ins>
82873 </p><blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));</ins>
82874 </pre></blockquote>
82875 <ul>
82876 <li><del>Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> and exits the loop if the
82877 result is <tt>true</tt>.
82878 </del></li>
82879
82880 <li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
82881 </del></li>
82882
82883 <li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
82884 </del></li>
82885
82886 <li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
82887 by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
82888 </del></li>
82889
82890 <li><del>If the function exits via an exception, <tt>lock.lock()</tt> shall be called prior to exiting the function
82891 scope.
82892 </del></li>
82893
82894 <li><del>The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time duration specified by <tt>rel_time</tt>
82895 has elapsed.
82896 </del></li>
82897
82898 </ul>
82899 </blockquote>
82900 </li>
82901
82902 <li>Change 30.5.2 [thread.condition.condvarany] paragraph 20, <tt>wait_for</tt> <i>Effects</i> as indicated:
82903 <blockquote><pre>template &lt;class Lock, class Rep, class Period&gt;
82904 cv_status wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
82905 </pre></blockquote>
82906 <blockquote>
82907 20 <i>Effects</i>: <ins>as if</ins>
82908 <blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time);</ins>
82909 </pre></blockquote>
82910 <ul>
82911 <li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
82912 </del></li>
82913
82914 <li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock), then returns.
82915 </del></li>
82916
82917 <li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
82918 by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
82919 </del></li>
82920
82921 <li><del>If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior to exiting the function
82922 scope.
82923 </del></li>
82924 </ul>
82925 </blockquote>
82926 </li>
82927
82928 <li>Change 30.5.2 [thread.condition.condvarany] paragraph 28, <tt>wait_for</tt> with predicate <i>Effects</i> as indicated:
82929 <blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
82930 bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
82931 </pre></blockquote>
82932 <blockquote>
82933 28 <i>Effects</i>: <ins>as if</ins>
82934 <blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));</ins>
82935 </pre></blockquote>
82936 <ul>
82937 <li><del>Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> and exits the loop if the
82938 result is <tt>true</tt>.
82939 </del></li>
82940
82941 <li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
82942 </del></li>
82943
82944 <li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
82945 </del></li>
82946
82947 <li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
82948 by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
82949 </del></li>
82950
82951 <li><del>If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior to exiting the function
82952 scope.
82953 </del></li>
82954
82955 <li><del>The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time duration specified by <tt>rel_time</tt>
82956 has elapsed.
82957 </del></li>
82958 </ul>
82959 </blockquote>
82960 </li>
82961
82962 </ol>
82963
82964 </blockquote>
82965
82966
82967 <p><b>Proposed resolution:</b></p>
82968 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
82969
82970
82971
82972
82973
82974 <hr>
82975 <h3><a name="1501"></a>1501. [FCD] spec for managing associated asynchronous
82976 state has problems</h3>
82977 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
82978  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
82979 <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>
82980 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
82981 <p><b>Discussion:</b></p>
82982 <p><b>Addresses US-194</b></p>
82983
82984 The specification for managing associated asynchronous
82985 state is confusing, sometimes omitted, and redundantly
82986 specified.
82987
82988 <p><i>[
82989 Resolution proposed by ballot comment:
82990 ]</i></p>
82991
82992
82993 <blockquote>
82994 Define terms-of-art for releasing, making ready,
82995 and abandoning an associated asynchronous
82996 state. Use those terms where appropriate. See
82997 Appendix 1 - Additional Details
82998 </blockquote>
82999
83000
83001 <p><b>Proposed resolution:</b></p>
83002 Resolved in Batavia by accepting
83003 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3192.html">n3192</a>.
83004
83005
83006
83007
83008
83009 <hr>
83010 <h3><a name="1508"></a>1508. [FCD] Rename <tt>packaged_task::operator bool()</tt></h3>
83011 <p><b>Section:</b> 30.6.10 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
83012  <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
83013 <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>
83014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
83015 <p><b>Discussion:</b></p>
83016 <p><b>Addresses US-201</b></p>
83017 <p>
83018 <tt>packaged_task</tt> provides <tt>operator bool()</tt> to check whether
83019 an object has an associated asynchronous state. The various <tt>future</tt> 
83020 types provide a member function <tt>valid()</tt> that does the same thing. 
83021 The names of these members should be the same.
83022 </p>
83023
83024 <p><i>[
83025 Resolution proposed by ballot comment:
83026 ]</i></p>
83027
83028 <blockquote>
83029 Replaced the name <tt>packaged_task::operator bool()</tt> with <tt>packaged_task::valid()</tt> in the synopsis
83030 (30.6.10 [futures.task]/2) and the member function specification (before 30.6.10.1 [futures.task.members]/15).
83031 </blockquote>
83032
83033 <p><i>[
83034 2010-11-02 Daniel translates proposed wording changes into a proper proposed resolution
83035 and verified that no other places implicitly take advantage of <tt>packaged_task</tt> 
83036 conversion to bool.
83037 ]</i></p>
83038
83039
83040 <p><i>[Resolved in Batavia by accepting
83041 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3194.html">n3194</a>.
83042 ]</i></p>
83043
83044
83045
83046
83047 <p><b>Proposed resolution:</b></p>
83048 <ol>
83049 <li>Change 30.6.10 [futures.task]/2, class template <tt>packaged_task</tt> synopsis as indicated:
83050 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
83051 class packaged_task&lt;R(ArgTypes...)&gt; {
83052 public:
83053   typedef R result_type;
83054   [..]
83055   <del>explicit operator</del> bool <ins>valid</ins>() const;
83056   [..]
83057 };
83058 </pre></blockquote>
83059 </li>
83060 <li>Change 30.6.10 [futures.task] before p. 15 as indicated:
83061 <blockquote><pre><del>explicit operator</del> bool <ins>valid</ins>() const;
83062 </pre><blockquote>
83063 15 <em>Returns</em>: true only if <tt>*this</tt> has an associated asynchronous state.
83064 <p>
83065 16 <em>Throws</em>: nothing.
83066 </p></blockquote></blockquote>
83067 </li>
83068 </ol>
83069
83070
83071
83072
83073
83074 <hr>
83075 <h3><a name="1513"></a>1513. [FCD] 'launch' enum too restrictive</h3>
83076 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
83077  <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
83078 <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>
83079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
83080 <p><b>Discussion:</b></p>
83081 <p><b>Addresses CH-36</b></p>
83082
83083 Providing only three different possible values for the enum
83084 <tt>launch</tt> and saying that <tt>launch::any</tt> means either
83085 <tt>launch::sync</tt> or <tt>launch::async</tt> is very restricting. This
83086 hinders future implementors to provide clever
83087 infrastructures that can simply by used by a call to
83088 <tt>async(launch::any,...)</tt>. Also there is no hook for an
83089 implementation to provide additional alternatives to <tt>launch</tt>
83090 enumeration and no useful means to combine those (i.e.
83091 interpret them like flags). We believe something like
83092 <tt>async(launch::sync | launch::async, ...)</tt> should be allowed
83093 and can become especially useful if one could say also
83094 something like <tt>async(launch::any &amp; ~launch::sync, ....)</tt>
83095 respectively. This flexibility might limit the features usable
83096 in the function called through <tt>async()</tt>, but it will allow a
83097 path to effortless profit from improved hardware/software
83098 without complicating the programming model when just
83099 using <tt>async(launch::any,...)</tt>
83100
83101 <p><i>[
83102 Resolution proposed by ballot comment:
83103 ]</i></p>
83104
83105 <p>
83106 Change in 30.6.1 [futures.overview] 'enum class launch' to allow
83107 further implementation defined values and provide
83108 the following bit-operators on the launch values
83109 (<tt>operator|</tt>, <tt>operator&amp;</tt>, <tt>operator~</tt> delivering a
83110 <tt>launch</tt> value).
83111 </p><p>
83112 Note: a possible implementation might use an
83113 unsigned value to represent the <tt>launch</tt> enums,
83114 but we shouldn't limit the standard to just 32 or 64
83115 available bits in that case and also should keep
83116 the launch enums in their own enum namespace.
83117 </p><p>
83118 Change [future.async] p3 according to the
83119 changes to <tt>enum launch</tt>. change --<tt>launch::any</tt> to
83120 "the implementation may choose any of the
83121 policies it provides." Note: this can mean that an
83122 implementation may restrict the called function to
83123 take all required information by copy in case it will
83124 be called in a different address space, or even, on
83125 a different processor type. To ensure that a call is
83126 either performed like <tt>launch::async</tt> or
83127 <tt>launch::sync</tt> describe one should call
83128 <tt>async(launch::sync|launch::async,...)</tt>
83129 </p>
83130
83131 <p><i>[
83132 2010-11-02 Daniel comments:
83133 ]</i></p>
83134
83135
83136 <blockquote>
83137 The new paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3113.html">n3113</a> provides concrete wording.
83138 </blockquote>
83139
83140
83141 <p><b>Proposed resolution:</b></p>
83142 Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3188.html">n3188</a>.
83143
83144
83145
83146
83147
83148 <hr>
83149 <h3><a name="1516"></a>1516. [FCD] No specification for which header contains <tt>auto_ptr</tt></h3>
83150 <p><b>Section:</b> D.12 [depr.auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83151  <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
83152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83153 <p><b>Discussion:</b></p>
83154 <p><b>Addresses GB-142</b></p>
83155 <p>
83156 <tt>auto_ptr</tt> does not appear in the <tt>&lt;memory&gt;</tt> synopsis and
83157 [depr.auto.ptr] doesn't say which header declares it.
83158 Conversely, the deprecated binders <tt>bind1st</tt> etc. are in the
83159 <tt>&lt;functional&gt;</tt> synopsis, this is inconsistent
83160 </p>
83161 <p>
83162 Either <tt>auto_ptr</tt> should be declared in the
83163 <tt>&lt;memory&gt;</tt> synopsis, or the deprecated binders
83164 should be removed from the <tt>&lt;functional&gt;</tt> synopsis
83165 and appendix D should say which header declares
83166 the binders and <tt>auto_ptr</tt>.
83167 </p>
83168
83169 <p><i>[
83170 Post-Rapperswil
83171 ]</i></p>
83172
83173
83174 <blockquote>
83175 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
83176 </blockquote>
83177
83178 <p><i>[
83179 Adopted at 2010-11 Batavia
83180 ]</i></p>
83181
83182
83183
83184
83185 <p><b>Proposed resolution:</b></p>
83186
83187 <p>Add the following lines to the synopsis of header <tt>&lt;memory&gt;</tt>
83188 in [memory]/1:<br></p>
83189 <blockquote>
83190 <pre><ins>// [depr.auto.ptr], Class auto_ptr (deprecated):
83191 template &lt;class X&gt; class auto_ptr;<br></ins>
83192 </pre></blockquote>
83193
83194
83195
83196
83197
83198 <hr>
83199 <h3><a name="1517"></a>1517. default_delete's default constructor should be trivial</h3>
83200 <p><b>Section:</b> 20.9.9.1.2 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83201  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-09-12 <b>Last modified:</b> 2010-11-23</p>
83202 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.dltr.dflt">issues</a> in [unique.ptr.dltr.dflt].</p>
83203 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83204 <p><b>Discussion:</b></p>
83205 <p>
83206 The current working draft does specify the default c'tor of <tt>default_delete</tt> in a manner
83207 to guarantee static initialization for default-constructed objects of static storage duration
83208 as a consequence of the acceptance of the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2976.html">n2976</a>
83209 but this paper overlooked the fact that the suggested declaration does not ensure that the type 
83210 will be a trivial type. The type <tt>default_delete</tt> was always considered as a simple wrapper for 
83211 calling <tt>delete</tt> or <tt>delete[]</tt>, respectivly and should be a trivial type.
83212 </p>
83213 <p>
83214 In agreement with the new settled core language rules this easy to realize by just changing the declaration to
83215 </p><blockquote><pre>constexpr default_delete()<ins> = default</ins>;
83216 </pre></blockquote><p></p>
83217 <p>
83218 This proposal also automatically solves the problem, that the semantics of the default constructor of the 
83219 partial specialization <tt>default_delete&lt;T[]&gt;</tt> is not specified at all. By defaulting its default constructor 
83220 as well, the semantics are well-defined.
83221 </p>
83222
83223 <p><i>[
83224 Post-Rapperswil
83225 ]</i></p>
83226
83227
83228 <blockquote>
83229 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
83230 </blockquote>
83231
83232 <p><i>[
83233 Adopted at 2010-11 Batavia
83234 ]</i></p>
83235
83236
83237
83238
83239 <p><b>Proposed resolution:</b></p>
83240 <p><i>The following wording changes are against N3126.</i></p>
83241
83242 <ol>
83243 <li>Change the synopsis of the primary template definition of <tt>default_delete</tt> in [unique.ptr.dltr.dflt] as indicated:
83244 <blockquote><pre>namespace std {
83245   template &lt;class T&gt; struct default_delete {
83246     constexpr default_delete()<ins> = default</ins>;
83247     template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp;);
83248     void operator()(T*) const;
83249   };
83250 }
83251 </pre></blockquote>
83252 </li>
83253 <li>
83254 Remove the prototype specification of the <tt>default_delete</tt> default constructor in [unique.ptr.dltr.dflt]/1. This
83255 brings it in harmony with the style used in the partial specialization <tt>default_delete&lt;T[]&gt;</tt>. Since there are
83256 neither implied nor explicit members, there is no possibility to misinterpret what the constructor does:
83257 <blockquote><pre><del>constexpr default_delete();</del>
83258 </pre><blockquote>
83259 <del>1 <em>Effects</em>: Default constructs a <tt>default_delete</tt> object.</del>
83260 </blockquote></blockquote>
83261 </li>
83262 <li>Change the synopsis of the partial specialization of <tt>default_delete</tt> in [unique.ptr.dltr.dflt1] as indicated:
83263 <blockquote><pre>namespace std {
83264   template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
83265     constexpr default_delete()<ins> = default</ins>;
83266     void operator()(T*) const;
83267     template &lt;class U&gt; void operator()(U*) const = delete;
83268   };
83269 }</pre></blockquote>
83270 </li>
83271 </ol>
83272
83273
83274
83275
83276
83277 <hr>
83278 <h3><a name="1518"></a>1518. Waiting for deferred functions</h3>
83279 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83280  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2010-09-14 <b>Last modified:</b> 2010-11-24</p>
83281 <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>
83282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83283 <p><b>Discussion:</b></p>
83284 <p>The current WP N3126 contains ambiguous statements about the
83285 behaviour of functions <tt>wait_for</tt>/<tt>wait_until</tt> in
83286 case the future refers to a deferred function. Moreover, I believe
83287 it describes a disputable intent, different from the one contained
83288 in the original async proposals, that may have been introduced
83289 inadvertently during the "async cleanup" that occurred recently.
83290 Consider the following case:</p>
83291 <blockquote>
83292 <pre>int f();  
83293 future&lt;int&gt; x = async(launch::deferred, f);
83294 future_status s = x.wait_for(chrono::milliseconds(100));
83295 </pre></blockquote>
83296 <p>This example raises two questions:</p>
83297 <ol>
83298 <li>is <tt>f</tt> invoked?</li>
83299 <li>what is the value of <tt>s</tt>?</li>
83300 </ol>
83301 <p>According to the current WP, the answer to question 1 is yes,
83302 because 30.6.9/3 says "The first call to a function waiting for the
83303 associated asynchronous state created by this async call to become
83304 ready shall invoke the deferred function in the thread that called
83305 the waiting function". The answer to question 2, however, is not as
83306 clear. According to 30.6.6/23, s should be
83307 <tt>future_status::deferred</tt> because <tt>x</tt> refers to a
83308 deferred function that is not running, but it should also be
83309 <tt>future_status::ready</tt> because after executing <tt>f</tt>
83310 (and we saw that <tt>f</tt> is always executed) the state becomes
83311 ready. By the way, the expression "deferred function that is not
83312 running" is very unfortunate in itself, because it may apply to
83313 both the case where the function hasn't yet started, as well as the
83314 case where it was executed and completed.</p>
83315 <p>While we clearly have a defect in the WP answering to question
83316 2, it is my opinion that the answer to question 1 is wrong, which
83317 is even worse. Consider that the execution of the function
83318 <tt>f</tt> can take an arbitrarily long time. Having
83319 <tt>wait_for()</tt> invoke <tt>f</tt> is a potential violation of
83320 the reasonable expectation that the execution of
83321 <tt>x.wait_for(chrono::milliseconds(100))</tt> shall take <u>at most</u>
83322 100 milliseconds plus a delay dependent on the quality of implementation
83323 and the quality of management (as described in paper N3128).
83324 In fact, previous versions of the WP
83325 clearly specified that only function <tt>wait()</tt> is required to
83326 execute the deferred function, while <tt>wait_for()</tt> and
83327 <tt>wait_until()</tt> shouldn't.</p>
83328 <p>The proposed resolution captures the intent that
83329 <tt>wait_for()</tt> and <tt>wait_until()</tt> should never attempt
83330 to invoke the deferred function. In other words, the P/R provides
83331 the following answers to the two questions above:</p>
83332 <ol>
83333 <li>no</li>
83334 <li><tt>future_status::deferred</tt></li>
83335 </ol>
83336 <p>In order to simplify the wording, the definition of <i>deferred
83337 function</i> has been tweaked so that the function is no longer
83338 considered deferred once its evaluation has started, as suggested
83339 by Howard.</p>
83340 <p>Discussions in the reflector questioned whether
83341 <tt>wait_for()</tt> and <tt>wait_until()</tt> should return
83342 immediately or actually wait hoping for a second thread to execute
83343 the deferred function. I believe that waiting could be useful only
83344 in a very specific scenario but detrimental in the general case and
83345 would introduce another source of ambiguity: should
83346 <tt>wait_for()</tt> return <tt>future_status::deferred</tt> or
83347 <tt>future_status::timeout</tt> after the wait? Therefore the P/R
83348 specifies that <tt>wait_for</tt>/<tt>wait_until</tt> shall return
83349 immediately, which is simpler, easier to explain and more useful in
83350 the general case.</p>
83351
83352 <p><i>[
83353 Post-Rapperswil
83354 ]</i></p>
83355
83356
83357 <blockquote>
83358 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
83359 </blockquote>
83360
83361 <p><i>[
83362 Adopted at 2010-11 Batavia
83363 ]</i></p>
83364
83365
83366
83367
83368 <p><b>Proposed resolution:</b></p>
83369
83370 <p>The proposed wording changes are relative to the Final Committee Draft,
83371 N3126.</p>
83372 <p><b>Note to the editor:</b> the proposed wording is meant not be in conflict
83373 with any change proposed by paper N3128 "C++ Timeout Specification".
83374 Ellipsis are deliberately used to avoid any unintended overlapping.</p>
83375 <ol>
83376 <li>
83377 <p>In [futures.unique_future] 30.6.6/22:</p>
83378 <p>Effects: <ins>none if the associated asynchronous state contains
83379 a deferred function (30.6.9), otherwise</ins> blocks until the
83380 associated asynchronous state is ready or [...].</p>
83381 </li>
83382 <li>
83383 <p>In [futures.unique_future] 30.6.6/23 first bullet:</p>
83384 <p>\97 future_status::deferred if the associated asynchronous
83385 state contains a deferred function <del>that is not
83386 running</del>.</p>
83387 </li>
83388 <li>
83389 <p>In [futures.unique_future] 30.6.6/25:</p>
83390 <p>Effects: <ins>none if the associated asynchronous state contains
83391 a deferred function (30.6.9), otherwise</ins> blocks until the
83392 associated asynchronous state is ready or [...].</p>
83393 </li>
83394 <li>
83395 <p>In [futures.unique_future] 30.6.6/26 first bullet:</p>
83396 <p>\97 future_status::deferred if the associated asynchronous
83397 state contains a deferred function <del>that is not
83398 running</del>.</p>
83399 </li>
83400 <li>
83401 <p>In [futures.shared_future] 30.6.7/27</p>
83402 <p>Effects: <ins>none if the associated asynchronous state contains
83403 a deferred function (30.6.9), otherwise</ins> blocks until the
83404 associated asynchronous state is ready or [...].</p>
83405 </li>
83406 <li>
83407 <p>In [futures.unique_future] 30.6.7/28 first bullet:</p>
83408 <p>\97 future_status::deferred if the associated asynchronous
83409 state contains a deferred function <del>that is not
83410 running</del>.</p>
83411 </li>
83412 <li>
83413 <p>In [futures.shared_future] 30.6.6/30:</p>
83414 <p>Effects: <ins>none if the associated asynchronous state contains
83415 a deferred function (30.6.9), otherwise</ins> blocks until the
83416 associated asynchronous state is ready or [...].</p>
83417 </li>
83418 <li>
83419 <p>In [futures.unique_future] 30.6.7/31 first bullet:</p>
83420 <p>\97 future_status::deferred if the associated asynchronous
83421 state contains a deferred function <del>that is not
83422 running</del>.</p>
83423 </li>
83424 <li>
83425 <p>In [futures.atomic_future] 30.6.8/23</p>
83426 <p>Effects: <ins>none if the associated asynchronous state contains
83427 a deferred function (30.6.9), otherwise</ins> blocks until the
83428 associated asynchronous state is ready or [...].</p>
83429 </li>
83430 <li>
83431 <p>In [futures.unique_future] 30.6.8/24 first bullet:</p>
83432 <p>\97 future_status::deferred if the associated asynchronous
83433 state contains a deferred function <del>that is not
83434 running</del>.</p>
83435 </li>
83436 <li>
83437 <p>In [futures.atomic_future] 30.6.8/27:</p>
83438 <p>Effects: <ins>none if the associated asynchronous state contains
83439 a deferred function (30.6.9), otherwise</ins> blocks until the
83440 associated asynchronous state is ready or [...].</p>
83441 </li>
83442 <li>
83443 <p>In [futures.unique_future] 30.6.8/28 first bullet:</p>
83444 <p>\97 future_status::deferred if the associated asynchronous
83445 state contains a deferred function <del>that is not
83446 running</del>.</p>
83447 </li>
83448 <li>
83449 <p>In [futures.async] 30.6.9/3 second bullet:</p>
83450 <p>[...] The first call to a function
83451 <del>waiting</del><ins>requiring a non-timed wait</ins> for the
83452 associated asynchronous state created by this async call to become
83453 ready shall invoke the deferred function in the thread that called
83454 the waiting function; <ins>once evaluation of <tt><i>INVOKE</i>(g,
83455 xyz)</tt> begins, the function is no longer considered
83456 deferred</ins> <del>all other calls waiting for the same associated
83457 asynchronous state to become ready shall block until the deferred
83458 function has completed</del>.</p>
83459 </li>
83460 </ol>
83461
83462
83463
83464
83465
83466
83467 <hr>
83468 <h3><a name="1519"></a>1519. bucketsize() const only for unordered set</h3>
83469 <p><b>Section:</b> 23.7.1 [unord.map], 23.7.2 [unord.multimap], 23.7.4 [unord.multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83470  <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-10-09 <b>Last modified:</b> 2010-11-24</p>
83471 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.map">issues</a> in [unord.map].</p>
83472 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83473 <p><b>Discussion:</b></p>
83474 <p>
83475 While <tt>bucket_size()</tt> is const for <tt>unordered_set</tt>, for all other unordered containers it is not defined as
83476 constant member function.
83477 </p>
83478
83479 <p><i>[
83480 Post-Rapperswil
83481 ]</i></p>
83482
83483
83484 <blockquote>
83485 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
83486 </blockquote>
83487
83488 <p><i>[
83489 Adopted at 2010-11 Batavia
83490 ]</i></p>
83491
83492
83493
83494
83495 <p><b>Proposed resolution:</b></p>
83496
83497 <p><i>The wording refers to N3126.</i></p>
83498
83499 <ol>
83500 <li>Change 23.7.1 Class template unordered_map [unord.map]/3, as indicated:
83501 <blockquote><pre>  namespace std {
83502     template &lt;class Key,
83503       class T,
83504       class Hash = hash&lt;Key&gt;,
83505       class Pred = std::equal_to&lt;Key&gt;,
83506       class Alloc = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
83507     class unordered_map
83508     {
83509     public:
83510       [..]
83511       // bucket interface
83512       size_type bucket_count() const;
83513       size_type max_bucket_count() const;
83514       size_type bucket_size(size_type n) <ins>const</ins>;
83515       [..]
83516 </pre></blockquote>
83517 </li>
83518 <li>Change 23.7.2 Class template unordered_multimap [unord.multimap]/3, as indicated:
83519 <blockquote><pre>  namespace std {
83520     template &lt;class Key,
83521       class T,
83522       class Hash = hash&lt;Key&gt;,
83523       class Pred = std::equal_to&lt;Key&gt;,
83524       class Alloc = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
83525     class unordered_multimap
83526     {
83527     public:
83528       [..]
83529       // bucket interface
83530       size_type bucket_count() const;
83531       size_type max_bucket_count() const;
83532       size_type bucket_size(size_type n) <ins>const</ins>;
83533       [..]
83534 </pre></blockquote>
83535 </li>
83536 <li>Change 23.7.4 Class template unordered_multiset [unord.multiset]/3, as indicated:
83537 <blockquote><pre>  namespace std {
83538     template &lt;class Key,
83539       class Hash = hash&lt;Key&gt;,
83540       class Pred = std::equal_to&lt;Key&gt;,
83541       class Alloc = std::allocator&lt;Key&gt; &gt;
83542     class unordered_multiset
83543     {
83544     public:
83545       [..]
83546       // bucket interface
83547       size_type bucket_count() const;
83548       size_type max_bucket_count() const;
83549       size_type bucket_size(size_type n) <ins>const</ins>;
83550       [..]
83551 </pre></blockquote>
83552 </li>
83553 </ol>
83554
83555
83556
83557
83558
83559
83560 <hr>
83561 <h3><a name="1520"></a>1520. <tt>INVOKE</tt> on member data pointer with too many arguments</h3>
83562 <p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83563  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-10-10 <b>Last modified:</b> 2010-11-23</p>
83564 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
83565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83566 <p><b>Discussion:</b></p>
83567
83568 <p>
83569 20.8.2 [func.require] p1 says:
83570 </p>
83571
83572 <blockquote>
83573 <p>
83574 1 Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
83575 </p>
83576
83577 <ul>
83578 <li>
83579 <tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function
83580 of a class <tt>T</tt> and <tt>t1</tt> is an object of type <tt>T</tt> or a
83581 reference to an object of type <tt>T</tt> or a reference to an object of a type
83582 derived from <tt>T</tt>;
83583 </li>
83584 <li>
83585 <tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member
83586 function of a class <tt>T</tt> and <tt>t1</tt> is not one of the types described
83587 in the previous item;
83588 </li>
83589 <li>
83590 <tt>t1.*f</tt> when <tt>f</tt> is a pointer to member data of a class <tt>T</tt>
83591 and <tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of
83592 type <tt>T</tt> or a reference to an object of a type derived from <tt>T</tt>;
83593 </li>
83594 <li>
83595 <tt>(*t1).*f</tt> when <tt>f</tt> is a pointer to member data of a class
83596 <tt>T</tt> and <tt>t1</tt> is not one of the types described in the previous
83597 item;
83598 </li>
83599 <li>
83600 <tt>f(t1, t2, ..., tN)</tt> in all other cases.
83601 </li>
83602 </ul>
83603 </blockquote>
83604
83605 <p>
83606 The question is:  What happens in the 3<sup><i>rd</i></sup> and
83607 4<sup><i>th</i></sup> bullets when <tt>N &gt; 1</tt>?
83608 </p>
83609
83610 <p>
83611 Does the presence of <tt>t2, ..., tN</tt> get ignored, or does it make the
83612 <tt><i>INVOKE</i></tt> ill formed?
83613 </p>
83614
83615 <p>
83616 Here is sample code which presents the problem in a concrete example:
83617 </p>
83618
83619 <blockquote><pre>#include &lt;functional&gt;
83620 #include &lt;cassert&gt;
83621
83622 struct S {
83623    char data;
83624 };
83625
83626 typedef char S::*PMD;
83627
83628 int main()
83629 {
83630    S s;
83631    PMD pmd = &amp;S::data;
83632    std::reference_wrapper&lt;PMD&gt; r(pmd);
83633    r(s, 3.0) = 'a';  // well formed?
83634    assert(s.data == 'a');
83635 }
83636 </pre></blockquote>
83637
83638 <p>
83639 Without the "<tt>3.0</tt>" the example is well formed.
83640 </p>
83641 <p>
83642 [Note: Daniel provided wording to make it explicit that the above example is ill-formed. \97 end note ]
83643 </p>
83644
83645 <p><i>[
83646 Post-Rapperswil
83647 ]</i></p>
83648
83649
83650 <blockquote>
83651 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
83652 </blockquote>
83653
83654 <p><i>[
83655 Adopted at 2010-11 Batavia
83656 ]</i></p>
83657
83658
83659
83660
83661 <p><b>Proposed resolution:</b></p>
83662
83663 <p><i>The wording refers to N3126.</i></p>
83664
83665 <p>
83666 Change 20.8.2 [func.require]/1 as indicated:
83667 </p>
83668 <blockquote>
83669 <p>
83670 1 Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
83671 </p>
83672
83673 <ul>
83674 <li>
83675 ...
83676 </li>
83677 <li>
83678 ...
83679 </li>
83680 <li>
83681 <tt>t1.*f</tt> when <ins><tt>N == 1</tt> and</ins> <tt>f</tt> is a pointer to
83682 member data of a class <tt>T</tt> and <tt>t1</tt> is an object of type
83683 <tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an
83684 object of a type derived from <tt>T</tt>;
83685 </li>
83686 <li>
83687 <tt>(*t1).*f</tt> when <ins><tt>N == 1</tt> and</ins> <tt>f</tt> is a pointer to
83688 member data of a class <tt>T</tt> and <tt>t1</tt> is not one of the types
83689 described in the previous item;
83690 </li>
83691 <li>
83692 ...
83693 </li>
83694 </ul>
83695 </blockquote>
83696
83697
83698
83699
83700
83701
83702 <hr>
83703 <h3><a name="1522"></a>1522. <tt>conj</tt> specification is now nonsense</h3>
83704 <p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
83705  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2010-11-24</p>
83706 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
83707 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
83708 <p><b>Discussion:</b></p>
83709 <p>
83710 In Pittsburgh, we accepted the resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, to add
83711 a sentence 3 to [cmplx.over]:
83712 </p>
83713 <blockquote>
83714 All the specified overloads shall have a return type which is the nested
83715 <tt>value_type</tt> of the effectively cast arguments.
83716 </blockquote>
83717 <p>
83718 This was already true for four of the six functions except <tt>conj</tt> and
83719 <tt>proj</tt>. It is not completely unreasonable to make <tt>proj</tt> return
83720 the real value only, but the IEC specification does call for an imaginary part
83721 of -0 in some circumstances. The people who care about these distinctions really
83722 care, and it <em>is</em> required by an international standard.
83723 </p>
83724 <p>
83725 Making <tt>conj</tt> return just the real part breaks it horribly, however. It is
83726 well understood in mathematics that <tt>conj(re + i*im)</tt> is <tt>(re - i*im)</tt>,
83727 and it is widely used. The accepted new definition makes <tt>conj</tt> useful only
83728 for pure real operations. This botch <em>absolutely must</em> be fixed.
83729 </p>
83730
83731 <p><i>[
83732 2010 Batavia: The working group concurred with the issue's Proposed Resolution
83733 ]</i></p>
83734
83735
83736 <p><i>[
83737 Adopted at 2010-11 Batavia
83738 ]</i></p>
83739
83740
83741
83742
83743 <p><b>Proposed resolution:</b></p>
83744 <p>
83745 Remove the recently added paragraph 3 from [cmplx.over]:
83746 </p>
83747 <blockquote>
83748 <del>3 All the specified overloads shall have a return type which is the nested 
83749 <tt>value_type</tt> of the effectively cast arguments.</del>
83750 </blockquote>
83751
83752
83753
83754
83755
83756 <hr>
83757 <h3><a name="2002"></a>2002. Class template <tt>match_results</tt> does not specify the semantics of <tt>operator==</tt></h3>
83758 <p><b>Section:</b> 28.10.8 [re.results.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
83759  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2010-10-24 <b>Last modified:</b> 2010-11-26</p>
83760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
83761 <p><b>Discussion:</b></p>
83762 <p>
83763 The <em>Returns</em> element of <tt>operator==</tt> says:
83764 </p>
83765
83766 <blockquote>
83767 <tt>true</tt> only if the two objects refer to the same match
83768 </blockquote>
83769
83770 <p>
83771 It is not really clear what this means: The current specification would allow for an
83772 implementation to return <tt>true</tt>, only if the address values of <tt>m1</tt> and
83773 <tt>m2</tt> are the same. While this approach is unproblematic in terms of used operations 
83774 this is also a bit unsatisfactory. With identity equality alone there seems to be no convincing
83775 reason to provide this operator at all. It could for example also refer to an comparison based
83776 on iterator values. In this case a user should better know that this will be done, because 
83777 there is no guarantee at all that inter-container comparison of iterators 
83778 is a feasible operation. This was a clear outcome of the resolution provided in 
83779 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a> 
83780 for LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#446">446</a>.
83781 It could also mean that a character-based comparison of the individual <tt>sub_match</tt>
83782 elements should be done - this would be equivalent to applying <tt>operator==</tt> to
83783 the subexpressions, prefix and suffix.
83784 </p>
83785
83786
83787
83788 <p><b>Proposed resolution:</b></p>
83789 Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a>.
83790
83791
83792
83793
83794
83795
83796
83797 </body></html>