1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
3 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
6 <title>C++ Standard Library Defect Report List</title>
7 <style type="text/css">
9 li {text-align:justify}
10 ins {background-color:#A0FFA0}
11 del {background-color:#FFA0A0}
16 <td align="left">Doc. no.</td>
17 <td align="left">N2728=08-0238</td>
20 <td align="left">Date:</td>
21 <td align="left">2008-08-24</td>
24 <td align="left">Project:</td>
25 <td align="left">Programming Language C++</td>
28 <td align="left">Reply to:</td>
29 <td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
32 <h1>C++ Standard Library Defect Report List (Revision R59)</h1>
34 <p>Reference ISO/IEC IS 14882:1998(E)</p>
37 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
38 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
39 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
40 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
41 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
43 <p>This document contains only library issues which have been closed
44 by the Library Working Group (LWG) after being found to be defects
45 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>,
46 <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
47 <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
48 <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
49 introductory material in that document also applies to this
52 <h2>Revision History</h2>
55 2008-08-22 pre-San Francisco mailing.
57 <li><b>Summary:</b><ul>
58 <li>192 open issues, up by 9.</li>
59 <li>686 closed issues, up by 0.</li>
60 <li>878 issues total, up by 9.</li>
62 <li><b>Details:</b><ul>
63 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
68 2008-07-28 mid-term mailing.
70 <li><b>Summary:</b><ul>
71 <li>183 open issues, up by 12.</li>
72 <li>686 closed issues, down by 4.</li>
73 <li>869 issues total, up by 8.</li>
75 <li><b>Details:</b><ul>
76 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
77 <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>
78 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
79 <li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
80 <li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
85 2008-06-27 post-Sophia Antipolis mailing.
87 <li><b>Summary:</b><ul>
88 <li>171 open issues, down by 20.</li>
89 <li>690 closed issues, up by 43.</li>
90 <li>861 issues total, up by 23.</li>
92 <li><b>Details:</b><ul>
93 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
94 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
95 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
96 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
97 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
98 <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>
99 <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>
100 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
101 <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>
102 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
103 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
104 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
105 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
106 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
107 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
108 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
109 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
110 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
111 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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>
116 2008-05-16 pre-Sophia Antipolis mailing.
118 <li><b>Summary:</b><ul>
119 <li>191 open issues, up by 24.</li>
120 <li>647 closed issues, up by 1.</li>
121 <li>838 issues total, up by 25.</li>
123 <li><b>Details:</b><ul>
124 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
125 <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>
130 2008-03-14 post-Bellevue mailing.
132 <li><b>Summary:</b><ul>
133 <li>167 open issues, down by 39.</li>
134 <li>646 closed issues, up by 65.</li>
135 <li>813 issues total, up by 26.</li>
137 <li><b>Details:</b><ul>
138 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
139 <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>
140 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
141 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
142 <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>
143 <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>
144 <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>
145 <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>
146 <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>
147 <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>
148 <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>
149 <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>
150 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
151 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#774">774</a>.</li>
152 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
153 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
154 <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-closed.html#625">625</a>.</li>
155 <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-active.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>
156 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
157 <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>
158 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
159 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
160 <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>
161 <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>
166 2008-02-01 pre-Bellevue mailing.
168 <li><b>Summary:</b><ul>
169 <li>206 open issues, up by 23.</li>
170 <li>581 closed issues, up by 0.</li>
171 <li>787 issues total, up by 23.</li>
173 <li><b>Details:</b><ul>
174 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
175 <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>
176 <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#353">353</a>.</li>
177 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li>
178 <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>
179 <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>
184 2007-12-09 mid-term mailing.
186 <li><b>Summary:</b><ul>
187 <li>183 open issues, up by 11.</li>
188 <li>581 closed issues, down by 1.</li>
189 <li>764 issues total, up by 10.</li>
191 <li><b>Details:</b><ul>
192 <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-active.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-active.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-active.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>
193 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
194 <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>
199 2007-10-19 post-Kona mailing.
201 <li><b>Summary:</b><ul>
202 <li>172 open issues, up by 4.</li>
203 <li>582 closed issues, up by 27.</li>
204 <li>754 issues total, up by 31.</li>
206 <li><b>Details:</b><ul>
207 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.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-active.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-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
208 <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>
209 <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>
210 <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>
211 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#708">708</a>.</li>
212 <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>
213 <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>
214 <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-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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>
215 <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>
216 <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-active.html#691">691</a>.</li>
217 <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>
218 <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>
219 <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>
224 2007-09-09 pre-Kona mailing.
226 <li><b>Summary:</b><ul>
227 <li>168 open issues, up by 15.</li>
228 <li>555 closed issues, up by 0.</li>
229 <li>723 issues total, up by 15.</li>
231 <li><b>Details:</b><ul>
232 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#723">723</a>.</li>
237 2007-08-05 post-Toronto mailing.
239 <li><b>Summary:</b><ul>
240 <li>153 open issues, down by 5.</li>
241 <li>555 closed issues, up by 17.</li>
242 <li>708 issues total, up by 12.</li>
244 <li><b>Details:</b><ul>
245 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#708">708</a>.</li>
246 <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>
247 <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>
248 <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-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
249 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li>
250 <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>
251 <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-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
252 <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>
253 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
254 <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>
255 <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>
256 <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>
257 <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>
258 <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>
259 <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>
264 2007-06-23 pre-Toronto mailing.
266 <li><b>Summary:</b><ul>
267 <li>158 open issues, up by 13.</li>
268 <li>538 closed issues, up by 7.</li>
269 <li>696 issues total, up by 20.</li>
271 <li><b>Details:</b><ul>
272 <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-active.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-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#696">696</a>.</li>
273 <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>
274 <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>
275 <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>
276 <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>
281 2007-05-06 post-Oxford mailing.
283 <li><b>Summary:</b><ul>
284 <li>145 open issues, down by 33.</li>
285 <li>531 closed issues, up by 53.</li>
286 <li>676 issues total, up by 20.</li>
288 <li><b>Details:</b><ul>
289 <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-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
290 <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>
291 <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-active.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>
292 <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>
293 <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#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
294 <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-active.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-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-closed.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>
295 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
296 <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>
297 <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-closed.html#594">594</a>.</li>
298 <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>
299 <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-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
300 <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>
301 <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>
302 <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>
303 <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>
308 2007-03-09 pre-Oxford mailing.
310 <li><b>Summary:</b><ul>
311 <li>178 open issues, up by 37.</li>
312 <li>478 closed issues, up by 0.</li>
313 <li>656 issues total, up by 37.</li>
315 <li><b>Details:</b><ul>
316 <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-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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>
317 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
318 <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-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#614">614</a>.</li>
319 <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-closed.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>
320 <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-active.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-active.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-closed.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>
321 <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>
326 2007-01-12 mid-term mailing.
328 <li><b>Summary:</b><ul>
329 <li>141 open issues, up by 11.</li>
330 <li>478 closed issues, down by 1.</li>
331 <li>619 issues total, up by 10.</li>
333 <li><b>Details:</b><ul>
334 <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#619">619</a>.</li>
339 2006-11-03 post-Portland mailing.
341 <li><b>Summary:</b><ul>
342 <li>130 open issues, up by 0.</li>
343 <li>479 closed issues, up by 17.</li>
344 <li>609 issues total, up by 17.</li>
346 <li><b>Details:</b><ul>
347 <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>
348 <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>
349 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
350 <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-active.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-active.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-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
351 <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>
352 <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>
353 <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#609">609</a>.</li>
358 2006-09-08 pre-Portland mailing.
360 <li><b>Summary:</b><ul>
361 <li>130 open issues, up by 6.</li>
362 <li>462 closed issues, down by 1.</li>
363 <li>592 issues total, up by 5.</li>
365 <li><b>Details:</b><ul>
366 <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#592">592</a>.</li>
371 2006-06-23 mid-term mailing.
373 <li><b>Summary:</b><ul>
374 <li>124 open issues, up by 14.</li>
375 <li>463 closed issues, down by 1.</li>
376 <li>587 issues total, up by 13.</li>
378 <li><b>Details:</b><ul>
379 <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-active.html#582">582</a>.</li>
380 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
381 <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>
386 2006-04-21 post-Berlin mailing.
388 <li><b>Summary:</b><ul>
389 <li>110 open issues, down by 16.</li>
390 <li>464 closed issues, up by 24.</li>
391 <li>574 issues total, up by 8.</li>
393 <li><b>Details:</b><ul>
394 <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#572">572</a>.</li>
395 <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#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>
396 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</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-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
397 <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>
398 <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>
399 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
404 2006-02-24 pre-Berlin mailing.
406 <li><b>Summary:</b><ul>
407 <li>126 open issues, up by 31.</li>
408 <li>440 closed issues, up by 0.</li>
409 <li>566 issues total, up by 31.</li>
411 <li><b>Details:</b><ul>
412 <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#566">566</a>.</li>
413 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
414 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
419 2005-12-16 mid-term mailing.
421 <li><b>Summary:</b><ul>
422 <li>95 open issues.</li>
423 <li>440 closed issues.</li>
424 <li>535 issues total.</li>
426 <li><b>Details:</b><ul>
427 <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#535">535</a>.</li>
432 2005-10-14 post-Mont Tremblant mailing.
433 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>.
434 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.
435 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-active.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.
436 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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.
437 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.
438 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
439 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
442 2005-07-03 pre-Mont Tremblant mailing.
443 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-active.html#522">522</a>.
444 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
447 2005-06 mid-term mailing.
448 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
451 2005-04 post-Lillehammer mailing. All issues in "ready" status except
452 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
453 previously in "DR" status were moved to "WP".
456 2005-03 pre-Lillehammer mailing.
459 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>.
462 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
465 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
466 new issues received after the 2004-07 mailing. Added
467 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>.
470 2004-07 mid-term mailing: reflects new proposed resolutions and
471 new issues received after the post-Sydney mailing. Added
472 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
475 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
476 Voted all "Ready" issues from R29 into the working paper.
477 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>.
480 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>.
483 Post-Kona mailing: reflects decisions made at the Kona meeting.
484 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>.
487 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-active.html#431">431</a>.
490 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
491 All issues in Ready status were voted into DR status. All issues in
492 DR status were voted into WP status.
495 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>.
498 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
499 meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
500 moved to DR status. Added new issues <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#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
501 at the meeting.) Made progress on issues <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#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
502 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
505 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-active.html#382">382</a>.
506 Moved issues in the TC to TC status.
509 Post-Curaçao mailing. Added new issues <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-closed.html#366">366</a>.
512 Pre-Curaçao mailing. Added new issues <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#361">361</a>.
515 Post-Redmond mailing; reflects actions taken in Redmond. Added
516 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
517 <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
518 not discussed at the meeting.
520 All Ready issues were moved to DR status, with the exception of issues
521 <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>.
523 Noteworthy issues discussed at Redmond include
524 <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>,
525 <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>.
528 Pre-Redmond mailing. Added new issues
529 <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>.
532 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
533 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
534 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>.
536 Changed status of issues
537 <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>
538 <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>
539 <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>
540 <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>
541 <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>
542 <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>
543 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
546 Changed status of issues
547 <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>
548 <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>
549 <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>
550 <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>
551 <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>
552 <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>
553 <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>
554 <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>
555 <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>
559 <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>
560 <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>
561 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
566 Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
567 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>, <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#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>.
568 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>.
571 post-Toronto mailing; reflects actions taken in Toronto. Added new
572 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
573 <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>,
574 <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>,
575 <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>,
576 <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>,
577 <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>,
578 <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>,
579 <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>,
580 <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>,
581 <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>,
582 <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>,
583 <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>,
584 <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>,
585 <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-active.html#23">23</a>. Reopened
586 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
587 <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
588 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
589 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
590 the bug in enough places.
593 pre-Toronto mailing. Added issues
594 <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
595 changes so that we pass Weblint tests.
598 post-Tokyo II mailing; reflects committee actions taken in
599 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)
602 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>.
605 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
606 <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
607 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
608 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
611 post-Kona mailing: Updated to reflect LWG and full committee actions
612 in Kona (99-0048/N1224). Note changed resolution of issues
613 <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>
614 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
615 "closed" documents. Changed the proposed resolution of issue
616 <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
617 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
620 pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
621 <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>,
622 <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-active.html#190">190</a> to
623 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
626 pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
627 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
628 "closed" documents. (99-0030/N1206, 25 Aug 99)
631 post-Dublin mailing. Updated to reflect LWG and full committee actions
632 in Dublin. (99-0016/N1193, 21 Apr 99)
635 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>,
636 <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>,
637 <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>,
638 <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)
641 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-active.html#128">128</a>,
642 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
645 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
646 <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
647 for making list public. (30 Dec 98)
650 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
651 <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
652 issues corrected. (22 Oct 98)
655 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>
656 added, many issues updated to reflect LWG consensus (12 Oct 98)
659 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,
660 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
663 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
664 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
668 <h2>Defect Reports</h2>
670 <h3><a name="1"></a>1. C library linkage editing oversight</h3>
671 <p><b>Section:</b> 17.4.2.2 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
672 <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
673 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
674 <p><b>Discussion:</b></p>
675 <p>The change specified in the proposed resolution below did not make
676 it into the Standard. This change was accepted in principle at the
677 London meeting, and the exact wording below was accepted at the
678 Morristown meeting.</p>
681 <p><b>Proposed resolution:</b></p>
682 <p>Change 17.4.2.2 [using.linkage] paragraph 2
686 <p>It is unspecified whether a name from the Standard C library
687 declared with external linkage has either extern "C" or
688 extern "C++" linkage.</p>
694 <p>Whether a name from the Standard C library declared with external
695 linkage has extern "C" or extern "C++" linkage
696 is implementation defined. It is recommended that an implementation
697 use extern "C++" linkage for this purpose.</p>
705 <h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
706 <p><b>Section:</b> 18.4 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
707 <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</p>
708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
709 <p><b>Discussion:</b></p>
710 <p>We appear not to have covered all the possibilities of
711 exit processing with respect to
712 atexit registration. <br>
714 Example 1: (C and C++)</p>
716 <pre> #include <stdlib.h>
718 void f2() { atexit(f1); }
722 atexit(f2); // the only use of f2
723 return 0; // for C compatibility
726 <p>At program exit, f2 gets called due to its registration in
727 main. Running f2 causes f1 to be newly registered during the exit
728 processing. Is this a valid program? If so, what are its
732 Interestingly, neither the C standard, nor the C++ draft standard nor
733 the forthcoming C9X Committee Draft says directly whether you can
734 register a function with atexit during exit processing.</p>
737 All 3 standards say that functions are run in reverse order of their
738 registration. Since f1 is registered last, it ought to be run first,
739 but by the time it is registered, it is too late to be first.</p>
741 <p>If the program is valid, the standards are self-contradictory about
744 <p>Example 2: (C++ only)</p>
747 void F() { static T t; } // type T has a destructor
751 atexit(F); // the only use of F
755 <p>Function F registered with atexit has a local static variable t,
756 and F is called for the first time during exit processing. A local
757 static object is initialized the first time control flow passes
758 through its definition, and all static objects are destroyed during
759 exit processing. Is the code valid? If so, what are its semantics?</p>
762 Section 18.3 "Start and termination" says that if a function
763 F is registered with atexit before a static object t is initialized, F
764 will not be called until after t's destructor completes.</p>
767 In example 2, function F is registered with atexit before its local
768 static object O could possibly be initialized. On that basis, it must
769 not be called by exit processing until after O's destructor
770 completes. But the destructor cannot be run until after F is called,
771 since otherwise the object could not be constructed in the first
774 <p>If the program is valid, the standard is self-contradictory about
777 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
778 a recommendation that the results be undefined. (Alternative: make it
779 unspecified. I don't think it is worthwhile to specify the case where
780 f1 itself registers additional functions, each of which registers
781 still more functions.)</p>
783 <p>I think we should resolve the situation in the whatever way the C
784 committee decides. </p>
786 <p>For Example 2, I recommend we declare the results undefined.</p>
788 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
793 <p><b>Proposed resolution:</b></p>
794 <p>Change section 18.3/8 from:</p>
796 First, objects with static storage duration are destroyed and
797 functions registered by calling atexit are called. Objects with
798 static storage duration are destroyed in the reverse order of the
799 completion of their constructor. (Automatic objects are not
800 destroyed as a result of calling exit().) Functions registered with
801 atexit are called in the reverse order of their registration. A
802 function registered with atexit before an object obj1 of static
803 storage duration is initialized will not be called until obj1's
804 destruction has completed. A function registered with atexit after
805 an object obj2 of static storage duration is initialized will be
806 called before obj2's destruction starts.
810 First, objects with static storage duration are destroyed and
811 functions registered by calling atexit are called. Non-local objects
812 with static storage duration are destroyed in the reverse order of
813 the completion of their constructor. (Automatic objects are not
814 destroyed as a result of calling exit().) Functions registered with
815 atexit are called in the reverse order of their registration, except
816 that a function is called after any previously registered functions
817 that had already been called at the time it was registered. A
818 function registered with atexit before a non-local object obj1 of
819 static storage duration is initialized will not be called until
820 obj1's destruction has completed. A function registered with atexit
821 after a non-local object obj2 of static storage duration is
822 initialized will be called before obj2's destruction starts. A local
823 static object obj3 is destroyed at the same time it would be if a
824 function calling the obj3 destructor were registered with atexit at
825 the completion of the obj3 constructor.
829 <p><b>Rationale:</b></p>
830 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
831 supporting to the proposed resolution.</p>
838 <h3><a name="5"></a>5. String::compare specification questionable</h3>
839 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
840 <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p>
841 <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>
842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
843 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
844 <p><b>Discussion:</b></p>
845 <p>At the very end of the basic_string class definition is the signature: int
846 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
847 following text this is defined as: returns
848 basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
849 basic_string<charT,traits,Allocator>(s,n2); </p>
851 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a
852 = Allocator()) clearly requires that s != NULL and n < npos and further states that it
853 throws length_error if n == npos, it appears the compare() signature above should always
854 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
855 null terminated character array. </p>
857 <p>This appears to be a typo since the obvious intent is to allow either the call above or
858 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
860 <p>This would imply that what was really intended was two signatures int compare(size_type
861 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
862 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
865 <p><b>Proposed resolution:</b></p>
866 <p>Replace the compare signature in 21.3 [basic.string]
867 (at the very end of the basic_string synopsis) which reads:</p>
870 <p><tt>int compare(size_type pos1, size_type n1,<br>
871 const charT* s,
872 size_type n2 = npos) const;</tt></p>
878 <p><tt>int compare(size_type pos1, size_type n1,<br>
879 const charT* s) const;<br>
880 int compare(size_type pos1, size_type n1,<br>
881 const charT* s,
882 size_type n2) const;</tt></p>
885 <p>Replace the portion of 21.3.6.8 [string::swap]
886 paragraphs 5 and 6 which read:</p>
889 <p><tt>int compare(size_type pos, size_type n1,<br>
890 charT * s, size_type n2
892 </tt>Returns:<tt><br>
893 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
894
895 basic_string<charT,traits,Allocator>( s, n2))</tt></p>
901 <p><tt>int compare(size_type pos, size_type n1,<br>
902 const charT * s) const;<br>
903 </tt>Returns:<tt><br>
904 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
905
906 basic_string<charT,traits,Allocator>( s ))<br>
908 int compare(size_type pos, size_type n1,<br>
909 const charT * s,
910 size_type n2) const;<br>
911 </tt>Returns:<tt><br>
912 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
913
914 basic_string<charT,traits,Allocator>( s, n2))</tt></p>
917 <p>Editors please note that in addition to splitting the signature, the third argument
918 becomes const, matching the existing synopsis.</p>
921 <p><b>Rationale:</b></p>
922 <p>While the LWG dislikes adding signatures, this is a clear defect in
923 the Standard which must be fixed. The same problem was also
924 identified in issues 7 (item 5) and 87.</p>
931 <h3><a name="7"></a>7. String clause minor problems</h3>
932 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
933 <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
934 <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>
935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
936 <p><b>Discussion:</b></p>
937 <p>(1) In 21.3.6.4 [string::insert], the description of template
938 <class InputIterator> insert(iterator, InputIterator,
939 InputIterator) makes no sense. It refers to a member function that
940 doesn't exist. It also talks about the return value of a void
943 <p>(2) Several versions of basic_string::replace don't appear in the
946 <p>(3) basic_string::push_back appears in the synopsis, but is never
947 described elsewhere. In the synopsis its argument is const charT,
948 which doesn't makes much sense; it should probably be charT, or
949 possible const charT&. </p>
951 <p>(4) basic_string::pop_back is missing. </p>
953 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
954 = npos) make no sense. First, it's const charT* in the synopsis and
955 charT* in the description. Second, given what it says in RETURNS,
956 leaving out the final argument will always result in an exception
957 getting thrown. This is paragraphs 5 and 6 of
958 21.3.6.8 [string::swap]</p>
960 <p>(6) In table 37, in section 21.1.1 [char.traits.require],
961 there's a note for X::move(s, p, n). It says "Copies correctly
962 even where p is in [s, s+n)". This is correct as far as it goes,
963 but it doesn't go far enough; it should also guarantee that the copy
964 is correct even where s in in [p, p+n). These are two orthogonal
965 guarantees, and neither one follows from the other. Both guarantees
966 are necessary if X::move is supposed to have the same sort of
967 semantics as memmove (which was clearly the intent), and both
968 guarantees are necessary if X::move is actually supposed to be
972 <p><b>Proposed resolution:</b></p>
973 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
975 EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
977 ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in
978 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
980 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
981 [lib.basic.string]) from:</p>
983 <p> void push_back(const charT)<br>
987 void push_back(charT)<br>
989 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
991 void basic_string::push_back(charT c);<br>
992 EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br>
994 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
996 ITEM 5: Duplicate; see issue 5 (and 87).<br>
998 ITEM 6: In table 37, Replace:<br>
1000 "Copies correctly even where p is in [s, s+n)."<br>
1004 "Copies correctly even where the ranges [p, p+n) and [s,
1012 <h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
1013 <p><b>Section:</b> 22.1.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1014 <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-24</p>
1015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1016 <p><b>Discussion:</b></p>
1017 <p>It appears there's an important guarantee missing from clause
1018 22. We're told that invoking locale::global(L) sets the C locale if L
1019 has a name. However, we're not told whether or not invoking
1020 setlocale(s) sets the global C++ locale. </p>
1022 <p>The intent, I think, is that it should not, but I can't find any
1023 such words anywhere. </p>
1026 <p><b>Proposed resolution:</b></p>
1027 <p>Add a sentence at the end of 22.1.1.5 [locale.statics],
1028 paragraph 2: </p>
1031 <p>No library function other than <tt>locale::global()</tt> shall affect
1032 the value returned by <tt>locale()</tt>. </p>
1041 <h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
1042 <p><b>Section:</b> 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1043 <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</p>
1044 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1045 <p><b>Discussion:</b></p>
1046 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
1047 section 3.7.3.1 of CD2 seems to allow for the possibility that all
1048 calls to operator new(0) yield the same pointer, an implementation
1049 technique specifically prohibited by ARM 5.3.3.Was this prohibition
1050 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
1051 list maintainer's note: the IS is the same.]</p>
1054 <p><b>Proposed resolution:</b></p>
1055 <p>Change the last paragraph of 3.7.3 from:</p>
1057 <p>Any allocation and/or deallocation functions defined in a C++ program shall
1058 conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
1062 <p>Any allocation and/or deallocation functions defined in a C++ program,
1063 including the default versions in the library, shall conform to the semantics
1064 specified in 3.7.3.1 and 3.7.3.2.</p>
1066 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
1068 <p>If the size of the space requested is zero, the value returned shall not be
1069 a null pointer value (4.10).</p>
1073 <p>Even if the size of the space requested is zero, the request can fail. If
1074 the request succeeds, the value returned shall be a non-null pointer value
1075 (4.10) p0 different from any previously returned value p1, unless that value
1076 p1 was since passed to an operator delete.</p>
1078 <p>5.3.4/7 currently reads:</p>
1080 <p>When the value of the expression in a direct-new-declarator is zero, the
1081 allocation function is called to allocate an array with no elements. The
1082 pointer returned by the new-expression is non-null. [Note: If the library
1083 allocation function is called, the pointer returned is distinct from the
1084 pointer to any other object.]</p>
1086 <p>Retain the first sentence, and delete the remainder.</p>
1087 <p>18.5.1 currently has no text. Add the following:</p>
1089 <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
1090 library versions of operator new and operator delete.</p>
1092 <p>To 18.5.1.3, add the following text:</p>
1094 <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
1095 operator new and operator delete.</p>
1099 <p><b>Rationale:</b></p>
1100 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
1101 supporting to the proposed resolution.</p>
1108 <h3><a name="11"></a>11. Bitset minor problems</h3>
1109 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1110 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
1111 <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>
1112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1113 <p><b>Discussion:</b></p>
1114 <p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
1115 not documented in 23.3.5.2. </p>
1117 <p>(2) The class synopsis only gives a single signature for bitset<>::operator[],
1118 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
1119 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
1121 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
1122 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
1123 go in the Effects clause.</p>
1126 <p><b>Proposed resolution:</b></p>
1127 <p>ITEMS 1 AND 2:<br>
1129 In the bitset synopsis (23.3.5 [template.bitset]),
1130 replace the member function <br>
1132 <tt> reference operator[](size_t pos);<br>
1134 with the two member functions<br>
1136 <tt> bool operator[](size_t pos) const; <br>
1137 reference operator[](size_t pos); <br>
1139 Add the following text at the end of 23.3.5.2 [bitset.members],
1140 immediately after paragraph 45:</p>
1143 <p><tt>bool operator[](size_t pos) const;</tt><br>
1144 Requires: pos is valid<br>
1146 Returns: <tt>test(pos)</tt><br>
1148 <tt>bitset<N>::reference operator[](size_t pos);</tt> <br>
1149 Requires: pos is valid<br>
1151 Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos]
1152 == this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos,
1157 <p><b>Rationale:</b></p>
1158 <p>The LWG believes Item 3 is not a defect. "Formatted
1159 input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
1167 <h3><a name="13"></a>13. Eos refuses to die</h3>
1168 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1169 <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p>
1170 <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>
1171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1172 <p><b>Discussion:</b></p>
1173 <p>In 27.6.1.2.3, there is a reference to "eos", which is
1174 the only one in the whole draft (at least using Acrobat search), so
1175 it's undefined. </p>
1178 <p><b>Proposed resolution:</b></p>
1179 <p>In 27.6.1.2.3 [istream::extractors], replace "eos" with
1187 <h3><a name="14"></a>14. Locale::combine should be const</h3>
1188 <p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1189 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1190 <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>
1191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1192 <p><b>Discussion:</b></p>
1193 <p>locale::combine is the only member function of locale (other than constructors and
1194 destructor) that is not const. There is no reason for it not to be const, and good reasons
1195 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
1196 paragraph 6: "An instance of a locale is immutable." </p>
1198 <p>History: this member function originally was a constructor. it happened that the
1199 interface it specified had no corresponding language syntax, so it was changed to a member
1200 function. As constructors are never const, there was no "const" in the interface
1201 which was transformed into member "combine". It should have been added at that
1202 time, but the omission was not noticed. </p>
1205 <p><b>Proposed resolution:</b></p>
1206 <p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add
1207 "const" to the declaration of member combine: </p>
1209 <pre>template <class Facet> locale combine(const locale& other) const; </pre>
1217 <h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
1218 <p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1219 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1220 <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>
1221 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1222 <p><b>Discussion:</b></p>
1223 <p>locale::name() is described as returning a string that can be passed to a locale
1224 constructor, but there is no matching constructor. </p>
1227 <p><b>Proposed resolution:</b></p>
1228 <p>In 22.1.1.3 [locale.members], paragraph 5, replace
1229 "<tt>locale(name())</tt>" with
1230 "<tt>locale(name().c_str())</tt>".
1238 <h3><a name="16"></a>16. Bad ctype_byname<char> decl</h3>
1239 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1240 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1241 <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>
1242 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1243 <p><b>Discussion:</b></p>
1244 <p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
1245 edited in properly. Instead, the member do_widen appears four times, with wrong argument
1249 <p><b>Proposed resolution:</b></p>
1250 <p>The correct declarations for the overloaded members
1251 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
1252 from 22.2.1.3 [facet.ctype.special].</p>
1259 <h3><a name="17"></a>17. Bad bool parsing</h3>
1260 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1261 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1262 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
1263 <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>
1264 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1265 <p><b>Discussion:</b></p>
1266 <p>This section describes the process of parsing a text boolean value from the input
1267 stream. It does not say it recognizes either of the sequences "true" or
1268 "false" and returns the corresponding bool value; instead, it says it recognizes
1269 only one of those sequences, and chooses which according to the received value of a
1270 reference argument intended for returning the result, and reports an error if the other
1271 sequence is found. (!) Furthermore, it claims to get the names from the ctype<>
1272 facet rather than the numpunct<> facet, and it examines the "boolalpha"
1273 flag wrongly; it doesn't define the value "loc"; and finally, it computes
1274 wrongly whether to use numeric or "alpha" parsing.<br>
1276 I believe the correct algorithm is "as if": </p>
1278 <pre> // in, err, val, and str are arguments.
1280 const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
1281 const string_type t = np.truename(), f = np.falsename();
1282 bool tm = true, fm = true;
1284 while (tm && pos < t.size() || fm && pos < f.size()) {
1285 if (in == end) { err = str.eofbit; }
1286 bool matched = false;
1287 if (tm && pos < t.size()) {
1288 if (!err && t[pos] == *in) matched = true;
1291 if (fm && pos < f.size()) {
1292 if (!err && f[pos] == *in) matched = true;
1295 if (matched) { ++in; ++pos; }
1296 if (pos > t.size()) tm = false;
1297 if (pos > f.size()) fm = false;
1299 if (tm == fm || pos == 0) { err |= str.failbit; }
1303 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
1304 when one is a substring of the other. The proposed text below captures the logic of the
1308 <p><b>Proposed resolution:</b></p>
1309 <p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
1310 change "&&" to "&".</p>
1312 <p>Then, replace paragraphs 15 and 16 as follows:</p>
1316 <p>Otherwise target sequences are determined "as if" by
1317 calling the members <tt>falsename()</tt> and
1318 <tt>truename()</tt> of the facet obtained by
1319 <tt>use_facet<numpunct<charT> >(str.getloc())</tt>.
1320 Successive characters in the range <tt>[in,end)</tt> (see
1321 [lib.sequence.reqmts]) are obtained and matched against
1322 corresponding positions in the target sequences only as necessary to
1323 identify a unique match. The input iterator <tt>in</tt> is
1324 compared to <tt>end</tt> only when necessary to obtain a
1325 character. If and only if a target sequence is uniquely matched,
1326 <tt>val</tt> is set to the corresponding value.</p>
1331 <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
1332 successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
1333 <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
1334 <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
1335 <tt>(str.failbit|str.eofbit)</tt>if
1336 the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
1337 <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
1338 <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
1339 <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
1341 and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
1342 and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
1343 <tt>err==str.failbit</tt>. --end example]</p>
1351 <h3><a name="18"></a>18. Get(...bool&) omitted</h3>
1352 <p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1353 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1354 <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>
1355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1356 <p><b>Discussion:</b></p>
1357 <p>In the list of num_get<> non-virtual members on page 22-23, the member
1358 that parses bool values was omitted from the list of definitions of non-virtual
1359 members, though it is listed in the class definition and the corresponding
1360 virtual is listed everywhere appropriate. </p>
1363 <p><b>Proposed resolution:</b></p>
1364 <p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
1365 another get member for bool&, copied from the entry in
1366 22.2.2.1 [locale.num.get].</p>
1373 <h3><a name="19"></a>19. "Noconv" definition too vague</h3>
1374 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1375 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1376 <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>
1377 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1378 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
1379 <p><b>Discussion:</b></p>
1381 In the definitions of codecvt<>::do_out and do_in, they are
1382 specified to return noconv if "no conversion is
1383 needed". This definition is too vague, and does not say
1384 normatively what is done with the buffers.
1388 <p><b>Proposed resolution:</b></p>
1390 Change the entry for noconv in the table under paragraph 4 in section
1391 22.2.1.4.2 [locale.codecvt.virtuals] to read:
1394 <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
1395 and input sequence is identical to converted sequence.</p>
1397 <p>Change the Note in paragraph 2 to normative text as follows:</p>
1399 <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
1400 same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
1401 <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
1402 unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
1410 <h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
1411 <p><b>Section:</b> 22.2.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1412 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1413 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1414 <p><b>Discussion:</b></p>
1415 <p>The synopsis for numpunct<>::do_thousands_sep, and the
1416 definition of numpunct<>::thousands_sep which calls it, specify
1417 that it returns a value of type char_type. Here it is erroneously
1418 described as returning a "string_type". </p>
1421 <p><b>Proposed resolution:</b></p>
1422 <p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
1423 "string_type" to "char_type". </p>
1430 <h3><a name="21"></a>21. Codecvt_byname<> instantiations</h3>
1431 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1432 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1433 <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>
1434 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1435 <p><b>Discussion:</b></p>
1436 <p>In the second table in the section, captioned "Required
1437 instantiations", the instantiations for codecvt_byname<>
1438 have been omitted. These are necessary to allow users to construct a
1439 locale by name from facets. </p>
1442 <p><b>Proposed resolution:</b></p>
1443 <p>Add in 22.1.1.1.1 [locale.category] to the table captioned
1444 "Required instantiations", in the category "ctype"
1448 <pre>codecvt_byname<char,char,mbstate_t>,
1449 codecvt_byname<wchar_t,char,mbstate_t> </pre>
1457 <h3><a name="22"></a>22. Member open vs. flags</h3>
1458 <p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1459 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1460 <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>
1461 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1462 <p><b>Discussion:</b></p>
1463 <p>The description of basic_istream<>::open leaves unanswered questions about how it
1464 responds to or changes flags in the error status for the stream. A strict reading
1465 indicates that it ignores the bits and does not change them, which confuses users who do
1466 not expect eofbit and failbit to remain set after a successful open. There are three
1467 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
1468 and eofbit on call to open(). </p>
1471 <p><b>Proposed resolution:</b></p>
1472 <p>In 27.8.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
1476 <p>A successful open does not change the error state.</p>
1480 <p><b>Rationale:</b></p>
1481 <p>This may seem surprising to some users, but it's just an instance
1482 of a general rule: error flags are never cleared by the
1483 implementation. The only way error flags are are ever cleared is if
1484 the user explicitly clears them by hand.</p>
1486 <p>The LWG believed that preserving this general rule was
1487 important enough so that an exception shouldn't be made just for this
1488 one case. The resolution of this issue clarifies what the LWG
1489 believes to have been the original intent.</p>
1497 <h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
1498 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1499 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1500 <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>
1501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1502 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
1503 <p><b>Discussion:</b></p>
1504 <p>The description of codecvt<>::do_out and do_in mentions a
1505 symbol "do_convert" which is not defined in the
1506 standard. This is a leftover from an edit, and should be "do_in
1510 <p><b>Proposed resolution:</b></p>
1511 <p>In 22.2.1.4 [locale.codecvt], paragraph 3, change
1512 "do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
1520 <h3><a name="25"></a>25. String operator<< uses width() value wrong</h3>
1521 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1522 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1523 <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>
1524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1525 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
1526 <p><b>Discussion:</b></p>
1527 <p>In the description of operator<< applied to strings, the standard says that uses
1528 the smaller of os.width() and str.size(), to pad "as described in stage 3"
1529 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
1532 <p><b>Proposed resolution:</b></p>
1533 <p>Change 21.3.8.9 [string.io] paragraph 4 from:<br>
1535 "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
1540 "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
1548 <h3><a name="26"></a>26. Bad sentry example</h3>
1549 <p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1550 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1551 <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>
1552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1553 <p><b>Discussion:</b></p>
1554 <p>In paragraph 6, the code in the example: </p>
1556 <pre> template <class charT, class traits = char_traits<charT> >
1557 basic_istream<charT,traits>::sentry(
1558 basic_istream<charT,traits>& is, bool noskipws = false) {
1561 typedef ctype<charT> ctype_type;
1562 const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
1563 while ((c = is.rdbuf()->snextc()) != traits::eof()) {
1564 if (ctype.is(ctype.space,c)==0) {
1565 is.rdbuf()->sputbackc (c);
1572 <p>fails to demonstrate correct use of the facilities described. In
1573 particular, it fails to use traits operators, and specifies incorrect
1574 semantics. (E.g. it specifies skipping over the first character in the
1575 sequence without examining it.) </p>
1578 <p><b>Proposed resolution:</b></p>
1579 <p>Remove the example above from 27.6.1.1.3 [istream::sentry]
1583 <p><b>Rationale:</b></p>
1584 <p>The originally proposed replacement code for the example was not
1585 correct. The LWG tried in Kona and again in Tokyo to correct it
1586 without success. In Tokyo, an implementor reported that actual working
1587 code ran over one page in length and was quite complicated. The LWG
1588 decided that it would be counter-productive to include such a lengthy
1589 example, which might well still contain errors.</p>
1596 <h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
1597 <p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1598 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1599 <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>
1600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1601 <p><b>Discussion:</b></p>
1602 <p>The string::erase(iterator first, iterator last) is specified to return an element one
1603 place beyond the next element after the last one erased. E.g. for the string
1604 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
1605 while 'd' has not been erased. </p>
1608 <p><b>Proposed resolution:</b></p>
1609 <p>In 21.3.6.5 [string::erase], paragraph 10, change: </p>
1612 <p>Returns: an iterator which points to the element immediately following _last_ prior to
1613 the element being erased. </p>
1619 <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
1620 other elements being erased. </p>
1628 <h3><a name="28"></a>28. Ctype<char>is ambiguous</h3>
1629 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1630 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1631 <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>
1632 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1633 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
1634 <p><b>Discussion:</b></p>
1635 <p>The description of the vector form of ctype<char>::is can be interpreted to mean
1636 something very different from what was intended. Paragraph 4 says </p>
1639 <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
1640 table()[(unsigned char)*p]. </p>
1643 <p>This is intended to copy the value indexed from table()[] into the place identified in
1647 <p><b>Proposed resolution:</b></p>
1648 <p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
1651 <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1652 the value table()[(unsigned char)*p]. </p>
1660 <h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
1661 <p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1662 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1663 <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>
1664 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1665 <p><b>Discussion:</b></p>
1666 <p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention
1667 a function ios_base::init, which is not defined. Probably they mean
1668 basic_ios<>::init, defined in 27.4.4.1 [basic.ios.cons],
1672 <p><b>Proposed resolution:</b></p>
1673 <p>[R12: modified to include paragraph 5.]</p>
1675 <p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
1678 <p>ios_base::init </p>
1684 <p>basic_ios<char>::init </p>
1687 <p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it
1691 <p>basic_ios<wchar_t>::init </p>
1699 <h3><a name="30"></a>30. Wrong header for LC_*</h3>
1700 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1701 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1702 <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>
1703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1704 <p><b>Discussion:</b></p>
1705 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
1706 where they are in fact defined elsewhere to appear in <clocale>. </p>
1709 <p><b>Proposed resolution:</b></p>
1710 <p>In 22.1.1.1.1 [locale.category], paragraph 2, change
1711 "<cctype>" to read "<clocale>". </p>
1718 <h3><a name="31"></a>31. Immutable locale values</h3>
1719 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1720 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1721 <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>
1722 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1723 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
1724 <p><b>Discussion:</b></p>
1725 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1726 <i>immutable</i>; once a facet reference is obtained from it,
1727 ...". This has caused some confusion, because locale variables
1728 are manifestly assignable. </p>
1731 <p><b>Proposed resolution:</b></p>
1732 <p>In 22.1.1 [locale] replace paragraph 6</p>
1735 <p>An instance of <tt>locale</tt> is immutable; once a facet
1736 reference is obtained from it, that reference remains usable as long
1737 as the locale value itself exists.</p>
1743 <p>Once a facet reference is obtained from a locale object by
1744 calling use_facet<>, that reference remains usable, and the
1745 results from member functions of it may be cached and re-used, as
1746 long as some locale object refers to that facet.</p>
1754 <h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
1755 <p><b>Section:</b> 27.5.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1756 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1758 <p><b>Discussion:</b></p>
1759 <p>The description of the required state before calling virtual member
1760 basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
1761 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1762 Specifically, the latter says it calls pbackfail if: </p>
1764 <p> traits::eq(c,gptr()[-1]) is false </p>
1766 <p>where pbackfail claims to require: </p>
1768 <p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1770 <p>It appears that the pbackfail description is wrong. </p>
1773 <p><b>Proposed resolution:</b></p>
1774 <p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
1777 <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1783 <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1788 <p><b>Rationale:</b></p>
1789 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1790 the argument value.</p>
1797 <h3><a name="33"></a>33. Codecvt<> mentions from_type</h3>
1798 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1799 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1800 <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>
1801 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1802 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
1803 <p><b>Discussion:</b></p>
1804 <p>In the table defining the results from do_out and do_in, the specification for the
1805 result <i>error</i> says </p>
1808 <p>encountered a from_type character it could not convert </p>
1811 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1812 an internT for do_out. </p>
1815 <p><b>Proposed resolution:</b></p>
1816 <p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
1817 in the table for the case of _error_ with </p>
1820 <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1828 <h3><a name="34"></a>34. True/falsename() not in ctype<></h3>
1829 <p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1830 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1831 <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>
1832 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1833 <p><b>Discussion:</b></p>
1834 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1835 ctype<charT>, but it has no such members. Note that this is also a problem in
1836 22.2.2.1.2, addressed in (4). </p>
1839 <p><b>Proposed resolution:</b></p>
1840 <p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
1841 clause for member put(...., bool), replace the initialization of the
1842 string_type value s as follows: </p>
1845 <pre>const numpunct& np = use_facet<numpunct<charT> >(loc);
1846 string_type s = val ? np.truename() : np.falsename(); </pre>
1854 <h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
1855 <p><b>Section:</b> 27.4 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1856 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1857 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1858 <p><b>Discussion:</b></p>
1859 <p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator
1860 named "unitbuf". Unlike other manipulators, it's not listed
1861 in synopsis. Similarly for "nounitbuf". </p>
1864 <p><b>Proposed resolution:</b></p>
1865 <p>Add to the synopsis for <ios> in 27.4 [iostreams.base], after
1866 the entry for "nouppercase", the prototypes: </p>
1869 <pre>ios_base& unitbuf(ios_base& str);
1870 ios_base& nounitbuf(ios_base& str); </pre>
1878 <h3><a name="36"></a>36. Iword & pword storage lifetime omitted</h3>
1879 <p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1880 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1881 <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>
1882 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1883 <p><b>Discussion:</b></p>
1884 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1885 specified badly, so that an implementation which only keeps the last value stored appears
1886 to conform. In particular, it says: </p>
1888 <p>The reference returned may become invalid after another call to the object's iword
1889 member with a different index ... </p>
1891 <p>This is not idle speculation; at least one implementation was done this way. </p>
1894 <p><b>Proposed resolution:</b></p>
1895 <p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in
1896 paragraph 4, replace the sentence: </p>
1899 <p>The reference returned may become invalid after another call to the object's iword
1900 [pword] member with a different index, after a call to its copyfmt member, or when the
1901 object is destroyed. </p>
1907 <p>The reference returned is invalid after any other operations on the object. However,
1908 the value of the storage referred to is retained, so that until the next call to copyfmt,
1909 calling iword [pword] with the same index yields another reference to the same value. </p>
1912 <p>substituting "iword" or "pword" as appropriate. </p>
1919 <h3><a name="37"></a>37. Leftover "global" reference</h3>
1920 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1921 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1922 <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>
1923 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1924 <p><b>Discussion:</b></p>
1925 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1928 <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1929 the standard exception bad_cast. </p>
1932 <p>This is not supported by the definition of use_facet<>, and represents semantics
1933 from an old draft. </p>
1936 <p><b>Proposed resolution:</b></p>
1937 <p>In 22.1.1 [locale], paragraph 4, delete the parenthesized
1941 <p>(or, failing that, in the global locale) </p>
1949 <h3><a name="38"></a>38. Facet definition incomplete</h3>
1950 <p><b>Section:</b> 22.1.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1951 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1952 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1953 <p><b>Discussion:</b></p>
1954 <p>It has been noticed by Esa Pulkkinen that the definition of
1955 "facet" is incomplete. In particular, a class derived from
1956 another facet, but which does not define a member <i>id</i>, cannot
1957 safely serve as the argument <i>F</i> to use_facet<F>(loc),
1958 because there is no guarantee that a reference to the facet instance
1959 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1962 <p><b>Proposed resolution:</b></p>
1963 <p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which
1967 <p>Get a reference to a facet of a locale. </p>
1973 <p>Requires: <tt>Facet</tt> is a facet class whose definition
1974 contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p>
1978 Kona: strike as overspecification the text "(not inherits)"
1979 from the original resolution, which read "... whose definition
1980 contains (not inherits) the public static member
1991 <h3><a name="39"></a>39. istreambuf_iterator<>::operator++(int) definition garbled</h3>
1992 <p><b>Section:</b> 24.5.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
1993 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
1994 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
1995 <p><b>Discussion:</b></p>
1996 <p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
1997 3, the standard contains three lines of garbage text left over from a previous edit. </p>
2000 <pre>istreambuf_iterator<charT,traits> tmp = *this;
2006 <p><b>Proposed resolution:</b></p>
2007 <p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
2008 end of paragraph 3. </p>
2015 <h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
2016 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2017 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
2018 <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>
2019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2020 <p><b>Discussion:</b></p>
2021 <p>Paragraph 3 of the locale examples is a description of part of an
2022 implementation technique that has lost its referent, and doesn't mean
2026 <p><b>Proposed resolution:</b></p>
2027 <p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This
2028 initialization/identification system depends...", or (at the
2029 editor's option) replace it with a place-holder to keep the paragraph
2030 numbering the same. </p>
2037 <h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
2038 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2039 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
2040 <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>
2041 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2042 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
2043 <p><b>Discussion:</b></p>
2044 <p>The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit,
2045 which may throw an exception". However, ios_base offers no
2046 interface to set or to test badbit; those interfaces are defined in
2047 basic_ios<>. </p>
2050 <p><b>Proposed resolution:</b></p>
2051 <p>Change the description in 27.4.2.5 [ios.base.storage] in
2052 paragraph 2, and also in paragraph 4, as follows. Replace</p>
2055 <p>If the function fails it sets badbit, which may throw an exception.</p>
2061 <p>If the function fails, and <tt>*this</tt> is a base sub-object of
2062 a <tt>basic_ios<></tt> object or sub-object, the effect is
2063 equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt>
2064 on the derived object (which may throw <tt>failure</tt>).</p>
2067 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
2068 setstate(badbit).]</i></p>
2077 <h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
2078 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2079 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
2080 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
2081 <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>
2082 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2083 <p><b>Discussion:</b></p>
2084 <p>The basic_string<> copy constructor: </p>
2086 <pre>basic_string(const basic_string& str, size_type pos = 0,
2087 size_type n = npos, const Allocator& a = Allocator()); </pre>
2089 <p>specifies an Allocator argument default value that is
2090 counter-intuitive. The natural choice for a the allocator to copy from
2091 is str.get_allocator(). Though this cannot be expressed in
2092 default-argument notation, overloading suffices. </p>
2094 <p>Alternatively, the other containers in Clause 23 (deque, list,
2095 vector) do not have this form of constructor, so it is inconsistent,
2096 and an evident source of confusion, for basic_string<> to have
2097 it, so it might better be removed. </p>
2100 <p><b>Proposed resolution:</b></p>
2101 <p> In 21.3 [basic.string], replace the declaration of the copy
2102 constructor as follows: </p>
2105 <pre>basic_string(const basic_string& str);
2106 basic_string(const basic_string& str, size_type pos, size_type n = npos,
2107 const Allocator& a = Allocator());</pre>
2110 <p>In 21.3.1 [string.require], replace the copy constructor declaration
2111 as above. Add to paragraph 5, Effects:</p>
2114 <p>In the first form, the Allocator value used is copied from
2115 <tt>str.get_allocator()</tt>.</p>
2119 <p><b>Rationale:</b></p>
2120 <p>The LWG believes the constructor is actually broken, rather than
2121 just an unfortunate design choice.</p>
2123 <p>The LWG considered two other possible resolutions:</p>
2125 <p>A. In 21.3 [basic.string], replace the declaration of the copy
2126 constructor as follows:</p>
2129 <pre>basic_string(const basic_string& str, size_type pos = 0,
2130 size_type n = npos);
2131 basic_string(const basic_string& str, size_type pos,
2132 size_type n, const Allocator& a); </pre>
2135 <p>In 21.3.1 [string.require], replace the copy constructor declaration
2136 as above. Add to paragraph 5, Effects: </p>
2139 <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
2140 value <tt>str.get_allocator()</tt>. </p>
2143 <p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace
2144 the declaration of the copy constructor as follows: </p>
2147 <pre>basic_string(const basic_string& str, size_type pos = 0,
2148 size_type n = npos); </pre>
2151 <p>The proposed resolution reflects the original intent of the LWG. It
2152 was also noted by Pete Becker that this fix "will cause
2153 a small amount of existing code to now work correctly."</p>
2156 Kona: issue editing snafu fixed - the proposed resolution now correctly
2157 reflects the LWG consensus.
2166 <h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
2167 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
2168 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
2169 <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>
2170 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
2171 <p><b>Discussion:</b></p>
2172 <p>Many of the specifications for iostreams specify that character
2173 values or their int_type equivalents are compared using operators ==
2174 or !=, though in other places traits::eq() or traits::eq_int_type is
2175 specified to be used throughout. This is an inconsistency; we should
2176 change uses of == and != to use the traits members instead. </p>
2179 <p><b>Proposed resolution:</b></p>
2181 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
2184 <p>List of changes to clause 27:</p>
2187 In lib.basic.ios.members paragraph 13 (postcondition clause for
2190 <blockquote><pre> fillch == fill()
2195 <blockquote><pre> traits::eq(fillch, fill())
2201 In lib.istream.unformatted paragraph 7 (effects clause for
2202 'get(cT,streamsize,cT)'), third bullet, change
2204 <blockquote><pre> c == delim for the next available input character c
2209 <blockquote><pre> traits::eq(c, delim) for the next available input character c
2214 In lib.istream.unformatted paragraph 12 (effects clause for
2215 'get(basic_streambuf<cT,Tr>&,cT)'), third bullet, change
2217 <blockquote><pre> c == delim for the next available input character c
2222 <blockquote><pre> traits::eq(c, delim) for the next available input character c
2227 In lib.istream.unformatted paragraph 17 (effects clause for
2228 'getline(cT,streamsize,cT)'), second bullet, change
2230 <blockquote><pre> c == delim for the next available input character c
2235 <blockquote><pre> traits::eq(c, delim) for the next available input character c
2240 In lib.istream.unformatted paragraph 24 (effects clause for
2241 'ignore(int,int_type)'), second bullet, change
2243 <blockquote><pre> c == delim for the next available input character c
2248 <blockquote><pre> traits::eq_int_type(c, delim) for the next available input
2254 In lib.istream.unformatted paragraph 25 (notes clause for
2255 'ignore(int,int_type)'), second bullet, change
2257 <blockquote><pre> The last condition will never occur if delim == traits::eof()
2262 <blockquote><pre> The last condition will never occur if
2263 traits::eq_int_type(delim, traits::eof()).
2268 In lib.istream.sentry paragraph 6 (example implementation for the
2269 sentry constructor) change
2271 <blockquote><pre> while ((c = is.rdbuf()->snextc()) != traits::eof()) {
2276 <blockquote><pre> while (!traits::eq_int_type(c = is.rdbuf()->snextc(), traits::eof())) {
2282 <p>List of changes to Chapter 21:</p>
2286 In lib.string::find paragraph 1 (effects clause for find()),
2287 second bullet, change
2289 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2294 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2299 In lib.string::rfind paragraph 1 (effects clause for rfind()),
2300 second bullet, change
2302 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2307 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2312 In lib.string::find.first.of paragraph 1 (effects clause for
2313 find_first_of()), second bullet, change
2315 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2320 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2325 In lib.string::find.last.of paragraph 1 (effects clause for
2326 find_last_of()), second bullet, change
2328 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2333 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2338 In lib.string::find.first.not.of paragraph 1 (effects clause for
2339 find_first_not_of()), second bullet, change
2341 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2346 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2351 In lib.string::find.last.not.of paragraph 1 (effects clause for
2352 find_last_not_of()), second bullet, change
2354 <blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
2359 <blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
2364 In lib.string.ios paragraph 5 (effects clause for getline()),
2365 second bullet, change
2367 <blockquote><pre> c == delim for the next available input character c
2372 <blockquote><pre> traits::eq(c, delim) for the next available input character c
2381 Fixing this issue highlights another sloppyness in
2382 lib.istream.unformatted paragraph 24: this clause mentions a "character"
2383 which is then compared to an 'int_type' (see item 5. in the list
2384 below). It is not clear whether this requires explicit words and
2385 if so what these words are supposed to be. A similar issue exists,
2386 BTW, for operator*() of istreambuf_iterator which returns the result
2387 of sgetc() as a character type (see lib.istreambuf.iterator::op*
2388 paragraph 1), and for operator++() of istreambuf_iterator which
2389 passes the result of sbumpc() to a constructor taking a char_type
2390 (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
2391 assignment operator ostreambuf_iterator passes a char_type to a function
2392 taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
2395 It is inconsistent to use comparisons using the traits functions in
2396 Chapter 27 while not using them in Chapter 21, especially as some
2397 of the inconsistent uses actually involve streams (eg. getline() on
2398 streams). To avoid leaving this issue open still longer due to this
2399 inconsistency (it is open since 1998), a list of changes to Chapter
2403 In Chapter 24 there are several places with statements like "the end
2404 of stream is reached (streambuf_type::sgetc() returns traits::eof())"
2405 (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
2406 paragraph 5). It is unclear whether these should be clarified to use
2407 traits::eq_int_type() for detecting traits::eof().
2417 <h3><a name="46"></a>46. Minor Annex D errors</h3>
2418 <p><b>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2419 <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
2420 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2421 <p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
2423 <p><b>Proposed resolution:</b></p>
2424 <p>Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of
2425 basic_streambuf<char>) from:</p>
2427 <pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
2431 <pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
2433 <p>In D.7.4 [depr.strstream] insert the semicolon now missing after
2436 <pre> namespace std {
2438 : public basic_iostream<char> {
2441 typedef char char_type;
2442 typedef typename char_traits<char>::int_type int_type
2443 typedef typename char_traits<char>::pos_type pos_type;</pre>
2450 <h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
2451 <p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2452 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2453 <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>
2454 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2455 <p><b>Discussion:</b></p>
2456 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
2457 section has two RETURNS clauses, and they make no sense as
2458 stated. They make perfect sense, though, if you swap them. Am I
2459 correct in thinking that paragraphs 2 and 4 just got mixed up by
2463 <p><b>Proposed resolution:</b></p>
2464 <p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
2471 <h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
2472 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2473 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2474 <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>
2475 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2476 <p><b>Discussion:</b></p>
2477 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
2478 base class, exception, with exception(msg). Class exception (see
2479 18.6.1) has no such constructor.</p>
2482 <p><b>Proposed resolution:</b></p>
2483 <p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p>
2486 <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
2494 <h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
2495 <p><b>Section:</b> 27.4.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
2496 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2497 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
2498 <p><b>Discussion:</b></p>
2501 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
2502 returns. Does it return f, or does it return the previous
2503 synchronization state? My guess is the latter, but the standard
2506 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
2507 synchronized with stdio. Again, of course, I can make some
2508 guesses. (And I'm unhappy about the performance implications of those
2509 guesses, but that's another matter.)</p>
2512 <p><b>Proposed resolution:</b></p>
2513 <p>Change the following sentence in 27.4.2.4 [ios.members.static]
2514 returns clause from:</p>
2517 <p><tt>true</tt> if the standard iostream objects (27.3) are
2518 synchronized and otherwise returns <tt>false</tt>.</p>
2524 <p><tt>true</tt> if the previous state of the standard iostream
2525 objects (27.3) was synchronized and otherwise returns
2529 <p>Add the following immediately after 27.4.2.4 [ios.members.static],
2533 <p>When a standard iostream object str is <i>synchronized</i> with a
2534 standard stdio stream f, the effect of inserting a character c by</p>
2538 <p>is the same as the effect of</p>
2539 <pre> str.rdbuf()->sputc(c);
2542 <p>for any sequence of characters; the effect of extracting a
2547 <p>is the same as the effect of:</p>
2548 <pre> c = str.rdbuf()->sbumpc(c);
2551 <p>for any sequences of characters; and the effect of pushing
2552 back a character c by</p>
2556 <p>is the same as the effect of</p>
2557 <pre> str.rdbuf()->sputbackc(c);
2560 <p>for any sequence of characters. [<i>Footnote</i>: This implies
2561 that operations on a standard iostream object can be mixed arbitrarily
2562 with operations on the corresponding stdio stream. In practical
2563 terms, synchronization usually means that a standard iostream object
2564 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
2567 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
2568 of "synchronization"]</i></p>
2571 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
2572 text was added in the non-normative footnote to say that operations
2573 on the two streams can be mixed arbitrarily.]</i></p>
2581 <h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
2582 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2583 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
2584 <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>
2585 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2586 <p><b>Discussion:</b></p>
2587 <p>As written, ios_base has a copy constructor and an assignment
2588 operator. (Nothing in the standard says it doesn't have one, and all
2589 classes have copy constructors and assignment operators unless you
2590 take specific steps to avoid them.) However, nothing in 27.4.2 says
2591 what the copy constructor and assignment operator do. </p>
2593 <p>My guess is that this was an oversight, that ios_base is, like
2594 basic_ios, not supposed to have a copy constructor or an assignment
2598 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
2599 sense to what you're suggesting. At one point there was a definite
2600 intention that you could copy ios_base. It's an easy way to save the
2601 entire state of a stream for future use. As you note, to carry out
2602 that intention would have required a explicit description of the
2603 semantics (e.g. what happens to the iarray and parray stuff).
2607 <p><b>Proposed resolution:</b></p>
2608 <p>In 27.4.2 [ios.base], class ios_base, specify the copy
2609 constructor and operator= members as being private.</p>
2612 <p><b>Rationale:</b></p>
2613 <p>The LWG believes the difficulty of specifying correct semantics
2614 outweighs any benefit of allowing ios_base objects to be copyable.</p>
2621 <h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
2622 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2623 <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</p>
2624 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
2625 <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>
2626 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2627 <p><b>Discussion:</b></p>
2628 <p>The std::sort algorithm can in general only sort a given sequence
2629 by moving around values. The list<>::sort() member on the other
2630 hand could move around values or just update internal pointers. Either
2631 method can leave iterators into the list<> dereferencable, but
2632 they would point to different things. </p>
2634 <p>Does the FDIS mandate anywhere which method should be used for
2635 list<>::sort()?</p>
2637 <p>Matt Austern comments:</p>
2639 <p>I think you've found an omission in the standard. </p>
2641 <p>The library working group discussed this point, and there was
2642 supposed to be a general requirement saying that list, set, map,
2643 multiset, and multimap may not invalidate iterators, or change the
2644 values that iterators point to, except when an operation does it
2645 explicitly. So, for example, insert() doesn't invalidate any iterators
2646 and erase() and remove() only invalidate iterators pointing to the
2647 elements that are being erased. </p>
2649 <p>I looked for that general requirement in the FDIS, and, while I
2650 found a limited form of it for the sorted associative containers, I
2651 didn't find it for list. It looks like it just got omitted. </p>
2653 <p>The intention, though, is that list<>::sort does not
2654 invalidate any iterators and does not change the values that any
2655 iterator points to. There would be no reason to have the member
2656 function otherwise.</p>
2659 <p><b>Proposed resolution:</b></p>
2660 <p>Add a new paragraph at the end of 23.1:</p>
2663 <p>Unless otherwise specified (either explicitly or by defining a function in terms of
2664 other functions), invoking a container member function or passing a container as an
2665 argument to a library function shall not invalidate iterators to, or change the values of,
2666 objects within that container. </p>
2670 <p><b>Rationale:</b></p>
2671 <p>This was US issue CD2-23-011; it was accepted in London but the
2672 change was not made due to an editing oversight. The wording in the
2673 proposed resolution below is somewhat updated from CD2-23-011,
2674 particularly the addition of the phrase "or change the values
2682 <h3><a name="52"></a>52. Small I/O problems</h3>
2683 <p><b>Section:</b> 27.4.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2684 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2686 <p><b>Discussion:</b></p>
2687 <p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious:
2688 it should be titled "basic_ios<>() effects", not
2689 "ios_base() effects". </p>
2691 <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
2694 <p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple
2695 different things wrong with it, some of which I've already discussed
2696 with Jerry, but the most obvious mechanical sort of error is that it
2697 uses expressions like P(i) and p(i), without ever defining what sort
2701 <p>(The other problem is that it requires support for streampos
2702 arithmetic. This is impossible on some systems, i.e. ones where file
2703 position is a complicated structure rather than just a number. Jerry
2704 tells me that the intention was to require syntactic support for
2705 streampos arithmetic, but that it wasn't actually supposed to do
2706 anything meaningful except on platforms, like Unix, where genuine
2707 arithmetic is possible.) </p>
2710 <p><b>Proposed resolution:</b></p>
2711 <p>Change 27.4.4.1 [basic.ios.cons] table 89 title from
2712 "ios_base() effects" to "basic_ios<>()
2720 <h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
2721 <p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2722 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
2723 <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>
2724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2725 <p><b>Discussion:</b></p>
2726 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
2727 The important question is whether basic_ios::~basic_ios() destroys
2731 <p><b>Proposed resolution:</b></p>
2732 <p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p>
2735 <p><tt>virtual ~basic_ios();</tt></p>
2736 <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
2740 <p><b>Rationale:</b></p>
2741 <p>The LWG reviewed the additional question of whether or not
2742 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
2743 clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length
2744 by the LWG, which removed from the original proposed resolution a
2745 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
2746 <tt>badbit</tt>".</p>
2753 <h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
2754 <p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2755 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-25</p>
2756 <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>
2757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2758 <p><b>Discussion:</b></p>
2759 <p>The class synopsis for basic_streambuf shows a (virtual)
2760 destructor, but the standard doesn't say what that destructor does. My
2761 assumption is that it does nothing, but the standard should say so
2765 <p><b>Proposed resolution:</b></p>
2766 <p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p>
2769 <p><tt>virtual ~basic_streambuf();</tt></p>
2770 <p><b>Effects</b>: None.</p>
2778 <h3><a name="55"></a>55. Invalid stream position is undefined</h3>
2779 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2780 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-26</p>
2781 <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>
2782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2783 <p><b>Discussion:</b></p>
2784 <p>Several member functions in clause 27 are defined in certain
2785 circumstances to return an "invalid stream position", a term
2786 that is defined nowhere in the standard. Two places (27.5.2.4.2,
2787 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
2788 a definition in _lib.iostreams.definitions_, a nonexistent
2791 <p>I suspect that the invalid stream position is just supposed to be
2792 pos_type(-1). Probably best to say explicitly in (for example)
2793 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
2794 the term "invalid stream position", define that term
2795 somewhere, and then put in a cross-reference. </p>
2797 <p>The phrase "invalid stream position" appears ten times in
2798 the C++ Standard. In seven places it refers to a return value, and it
2799 should be changed. In three places it refers to an argument, and it
2800 should not be changed. Here are the three places where "invalid
2801 stream position" should not be changed:</p>
2804 <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br>
2805 27.8.1.5 [filebuf.virtuals], paragraph 14<br>
2806 D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17
2811 <p><b>Proposed resolution:</b></p>
2812 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
2813 object of class pos_type that stores an invalid stream position
2814 (_lib.iostreams.definitions_)" to "Returns
2815 <tt>pos_type(off_type(-1))</tt>".
2818 <p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
2819 an object of class pos_type that stores an invalid stream
2820 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
2822 <p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object
2823 stores an invalid stream position" to "the return value is
2824 <tt>pos_type(off_type(-1))</tt>". </p>
2826 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an
2827 invalid stream position (27.4.3)" to "returns
2828 <tt>pos_type(off_type(-1))</tt>" </p>
2830 <p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
2831 returns an invalid stream position (_lib.iostreams.definitions_)"
2832 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
2835 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
2836 stores an invalid stream position" to "the return value is
2837 <tt>pos_type(off_type(-1))</tt>" </p>
2839 <p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
2840 stores an invalid stream position" to "the return value is
2841 <tt>pos_type(off_type(-1))</tt>"</p>
2848 <h3><a name="56"></a>56. Showmanyc's return type</h3>
2849 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2850 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</p>
2851 <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>
2852 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2853 <p><b>Discussion:</b></p>
2854 <p>The class summary for basic_streambuf<>, in 27.5.2, says that
2855 showmanyc has return type int. However, 27.5.2.4.3 says that its
2856 return type is streamsize. </p>
2859 <p><b>Proposed resolution:</b></p>
2860 <p>Change <tt>showmanyc</tt>'s return type in the
2861 27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
2868 <h3><a name="57"></a>57. Mistake in char_traits</h3>
2869 <p><b>Section:</b> 21.1.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2870 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
2871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2872 <p><b>Discussion:</b></p>
2873 <p>21.1.3.2, paragraph 3, says "The types streampos and
2874 wstreampos may be different if the implementation supports no shift
2875 encoding in narrow-oriented iostreams but supports one or more shift
2876 encodings in wide-oriented streams". </p>
2878 <p>That's wrong: the two are the same type. The <iosfwd> summary
2879 in 27.2 says that streampos and wstreampos are, respectively, synonyms
2880 for fpos<char_traits<char>::state_type> and
2881 fpos<char_traits<wchar_t>::state_type>, and, flipping back
2882 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
2883 char_traits<char>::state_type and
2884 char_traits<wchar_t>::state_type must both be mbstate_t. </p>
2887 <p><b>Proposed resolution:</b></p>
2888 <p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
2889 begins "The types streampos and wstreampos may be
2890 different..." . </p>
2897 <h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
2898 <p><b>Section:</b> 27.5.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2899 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-28</p>
2900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2901 <p><b>Discussion:</b></p>
2902 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
2903 next pointer for the input sequence by n." </p>
2905 <p>The straightforward interpretation is that it is just gptr() +=
2906 n. An alternative interpretation, though, is that it behaves as if it
2907 calls sbumpc n times. (The issue, of course, is whether it might ever
2908 call underflow.) There is a similar ambiguity in the case of
2911 <p>(The "classic" AT&T implementation used the
2912 former interpretation.)</p>
2915 <p><b>Proposed resolution:</b></p>
2916 <p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
2919 <p>Effects: Advances the next pointer for the input sequence by n.</p>
2925 <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
2928 <p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump
2936 <h3><a name="60"></a>60. What is a formatted input function?</h3>
2937 <p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
2938 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-03</p>
2939 <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>
2940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
2941 <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>
2942 <p><b>Discussion:</b></p>
2943 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
2944 formatted input functions. Some of the functions defined in section
2945 27.6.1.2 explicitly say that those requirements apply ("Behaves
2946 like a formatted input member (as described in 27.6.1.2.1)"), but
2947 others don't. The question: is 27.6.1.2.1 supposed to apply to
2948 everything in 27.6.1.2, or only to those member functions that
2949 explicitly say "behaves like a formatted input member"? Or
2950 to put it differently: are we to assume that everything that appears
2951 in a section called "Formatted input functions" really is a
2952 formatted input function? I assume that 27.6.1.2.1 is intended to
2953 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
2954 is not intended to apply to extractors like </p>
2956 <pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre>
2960 <pre> basic_istream& operator>>(basic_streammbuf*);</pre>
2962 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
2965 <p>Comments from Judy Ward: It seems like the problem is that the
2966 basic_istream and basic_ostream operator <<()'s that are used
2967 for the manipulators and streambuf* are in the wrong section and
2968 should have their own separate section or be modified to make it clear
2969 that the "Common requirements" listed in section 27.6.1.2.1
2970 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
2973 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
2974 nonsensical to consider the functions defined in 27.6.1.2.3
2975 [istream::extractors] paragraphs 1 to 5 to be "Formatted input
2976 function" but since these functions are defined in a section
2977 labeled "Formatted input functions" it is unclear to me
2978 whether these operators are considered formatted input functions which
2979 have to conform to the "common requirements" from 27.6.1.2.1
2980 [istream.formatted.reqmts]: If this is the case, all manipulators, not
2981 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2982 set (... but setting <tt>noskipws</tt> using the manipulator syntax
2983 would also skip whitespace :-)</p> <p>It is not clear which functions
2984 are to be considered unformatted input functions. As written, it seems
2985 that all functions in 27.6.1.3 [istream.unformatted] are unformatted input
2986 functions. However, it does not really make much sense to construct a
2987 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2988 unclear what happens to the <tt>gcount()</tt> if
2989 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2990 <tt>sync()</tt> is called: These functions don't extract characters,
2991 some of them even "unextract" a character. Should this still
2992 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2993 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2994 (the last unformatted input function, <tt>gcount()</tt>, didn't
2995 extract any character) and after a call to <tt>putback()</tt>
2996 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2997 function <tt>putback()</tt> did "extract" back into the
2998 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2999 intended? If so, this should be clarified. Otherwise, a corresponding
3000 clarification should be used.</p>
3003 <p><b>Proposed resolution:</b></p>
3005 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
3006 Change the beginning of the second sentence from "The conversion
3007 occurs" to "These extractors behave as formatted input functions (as
3008 described in 27.6.1.2.1). After a sentry object is constructed,
3009 the conversion occurs"
3013 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
3014 Add an effects clause. "Effects: None. This extractor does
3015 not behave as a formatted input function (as described in
3020 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
3021 effects clause to "Effects: Calls pf(*this). This extractor does not
3022 behave as a formatted input function (as described in 27.6.1.2.1).
3026 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
3027 effects clause to "Effects: Calls pf(*this). This extractor does not
3028 behave as a formatted input function (as described in 27.6.1.2.1).
3032 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
3033 first two sentences from "If sb is null, calls setstate(failbit),
3034 which may throw ios_base::failure (27.4.4.3). Extracts characters
3035 from *this..." to "Behaves as a formatted input function (as described
3036 in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
3037 throw ios_base::failure (27.4.4.3). After a sentry object is
3038 constructed, extracts characters from *this...".
3042 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
3043 effects clause. "Effects: none. This member function does not behave
3044 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
3048 In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
3049 beginning of the first sentence of the effects clause from "Extracts a
3050 character" to "Behaves as an unformatted input function (as described
3051 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
3056 In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
3057 beginning of the first sentence of the effects clause from "Extracts a
3058 character" to "Behaves as an unformatted input function (as described
3059 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
3064 In 27.6.1.3, [lib.istream.unformatted], paragraph 7. Change the
3065 beginning of the first sentence of the effects clause from "Extracts
3066 characters" to "Behaves as an unformatted input function (as described
3067 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
3072 [No change needed in paragraph 10, because it refers to paragraph 7.]
3076 In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
3077 beginning of the first sentence of the effects clause from "Extracts
3078 characters" to "Behaves as an unformatted input function (as described
3079 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
3084 [No change needed in paragraph 15.]
3088 In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
3089 beginning of the first sentence of the effects clause from "Extracts
3090 characters" to "Behaves as an unformatted input function (as described
3091 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
3096 [No change needed in paragraph 23.]
3100 In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
3101 beginning of the first sentence of the effects clause from "Extracts
3102 characters" to "Behaves as an unformatted input function (as described
3103 in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
3108 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
3109 Effects clause: "Effects: Behaves as an unformatted input function (as
3110 described in 27.6.1.3, paragraph 1). After constructing a sentry
3111 object, reads but does not extract the current input character."
3115 In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
3116 first sentence of the Effects clause from "If !good() calls" to
3117 Behaves as an unformatted input function (as described in 27.6.1.3,
3118 paragraph 1). After constructing a sentry object, if !good() calls"
3122 In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
3123 first sentence of the Effects clause from "If !good() calls" to
3124 "Behaves as an unformatted input function (as described in 27.6.1.3,
3125 paragraph 1). After constructing a sentry object, if !good() calls"
3129 In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
3130 first sentence of the Effects clause from "If !good() calls..." to
3131 "Behaves as an unformatted input function (as described in 27.6.1.3,
3132 paragraph 1). After constructing a sentry object, if !good()
3133 calls..." Add a new sentence to the end of the Effects clause:
3134 "[Note: this function extracts no characters, so the value returned
3135 by the next call to gcount() is 0.]"
3139 In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
3140 first sentence of the Effects clause from "If !good() calls" to
3141 "Behaves as an unformatted input function (as described in 27.6.1.3,
3142 paragraph 1). After constructing a sentry object, if !good() calls".
3143 Add a new sentence to the end of the Effects clause: "[Note: this
3144 function extracts no characters, so the value returned by the next
3145 call to gcount() is 0.]"
3149 In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
3150 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
3151 as an unformatted input function (as described in 27.6.1.3, paragraph
3152 1), except that it does not count the number of characters extracted
3153 and does not affect the value returned by subsequent calls to
3154 gcount(). After constructing a sentry object, if rdbuf() is"
3158 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
3159 Effects clause: "Effects: Behaves as an unformatted input function (as
3160 described in 27.6.1.3, paragraph 1), except that it does not count the
3161 number of characters extracted and does not affect the value returned
3162 by subsequent calls to gcount()." Change the first sentence of
3163 paragraph 37 from "if fail()" to "after constructing a sentry object,
3168 In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
3169 first sentence of the Effects clause from "If fail()" to "Behaves
3170 as an unformatted input function (as described in 27.6.1.3, paragraph
3171 1), except that it does not count the number of characters extracted
3172 and does not affect the value returned by subsequent calls to
3173 gcount(). After constructing a sentry object, if fail()
3177 In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
3178 first sentence of the Effects clause from "If fail()" to "Behaves
3179 as an unformatted input function (as described in 27.6.1.3, paragraph
3180 1), except that it does not count the number of characters extracted
3181 and does not affect the value returned by subsequent calls to
3182 gcount(). After constructing a sentry object, if fail()
3186 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
3187 the beginning of the third sentence from "The formatting conversion"
3188 to "These extractors behave as formatted output functions (as
3189 described in 27.6.2.5.1). After the sentry object is constructed, the
3194 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
3195 effects clause: "Effects: None. Does not behave as a formatted output
3196 function (as described in 27.6.2.5.1).".
3200 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
3201 effects clause to "Effects: calls pf(*this). This extractor does not
3202 behave as a formatted output function (as described in 27.6.2.5.1).".
3206 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
3207 effects clause to "Effects: calls pf(*this). This extractor does not
3208 behave as a formatted output function (as described in 27.6.2.5.1).".
3212 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
3213 sentence from "If sb" to "Behaves as a formatted output function (as
3214 described in 27.6.2.5.1). After the sentry object is constructed, if
3219 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
3220 sentence from "Inserts the character" to "Behaves as an unformatted
3221 output function (as described in 27.6.2.6, paragraph 1). After
3222 constructing a sentry object, inserts the character".
3226 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
3227 sentence from "Obtains characters" to "Behaves as an unformatted
3228 output function (as described in 27.6.2.6, paragraph 1). After
3229 constructing a sentry object, obtains characters".
3233 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
3234 sentence at the end of the paragraph: "Does not behave as an
3235 unformatted output function (as described in 27.6.2.6, paragraph 1)."
3239 <p><b>Rationale:</b></p>
3240 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
3241 by Judy Ward and Matt Austern. This proposed resolution is section
3242 VI of that paper.</p>
3249 <h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
3250 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3251 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3252 <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>
3253 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3254 <p><b>Discussion:</b></p>
3255 <p>The introduction to the section on unformatted input (27.6.1.3)
3256 says that every unformatted input function catches all exceptions that
3257 were thrown during input, sets badbit, and then conditionally rethrows
3258 the exception. That seems clear enough. Several of the specific
3259 functions, however, such as get() and read(), are documented in some
3260 circumstances as setting eofbit and/or failbit. (The standard notes,
3261 correctly, that setting eofbit or failbit can sometimes result in an
3262 exception being thrown.) The question: if one of these functions
3263 throws an exception triggered by setting failbit, is this an exception
3264 "thrown during input" and hence covered by 27.6.1.3, or does
3265 27.6.1.3 only refer to a limited class of exceptions? Just to make
3266 this concrete, suppose you have the following snippet. </p>
3272 is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
3273 is.read(buffer, N);</pre>
3275 <p>Now suppose we reach EOF before we've read N characters. What
3276 iostate bits can we expect to be set, and what exception (if any) will
3280 <p><b>Proposed resolution:</b></p>
3282 In 27.6.1.3, paragraph 1, after the sentence that begins
3283 "If an exception is thrown...", add the following
3284 parenthetical comment: "(Exceptions thrown from
3285 <tt>basic_ios<>::clear()</tt> are not caught or rethrown.)"
3289 <p><b>Rationale:</b></p>
3290 <p>The LWG looked to two alternative wordings, and choose the proposed
3291 resolution as better standardese.</p>
3298 <h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
3299 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3300 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
3301 <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>
3302 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3303 <p><b>Discussion:</b></p>
3304 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
3305 "calls rdbuf()->pubsync() and, if that function returns -1
3306 ... returns traits::eof()." </p>
3308 <p>That looks suspicious, because traits::eof() is of type
3309 traits::int_type while the return type of sync() is int. </p>
3312 <p><b>Proposed resolution:</b></p>
3313 <p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns
3314 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
3322 <h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
3323 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3324 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3325 <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>
3326 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3327 <p><b>Discussion:</b></p>
3328 <p>Clause 27 details an exception-handling policy for formatted input,
3329 unformatted input, and formatted output. It says nothing for
3330 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
3331 kind of exception-handling policy as in the other three places, or
3332 else it should have a footnote saying that the omission is
3336 <p><b>Proposed resolution:</b></p>
3338 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
3339 case, the unformatted output function ends by destroying the sentry
3340 object, then returning the value specified for the formatted output
3341 function.") with the following text:
3344 If an exception is thrown during output, then <tt>ios::badbit</tt> is
3345 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
3346 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &
3347 badbit) != 0</tt> then the exception is rethrown. In any case, the
3348 unformatted output function ends by destroying the sentry object,
3349 then, if no exception was thrown, returning the value specified for
3350 the formatted output function.
3354 <p><b>Rationale:</b></p>
3356 This exception-handling policy is consistent with that of formatted
3357 input, unformatted input, and formatted output.
3365 <h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt></h3>
3366 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3367 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
3368 <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>
3369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3370 <p><b>Discussion:</b></p>
3371 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
3372 different ways, depending on whether the second sentence is read as an
3373 elaboration of the first. </p>
3376 <p><b>Proposed resolution:</b></p>
3377 <p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins
3378 "If the function inserts no characters ..." with:</p>
3381 <p>If the function inserts no characters, it calls
3382 <tt>setstate(failbit)</tt>, which may throw
3383 <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
3384 because it caught an exception thrown while extracting characters
3385 from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
3386 (27.4.4.3), then the caught exception is rethrown. </p>
3394 <h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
3395 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3396 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
3397 <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>
3398 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3399 <p><b>Discussion:</b></p>
3400 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
3401 "Performs an operation that is defined separately for each class
3402 derived from strstreambuf". This is obviously an incorrect
3403 cut-and-paste from basic_streambuf. There are no classes derived from
3407 <p><b>Proposed resolution:</b></p>
3408 <p>D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
3409 clause which currently says "Performs an operation that is
3410 defined separately for each class derived from strstreambuf"
3414 <p><b>Effects</b>: implementation defined, except that
3415 <tt>setbuf(0,0)</tt> has no effect.</p>
3423 <h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
3424 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3425 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p>
3426 <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>
3427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3428 <p><b>Discussion:</b></p>
3429 <p>Extractors for char* (27.6.1.2.3) do not store a null character
3430 after the extracted character sequence whereas the unformatted
3431 functions like get() do. Why is this?</p>
3433 <p>Comment from Jerry Schwarz: There is apparently an editing
3434 glitch. You'll notice that the last item of the list of what stops
3435 extraction doesn't make any sense. It was supposed to be the line that
3436 said a null is stored.</p>
3439 <p><b>Proposed resolution:</b></p>
3440 <p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list
3444 A null byte (<tt>charT()</tt>) in the next position, which may be
3445 the first position if no characters were extracted.
3448 <p>to become a new paragraph which reads:</p>
3451 Operator>> then stores a null byte (<tt>charT()</tt>) in the
3452 next position, which may be the first position if no characters were
3461 <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
3462 <p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3463 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
3464 <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>
3465 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3466 <p><b>Discussion:</b></p>
3467 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
3469 <p>(Please note that this is entirely separate from the question of
3470 whether a vector iterator is required to be a pointer; the answer to
3471 that question is clearly "no," as it would rule out
3472 debugging implementations)</p>
3475 <p><b>Proposed resolution:</b></p>
3476 <p>Add the following text to the end of 23.2.6 [vector],
3480 <p>The elements of a vector are stored contiguously, meaning that if
3481 v is a <tt>vector<T, Allocator></tt> where T is some type
3482 other than <tt>bool</tt>, then it obeys the identity <tt>&v[n]
3483 == &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p>
3487 <p><b>Rationale:</b></p>
3488 <p>The LWG feels that as a practical matter the answer is clearly
3489 "yes". There was considerable discussion as to the best way
3490 to express the concept of "contiguous", which is not
3491 directly defined in the standard. Discussion included:</p>
3494 <li>An operational definition similar to the above proposed resolution is
3495 already used for valarray (26.5.2.3 [valarray.access]).</li>
3496 <li>There is no need to explicitly consider a user-defined operator&
3497 because elements must be copyconstructible (23.1 [container.requirements] para 3)
3498 and copyconstructible (20.1.1 [utility.arg.requirements]) specifies
3499 requirements for operator&.</li>
3500 <li>There is no issue of one-past-the-end because of language rules.</li>
3508 <h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
3509 <p><b>Section:</b> 18.7 [support.exception], 18.7.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3510 <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p>
3511 <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>
3512 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3513 <p><b>Discussion:</b></p>
3514 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
3516 <p>uncaught_exception() doesn't have a throw specification.</p>
3518 <p>It is intentional ? Does it means that one should be prepared to
3519 handle exceptions thrown from uncaught_exception() ?</p>
3521 <p>uncaught_exception() is called in exception handling contexts where
3522 exception safety is very important.</p>
3525 <p><b>Proposed resolution:</b></p>
3526 <p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception],
3527 and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p>
3533 <h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
3534 <p><b>Section:</b> 22.2.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3535 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</p>
3536 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3537 <p><b>Discussion:</b></p>
3538 <p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
3539 is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments,
3540 consistent with do_get_weekday and with its specified use by member
3541 get_monthname. However, in the synopsis, it is specified instead with
3542 four arguments. The missing argument is the "end" iterator
3546 <p><b>Proposed resolution:</b></p>
3547 <p>In 22.2.5.1 [locale.time.get], add an "end" argument to
3548 the declaration of member do_monthname as follows:</p>
3550 <pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
3551 ios_base::iostate& err, tm* t) const;</pre>
3557 <h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
3558 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3559 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-08</p>
3560 <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>
3561 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3562 <p><b>Discussion:</b></p>
3563 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
3564 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
3565 parentheses and a spurious <b>n</b>.</p>
3568 <p><b>Proposed resolution:</b></p>
3569 <p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
3573 <b>Returns</b>: The maximum value that
3574 <tt>do_length(state, from, from_end, 1)</tt> can return for any
3575 valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
3576 <tt>state</tt>. The specialization <tt>codecvt<char, char,
3577 mbstate_t>::do_max_length()</tt> returns 1.
3584 <h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
3585 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3586 <b>Submitter:</b> Matt
3587 Austern <b>Date:</b> 1998-09-18</p>
3588 <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>
3589 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3590 <p><b>Discussion:</b></p>
3591 <p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
3592 and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
3593 parameter of the member functions <tt>length</tt> and
3594 <tt>do_length</tt> is of type <tt>const stateT&</tt>. The member
3595 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
3596 paragraph 9) say that the type is <tt>stateT&</tt>. Either the
3597 synopsis or the summary must be changed. </p>
3599 <p>If (as I believe) the member function descriptions are correct,
3600 then we must also add text saying how <tt>do_length</tt> changes its
3601 <tt>stateT</tt> argument. </p>
3604 <p><b>Proposed resolution:</b></p>
3605 <p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
3606 change the <tt>stateT</tt> argument type on both member
3607 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
3610 <p><tt>const stateT&</tt></p>
3616 <p><tt>stateT&</tt></p>
3619 <p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
3620 <tt>do_length</tt> a paragraph:</p>
3623 <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
3624 it called <tt>do_in(state, from, from_end, from, to, to+max,
3625 to)</tt> for <tt>to</tt> pointing to a buffer of at least
3626 <tt>max</tt> elements.</p>
3633 <h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
3634 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3635 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-25</p>
3636 <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>
3637 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3638 <p><b>Discussion:</b></p>
3639 <p>This issue concerns the requirements on classes derived from
3640 <tt>codecvt</tt>, including user-defined classes. What are the
3641 restrictions on the conversion from external characters
3642 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
3643 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
3644 the I/O library make? </p>
3646 <p>The question is whether it's possible to convert from internal
3647 characters to external characters one internal character at a time,
3648 and whether, given a valid sequence of external characters, it's
3649 possible to pick off internal characters one at a time. Or, to put it
3650 differently: given a sequence of external characters and the
3651 corresponding sequence of internal characters, does a position in the
3652 internal sequence correspond to some position in the external
3655 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
3656 sequence of <i>M</i> external characters and that <tt>[ifirst,
3657 ilast)</tt> is the corresponding sequence of <i>N</i> internal
3658 characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>,
3659 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
3660 ilast)</tt>. Now the question: does there necessarily exist a
3661 subsequence of external characters, <tt>[first, last_1)</tt>, such
3662 that the corresponding sequence of internal characters is the single
3663 character <tt>*ifirst</tt>?
3666 <p>(What a "no" answer would mean is that
3667 <tt>my_encoding</tt> translates sequences only as blocks. There's a
3668 sequence of <i>M</i> external characters that maps to a sequence of
3669 <i>N</i> internal characters, but that external sequence has no
3670 subsequence that maps to <i>N-1</i> internal characters.) </p>
3672 <p>Some of the wording in the standard, such as the description of
3673 <tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals],
3674 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
3675 possible to pick off internal characters one at a time from a sequence
3676 of external characters. However, this is never explicitly stated one
3677 way or the other. </p>
3679 <p>This issue seems (and is) quite technical, but it is important if
3680 we expect users to provide their own encoding facets. This is an area
3681 where the standard library calls user-supplied code, so a well-defined
3682 set of requirements for the user-supplied code is crucial. Users must
3683 be aware of the assumptions that the library makes. This issue affects
3684 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
3685 and several of <tt>codecvt</tt>'s member functions. </p>
3688 <p><b>Proposed resolution:</b></p>
3689 <p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
3692 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
3693 (27.8 [file.streams]) must have the property that if</p>
3694 <pre> do_out(state, from, from_end, from_next, to, to_lim, to_next)
3696 <p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
3697 <pre> do_out(state, from, from + 1, from_next, to, to_end, to_next)
3699 <p>must also return <tt>ok</tt>, and that if</p>
3700 <pre> do_in(state, from, from_end, from_next, to, to_lim, to_next)
3702 <p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
3703 <pre> do_in(state, from, from_end, from_next, to, to + 1, to_next)
3705 <p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this
3706 means that <tt>basic_filebuf</tt> assumes that the mapping from
3707 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
3708 used by <tt>basic_filebuf</tt> must be able to translate characters
3709 one internal character at a time. <i>--End Footnote</i>]</p>
3712 <p><i>[Redmond: Minor change in proposed resolution. Original
3713 proposed resolution talked about "success", with a parenthetical
3714 comment that success meant returning <tt>ok</tt>. New wording
3715 removes all talk about "success", and just talks about the
3716 return value.]</i></p>
3721 <p><b>Rationale:</b></p>
3723 <p>The proposed resoluion says that conversions can be performed one
3724 internal character at a time. This rules out some encodings that
3725 would otherwise be legal. The alternative answer would mean there
3726 would be some internal positions that do not correspond to any
3727 external file position.</p>
3729 An example of an encoding that this rules out is one where the
3730 <tt>internT</tt> and <tt>externT</tt> are of the same type, and
3731 where the internal sequence <tt>c1 c2</tt> corresponds to the
3732 external sequence <tt>c2 c1</tt>.
3734 <p>It was generally agreed that <tt>basic_filebuf</tt> relies
3735 on this property: it was designed under the assumption that
3736 the external-to-internal mapping is N-to-1, and it is not clear
3737 that <tt>basic_filebuf</tt> is implementable without that
3741 The proposed resolution is expressed as a restriction on
3742 <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
3743 than a blanket restriction on all <tt>codecvt</tt> facets,
3744 because <tt>basic_filebuf</tt> is the only other part of the
3745 library that uses <tt>codecvt</tt>. If a user wants to define
3746 a <tt>codecvt</tt> facet that implements a more general N-to-M
3747 mapping, there is no reason to prohibit it, so long as the user
3748 does not expect <tt>basic_filebuf</tt> to be able to use it.
3756 <h3><a name="78"></a>78. Typo: event_call_back</h3>
3757 <p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3758 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3759 <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>
3760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3761 <p><b>Discussion:</b></p>
3762 <p>typo: event_call_back should be event_callback </p>
3765 <p><b>Proposed resolution:</b></p>
3766 <p>In the 27.4.2 [ios.base] synopsis change
3767 "event_call_back" to "event_callback". </p>
3773 <h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
3774 <p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3775 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3776 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
3777 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3778 <p><b>Discussion:</b></p>
3779 <p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p>
3780 <pre> template<class T> complex<T> polar(const T&, const T&); </pre>
3782 <p>In 26.3.7 [complex.value.ops] it is declared as follows:</p>
3783 <pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
3785 <p>Thus whether the second parameter is optional is not clear. </p>
3788 <p><b>Proposed resolution:</b></p>
3789 <p>In 26.3.1 [complex.synopsis] change:</p>
3790 <pre> template<class T> complex<T> polar(const T&, const T&);</pre>
3793 <pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
3800 <h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
3801 <p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3802 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3803 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
3804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3805 <p><b>Discussion:</b></p>
3806 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
3807 class complex. This redundancy should be removed.</p>
3810 <p><b>Proposed resolution:</b></p>
3811 <p>Reduce redundancy according to the general style of the standard. </p>
3817 <h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
3818 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3819 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3820 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
3821 <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>
3822 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3823 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
3824 <p><b>Discussion:</b></p>
3825 <p>Many string member functions throw if size is getting or exceeding
3826 npos. However, I wonder why they don't throw if size is getting or
3827 exceeding max_size() instead of npos. May be npos is known at compile
3828 time, while max_size() is known at runtime. However, what happens if
3829 size exceeds max_size() but not npos, then? It seems the standard
3830 lacks some clarifications here.</p>
3833 <p><b>Proposed resolution:</b></p>
3834 <p>After 21.3 [basic.string] paragraph 4 ("The functions
3835 described in this clause...") add a new paragraph:</p>
3838 <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
3839 <tt> max_size()</tt> then
3840 the operation throws <tt>length_error</tt>.</p>
3844 <p><b>Rationale:</b></p>
3845 <p>The LWG believes length_error is the correct exception to throw.</p>
3851 <h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
3852 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3853 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3854 <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>
3855 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3856 <p><b>Discussion:</b></p>
3857 <p>The constructor from a range:</p>
3859 <pre>template<class InputIterator>
3860 basic_string(InputIterator begin, InputIterator end,
3861 const Allocator& a = Allocator());</pre>
3863 <p>lacks a throws clause. However, I would expect that it throws
3864 according to the other constructors if the numbers of characters in
3865 the range equals npos (or exceeds max_size(), see above). </p>
3868 <p><b>Proposed resolution:</b></p>
3869 <p>In 21.3.1 [string.require], Strike throws paragraphs for
3870 constructors which say "Throws: length_error if n ==
3874 <p><b>Rationale:</b></p>
3875 <p>Throws clauses for length_error if n == npos are no longer needed
3876 because they are subsumed by the general wording added by the
3877 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
3883 <h3><a name="90"></a>90. Incorrect description of operator >> for strings</h3>
3884 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
3885 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3886 <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>
3887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
3888 <p><b>Discussion:</b></p>
3889 <p>The effect of operator >> for strings contain the following item:</p>
3891 <p> <tt>isspace(c,getloc())</tt> is true for the next available input
3894 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
3897 <p><b>Proposed resolution:</b></p>
3898 <p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p>
3901 <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
3907 <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
3915 <h3><a name="91"></a>91. Description of operator>> and getline() for string<> might cause endless loop</h3>
3916 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
3917 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3918 <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>
3919 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3920 <p><b>Discussion:</b></p>
3921 <p>Operator >> and getline() for strings read until eof()
3922 in the input stream is true. However, this might never happen, if the
3923 stream can't read anymore without reaching EOF. So shouldn't it be
3924 changed into that it reads until !good() ? </p>
3927 <p><b>Proposed resolution:</b></p>
3928 <p>In 21.3.8.9 [string.io], paragraph 1, replace:</p>
3930 Effects: Begins by constructing a sentry object k as if k were
3931 constructed by typename basic_istream<charT,traits>::sentry k( is). If
3932 bool( k) is true, it calls str.erase() and then extracts characters
3933 from is and appends them to str as if by calling str.append(1, c). If
3934 is.width() is greater than zero, the maximum number n of characters
3935 appended is is.width(); otherwise n is str.max_size(). Characters are
3936 extracted and appended until any of the following occurs:
3940 Effects: Behaves as a formatted input function (27.6.1.2.1
3941 [istream.formatted.reqmts]). After constructing a sentry object, if the
3942 sentry converts to true, calls str.erase() and then extracts
3943 characters from is and appends them to str as if by calling
3944 str.append(1,c). If is.width() is greater than zero, the maximum
3945 number n of characters appended is is.width(); otherwise n is
3946 str.max_size(). Characters are extracted and appended until any of the
3950 <p>In 21.3.8.9 [string.io], paragraph 6, replace</p>
3952 Effects: Begins by constructing a sentry object k as if by typename
3953 basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
3954 it calls str.erase() and then extracts characters from is and appends
3955 them to str as if by calling str.append(1, c) until any of the
3959 <blockquote><p>Effects: Behaves as an unformatted input function
3960 (27.6.1.3 [istream.unformatted]), except that it does not affect the
3962 by subsequent calls to basic_istream<>::gcount(). After
3963 constructing a sentry object, if the sentry converts to true, calls
3964 str.erase() and then extracts characters from is and appends them to
3965 str as if by calling str.append(1,c) until any of the following
3969 <p><i>[Redmond: Made changes in proposed resolution. <tt>operator>></tt>
3970 should be a formatted input function, not an unformatted input function.
3971 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
3972 there is no mechanism for <tt>gcount</tt> to be set except by one of
3973 <tt>basic_istream</tt>'s member functions.]</i></p>
3976 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
3981 <p><b>Rationale:</b></p>
3982 <p>The real issue here is whether or not these string input functions
3983 get their characters from a streambuf, rather than by calling an
3984 istream's member functions, a streambuf signals failure either by
3985 returning eof or by throwing an exception; there are no other
3986 possibilities. The proposed resolution makes it clear that these two
3987 functions do get characters from a streambuf.</p>
3994 <h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
3995 <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>
3996 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
3997 <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>
3998 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
3999 <p><b>Discussion:</b></p>
4000 <p>The standard does not state, how often a function object is copied,
4001 called, or the order of calls inside an algorithm. This may lead to
4002 surprising/buggy behavior. Consider the following example: </p>
4004 <pre>class Nth { // function object that returns true for the nth element
4006 int nth; // element to return true for
4007 int count; // element counter
4009 Nth (int n) : nth(n), count(0) {
4011 bool operator() (int) {
4012 return ++count == nth;
4016 // remove third element
4017 list<int>::iterator pos;
4018 pos = remove_if(coll.begin(),coll.end(), // range
4019 Nth(3)), // remove criterion
4020 coll.erase(pos,coll.end()); </pre>
4022 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
4023 happens because the usual implementation of the algorithm copies the
4024 function object internally: </p>
4026 <pre>template <class ForwIter, class Predicate>
4027 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
4029 beg = find_if(beg, end, op);
4034 ForwIter next = beg;
4035 return remove_copy_if(++next, end, beg, op);
4039 <p>The algorithm uses find_if() to find the first element that should
4040 be removed. However, it then uses a copy of the passed function object
4041 to process the resulting elements (if any). Here, Nth is used again
4042 and removes also the sixth element. This behavior compromises the
4043 advantage of function objects being able to have a state. Without any
4044 cost it could be avoided (just implement it directly instead of
4045 calling find_if()). </p>
4048 <p><b>Proposed resolution:</b></p>
4050 <p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
4052 [Note: Unless otherwise specified, algorithms that take function
4053 objects as arguments are permitted to copy those function objects
4054 freely. Programmers for whom object identity is important should
4055 consider using a wrapper class that points to a noncopied
4056 implementation object, or some equivalent solution.]
4059 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
4060 but rather something that programmers need to be educated about.
4061 There was discussion of adding wording to the effect that the number
4062 and order of calls to function objects, including predicates, not
4063 affect the behavior of the function object.]</i></p>
4066 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
4067 have a clear statement of "predicate" in the
4068 standard. People including me seemed to think "a function
4069 returning a Boolean value and being able to be called by an STL
4070 algorithm or be used as sorting criterion or ... is a
4071 predicate". But a predicate has more requirements: It should
4072 never change its behavior due to a call or being copied. IMHO we have
4073 to state this in the standard. If you like, see section 8.1.4 of my
4074 library book for a detailed discussion.]</i></p>
4077 <p><i>[Kona: Nico will provide wording to the effect that "unless
4078 otherwise specified, the number of copies of and calls to function
4079 objects by algorithms is unspecified". Consider placing in
4080 25 [algorithms] after paragraph 9.]</i></p>
4083 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
4084 functions object won't be copied, and what isn't forbidden is
4085 allowed. It is believed (especially since implementations that were
4086 written in concert with the standard do make copies of function
4087 objects) that this was intentional. Thus, no normative change is
4088 needed. What we should put in is a non-normative note suggesting to
4089 programmers that if they want to guarantee the lack of copying they
4090 should use something like the <tt>ref</tt> wrapper.]</i></p>
4093 <p><i>[Oxford: Matt provided wording.]</i></p>
4103 <h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
4104 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4105 <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4106 <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>
4107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4108 <p><b>Discussion:</b></p>
4109 <p>Table 72 in 24.1.1 [input.iterators] specifies semantics for
4110 <tt>*r++</tt> of:</p>
4112 <p> <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
4114 <p>There are two problems with this. First, the return type is
4115 specified to be "T", as opposed to something like "convertible to T".
4116 This is too specific: we want to allow *r++ to return an lvalue.</p>
4118 <p>Second, writing the semantics in terms of code misleadingly
4119 suggests that the effects *r++ should precisely replicate the behavior
4120 of this code, including side effects. (Does this mean that *r++
4121 should invoke the copy constructor exactly as many times as the sample
4122 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
4127 <p><b>Proposed resolution:</b></p>
4128 <p>In Table 72 in 24.1.1 [input.iterators], change the return type
4129 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
4132 <p><b>Rationale:</b></p>
4133 <p>This issue has two parts: the return type, and the number of times
4134 the copy constructor is invoked.</p>
4136 <p>The LWG believes the the first part is a real issue. It's
4137 inappropriate for the return type to be specified so much more
4138 precisely for *r++ than it is for *r. In particular, if r is of
4139 (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
4140 but <tt>int&</tt>.</p>
4142 <p>The LWG does not believe that the number of times the copy
4143 constructor is invoked is a real issue. This can vary in any case,
4144 because of language rules on copy constructor elision. That's too
4145 much to read into these semantics clauses.</p>
4147 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
4148 we're told (24.1/3) that forward iterators satisfy all the requirements
4149 of input iterators, we can't impose any requirements in the Input
4150 Iterator requirements table that forward iterators don't satisfy.</p>
4157 <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
4158 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4159 <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4160 <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>
4161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4162 <p><b>Discussion:</b></p>
4163 <p>Set::iterator is described as implementation-defined with a
4164 reference to the container requirement; the container requirement says
4165 that const_iterator is an iterator pointing to const T and iterator an
4166 iterator pointing to T.</p>
4168 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
4169 break the ordering of elements. But that is not clearly
4170 specified. Especially considering that the current standard requires
4171 that iterator for associative containers be different from
4172 const_iterator. Set, for example, has the following: </p>
4174 <p><tt>typedef implementation defined iterator;<br>
4175 // See _lib.container.requirements_</tt></p>
4177 <p>23.1 [container.requirements] actually requires that iterator type pointing
4178 to T (table 65). Disallowing user modification of keys by changing the
4179 standard to require an iterator for associative container to be the
4180 same as const_iterator would be overkill since that will unnecessarily
4181 significantly restrict the usage of associative container. A class to
4182 be used as elements of set, for example, can no longer be modified
4183 easily without either redesigning the class (using mutable on fields
4184 that have nothing to do with ordering), or using const_cast, which
4185 defeats requiring iterator to be const_iterator. The proposed solution
4186 goes in line with trusting user knows what he is doing. </p>
4188 <p><b>Other Options Evaluated:</b> </p>
4190 <p>Option A. In 23.1.4 [associative.reqmts], paragraph 2, after
4191 first sentence, and before "In addition,...", add one line:
4195 <p>Modification of keys shall not change their strict weak ordering. </p>
4198 <p>Option B. Add three new sentences to 23.1.4 [associative.reqmts]:</p>
4201 <p>At the end of paragraph 5: "Keys in an associative container
4202 are immutable." At the end of paragraph 6: "For
4203 associative containers where the value type is the same as the key
4204 type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
4205 constant iterators. It is unspecified whether or not
4206 <tt>iterator</tt> and <tt>const_iterator</tt> are the same
4210 <p>Option C. To 23.1.4 [associative.reqmts], paragraph 3, which
4211 currently reads:</p>
4214 <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
4215 comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
4216 container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
4217 == false && comp(k2, k1) == false.</p>
4220 <p> add the following:</p>
4223 <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
4224 value whenever it is evaluated. [Note: If k2 is removed from the container and later
4225 reinserted, comp(k1, k2) must still return a consistent value but this value may be
4226 different than it was the first time k1 and k2 were in the same container. This is
4227 intended to allow usage like a string key that contains a filename, where comp compares
4228 file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
4229 reinserted, comp(k1, k2) must again return a consistent value but this value may be
4230 different than it was the previous time k2 was in the container.]</p>
4235 <p><b>Proposed resolution:</b></p>
4236 <p>Add the following to 23.1.4 [associative.reqmts] at
4237 the indicated location:</p>
4240 <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
4241 calling comp(k1, k2) shall always return the same
4243 <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
4244 <p>At the end of paragraph 6: "For associative containers where the value type is the
4245 same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
4246 iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
4247 are the same type."</p>
4251 <p><b>Rationale:</b></p>
4252 <p>Several arguments were advanced for and against allowing set elements to be
4253 mutable as long as the ordering was not effected. The argument which swayed the
4254 LWG was one of safety; if elements were mutable, there would be no compile-time
4255 way to detect of a simple user oversight which caused ordering to be
4256 modified. There was a report that this had actually happened in practice,
4257 and had been painful to diagnose. If users need to modify elements,
4258 it is possible to use mutable members or const_cast.</p>
4260 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
4261 object may indirectly (via pointers) operate on values outside of the keys.</p>
4264 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
4265 to be different types to allow for potential future work in which some
4266 member functions might be overloaded between the two types. No such
4267 member functions exist now, and the LWG believes that user functionality
4268 will not be impaired by permitting the two types to be the same. A
4269 function that operates on both iterator types can be defined for
4270 <tt>const_iterator</tt> alone, and can rely on the automatic
4271 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
4274 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
4282 <h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
4283 <p><b>Section:</b> 26.5.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4284 <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4285 <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>
4286 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4287 <p><b>Discussion:</b></p>
4288 <p>This is the only place in the whole standard where the implementation has to document
4289 something private.</p>
4292 <p><b>Proposed resolution:</b></p>
4294 Remove the comment which says "// remainder implementation defined" from:
4298 <li>26.5.5 [template.slice.array]</li>
4299 <li>26.5.7 [template.gslice.array]</li>
4300 <li>26.5.8 [template.mask.array]</li>
4301 <li>26.5.9 [template.indirect.array]</li>
4309 <h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
4310 <p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4311 <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
4312 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
4313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4314 <p><b>Discussion:</b></p>
4315 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
4316 exception::what() is left unspecified. This issue has implications
4317 with exception safety of exception handling: some exceptions should
4318 not throw bad_alloc.</p>
4321 <p><b>Proposed resolution:</b></p>
4322 <p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
4323 clause) the sentence:</p>
4326 <p>The return value remains valid until the exception object from which it is obtained is
4327 destroyed or a non-const member function of the exception object is called.</p>
4331 <p><b>Rationale:</b></p>
4332 <p>If an exception object has non-const members, they may be used
4333 to set internal state that should affect the contents of the string
4334 returned by <tt>what()</tt>.
4342 <h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
4343 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4344 <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 1998-10-07</p>
4345 <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>
4346 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4347 <p><b>Discussion:</b></p>
4349 <p>There are no versions of binders that apply to non-const elements
4350 of a sequence. This makes examples like for_each() using bind2nd() on
4351 page 521 of "The C++ Programming Language (3rd)"
4352 non-conforming. Suitable versions of the binders need to be added.</p>
4354 <p>Further discussion from Nico:</p>
4356 <p>What is probably meant here is shown in the following example:</p>
4360 void print (int i) const { }
4361 void modify (int i) { }
4365 vector<Elem> coll(2);
4366 for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK
4367 for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR
4370 <p>The error results from the fact that bind2nd() passes its first
4371 argument (the argument of the sequence) as constant reference. See the
4372 following typical implementation:</p>
4375 <pre>template <class Operation>
4377 : public unary_function<typename Operation::first_argument_type,
4378 typename Operation::result_type> {
4381 typename Operation::second_argument_type value;
4383 binder2nd(const Operation& o,
4384 const typename Operation::second_argument_type& v)
4385 : op(o), value(v) {} </pre>
4386 <pre> typename Operation::result_type
4387 operator()(const typename Operation::first_argument_type& x) const {
4388 return op(x, value);
4393 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
4396 <pre>template <class Operation>
4398 : public unary_function<typename Operation::first_argument_type,
4399 typename Operation::result_type> {
4402 typename Operation::second_argument_type value;
4404 binder2nd(const Operation& o,
4405 const typename Operation::second_argument_type& v)
4406 : op(o), value(v) {} </pre>
4407 <pre> typename Operation::result_type
4408 operator()(const typename Operation::first_argument_type& x) const {
4409 return op(x, value);
4411 typename Operation::result_type
4412 operator()(typename Operation::first_argument_type& x) const {
4413 return op(x, value);
4419 <p><b>Proposed resolution:</b></p>
4421 <p><b>Howard believes there is a flaw</b> in this resolution.
4422 See c++std-lib-9127. We may need to reopen this issue.</p>
4424 <p>In D.8 [depr.lib.binders] in the declaration of binder1st after:</p>
4426 <p><tt>typename Operation::result_type<br>
4427 operator()(const typename Operation::second_argument_type& x) const;</tt></p>
4431 <p><tt>typename Operation::result_type<br>
4432 operator()(typename Operation::second_argument_type& x) const;</tt></p>
4434 <p>In D.8 [depr.lib.binders] in the declaration of binder2nd after:</p>
4436 <p><tt>typename Operation::result_type<br>
4437 operator()(const typename Operation::first_argument_type& x) const;</tt></p>
4441 <p><tt>typename Operation::result_type<br>
4442 operator()(typename Operation::first_argument_type& x) const;</tt></p>
4445 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
4446 this is a mistake in the design, but there was no consensus on whether
4447 it was a defect in the Standard. Straw vote: NAD - 5. Accept
4448 proposed resolution - 3. Leave open - 6.]</i></p>
4451 <p><i>[Copenhagen: It was generally agreed that this was a defect.
4452 Strap poll: NAD - 0. Accept proposed resolution - 10.
4453 Leave open - 1.]</i></p>
4462 <h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
4463 <p><b>Section:</b> 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4464 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
4465 <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>
4466 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4467 <p><b>Discussion:</b></p>
4468 <p>Member istreambuf_iterator<>::equal is not declared
4469 "const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
4470 which is const, calls it. This is contradictory. </p>
4473 <p><b>Proposed resolution:</b></p>
4474 <p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
4478 <pre>bool equal(istreambuf_iterator& b);</pre>
4484 <pre>bool equal(const istreambuf_iterator& b) const;</pre>
4492 <h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
4493 <p><b>Section:</b> 24.5.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4494 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-10-20</p>
4495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4496 <p><b>Discussion:</b></p>
4497 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
4498 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
4499 reads "<i>s</i> is not null". However, <i>s</i> is a
4500 reference, and references can't be null. </p>
4503 <p><b>Proposed resolution:</b></p>
4504 <p>In 24.5.4.1 [ostreambuf.iter.cons]:</p>
4506 <p>Move the current paragraph 1, which reads "Requires: s is not
4507 null.", from the first constructor to the second constructor.</p>
4509 <p>Insert a new paragraph 1 Requires clause for the first constructor
4513 <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
4521 <h3><a name="114"></a>114. Placement forms example in error twice</h3>
4522 <p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4523 <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p>
4524 <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>
4525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4526 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
4527 <p><b>Discussion:</b></p>
4528 <p>Section 18.5.1.3 contains the following example: </p>
4530 <pre>[Example: This can be useful for constructing an object at a known address:
4531 char place[sizeof(Something)];
4532 Something* p = new (place) Something();
4535 <p>First code line: "place" need not have any special alignment, and the
4536 following constructor could fail due to misaligned data.</p>
4538 <p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG
4539 believes the () are correct.]</p>
4541 <p>Examples are not normative, but nevertheless should not show code that is invalid or
4545 <p><b>Proposed resolution:</b></p>
4546 <p>Replace the first line of code in the example in
4547 18.5.1.3 [new.delete.placement] with:
4551 <pre>void* place = operator new(sizeof(Something));</pre>
4559 <h3><a name="115"></a>115. Typo in strstream constructors</h3>
4560 <p><b>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4561 <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</p>
4562 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4563 <p><b>Discussion:</b></p>
4564 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
4567 <p>Effects: Constructs an object of class strstream, initializing the base class with
4568 iostream(& sb) and initializing sb with one of the two constructors: </p>
4569 <p>- If mode&app==0, then s shall designate the first element of an array of n
4570 elements. The constructor is strstreambuf(s, n, s). </p>
4571 <p>- If mode&app==0, then s shall designate the first element of an array of n
4572 elements that contains an NTBS whose first element is designated by s. The constructor is
4573 strstreambuf(s, n, s+std::strlen(s)).</p>
4576 <p>Notice the second condition is the same as the first. I think the second condition
4577 should be "If mode&app==app", or "mode&app!=0", meaning that
4578 the append bit is set.</p>
4581 <p><b>Proposed resolution:</b></p>
4582 <p>In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons]
4583 paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
4584 and the second condition to <tt>(mode&app)!=0</tt>.</p>
4591 <h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
4592 <p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4593 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4594 <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>
4595 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4596 <p><b>Discussion:</b></p>
4597 <p>The <b>effects</b> clause for numeric inserters says that
4598 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
4599 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4600 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
4601 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
4602 delegated to <tt>num_put</tt>, and that insertion is performed as if
4603 through the following code fragment: </p>
4605 <pre>bool failed = use_facet<
4606 num_put<charT,ostreambuf_iterator<charT,traits> >
4607 >(getloc()).put(*this, *this, fill(), val). failed();</pre>
4609 <p>This doesn't work, because <tt>num_put<></tt>::put is only
4610 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
4611 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
4612 void*</tt>. That is, the code fragment in the standard is incorrect
4613 (it is diagnosed as ambiguous at compile time) for the types
4614 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
4615 int</tt>, and <tt>float</tt>. </p>
4617 <p>We must either add new member functions to <tt>num_put</tt>, or
4618 else change the description in <tt>ostream</tt> so that it only calls
4619 functions that are actually there. I prefer the latter. </p>
4622 <p><b>Proposed resolution:</b></p>
4623 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
4627 The classes num_get<> and num_put<> handle locale-dependent numeric
4628 formatting and parsing. These inserter functions use the imbued
4629 locale value to perform numeric formatting. When val is of type bool,
4630 long, unsigned long, double, long double, or const void*, the
4631 formatting conversion occurs as if it performed the following code
4635 <pre>bool failed = use_facet<
4636 num_put<charT,ostreambuf_iterator<charT,traits> >
4637 >(getloc()).put(*this, *this, fill(), val). failed();
4641 When val is of type short the formatting conversion occurs as if it
4642 performed the following code fragment:
4645 <pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
4646 bool failed = use_facet<
4647 num_put<charT,ostreambuf_iterator<charT,traits> >
4648 >(getloc()).put(*this, *this, fill(),
4649 baseflags == ios_base::oct || baseflags == ios_base::hex
4650 ? static_cast<long>(static_cast<unsigned short>(val))
4651 : static_cast<long>(val)). failed();
4655 When val is of type int the formatting conversion occurs as if it performed
4656 the following code fragment:
4659 <pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
4660 bool failed = use_facet<
4661 num_put<charT,ostreambuf_iterator<charT,traits> >
4662 >(getloc()).put(*this, *this, fill(),
4663 baseflags == ios_base::oct || baseflags == ios_base::hex
4664 ? static_cast<long>(static_cast<unsigned int>(val))
4665 : static_cast<long>(val)). failed();
4669 When val is of type unsigned short or unsigned int the formatting conversion
4670 occurs as if it performed the following code fragment:
4673 <pre>bool failed = use_facet<
4674 num_put<charT,ostreambuf_iterator<charT,traits> >
4675 >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
4680 When val is of type float the formatting conversion occurs as if it
4681 performed the following code fragment:
4684 <pre>bool failed = use_facet<
4685 num_put<charT,ostreambuf_iterator<charT,traits> >
4686 >(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
4692 <p><i>[post-Toronto: This differs from the previous proposed
4693 resolution; PJP provided the new wording. The differences are in
4694 signed short and int output.]</i></p>
4698 <p><b>Rationale:</b></p>
4699 <p>The original proposed resolution was to cast int and short to long,
4700 unsigned int and unsigned short to unsigned long, and float to double,
4701 thus ensuring that we don't try to use nonexistent num_put<>
4702 member functions. The current proposed resolution is more
4703 complicated, but gives more expected results for hex and octal output
4704 of signed short and signed int. (On a system with 16-bit short, for
4705 example, printing short(-1) in hex format should yield 0xffff.)</p>
4712 <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
4713 <p><b>Section:</b> 27.6.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>
4714 <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
4715 <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>
4716 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4717 <p><b>Discussion:</b></p>
4718 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
4719 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
4720 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
4721 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
4723 <pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
4725 use_facet< numget >(loc).get(*this, 0, *this, err, val);
4726 setstate(err);</pre>
4728 <p>According to section 22.2.2.1.1 [facet.num.get.members], however,
4729 <tt>num_get<>::get()</tt> is only overloaded for the types
4730 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
4731 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
4732 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
4733 <tt>void*</tt>. Comparing the lists from the two sections, we find
4734 that 27.6.1.2.2 is using a nonexistent function for types
4735 <tt>short</tt> and <tt>int</tt>. </p>
4738 <p><b>Proposed resolution:</b></p>
4739 <p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
4740 two lines (1st and 3rd) which read:</p>
4742 <pre>operator>>(short& val);
4744 operator>>(int& val);</pre>
4747 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
4750 <pre>operator>>(short& val);</pre>
4751 <p>The conversion occurs as if performed by the following code fragment (using
4752 the same notation as for the preceding code fragment):</p>
4753 <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
4756 use_facet< numget >(loc).get(*this, 0, *this, err, lval);
4758 && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
4759 err = ios_base::failbit;
4760 setstate(err);</pre>
4761 <pre>operator>>(int& val);</pre>
4762 <p>The conversion occurs as if performed by the following code fragment (using
4763 the same notation as for the preceding code fragment):</p>
4764 <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
4767 use_facet< numget >(loc).get(*this, 0, *this, err, lval);
4769 && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
4770 err = ios_base::failbit;
4771 setstate(err);</pre>
4774 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
4782 <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
4783 <p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4784 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4785 <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>
4786 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4787 <p><b>Discussion:</b></p>
4788 <p>Section 17.4.4.9 [res.on.exception.handling] states: </p>
4790 <p>"An implementation may strengthen the exception-specification
4791 for a function by removing listed exceptions." </p>
4793 <p>The problem is that if an implementation is allowed to do this for
4794 virtual functions, then a library user cannot write a class that
4795 portably derives from that class. </p>
4797 <p>For example, this would not compile if ios_base::failure::~failure
4798 had an empty exception specification: </p>
4800 <pre>#include <ios>
4801 #include <string>
4803 class D : public std::ios_base::failure {
4805 D(const std::string&);
4806 ~D(); // error - exception specification must be compatible with
4807 // overridden virtual function ios_base::failure::~failure()
4811 <p><b>Proposed resolution:</b></p>
4812 <p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p>
4814 <p> "may strengthen the
4815 exception-specification for a function"</p>
4819 <p> "may strengthen the
4820 exception-specification for a non-virtual function". </p>
4827 <h3><a name="120"></a>120. Can an implementor add specializations?</h3>
4828 <p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4829 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4830 <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>
4831 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4832 <p><b>Discussion:</b></p>
4834 <p>The original issue asked whether a library implementor could
4835 specialize standard library templates for built-in types. (This was
4836 an issue because users are permitted to explicitly instantiate
4837 standard library templates.)</p>
4839 <p>Specializations are no longer a problem, because of the resolution
4840 to core issue 259. Under the proposed resolution, it will be legal
4841 for a translation unit to contain both a specialization and an
4842 explicit instantiation of the same template, provided that the
4843 specialization comes first. In such a case, the explicit
4844 instantiation will be ignored. Further discussion of library issue
4845 120 assumes that the core 259 resolution will be adopted.</p>
4847 <p>However, as noted in lib-7047, one piece of this issue still
4848 remains: what happens if a standard library implementor explicitly
4849 instantiates a standard library templates? It's illegal for a program
4850 to contain two different explicit instantiations of the same template
4851 for the same type in two different translation units (ODR violation),
4852 and the core working group doesn't believe it is practical to relax
4853 that restriction.</p>
4855 <p>The issue, then, is: are users allowed to explicitly instantiate
4856 standard library templates for non-user defined types? The status quo
4857 answer is 'yes'. Changing it to 'no' would give library implementors
4860 <p>This is an issue because, for performance reasons, library
4861 implementors often need to explicitly instantiate standard library
4862 templates. (for example, std::basic_string<char>) Does giving
4863 users freedom to explicitly instantiate standard library templates for
4864 non-user defined types make it impossible or painfully difficult for
4865 library implementors to do this?</p>
4867 <p>John Spicer suggests, in lib-8957, that library implementors have a
4868 mechanism they can use for explicit instantiations that doesn't
4869 prevent users from performing their own explicit instantiations: put
4870 each explicit instantiation in its own object file. (Different
4871 solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On
4872 some platforms, library implementors might not need to do anything
4873 special: the "undefined behavior" that results from having two
4874 different explicit instantiations might be harmless.</p>
4878 <p><b>Proposed resolution:</b></p>
4879 <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p>
4881 A program may explicitly instantiate any templates in the standard
4882 library only if the declaration depends on the name of a user-defined
4883 type of external linkage and the instantiation meets the standard library
4884 requirements for the original template.
4887 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
4888 a user-defined type"]</i></p>
4893 <p><b>Rationale:</b></p>
4894 <p>The LWG considered another possible resolution:</p>
4896 <p>In light of the resolution to core issue 259, no normative changes
4897 in the library clauses are necessary. Add the following non-normative
4898 note to the end of 17.4.3.2 [reserved.names] paragraph 1:</p>
4900 [<i>Note:</i> A program may explicitly instantiate standard library
4901 templates, even when an explicit instantiation does not depend on
4902 a user-defined name. <i>--end note</i>]
4906 <p>The LWG rejected this because it was believed that it would make
4907 it unnecessarily difficult for library implementors to write
4908 high-quality implementations. A program may not include an
4909 explicit instantiation of the same template, for the same template
4910 arguments, in two different translation units. If users are
4911 allowed to provide explicit instantiations of Standard Library
4912 templates for built-in types, then library implementors aren't,
4913 at least not without nonportable tricks.</p>
4915 <p>The most serious problem is a class template that has writeable
4916 static member variables. Unfortunately, such class templates are
4917 important and, in existing Standard Library implementations, are
4918 often explicitly specialized by library implementors: locale facets,
4919 which have a writeable static member variable <tt>id</tt>. If a
4920 user's explicit instantiation collided with the implementations
4921 explicit instantiation, iostream initialization could cause locales
4922 to be constructed in an inconsistent state.</p>
4924 <p>One proposed implementation technique was for Standard Library
4925 implementors to provide explicit instantiations in separate object
4926 files, so that they would not be picked up by the linker when the
4927 user also provides an explicit instantiation. However, this
4928 technique only applies for Standard Library implementations that
4929 are packaged as static archives. Most Standard Library
4930 implementations nowadays are packaged as dynamic libraries, so this
4931 technique would not apply.</p>
4933 <p>The Committee is now considering standardization of dynamic
4934 linking. If there are such changes in the future, it may be
4935 appropriate to revisit this issue later.</p>
4942 <h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
4943 <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
4944 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4945 <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>
4946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
4947 <p><b>Discussion:</b></p>
4948 <p>Section 27.5.2 describes the streambuf classes this way: </p>
4952 <p>The class streambuf is a specialization of the template class basic_streambuf
4953 specialized for the type char. </p>
4955 <p>The class wstreambuf is a specialization of the template class basic_streambuf
4956 specialized for the type wchar_t. </p>
4960 <p>This implies that these classes must be template specializations, not typedefs. </p>
4962 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
4965 <p><b>Proposed resolution:</b></p>
4966 <p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two
4970 <p><b>Rationale:</b></p>
4971 <p>The <tt>streambuf</tt> synopsis already has a declaration for the
4972 typedefs and that is sufficient. </p>
4979 <h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
4980 <p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
4981 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
4982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
4983 <p><b>Discussion:</b></p>
4984 <p>One of the operator= in the valarray helper arrays is const and one
4985 is not. For example, look at slice_array. This operator= in Section
4986 26.5.5.1 [slice.arr.assign] is const: </p>
4988 <p> <tt>void operator=(const valarray<T>&) const;</tt> </p>
4990 <p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p>
4992 <p> <tt>void operator=(const T&); </tt></p>
4994 <p>The description of the semantics for these two functions is similar. </p>
4997 <p><b>Proposed resolution:</b></p>
4999 <p>26.5.5 [template.slice.array] Template class slice_array</p>
5002 <p>In the class template definition for slice_array, replace the member
5003 function declaration</p>
5004 <pre> void operator=(const T&);
5007 <pre> void operator=(const T&) const;
5011 <p>26.5.5.3 [slice.arr.fill] slice_array fill function</p>
5014 <p>Change the function declaration</p>
5015 <pre> void operator=(const T&);
5018 <pre> void operator=(const T&) const;
5022 <p>26.5.7 [template.gslice.array] Template class gslice_array</p>
5025 <p>In the class template definition for gslice_array, replace the member
5026 function declaration</p>
5027 <pre> void operator=(const T&);
5030 <pre> void operator=(const T&) const;
5034 <p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p>
5037 <p>Change the function declaration</p>
5038 <pre> void operator=(const T&);
5041 <pre> void operator=(const T&) const;
5045 <p>26.5.8 [template.mask.array] Template class mask_array</p>
5048 <p>In the class template definition for mask_array, replace the member
5049 function declaration</p>
5050 <pre> void operator=(const T&);
5053 <pre> void operator=(const T&) const;
5057 <p>26.5.8.3 [mask.array.fill] mask_array fill function</p>
5060 <p>Change the function declaration</p>
5061 <pre> void operator=(const T&);
5064 <pre> void operator=(const T&) const;
5068 <p>26.5.9 [template.indirect.array] Template class indirect_array</p>
5071 <p>In the class template definition for indirect_array, replace the member
5072 function declaration</p>
5073 <pre> void operator=(const T&);
5076 <pre> void operator=(const T&) const;
5080 <p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p>
5083 <p>Change the function declaration</p>
5084 <pre> void operator=(const T&);
5087 <pre> void operator=(const T&) const;
5092 <p><i>[Redmond: Robert provided wording.]</i></p>
5097 <p><b>Rationale:</b></p>
5098 <p>There's no good reason for one version of operator= being const and
5099 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
5100 matters: these functions are now callable in more circumstances. In
5101 many existing implementations, both versions are already const.</p>
5108 <h3><a name="124"></a>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3>
5109 <p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5110 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
5111 <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>
5112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5113 <p><b>Discussion:</b></p>
5114 <p>In Section 22.2.1.2 [locale.ctype.byname]
5115 ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
5116 to return a const char* not a const charT*. </p>
5119 <p><b>Proposed resolution:</b></p>
5120 <p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
5121 <tt>do_scan_not()</tt> to return a <tt> const
5129 <h3><a name="125"></a>125. valarray<T>::operator!() return type is inconsistent</h3>
5130 <p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5131 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
5132 <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>
5133 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5134 <p><b>Discussion:</b></p>
5135 <p>In Section 26.5.2 [template.valarray] valarray<T>::operator!()
5137 declared to return a valarray<T>, but in Section 26.5.2.5
5138 [valarray.unary] it is declared to return a valarray<bool>. The
5139 latter appears to be correct. </p>
5142 <p><b>Proposed resolution:</b></p>
5143 <p>Change in Section 26.5.2 [template.valarray] the declaration of
5144 <tt>operator!()</tt> so that the return type is
5145 <tt>valarray<bool></tt>. </p>
5151 <h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
5152 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5153 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
5154 <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>
5155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5156 <p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
5158 <p><b>Proposed resolution:</b></p>
5159 <p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p>
5161 <pre> do_widen(do_narrow(c),0) == c</pre>
5165 <pre> do_widen(do_narrow(c,0)) == c</pre>
5169 <pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
5173 <pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
5180 <h3><a name="127"></a>127. auto_ptr<> conversion issues</h3>
5181 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5182 <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</p>
5183 <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>
5184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5185 <p><b>Discussion:</b></p>
5186 <p>There are two problems with the current <tt>auto_ptr</tt> wording
5187 in the standard: </p>
5189 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
5190 because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to
5191 <tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by
5192 Nathan Myers, with the same proposed resolution.</i></p>
5194 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
5195 <tt>auto_ptr_ref</tt> argument. </p>
5197 <p>I have discussed these problems with my proposal coauthor, Bill
5198 Gibbons, and with some compiler and library implementors, and we
5199 believe that these problems are not desired or desirable implications
5200 of the standard. </p>
5202 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
5203 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
5204 "assignment operator" to "public assignment
5205 operator", 2) changed effects to specify use of release(), 3)
5206 made the conversion to auto_ptr_ref const. </p>
5208 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
5209 states that the conversion from auto_ptr to auto_ptr_ref should
5210 be const. This is not acceptable, because it would allow
5211 initialization and assignment from _any_ const auto_ptr! It also
5212 introduces an implementation difficulty in writing this conversion
5213 function -- namely, somewhere along the line, a const_cast will be
5214 necessary to remove that const so that release() may be called. This
5215 may result in undefined behavior [7.1.5.1/4]. The conversion
5216 operator does not have to be const, because a non-const implicit
5217 object parameter may be bound to an rvalue [13.3.3.1.4/3]
5220 <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
5222 <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop],
5223 paragraph 2, make the conversion to auto_ptr_ref const:</p>
5225 <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
5229 <p><b>Proposed resolution:</b></p>
5230 <p>In 20.5.4 [meta.unary], paragraph 2, move
5231 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
5233 <p>In 20.5.4 [meta.unary], paragraph 2, add
5234 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
5237 <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
5240 <p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p>
5243 <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
5245 <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
5246 p</tt> that <tt>r</tt> holds a reference to.<br>
5247 <b>Returns: </b><tt>*this</tt>.</p>
5256 <h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
5257 <p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5258 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
5259 <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>
5260 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5261 <p><b>Discussion:</b></p>
5262 <p>Currently, the standard does not specify how seekg() and seekp()
5263 indicate failure. They are not required to set failbit, and they can't
5264 return an error indication because they must return *this, i.e. the
5265 stream. Hence, it is undefined what happens if they fail. And they
5266 <i>can</i> fail, for instance, when a file stream is disconnected from the
5267 underlying file (is_open()==false) or when a wide character file
5268 stream must perform a state-dependent code conversion, etc. </p>
5270 <p>The stream functions seekg() and seekp() should set failbit in the
5271 stream state in case of failure.</p>
5274 <p><b>Proposed resolution:</b></p>
5275 <p>Add to the Effects: clause of seekg() in
5276 27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
5277 27.6.2.5 [ostream.seeks]: </p>
5280 <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
5285 <p><b>Rationale:</b></p>
5286 <p>Setting failbit is the usual error reporting mechanism for streams</p>
5292 <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
5293 <p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
5294 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p>
5295 <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>
5296 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
5297 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
5298 <p><b>Discussion:</b></p>
5299 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
5300 iterator. Table 69 (23.1.2) says that in addition to this requirement,
5301 associative containers also say that container::erase(iterator)
5302 returns void. That's not an addition; it's a change to the
5303 requirements, which has the effect of making associative containers
5304 fail to meet the requirements for containers.</p>
5307 <p><b>Proposed resolution:</b></p>
5310 In 23.1.4 [associative.reqmts], in Table 69 Associative container
5311 requirements, change the return type of <tt>a.erase(q)</tt> from
5312 <tt>void</tt> to <tt>iterator</tt>. Change the
5313 assertion/not/pre/post-condition from "erases the element pointed to
5314 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
5315 Returns an iterator pointing to the element immediately following q
5316 prior to the element being erased. If no such element exists, a.end()
5321 In 23.1.4 [associative.reqmts], in Table 69 Associative container
5322 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
5323 from <tt>void</tt> to <tt>iterator</tt>. Change the
5324 assertion/not/pre/post-condition from "erases the elements in the
5325 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
5326 q2)</tt>. Returns q2."
5330 In 23.3.1 [map], in the <tt>map</tt> class synopsis; and
5331 in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and
5332 in 23.3.3 [set], in the <tt>set</tt> class synopsis; and
5333 in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis:
5334 change the signature of the first <tt>erase</tt> overload to
5336 <pre> iterator erase(iterator position);
5338 <p>and change the signature of the third <tt>erase</tt> overload to</p>
5339 <pre> iterator erase(iterator first, iterator last);
5343 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
5346 <p><i>[Post-Kona: the LWG agrees the return type should be
5347 <tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.)
5348 Matt provided wording.]</i></p>
5352 Sydney: the proposed wording went in the right direction, but it
5353 wasn't good enough. We want to return an iterator from the range form
5354 of erase as well as the single-iterator form. Also, the wording is
5355 slightly different from the wording we have for sequences; there's no
5356 good reason for having a difference. Matt provided new wording,
5357 (reflected above) which we will review at the next meeting.
5362 Redmond: formally voted into WP.
5372 <h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
5373 <p><b>Section:</b> 23.2.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5374 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5376 <p><b>Discussion:</b></p>
5377 <p>The description reads:</p>
5381 <pre> if (sz > size())
5382 insert(end(), sz-size(), c);
5383 else if (sz < size())
5384 erase(begin()+sz, end());
5386 ; // do nothing</pre>
5388 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
5391 <p><b>Proposed resolution:</b></p>
5392 <p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p>
5396 <pre> if (sz > size())
5397 insert(end(), sz-size(), c);
5398 else if (sz < size())
5400 iterator i = begin();
5405 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
5406 with David Abrahams. They had a discussion and believe there is
5407 no issue of exception safety with the proposed resolution.]</i></p>
5415 <h3><a name="133"></a>133. map missing get_allocator()</h3>
5416 <p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5417 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5418 <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>
5419 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5420 <p><b>Discussion:</b></p><p>The title says it all.</p>
5422 <p><b>Proposed resolution:</b></p>
5423 <p>Insert in 23.3.1 [map], paragraph 2,
5424 after operator= in the map declaration:</p>
5426 <pre> allocator_type get_allocator() const;</pre>
5432 <h3><a name="134"></a>134. vector constructors over specified</h3>
5433 <p><b>Section:</b> 23.2.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5434 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5436 <p><b>Discussion:</b></p>
5437 <p>The complexity description says: "It does at most 2N calls to the copy constructor
5438 of T and logN reallocations if they are just input iterators ...".</p>
5440 <p>This appears to be overly restrictive, dictating the precise memory/performance
5441 tradeoff for the implementor.</p>
5444 <p><b>Proposed resolution:</b></p>
5445 <p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p>
5447 <p>-1- Complexity: The constructor template <class
5448 InputIterator> vector(InputIterator first, InputIterator last)
5449 makes only N calls to the copy constructor of T (where N is the
5450 distance between first and last) and no reallocations if iterators
5451 first and last are of forward, bidirectional, or random access
5452 categories. It makes order N calls to the copy constructor of T and
5453 order logN reallocations if they are just input iterators.
5457 <p><b>Rationale:</b></p>
5458 <p>"at most 2N calls" is correct only if the growth factor
5459 is greater than or equal to 2.
5466 <h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
5467 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
5468 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
5469 <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>
5470 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
5471 <p><b>Discussion:</b></p>
5472 <p>I may be misunderstanding the intent, but should not seekg set only
5473 the input stream and seekp set only the output stream? The description
5474 seems to say that each should set both input and output streams. If
5475 that's really the intent, I withdraw this proposal.</p>
5478 <p><b>Proposed resolution:</b></p>
5479 <p>In section 27.6.1.3 change:</p>
5481 <pre>basic_istream<charT,traits>& seekg(pos_type pos);
5482 Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
5486 <pre>basic_istream<charT,traits>& seekg(pos_type pos);
5487 Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre>
5489 <p>In section 27.6.1.3 change:</p>
5491 <pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
5492 Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
5496 <pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
5497 Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre>
5499 <p>In section 27.6.2.4, paragraph 2 change:</p>
5501 <pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
5505 <pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre>
5507 <p>In section 27.6.2.4, paragraph 4 change:</p>
5509 <pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
5513 <pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre>
5515 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
5516 like the opinion of more iostream experts before taking action.]</i></p>
5519 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
5520 incorrect, his implementation already implements the Proposed
5521 Resolution.]</i></p>
5524 <p><i>[Post-Tokyo: Matt Austern comments:<br>
5525 Is it a problem with basic_istream and basic_ostream, or is it a problem
5526 with basic_stringbuf?
5527 We could resolve the issue either by changing basic_istream and
5528 basic_ostream, or by changing basic_stringbuf. I prefer the latter
5529 change (or maybe both changes): I don't see any reason for the standard to
5530 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
5531 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
5532 This requirement is a bit weird. There's no similar requirement
5533 for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or
5534 basic_filebuf<>::seekpos.]</i></p>
5542 <h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
5543 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5544 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p>
5545 <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>
5546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5547 <p><b>Discussion:</b></p>
5548 <p>Section 22.1.1 [locale] says:</p>
5550 <p>-4- In the call to use_facet<Facet>(loc), the type argument
5551 chooses a facet, making available all members of the named type. If
5552 Facet is not present in a locale (or, failing that, in the global
5553 locale), it throws the standard exception bad_cast. A C++ program can
5554 check if a locale implements a particular facet with the template
5555 function has_facet<Facet>(). </p>
5557 <p>This contradicts the specification given in section
5558 22.1.2 [locale.global.templates]:
5560 template <class Facet> const Facet& use_facet(const
5561 locale& loc); <br>
5563 -1- Get a reference to a facet of a locale. <br>
5564 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
5565 -3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br>
5566 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
5570 <p><b>Proposed resolution:</b></p>
5571 <p>Remove the phrase "(or, failing that, in the global locale)"
5572 from section 22.1.1. </p>
5575 <p><b>Rationale:</b></p>
5576 <p>Needed for consistency with the way locales are handled elsewhere
5577 in the standard.</p>
5583 <h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
5584 <p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5585 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p>
5586 <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>
5587 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5588 <p><b>Discussion:</b></p>
5589 <p>The sentence introducing the Optional sequence operation table
5590 (23.1.1 paragraph 12) has two problems:</p>
5592 <p>A. It says ``The operations in table 68 are provided only for the containers for which
5593 they take constant time.''<br>
5595 That could be interpreted in two ways, one of them being ``Even though table 68 shows
5596 particular operations as being provided, implementations are free to omit them if they
5597 cannot implement them in constant time.''<br>
5599 B. That paragraph says nothing about amortized constant time, and it should. </p>
5602 <p><b>Proposed resolution:</b></p>
5603 <p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..."
5607 <p>Table 68 lists sequence operations that are provided for some types of sequential
5608 containers but not others. An implementation shall provide these operations for all
5609 container types shown in the ``container'' column, and shall implement them so as to take
5610 amortized constant time.</p>
5617 <h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
5618 <p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5619 <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p>
5620 <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>
5621 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5622 <p><b>Discussion:</b></p>
5623 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
5626 — <tt>xpos <= pos</tt> and <tt>pos < size();</tt></p>
5628 <p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p>
5630 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
5631 proposed resolution.]</i></p>
5635 <p><b>Proposed resolution:</b></p>
5636 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
5638 — <tt>xpos <= pos</tt> and <tt>pos < size();<br>
5642 </tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt></p>
5648 <h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
5649 <p><b>Section:</b> 25.3.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5650 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-06-20</p>
5651 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5652 <p><b>Discussion:</b></p>
5653 <p>The lexicographical_compare complexity is specified as:<br>
5655 "At most min((last1 - first1), (last2 - first2))
5656 applications of the corresponding comparison."<br>
5658 The best I can do is twice that expensive.</p>
5660 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
5661 equality you have to check both < and >? Yes, IMO you are
5662 right! (and Matt states this complexity in his book)</p>
5666 <p><b>Proposed resolution:</b></p>
5667 <p>Change 25.3.8 [alg.lex.comparison] complexity to:</p>
5669 At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
5670 applications of the corresponding comparison.
5673 <p>Change the example at the end of paragraph 3 to read:</p>
5677 for ( ; first1 != last1 && first2 != last2 ;
5678 ++first1, ++first2) {<br>
5679 if (*first1 < *first2) return true;<br>
5680 if (*first2 < *first1) return false;<br>
5681 }<br>
5682 return first1 == last1 && first2 != last2;<br>
5683 <br>
5691 <h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
5692 <p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5693 <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p>
5694 <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>
5695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5696 <p><b>Discussion:</b></p>
5697 <p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
5698 to have complexity requirements which are incorrect, and which contradict the
5699 complexity requirements for insert(). I suspect that the text in question,
5700 below, was taken from vector:</p>
5702 <p>Complexity: If the iterators first and last are forward iterators,
5703 bidirectional iterators, or random access iterators the constructor makes only
5704 N calls to the copy constructor, and performs no reallocations, where N is
5707 <p>The word "reallocations" does not really apply to deque. Further,
5708 all of the following appears to be spurious:</p>
5710 <p>It makes at most 2N calls to the copy constructor of T and log N
5711 reallocations if they are input iterators.1)</p>
5712 <p>1) The complexity is greater in the case of input iterators because each
5713 element must be added individually: it is impossible to determine the distance
5714 between first abd last before doing the copying.</p>
5716 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
5717 an efficiency advantage from knowing in advance the number of elements to
5721 <p><b>Proposed resolution:</b></p>
5722 <p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
5723 footnote, with the following text (which also corrects the "abd"
5726 <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
5733 <h3><a name="146"></a>146. complex<T> Inserter and Extractor need sentries</h3>
5734 <p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5735 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
5736 <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>
5737 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5738 <p><b>Discussion:</b></p>
5739 <p>The extractor for complex numbers is specified as: </p>
5743 <p> template<class T, class charT, class traits> <br>
5744 basic_istream<charT, traits>& <br>
5745 operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br>
5747 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
5748 where u is the real part and v is the imaginary part
5749 (lib.istream.formatted). <br>
5750 Requires: The input values be convertible to T. If bad input is
5751 encountered, calls is.setstate(ios::failbit) (which may throw
5752 ios::failure (lib.iostate.flags). <br>
5756 <p>Is it intended that the extractor for complex numbers does not skip
5757 whitespace, unlike all other extractors in the standard library do?
5758 Shouldn't a sentry be used? <br>
5760 The inserter for complex numbers is specified as:</p>
5764 <p> template<class T, class charT, class traits> <br>
5765 basic_ostream<charT, traits>& <br>
5766 operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br>
5768 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
5770 template<class T, class charT, class traits> <br>
5771 basic_ostream<charT, traits>& <br>
5772 operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br>
5774 basic_ostringstream<charT, traits> s; <br>
5775 s.flags(o.flags()); <br>
5776 s.imbue(o.getloc()); <br>
5777 s.precision(o.precision()); <br>
5778 s << '(' << x.real() << "," << x.imag() << ')'; <br>
5779 return o << s.str(); <br>
5784 <p>Is it intended that the inserter for complex numbers ignores the
5785 field width and does not do any padding? If, with the suggested
5786 implementation above, the field width were set in the stream then the
5787 opening parentheses would be adjusted, but the rest not, because the
5788 field width is reset to zero after each insertion.</p>
5790 <p>I think that both operations should use sentries, for sake of
5791 consistency with the other inserters and extractors in the
5792 library. Regarding the issue of padding in the inserter, I don't know
5793 what the intent was. </p>
5796 <p><b>Proposed resolution:</b></p>
5797 <p>After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a
5802 <p>Notes: This extraction is performed as a series of simpler
5803 extractions. Therefore, the skipping of whitespace is specified to be the
5804 same for each of the simpler extractions.</p>
5809 <p><b>Rationale:</b></p>
5810 <p>For extractors, the note is added to make it clear that skipping whitespace
5811 follows an "all-or-none" rule.</p>
5813 <p>For inserters, the LWG believes there is no defect; the standard is correct
5820 <h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
5821 <p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5822 <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p>
5823 <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>
5824 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5825 <p><b>Discussion:</b></p>
5826 <p>The library had many global functions until 17.4.1.1 [lib.contents]
5827 paragraph 2 was added: </p>
5831 <p>All library entities except macros, operator new and operator
5832 delete are defined within the namespace std or namespaces nested
5833 within namespace std. </p>
5837 <p>It appears "global function" was never updated in the following: </p>
5841 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
5843 -1- It is unspecified whether any global functions in the C++ Standard
5844 Library are defined as inline (dcl.fct.spec).<br>
5846 -2- A call to a global function signature described in Clauses
5847 lib.language.support through lib.input.output behaves the same as if
5848 the implementation declares no additional global function
5851 [Footnote: A valid C++ program always calls the expected library
5852 global function. An implementation may also define additional
5853 global functions that would otherwise not be called by a valid C++
5854 program. --- end footnote]<br>
5856 -3- A global function cannot be declared by the implementation as
5857 taking additional default arguments. <br>
5859 17.4.4.4 - Member functions [lib.member.functions]<br>
5861 -2- An implementation can declare additional non-virtual member
5862 function signatures within a class: </p>
5866 <p>-- by adding arguments with default values to a member function
5867 signature; The same latitude does not extend to the implementation of
5868 virtual or global functions, however. </p>
5874 <p><b>Proposed resolution:</b></p>
5875 <p> Change "global" to "global or non-member" in:</p>
5877 <p>17.4.4.3 [lib.global.functions] section title,<br>
5878 17.4.4.3 [lib.global.functions] para 1,<br>
5879 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
5880 places in the footnote,<br>
5881 17.4.4.3 [lib.global.functions] para 3,<br>
5882 17.4.4.4 [lib.member.functions] para 2</p>
5886 <p><b>Rationale:</b></p>
5888 Because operator new and delete are global, the proposed resolution
5889 was changed from "non-member" to "global or non-member.
5896 <h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
5897 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5898 <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p>
5899 <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>
5900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5901 <p><b>Discussion:</b></p>
5902 <p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
5903 do_falsename() functions in the example facet BoolNames should be
5904 const. The functions they are overriding in
5905 numpunct_byname<char> are const. </p>
5908 <p><b>Proposed resolution:</b></p>
5909 <p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in
5912 <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
5913 string do_falsename() const { return "Mais Non!"; }</tt></p>
5920 <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
5921 <p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5922 <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
5923 <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>
5924 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5925 <p><b>Discussion:</b></p>
5928 <p><b>Proposed resolution:</b></p>
5929 <p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p>
5932 <p>Returns: The first iterator i in the range [first1, last1) such
5933 that for some integer j in the range [first2, last2) ...</p>
5939 <p>Returns: The first iterator i in the range [first1, last1) such
5940 that for some iterator j in the range [first2, last2) ...</p>
5947 <h3><a name="151"></a>151. Can't currently clear() empty container</h3>
5948 <p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5949 <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p>
5950 <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>
5951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5952 <p><b>Discussion:</b></p>
5953 <p>For both sequences and associative containers, a.clear() has the
5954 semantics of erase(a.begin(),a.end()), which is undefined for an empty
5955 container since erase(q1,q2) requires that q1 be dereferenceable
5956 (23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
5957 not dereferenceable.<br>
5959 The requirement that q1 be unconditionally dereferenceable causes many
5960 operations to be intuitively undefined, of which clearing an empty
5961 container is probably the most dire.<br>
5963 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
5964 q2) is required to be a valid range, stating that q1 and q2 must be
5965 iterators or certain kinds of iterators is unnecessary.
5969 <p><b>Proposed resolution:</b></p>
5970 <p>In 23.1.1, paragraph 3, change:</p>
5972 <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>
5976 <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
5979 <p>In 23.1.2, paragraph 7, change:</p>
5981 <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
5982 iterators to a, [q1, q2) is a valid range</p>
5986 <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
5994 <h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
5995 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
5996 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
5997 <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>
5998 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
5999 <p><b>Discussion:</b></p>
6000 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
6001 because there is no function <tt>is()</tt> which only takes a character as
6002 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
6006 <p><b>Proposed resolution:</b></p>
6007 <p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
6010 <p>"... such that <tt>is(*p)</tt>
6013 <p>to: "... such that <tt>is(m, *p)</tt>
6021 <h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
6022 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6023 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6024 <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>
6025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6026 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
6027 <p><b>Discussion:</b></p>
6028 <p>The description of the array version of <tt>narrow()</tt> (in
6029 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
6030 takes only three arguments because in addition to the range a default
6031 character is needed.</p>
6033 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
6034 two signatures followed by a <b>Returns</b> clause that only addresses
6039 <p><b>Proposed resolution:</b></p>
6040 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
6041 paragraph 10 from:</p>
6042 <p> Returns: do_widen(low, high, to).</p>
6045 <p> Returns: do_widen(c) or do_widen(low, high, to),
6048 <p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
6049 <pre> char narrow(char c, char /*dfault*/) const;
6050 const char* narrow(const char* low, const char* high,
6051 char /*dfault*/, char* to) const;</pre>
6052 <pre> Returns: do_narrow(low, high, to).</pre>
6054 <pre> char narrow(char c, char dfault) const;
6055 const char* narrow(const char* low, const char* high,
6056 char dfault, char* to) const;</pre>
6057 <pre> Returns: do_narrow(c, dfault) or
6058 do_narrow(low, high, dfault, to), respectively.</pre>
6060 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
6061 defined version could be different.]</i></p>
6064 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
6065 the LWG. He could find no other places the problem occurred. He
6066 asks for clarification of the Kona "a user defined
6067 version..." comment above. Perhaps it was a circuitous way of
6068 saying "dfault" needed to be uncommented?]</i></p>
6071 <p><i>[Post-Toronto: the issues list maintainer has merged in the
6072 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
6073 same paragraphs.]</i></p>
6081 <h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
6082 <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6083 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6084 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
6085 <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>
6086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6087 <p><b>Discussion:</b></p>
6088 <p>The table in paragraph 7 for the length modifier does not list the length
6089 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
6090 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
6091 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
6092 is actually a problem I found quite often in production code, too).</p>
6095 <p><b>Proposed resolution:</b></p>
6096 <p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
6097 Modifier table to say that for <tt>double</tt> a length modifier
6098 <tt>l</tt> is to be used.</p>
6101 <p><b>Rationale:</b></p>
6102 <p>The standard makes an embarrassing beginner's mistake.</p>
6108 <h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
6109 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6110 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6111 <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>
6112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6113 <p><b>Discussion:</b></p>
6114 <p>There are conflicting statements about where the class
6115 <tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2
6116 it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
6119 <p><b>Proposed resolution:</b></p>
6120 <p>Change 27.3 [iostream.objects] paragraph 2 from
6121 "<tt>basic_ios::Init"</tt> to
6122 "<tt>ios_base::Init"</tt>.</p>
6125 <p><b>Rationale:</b></p>
6126 <p>Although not strictly wrong, the standard was misleading enough to warrant
6133 <h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
6134 <p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6135 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6136 <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>
6137 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6138 <p><b>Discussion:</b></p>
6139 <p>There is a small discrepancy between the declarations of
6140 <tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as
6141 <tt>locale const&</tt> (correct), in 27.4.2.3 [ios.base.locales] it
6142 is passed as <tt>locale const</tt> (wrong).</p>
6145 <p><b>Proposed resolution:</b></p>
6146 <p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
6147 from "<tt>locale const" to "locale
6148 const&".</tt></p>
6154 <h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
6155 <p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6156 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6157 <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>
6158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6159 <p><b>Discussion:</b></p>
6160 <p>The default behavior of <tt>setbuf()</tt> is described only for the
6161 situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
6162 namely to do nothing. What has to be done in other situations
6163 is not described although there is actually only one reasonable
6164 approach, namely to do nothing, too.</p>
6166 <p>Since changing the buffer would almost certainly mess up most
6167 buffer management of derived classes unless these classes do it
6168 themselves, the default behavior of <tt>setbuf()</tt> should always be
6172 <p><b>Proposed resolution:</b></p>
6173 <p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
6174 to: "Default behavior: Does nothing. Returns this."</p>
6180 <h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
6181 <p><b>Section:</b> 27.5.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6182 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6184 <p><b>Discussion:</b></p>
6185 <p>The description of the meaning of the result of
6186 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
6187 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
6188 this function only reads the current character but does not extract
6189 it, <tt>uflow()</tt> would extract the current character. This should
6190 be fixed to use <tt>sbumpc()</tt> instead.</p>
6193 <p><b>Proposed resolution:</b></p>
6194 <p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
6195 <tt>showmanyc()</tt>returns clause, by replacing the word
6196 "supplied" with the words "extracted from the
6203 <h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
6204 <p><b>Section:</b> 27.6.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6205 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6206 <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>
6207 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6208 <p><b>Discussion:</b></p>
6209 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
6210 is not defined. Probably, the referred function is
6211 <tt>basic_ios<>::exceptions()</tt>.</p>
6214 <p><b>Proposed resolution:</b></p>
6215 <p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
6216 27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
6217 paragraph 1, change "<tt>exception()" to
6218 "exceptions()"</tt>.</p>
6220 <p><i>[Note to Editor: "exceptions" with an "s"
6221 is the correct spelling.]</i></p>
6229 <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
6230 <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6231 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6232 <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>
6233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6234 <p><b>Discussion:</b></p>
6235 <p>The note in the second paragraph pretends that the first argument
6236 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
6237 an object of type <tt>istreambuf_iterator</tt>.</p>
6240 <p><b>Proposed resolution:</b></p>
6241 <p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p>
6243 <p>The first argument provides an object of the istream_iterator class...</p>
6247 <p>The first argument provides an object of the istreambuf_iterator class...</p>
6255 <h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
6256 <p><b>Section:</b> 22.2.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6257 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</p>
6258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6259 <p><b>Discussion:</b></p>
6260 <p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
6261 as taking a fill character as an argument, but the description of the
6262 function does not say whether the character is used at all and, if so,
6263 in which way. The same holds for any format control parameters that
6264 are accessible through the ios_base& argument, such as the
6265 adjustment or the field width. Is strftime() supposed to use the fill
6266 character in any way? In any case, the specification of
6267 time_put.do_put() looks inconsistent to me.<br> <br> Is the
6268 signature of do_put() wrong, or is the effects clause incomplete?</p>
6271 <p><b>Proposed resolution:</b></p>
6272 <p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
6275 <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
6276 for this argument. --end Note]</p>
6280 <p><b>Rationale:</b></p>
6281 <p>The LWG felt that while the normative text was correct,
6282 users need some guidance on what to pass for the <tt>fill</tt>
6283 argument since the standard doesn't say how it's used.</p>
6289 <h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
6290 <p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6291 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6292 <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>
6293 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6294 <p><b>Discussion:</b></p>
6295 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
6296 functions falling into one of the groups "formatted output functions"
6297 and "unformatted output functions" calls any stream buffer function
6298 which might call a virtual function other than <tt>overflow()</tt>. Basically
6299 this is fine but this implies that <tt>sputn()</tt> (this function would call
6300 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
6301 output functions. Is this really intended? At minimum it would be convenient to
6302 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
6303 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
6304 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt>
6305 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
6306 under "unformatted output functions").</p>
6307 <p>In addition, I guess that the sentence starting with "They may use other
6308 public members of <tt>basic_ostream</tt> ..." probably was intended to
6309 start with "They may use other public members of <tt>basic_streamuf</tt>..."
6310 although the problem with the virtual members exists in both cases.</p>
6311 <p>I see two obvious resolutions:</p>
6313 <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
6314 called by any ostream member and that this is intended.</li>
6315 <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
6316 Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
6320 <p><b>Proposed resolution:</b></p>
6321 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
6323 <p>They may use other public members of basic_ostream except that they do not
6324 invoke any virtual members of rdbuf() except overflow().</p>
6328 <p>They may use other public members of basic_ostream except that they shall
6329 not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
6333 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
6334 PJP why the standard is written this way.]</i></p>
6337 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
6338 LWG. He comments: The rules can be made a little bit more specific if
6339 necessary be explicitly spelling out what virtuals are allowed to be
6340 called from what functions and eg to state specifically that flush()
6341 is allowed to call sync() while other functions are not.]</i></p>
6349 <h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
6350 <p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6351 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6352 <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>
6353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6354 <p><b>Discussion:</b></p>
6355 <p>Paragraph 4 states that the length is determined using
6356 <tt>traits::length(s)</tt>. Unfortunately, this function is not
6357 defined for example if the character type is <tt>wchar_t</tt> and the
6358 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
6359 the character type is <tt>char</tt> and the type of <tt>s</tt> is
6360 either <tt>signed char const*</tt> or <tt>unsigned char
6364 <p><b>Proposed resolution:</b></p>
6365 <p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
6367 <p>Effects: Behaves like an formatted inserter (as described in
6368 lib.ostream.formatted.reqmts) of out. After a sentry object is
6369 constructed it inserts characters. The number of characters starting
6370 at s to be inserted is traits::length(s). Padding is determined as
6371 described in lib.facet.num.put.virtuals. The traits::length(s)
6372 characters starting at s are widened using out.widen
6373 (lib.basic.ios.members). The widened characters and any required
6374 padding are inserted into out. Calls width(0).</p>
6378 <p>Effects: Behaves like a formatted inserter (as described in
6379 lib.ostream.formatted.reqmts) of out. After a sentry object is
6380 constructed it inserts <i>n</i> characters starting at <i>s</i>,
6381 where <i>n</i> is the number that would be computed as if by:</p>
6383 <li>traits::length(s) for the overload where the first argument is of
6384 type basic_ostream<charT, traits>& and the second is
6385 of type const charT*, and also for the overload where the first
6386 argument is of type basic_ostream<char, traits>& and
6387 the second is of type const char*.</li>
6388 <li>std::char_traits<char>::length(s)
6389 for the overload where the first argument is of type
6390 basic_ostream<charT, traits>& and the second is of type
6392 <li>traits::length(reinterpret_cast<const char*>(s))
6393 for the other two overloads.</li>
6395 <p>Padding is determined as described in
6396 lib.facet.num.put.virtuals. The <i>n</i> characters starting at
6397 <i>s</i> are widened using out.widen (lib.basic.ios.members). The
6398 widened characters and any required padding are inserted into
6399 out. Calls width(0).</p>
6402 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
6405 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
6406 number that would be computed as if by"]</i></p>
6411 <p><b>Rationale:</b></p>
6412 <p>We have five separate cases. In two of them we can use the
6413 user-supplied traits class without any fuss. In the other three we
6414 try to use something as close to that user-supplied class as possible.
6415 In two cases we've got a traits class that's appropriate for
6416 char and what we've got is a const signed char* or a const
6417 unsigned char*; that's close enough so we can just use a reinterpret
6418 cast, and continue to use the user-supplied traits class. Finally,
6419 there's one case where we just have to give up: where we've got a
6420 traits class for some arbitrary charT type, and we somehow have to
6421 deal with a const char*. There's nothing better to do but fall back
6422 to char_traits<char></p>
6429 <h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
6430 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6431 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6432 <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>
6433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6434 <p><b>Discussion:</b></p>
6435 <p>The first paragraph begins with a descriptions what has to be done
6436 in <i>formatted</i> output functions. Probably this is a typo and the
6437 paragraph really want to describe unformatted output functions...</p>
6440 <p><b>Proposed resolution:</b></p>
6441 <p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
6442 sentences, change the word "formatted" to
6445 <p>"Each <b>unformatted </b> output function begins ..."<br>
6446 "... value specified for the <b>unformatted </b> output
6454 <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
6455 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6456 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6457 <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>
6458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6459 <p><b>Discussion:</b></p>
6460 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
6461 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
6462 especially in view of the restriction that <tt>basic_ostream</tt>
6463 member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer
6464 is to be created.</p>
6465 <p>Of course, the resolution below requires some handling of
6466 simultaneous input and output since it is no longer possible to update
6467 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
6468 solution is to handle this in <tt>underflow()</tt>.</p>
6471 <p><b>Proposed resolution:</b></p>
6472 <p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
6473 "at least" as in the following:</p>
6475 <p>To make a write position available, the function reallocates (or initially
6476 allocates) an array object with a sufficient number of elements to hold the
6477 current array object (if any), plus <b>at least</b> one additional write
6485 <h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
6486 <p><b>Section:</b> 27.7.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6487 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6489 <p><b>Discussion:</b></p>
6490 <p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]),
6491 <tt>basic_istringstream</tt> (27.7.2 [istringstream]), and
6492 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent
6493 in their definition of the type <tt>traits_type</tt>: For
6494 <tt>istringstream</tt>, this type is defined, for the other two it is
6495 not. This should be consistent.</p>
6498 <p><b>Proposed resolution:</b></p>
6499 <p><b>Proposed resolution:</b></p> <p>To the declarations of
6500 <tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and
6501 <tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p>
6503 <pre>typedef traits traits_type;</pre>
6510 <h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
6511 <p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6512 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
6513 <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>
6514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6515 <p><b>Discussion:</b></p>
6516 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
6517 output position is maintained by <tt>basic_filebuf</tt>. Still, the
6518 description of <tt>seekpos()</tt> seems to talk about different file
6519 positions. In particular, it is unclear (at least to me) what is
6520 supposed to happen to the output buffer (if there is one) if only the
6521 input position is changed. The standard seems to mandate that the
6522 output buffer is kept and processed as if there was no positioning of
6523 the output position (by changing the input position). Of course, this
6524 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
6525 set. However, I think, the standard should say something like
6528 <li>If <tt>(which & mode) == 0</tt> neither read nor write position is
6529 changed and the call fails. Otherwise, the joint read and write position is
6530 altered to correspond to <tt>sp</tt>.</li>
6531 <li>If there is an output buffer, the output sequences is updated and any
6532 unshift sequence is written before the position is altered.</li>
6533 <li>If there is an input buffer, the input sequence is updated after the
6534 position is altered.</li>
6536 <p>Plus the appropriate error handling, that is...</p>
6539 <p><b>Proposed resolution:</b></p>
6540 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
6541 paragraph 14 from:</p>
6543 <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6545 <p>Alters the file position, if possible, to correspond to the position stored
6546 in sp (as described below).</p>
6547 <p>- if (which&ios_base::in)!=0, set the file position to sp, then update
6548 the input sequence</p>
6549 <p>- if (which&ios_base::out)!=0, then update the output sequence, write
6550 any unshift sequence, and set the file position to sp.</p>
6554 <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
6556 <p>Alters the file position, if possible, to correspond to the position stored
6557 in sp (as described below). Altering the file position performs as follows:</p>
6558 <p>1. if (om & ios_base::out)!=0, then update the output sequence and
6559 write any unshift sequence;</p>
6560 <p>2. set the file position to sp;</p>
6561 <p>3. if (om & ios_base::in)!=0, then update the input sequence;</p>
6562 <p>where om is the open mode passed to the last call to open(). The operation
6563 fails if is_open() returns false.</p>
6566 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
6568 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
6576 <h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
6577 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6578 <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6579 <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>
6580 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6581 <p><b>Discussion:</b></p>
6582 <p>In 27.6.1.1 [istream] the function
6583 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
6584 argument. However, in 27.6.1.3 [istream.unformatted]
6585 paragraph 23 the first argument is of type <tt>int.</tt></p>
6587 <p>As far as I can see this is not really a contradiction because
6588 everything is consistent if <tt>streamsize</tt> is typedef to be
6589 <tt>int</tt>. However, this is almost certainly not what was
6590 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
6591 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
6594 submitted this issue, commenting: Either 27.6.1.1 should be modified
6595 to show a first parameter of type int, or 27.6.1.3 should be modified
6596 to show a first parameter of type streamsize and use
6597 numeric_limits<streamsize>::max.</p>
6600 <p><b>Proposed resolution:</b></p>
6601 <p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
6602 of <tt>int</tt> in the description of <tt>ignore()</tt> to
6603 <tt>streamsize</tt>.</p>
6609 <h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
6610 <p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6611 <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6612 <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>
6613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6614 <p><b>Discussion:</b></p>
6617 In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
6618 object of type <tt>streamsize</tt> as second argument. However, in
6619 27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
6624 As far as I can see this is not really a contradiction because
6625 everything is consistent if <tt>streamsize</tt> is typedef to be
6626 <tt>int</tt>. However, this is almost certainly not what was
6627 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
6628 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
6633 <p><b>Proposed resolution:</b></p>
6634 <p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of
6635 <tt>int</tt> in the description of <tt>setbuf()</tt> to
6636 <tt>streamsize</tt>.</p>
6642 <h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
6643 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6644 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6645 <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>
6646 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6647 <p><b>Discussion:</b></p>
6648 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
6649 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
6650 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
6653 <p><b>Proposed resolution:</b></p>
6654 <p>Change D.6 [depr.ios.members] paragraph 1 from "<tt>typedef
6655 OFF_T streampos;</tt>" to "<tt>typedef POS_T
6656 streampos;</tt>"</p>
6662 <h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
6663 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6664 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6665 <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>
6666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6667 <p><b>Discussion:</b></p>
6668 <p>According to paragraph 8 of this section, the methods
6669 <tt>basic_streambuf::pubseekpos()</tt>,
6670 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
6671 "may" be overloaded by a version of this function taking the
6672 type <tt>ios_base::open_mode</tt> as last argument argument instead of
6673 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
6674 in this section to be an alias for one of the integral types). The
6675 clause specifies, that the last argument has a default argument in
6676 three cases. However, this generates an ambiguity with the overloaded
6677 version because now the arguments are absolutely identical if the last
6678 argument is not specified.</p>
6681 <p><b>Proposed resolution:</b></p>
6682 <p>In D.6 [depr.ios.members] paragraph 8, remove the default arguments for
6683 <tt>basic_streambuf::pubseekpos()</tt>,
6684 <tt>basic_ifstream::open()</tt>, and
6685 <tt>basic_ofstream::open().</tt></p>
6691 <h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
6692 <p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6693 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p>
6694 <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>
6695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6696 <p><b>Discussion:</b></p>
6697 <p>The "overload" for the function <tt>exceptions()</tt> in
6698 paragraph 8 gives the impression that there is another function of
6699 this function defined in class <tt>ios_base</tt>. However, this is not
6700 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
6701 be implemented: "Call the corresponding member function specified
6702 in clause 27 [input.output]."</p>
6705 <p><b>Proposed resolution:</b></p>
6706 <p>In D.6 [depr.ios.members] paragraph 8, move the declaration of the
6707 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
6713 <h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
6714 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
6715 <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-07-02</p>
6716 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
6717 <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>
6718 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6719 <p><b>Discussion:</b></p>
6720 <p>Currently the following will not compile on two well-known standard
6721 library implementations:</p>
6724 <pre>#include <set>
6725 using namespace std;
6727 void f(const set<int> &s)
6729 set<int>::iterator i;
6730 if (i==s.end()); // s.end() returns a const_iterator
6735 The reason this doesn't compile is because operator== was implemented
6736 as a member function of the nested classes set:iterator and
6737 set::const_iterator, and there is no conversion from const_iterator to
6738 iterator. Surprisingly, (s.end() == i) does work, though, because of
6739 the conversion from iterator to const_iterator.
6743 I don't see a requirement anywhere in the standard that this must
6744 work. Should there be one? If so, I think the requirement would need
6745 to be added to the tables in section 24.1.1. I'm not sure about the
6746 wording. If this requirement existed in the standard, I would think
6747 that implementors would have to make the comparison operators
6748 non-member functions.</p>
6750 <p>This issues was also raised on comp.std.c++ by Darin
6751 Adler. The example given was:</p>
6754 <pre>bool check_equal(std::deque<int>::iterator i,
6755 std::deque<int>::const_iterator ci)
6761 <p>Comment from John Potter:</p>
6764 In case nobody has noticed, accepting it will break reverse_iterator.
6768 The fix is to make the comparison operators templated on two types.
6771 <pre> template <class Iterator1, class Iterator2>
6772 bool operator== (reverse_iterator<Iterator1> const& x,
6773 reverse_iterator<Iterator2> const& y);
6777 Obviously: return x.base() == y.base();
6781 Currently, no reverse_iterator to const_reverse_iterator compares are
6786 BTW, I think the issue is in support of bad code. Compares should be
6787 between two iterators of the same type. All std::algorithms require
6788 the begin and end iterators to be of the same type.
6793 <p><b>Proposed resolution:</b></p>
6794 <p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p>
6796 <p>In the expressions</p>
6805 <p>Where i and j denote objects of a container's iterator type,
6806 either or both may be replaced by an object of the container's
6807 const_iterator type referring to the same element with no
6808 change in semantics.</p>
6811 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
6812 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
6813 iterator comparison and difference operations.]</i></p>
6816 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
6817 explicitly listed expressions; there was concern that the previous
6818 proposed resolution was too informal.]</i></p>
6822 <p><b>Rationale:</b></p>
6824 The LWG believes it is clear that the above wording applies only to
6825 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
6826 where <tt>X</tt> is a container. There is no requirement that
6827 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
6828 can be mixed. If mixing them is considered important, that's a
6829 separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
6836 <h3><a name="181"></a>181. make_pair() unintended behavior</h3>
6837 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
6838 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</p>
6839 <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>
6840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
6841 <p><b>Discussion:</b></p>
6842 <p>The claim has surfaced in Usenet that expressions such as<br>
6844 <tt>make_pair("abc", 3)</tt><br>
6846 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
6847 parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br>
6849 I doubt anyone intended that behavior...
6853 <p><b>Proposed resolution:</b></p>
6854 <p>In 20.2 [utility], paragraph 1 change the following
6855 declaration of make_pair():</p>
6857 <pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
6861 <pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
6863 <p> In 20.2.3 [pairs] paragraph 7 and the line before, change:</p>
6865 <pre>template <class T1, class T2>
6866 pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
6870 <pre>template <class T1, class T2>
6871 pair<T1, T2> make_pair(T1 x, T2 y);</pre>
6873 <p>and add the following footnote to the effects clause:</p>
6875 <p> According to 12.8 [class.copy], an implementation is permitted
6876 to not perform a copy of an argument, thus avoiding unnecessary
6881 <p><b>Rationale:</b></p>
6882 <p>Two potential fixes were suggested by Matt Austern and Dietmar
6883 Kühl, respectively, 1) overloading with array arguments, and 2) use of
6884 a reference_traits class with a specialization for arrays. Andy
6885 Koenig suggested changing to pass by value. In discussion, it appeared
6886 that this was a much smaller change to the standard that the other two
6887 suggestions, and any efficiency concerns were more than offset by the
6888 advantages of the solution. Two implementors reported that the
6889 proposed resolution passed their test suites.</p>
6895 <h3><a name="182"></a>182. Ambiguous references to size_t</h3>
6896 <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>
6897 <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</p>
6898 <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>
6899 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6900 <p><b>Discussion:</b></p>
6901 <p>Many references to <tt> size_t</tt> throughout the document
6902 omit the <tt> std::</tt> namespace qualification.</p> <p>For
6903 example, 17.4.3.5 [replacement.functions] paragraph 2:</p>
6905 <pre> operator new(size_t)
6906 operator new(size_t, const std::nothrow_t&)
6907 operator new[](size_t)
6908 operator new[](size_t, const std::nothrow_t&)</pre>
6912 <p><b>Proposed resolution:</b></p>
6913 <p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p>
6915 <p><tt> - operator new(size_t)<br>
6916 - operator new(size_t, const std::nothrow_t&)<br>
6917 - operator new[](size_t)<br>
6918 - operator new[](size_t, const std::nothrow_t&)</tt></p>
6922 <pre>- operator new(std::size_t)
6923 - operator new(std::size_t, const std::nothrow_t&)
6924 - operator new[](std::size_t)
6925 - operator new[](std::size_t, const std::nothrow_t&)</pre>
6927 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
6929 <p>The typedef members pointer, const_pointer, size_type, and difference_type
6930 are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
6934 <p>The typedef members pointer, const_pointer, size_type, and difference_type
6935 are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
6938 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
6940 <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
6941 <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
6942 is unspecified when or how often this function is called. The use of hint is
6943 unspecified, but intended as an aid to locality if an implementation so
6948 <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
6949 <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
6950 it is unspecified when or how often this function is called. The use of hint
6951 is unspecified, but intended as an aid to locality if an implementation so
6954 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
6956 <p>In Table 37, X denotes a Traits class defining types and functions for the
6957 character container type CharT; c and d denote values of type CharT; p and q
6958 denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6959 j denote values of type size_t; e and f denote values of type X::int_type; pos
6960 denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6964 <p>In Table 37, X denotes a Traits class defining types and functions for the
6965 character container type CharT; c and d denote values of type CharT; p and q
6966 denote values of type const CharT*; s denotes a value of type CharT*; n, i and
6967 j denote values of type std::size_t; e and f denote values of type X::int_type;
6968 pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
6970 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
6971 X::length(p): "size_t" by "std::size_t".</p>
6972 <p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
6973 typedef ptrdiff_t difference_type;<br>
6975 typedef std::ptrdiff_t difference_type;</p>
6976 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
6977 declaration of template <class charT> class ctype.<br>
6979 In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
6981 template<class Iterator> struct iterator_traits<br>
6982 template<class T> struct iterator_traits<T*><br>
6983 template<class T> struct iterator_traits<const T*></p>
6986 <p><b>Rationale:</b></p>
6987 <p>The LWG believes correcting names like <tt>size_t</tt> and
6988 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
6989 to be essentially editorial. There there can't be another size_t or
6990 ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],</p>
6993 For each type T from the Standard C library, the types ::T and std::T
6994 are reserved to the implementation and, when defined, ::T shall be
6995 identical to std::T.
6998 <p>The issue is treated as a Defect Report to make explicit the Project
6999 Editor's authority to make this change.</p>
7001 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
7002 request of the LWG.]</i></p>
7005 <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
7006 address use of the name <tt>size_t</tt> in contexts outside of
7007 namespace std, such as in the description of <tt>::operator new</tt>.
7008 The proposed changes should be reviewed to make sure they are
7012 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
7013 them to be correct.]</i></p>
7022 <h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
7023 <p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7024 <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-07-07</p>
7025 <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>
7026 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7027 <p><b>Discussion:</b></p>
7028 <p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for
7031 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
7032 of) basic_ostream then the expression out<<s behaves as if f(s) were
7033 called, and if [2] in is an (instance of) basic_istream then the expression
7034 in>>s behaves as if f(s) were called. Where f can be defined as: ios_base&
7035 f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags
7036 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
7037 out<<s has type ostream& and value out. [4] The expression in>>s
7038 has type istream& and value in.</p>
7040 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
7041 "The expression out << s has type basic_ostream& ..." and
7042 [4] should read: "The expression in >> s has type basic_istream&
7044 <p>If the wording in the standard is correct, I can see no way of implementing
7045 any of the manipulators so that they will work with wide character streams.</p>
7046 <p>e.g. wcout << setbase( 16 );</p>
7047 <p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which
7049 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
7050 8. In addition, Para 6 [setfill] has a similar error, but relates only to
7052 <p>I'd be happier if there was a better way of saying this, to make it clear
7053 that the value of the expression is "the same specialization of
7054 basic_ostream as out"&</p>
7057 <p><b>Proposed resolution:</b></p>
7058 <p>Replace section 27.6.3 [std.manip] except paragraph 1 with the
7061 <p>2- The type designated smanip in each of the following function
7062 descriptions is implementation-specified and may be different for each
7065 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
7067 -3- Returns: An object s of unspecified type such that if out is an
7068 instance of basic_ostream<charT,traits> then the expression
7069 out<<s behaves
7070 as if f(s, mask) were called, or if in is an instance of
7071 basic_istream<charT,traits> then the expression in>>s
7073 f(s, mask) were called. The function f can be defined as:*<br>
7075 [Footnote: The expression cin >> resetiosflags(ios_base::skipws)
7076 clears ios_base::skipws in the format flags stored in the
7077 basic_istream<charT,traits> object cin (the same as cin >>
7078 noskipws), and the expression cout <<
7079 resetiosflags(ios_base::showbase) clears
7080 ios_base::showbase in the format flags stored in the
7081 basic_ostream<charT,traits> object cout (the same as cout
7083 noshowbase). --- end footnote]<br>
7085 <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
7087 // reset specified flags<br>
7088 str.setf(ios_base::fmtflags(0), mask);<br>
7089 return str;<br>
7092 The expression out<<s has type basic_ostream<charT,traits>& and value out.
7093 The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
7095 <tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
7097 -4- Returns: An object s of unspecified type such that if out is an
7098 instance of basic_ostream<charT,traits> then the expression
7099 out<<s behaves
7100 as if f(s, mask) were called, or if in is an instance of
7101 basic_istream<charT,traits> then the expression in>>s
7103 mask) were called. The function f can be defined as:<br>
7105 <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
7107 // set specified flags<br>
7108 str.setf(mask);<br>
7109 return str;<br>
7112 The expression out<<s has type basic_ostream<charT,traits>& and value out.
7113 The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
7115 <tt>smanip setbase(int base);</tt><br>
7117 -5- Returns: An object s of unspecified type such that if out is an
7118 instance of basic_ostream<charT,traits> then the expression
7119 out<<s behaves
7120 as if f(s, base) were called, or if in is an instance of
7121 basic_istream<charT,traits> then the expression in>>s
7123 base) were called. The function f can be defined as:<br>
7125 <tt>ios_base& f(ios_base& str, int base)<br>
7127 // set basefield<br>
7128 str.setf(base == 8 ? ios_base::oct :<br>
7129 base == 10 ? ios_base::dec :<br>
7130 base == 16 ? ios_base::hex :<br>
7131 ios_base::fmtflags(0), ios_base::basefield);<br>
7132 return str;<br>
7135 The expression out<<s has type basic_ostream<charT,traits>& and value out.
7136 The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
7138 <tt>smanip setfill(char_type c);<br>
7140 -6- Returns: An object s of unspecified type such that if out is (or is
7141 derived from) basic_ostream<charT,traits> and c has type charT
7143 expression out<<s behaves as if f(s, c) were called. The function
7147 <tt>template<class charT, class traits><br>
7148 basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br>
7150 // set fill character<br>
7151 str.fill(c);<br>
7152 return str;<br>
7155 The expression out<<s has type basic_ostream<charT,traits>& and value out.<br>
7157 <tt>smanip setprecision(int n);</tt><br>
7159 -7- Returns: An object s of unspecified type such that if out is an
7160 instance of basic_ostream<charT,traits> then the expression
7161 out<<s behaves
7162 as if f(s, n) were called, or if in is an instance of
7163 basic_istream<charT,traits> then the expression in>>s
7164 behaves as if f(s, n)
7165 were called. The function f can be defined as:<br>
7167 <tt>ios_base& f(ios_base& str, int n)<br>
7169 // set precision<br>
7170 str.precision(n);<br>
7171 return str;<br>
7174 The expression out<<s has type basic_ostream<charT,traits>& and value out.
7175 The expression in>>s has type basic_istream<charT,traits>& and value in<br>
7177 <tt>smanip setw(int n);<br>
7179 -8- Returns: An object s of unspecified type such that if out is an
7180 instance of basic_ostream<charT,traits> then the expression
7181 out<<s behaves
7182 as if f(s, n) were called, or if in is an instance of
7183 basic_istream<charT,traits> then the expression in>>s
7184 behaves as if f(s, n)
7185 were called. The function f can be defined as:<br>
7187 <tt>ios_base& f(ios_base& str, int n)<br>
7189 // set width<br>
7190 str.width(n);<br>
7191 return str;<br>
7194 The expression out<<s has type
7195 basic_ostream<charT,traits>& and value out. The expression
7196 in>>s has type basic_istream<charT,traits>& and value
7201 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
7202 the proposed resolution.]</i></p>
7205 <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
7206 the same paragraphs.]</i></p>
7209 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
7210 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
7211 intertwined that dealing with them separately appear fraught with
7212 error. The full text was supplied by Bill Plauger; it was cross
7213 checked against changes supplied by Andy Sawyer. It should be further
7214 checked by the LWG.]</i></p>
7222 <h3><a name="184"></a>184. numeric_limits<bool> wording problems</h3>
7223 <p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7224 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p>
7225 <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>
7226 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7227 <p><b>Discussion:</b></p>
7228 <p>bools are defined by the standard to be of integer types, as per
7229 3.9.1 [basic.fundamental] paragraph 7. However "integer types"
7230 seems to have a special meaning for the author of 18.2. The net effect
7231 is an unclear and confusing specification for
7232 numeric_limits<bool> as evidenced below.</p>
7234 <p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer
7235 types, the number of non-sign bits in the representation.</p>
7237 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
7238 arithmetical value converts to true.</p>
7240 <p>I don't think it makes sense at all to require
7241 numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to
7244 <p>The standard defines what constitutes a signed (resp. unsigned) integer
7245 types. It doesn't categorize bool as being signed or unsigned. And the set of
7246 values of bool type has only two elements.</p>
7248 <p>I don't think it makes sense to require numeric_limits<bool>::is_signed
7249 to be meaningful.</p>
7251 <p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p>
7253 <p>For integer types, specifies the base of the representation.186)</p>
7256 <p>This disposition is at best misleading and confusing for the standard
7257 requires a "pure binary numeration system" for integer types as per
7260 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
7261 BCD)." This also erroneous as the standard never defines any integer
7262 types with base representation other than 2.</p>
7264 <p>Furthermore, numeric_limits<bool>::is_modulo and
7265 numeric_limits<bool>::is_signed have similar problems.</p>
7268 <p><b>Proposed resolution:</b></p>
7269 <p>Append to the end of 18.2.1.5 [numeric.special]:</p>
7271 <p>The specialization for bool shall be provided as follows:</p>
7272 <pre> namespace std {
7273 template<> class numeric_limits<bool> {
7275 static const bool is_specialized = true;
7276 static bool min() throw() { return false; }
7277 static bool max() throw() { return true; }
7279 static const int digits = 1;
7280 static const int digits10 = 0;
7281 static const bool is_signed = false;
7282 static const bool is_integer = true;
7283 static const bool is_exact = true;
7284 static const int radix = 2;
7285 static bool epsilon() throw() { return 0; }
7286 static bool round_error() throw() { return 0; }
7288 static const int min_exponent = 0;
7289 static const int min_exponent10 = 0;
7290 static const int max_exponent = 0;
7291 static const int max_exponent10 = 0;
7293 static const bool has_infinity = false;
7294 static const bool has_quiet_NaN = false;
7295 static const bool has_signaling_NaN = false;
7296 static const float_denorm_style has_denorm = denorm_absent;
7297 static const bool has_denorm_loss = false;
7298 static bool infinity() throw() { return 0; }
7299 static bool quiet_NaN() throw() { return 0; }
7300 static bool signaling_NaN() throw() { return 0; }
7301 static bool denorm_min() throw() { return 0; }
7303 static const bool is_iec559 = false;
7304 static const bool is_bounded = true;
7305 static const bool is_modulo = false;
7307 static const bool traps = false;
7308 static const bool tinyness_before = false;
7309 static const float_round_style round_style = round_toward_zero;
7314 <p><i>[Tokyo: The LWG desires wording that specifies exact values
7315 rather than more general wording in the original proposed
7316 resolution.]</i></p>
7319 <p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico
7320 Josuttis provided the above wording.]</i></p>
7328 <h3><a name="185"></a>185. Questionable use of term "inline"</h3>
7329 <p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7330 <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
7331 <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>
7332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7333 <p><b>Discussion:</b></p>
7334 <p>Paragraph 4 of 20.6 [function.objects] says:</p>
7336 <p> [Example: To negate every element of a: transform(a.begin(), a.end(),
7337 a.begin(), negate<double>()); The corresponding functions will inline
7338 the addition and the negation. end example]</p>
7340 <p>(Note: The "addition" referred to in the above is in para 3) we can
7341 find no other wording, except this (non-normative) example which suggests that
7342 any "inlining" will take place in this case.</p>
7345 <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
7346 unspecified whether any global functions in the C++ Standard Library
7347 are defined as inline (7.1.2).</p>
7351 <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
7352 unspecified whether any member functions in the C++ Standard Library
7353 are defined as inline (7.1.2).</p>
7355 <p>take care to state that this may indeed NOT be the case.</p>
7356 <p>Thus the example "mandates" behavior that is explicitly
7357 not required elsewhere.</p>
7360 <p><b>Proposed resolution:</b></p>
7361 <p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p>
7363 <p>They are important for the effective use of the library.</p>
7365 <p>Remove 20.6 [function.objects] paragraph 2, which reads:</p>
7367 <p> Using function objects together with function templates
7368 increases the expressive power of the library as well as making the
7369 resulting code much more efficient.</p>
7371 <p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p>
7373 <p>The corresponding functions will inline the addition and the
7377 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
7379 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
7387 <h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
7388 <p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7389 <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p>
7390 <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>
7391 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7392 <p><b>Discussion:</b></p>
7393 <p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the
7394 bitset::set operation to take a second parameter of type int. The
7395 function tests whether this value is non-zero to determine whether to
7396 set the bit to true or false. The type of this second parameter should
7397 be bool. For one thing, the intent is to specify a Boolean value. For
7398 another, the result type from test() is bool. In addition, it's
7399 possible to slice an integer that's larger than an int. This can't
7400 happen with bool, since conversion to bool has the semantic of
7401 translating 0 to false and any non-zero value to true.</p>
7404 <p><b>Proposed resolution:</b></p>
7405 <p>In 23.3.5 [template.bitset] Para 1 Replace:</p>
7407 <pre>bitset<N>& set(size_t pos, int val = true ); </pre>
7411 <pre>bitset<N>& set(size_t pos, bool val = true );</pre>
7413 <p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p>
7415 <pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
7419 <pre>bitset<N>& set(size_t pos, bool val = true );</pre>
7422 <p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work
7423 on better P/R wording.]</i></p>
7425 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
7429 <p><b>Rationale:</b></p>
7430 <p><tt>bool</tt> is a better choice. It is believed that binary
7431 compatibility is not an issue, because this member function is
7432 usually implemented as <tt>inline</tt>, and because it is already
7433 the case that users cannot rely on the type of a pointer to a
7434 nonvirtual member of a standard library class.</p>
7441 <h3><a name="187"></a>187. iter_swap underspecified</h3>
7442 <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7443 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</p>
7444 <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>
7445 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7446 <p><b>Discussion:</b></p>
7447 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
7448 ``exchanges the values'' of the objects to which two iterators
7449 refer.<br> <br> What it doesn't say is whether it does so using swap
7450 or using the assignment operator and copy constructor.<br> <br> This
7451 question is an important one to answer, because swap is specialized to
7452 work efficiently for standard containers.<br> For example:</p>
7454 <pre>vector<int> v1, v2;
7455 iter_swap(&v1, &v2);</pre>
7457 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?
7458 Or is it equivalent to</p>
7461 vector<int> temp = v1;
7466 <p>The first alternative is O(1); the second is O(n).</p>
7467 <p>A LWG member, Dave Abrahams, comments:</p>
7469 <p>Not an objection necessarily, but I want to point out the cost of
7470 that requirement:</p>
7472 <p><tt>iter_swap(list<T>::iterator, list<T>::iterator)</tt></p>
7474 <p>can currently be specialized to be more efficient than
7475 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
7476 make that optimization illegal. </p>
7479 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
7480 which are no longer permitted.]</i></p>
7484 <p><b>Proposed resolution:</b></p>
7485 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
7487 <p>Exchanges the values pointed to by the two iterators a and b.</p>
7491 <p><tt>swap(*a, *b)</tt>.</p>
7496 <p><b>Rationale:</b></p>
7497 <p>It's useful to say just what <tt>iter_swap</tt> does. There may be
7498 some iterators for which we want to specialize <tt>iter_swap</tt>,
7499 but the fully general version should have a general specification.</p>
7501 <p>Note that in the specific case of <tt>list<T>::iterator</tt>,
7502 iter_swap should not be specialized as suggested above. That would do
7503 much more than exchanging the two iterators' values: it would change
7504 predecessor/successor relationships, possibly moving the iterator from
7505 one list to another. That would surely be inappropriate.</p>
7512 <h3><a name="189"></a>189. setprecision() not specified correctly</h3>
7513 <p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7514 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p>
7515 <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>
7516 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7517 <p><b>Discussion:</b></p>
7518 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
7519 and includes a parenthetical note saying that it is the number of
7520 digits after the decimal point.<br>
7522 This claim is not strictly correct. For example, in the default
7523 floating-point output format, setprecision sets the number of
7524 significant digits printed, not the number of digits after the decimal
7527 I would like the committee to look at the definition carefully and
7528 correct the statement in 27.4.2.2</p>
7531 <p><b>Proposed resolution:</b></p>
7532 <p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
7533 "(number of digits after the decimal point)".</p>
7539 <h3><a name="193"></a>193. Heap operations description incorrect</h3>
7540 <p><b>Section:</b> 25.3.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7541 <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</p>
7542 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7543 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
7544 <p><b>Discussion:</b></p>
7545 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
7548 `"(1) *a is the largest element"<br>
7550 I think this is incorrect and should be changed to the wording in the proposed
7552 <p>Actually there are two independent changes:</p>
7554 <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
7555 [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
7557 'an oldest' from that equivalence class, otherwise the heap functions
7558 could not be used for a priority queue as explained in 23.2.3.2.2
7559 [lib.priqueue.members] (where I assume that a "priority queue" respects
7560 priority AND time).</p>
7564 <p><b>Proposed resolution:</b></p>
7565 <p>Change 25.3.6 [alg.heap.operations] property (1) from:</p>
7567 <p>(1) *a is the largest element</p>
7571 <p>(1) There is no element greater than <tt>*a</tt></p>
7579 <h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
7580 <p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7581 <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-10-13</p>
7582 <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>
7583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7584 <p><b>Discussion:</b></p>
7585 <p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
7586 What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
7587 reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
7588 should set failbit. Should it set eofbit as well? The standard
7589 doesn't seem to answer that question.</p>
7591 <p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
7592 <tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
7593 other hand, 27.6.1.1 [istream] paragraph 4 says that if
7594 extraction from a <tt>streambuf</tt> "returns
7595 <tt>traits::eof()</tt>, then the input function, except as explicitly
7596 noted otherwise, completes its actions and does
7597 <tt>setstate(eofbit)"</tt>. So the question comes down to
7598 whether <tt>basic_istream<>::sentry</tt>'s constructor is an
7601 <p>Comments from Jerry Schwarz:</p>
7603 <p>It was always my intention that eofbit should be set any time that a
7604 virtual returned something to indicate eof, no matter what reason
7605 iostream code had for calling the virtual.</p>
7607 The motivation for this is that I did not want to require streambufs
7608 to behave consistently if their virtuals are called after they have
7611 The classic case is a streambuf reading from a UNIX file. EOF isn't
7612 really a state for UNIX file descriptors. The convention is that a
7613 read on UNIX returns 0 bytes to indicate "EOF", but the file
7614 descriptor isn't shut down in any way and future reads do not
7615 necessarily also return 0 bytes. In particular, you can read from
7616 tty's on UNIX even after they have signaled "EOF". (It
7617 isn't always understood that a ^D on UNIX is not an EOF indicator, but
7618 an EOL indicator. By typing a "line" consisting solely of
7619 ^D you cause a read to return 0 bytes, and by convention this is
7620 interpreted as end of file.)</p>
7624 <p><b>Proposed resolution:</b></p>
7625 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
7627 <p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt>
7628 returns <tt>traits::eof()</tt>, the function calls
7629 <tt>setstate(failbit | eofbit)</tt> (which may throw
7630 <tt>ios_base::failure</tt>).
7638 <h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
7639 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7640 <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-03</p>
7641 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
7642 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
7643 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7644 <p><b>Discussion:</b></p>
7646 Is a pointer or reference obtained from an iterator still valid after
7647 destruction of the iterator?
7650 Is a pointer or reference obtained from an iterator still valid after the value
7651 of the iterator changes?
7654 <pre>#include <iostream>
7655 #include <vector>
7656 #include <iterator>
7660 typedef std::vector<int> vec_t;
7664 // Is a pointer or reference obtained from an iterator still
7665 // valid after destruction of the iterator?
7666 int * p = &*v.begin();
7667 std::cout << *p << '\n'; // OK?
7669 // Is a pointer or reference obtained from an iterator still
7670 // valid after the value of the iterator changes?
7671 vec_t::iterator iter( v.begin() );
7673 std::cout << *p << '\n'; // OK?
7680 <p>The standard doesn't appear to directly address these
7681 questions. The standard needs to be clarified. At least two real-world
7682 cases have been reported where library implementors wasted
7683 considerable effort because of the lack of clarity in the
7684 standard. The question is important because requiring pointers and
7685 references to remain valid has the effect for practical purposes of
7686 prohibiting iterators from pointing to cached rather than actual
7687 elements of containers.</p>
7689 <p>The standard itself assumes that pointers and references obtained
7690 from an iterator are still valid after iterator destruction or
7691 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
7695 <pre>Iterator tmp = current;
7696 return *--tmp;</pre>
7698 <p>The definition of reverse_iterator::operator->(), 24.4.1.3.4
7699 [reverse.iter.op.star], which returns a pointer, defines effects:</p>
7701 <pre>return &(operator*());</pre>
7704 <p>Because the standard itself assumes pointers and references remain
7705 valid after iterator destruction or change, the standard should say so
7706 explicitly. This will also reduce the chance of user code breaking
7707 unexpectedly when porting to a different standard library
7711 <p><b>Proposed resolution:</b></p>
7712 <p>Add a new paragraph to 24.1 [iterator.requirements]:</p>
7714 Destruction of an iterator may invalidate pointers and references
7715 previously obtained from that iterator.
7718 <p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p>
7721 <p><b>Effects:</b></p>
7722 <pre> this->tmp = current;
7724 return *this->tmp;
7728 [<i>Note:</i> This operation must use an auxiliary member variable,
7729 rather than a temporary variable, to avoid returning a reference that
7730 persists beyond the lifetime of its associated iterator. (See
7731 24.1 [iterator.requirements].) The name of this member variable is shown for
7732 exposition only. <i>--end note</i>]
7736 <p><i>[Post-Tokyo: The issue has been reformulated purely
7737 in terms of iterators.]</i></p>
7740 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
7741 assumption by reverse_iterator. The issue and proposed resolution was
7742 reformulated yet again to reflect this reality.]</i></p>
7745 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
7746 assumes its underlying iterator has persistent pointers and
7747 references. Andy Koenig pointed out that it is possible to rewrite
7748 reverse_iterator so that it no longer makes such an assupmption.
7749 However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>. If we
7750 decide it is intentional that <tt>p[n]</tt> may return by value
7751 instead of reference when <tt>p</tt> is a Random Access Iterator,
7752 other changes in reverse_iterator will be necessary.]</i></p>
7756 <p><b>Rationale:</b></p>
7757 <p>This issue has been discussed extensively. Note that it is
7758 <i>not</i> an issue about the behavior of predefined iterators. It is
7759 asking whether or not user-defined iterators are permitted to have
7760 transient pointers and references. Several people presented examples
7761 of useful user-defined iterators that have such a property; examples
7762 include a B-tree iterator, and an "iota iterator" that doesn't point
7763 to memory. Library implementors already seem to be able to cope with
7764 such iterators: they take pains to avoid forming references to memory
7765 that gets iterated past. The only place where this is a problem is
7766 <tt>reverse_iterator</tt>, so this issue changes
7767 <tt>reverse_iterator</tt> to make it work.</p>
7769 <p>This resolution does not weaken any guarantees provided by
7770 predefined iterators like <tt>list<int>::iterator</tt>.
7771 Clause 23 should be reviewed to make sure that guarantees for
7772 predefined iterators are as strong as users expect.</p>
7780 <h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
7781 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
7782 <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7783 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
7784 <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>
7785 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
7786 <p><b>Discussion:</b></p>
7788 Suppose that <tt>A</tt> is a class that conforms to the
7789 Allocator requirements of Table 32, and <tt>a</tt> is an
7790 object of class <tt>A</tt> What should be the return
7791 value of <tt>a.allocate(0)</tt>? Three reasonable
7792 possibilities: forbid the argument <tt>0</tt>, return
7793 a null pointer, or require that the return value be a
7794 unique non-null pointer.
7798 <p><b>Proposed resolution:</b></p>
7800 Add a note to the <tt>allocate</tt> row of Table 32:
7801 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
7804 <p><b>Rationale:</b></p>
7805 <p>A key to understanding this issue is that the ultimate use of
7806 allocate() is to construct an iterator, and that iterator for zero
7807 length sequences must be the container's past-the-end
7808 representation. Since this already implies special case code, it
7809 would be over-specification to mandate the return value.
7816 <h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
7817 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7818 <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
7819 <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>
7820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7821 <p><b>Discussion:</b></p>
7823 In table 74, the return type of the expression <tt>*a</tt> is given
7824 as <tt>T&</tt>, where <tt>T</tt> is the iterator's value type.
7825 For constant iterators, however, this is wrong. ("Value type"
7826 is never defined very precisely, but it is clear that the value type
7827 of, say, <tt>std::list<int>::const_iterator</tt> is supposed to be
7828 <tt>int</tt>, not <tt>const int</tt>.)
7832 <p><b>Proposed resolution:</b></p>
7834 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
7835 return type from "<tt>T&</tt>" to "<tt>T&</tt>
7836 if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>".
7837 In the <tt>a->m</tt> row, change the return type from
7838 "<tt>U&</tt>" to "<tt>U&</tt> if <tt>X</tt> is mutable,
7839 otherwise <tt>const U&</tt>".
7842 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
7843 there are multiple const problems with the STL portion of the library
7844 and that these should be addressed as a single package. Note
7845 that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a> has already been declared NAD Future for
7846 that very reason.]</i></p>
7849 <p><i>[Redmond: the LWG thinks this is separable from other constness
7850 issues. This issue is just cleanup; it clarifies language that was
7851 written before we had iterator_traits. Proposed resolution was
7852 modified: the original version only discussed *a. It was pointed out
7853 that we also need to worry about *r++ and a->m.]</i></p>
7862 <h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
7863 <p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7864 <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p>
7865 <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>
7866 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7867 <p><b>Discussion:</b></p>
7869 In some places in this section, the terms "fundamental types" and
7870 "scalar types" are used when the term "arithmetic types" is intended.
7871 The current usage is incorrect because void is a fundamental type and
7872 pointers are scalar types, neither of which should have
7873 specializations of numeric_limits.
7875 <p><i>[Lillehammer: it remains true that numeric_limits is using
7876 imprecise language. However, none of the proposals for changed
7877 wording are clearer. A redesign of numeric_limits is needed, but this
7878 is more a task than an open issue.]</i></p>
7882 <p><b>Proposed resolution:</b></p>
7885 Change 18.2 [support.limits] to:
7890 -1- The headers <tt><limits></tt>, <tt><climits></tt>,
7891 <tt><cfloat></tt>, and <tt><cinttypes></tt> supply
7892 characteristics of implementation-dependent <del>fundamental</del>
7893 <ins>arithmetic</ins> types (3.9.1).
7898 Change 18.2.1 [limits] to:
7903 -1- The <tt>numeric_limits</tt> component provides a C++ program with
7904 information about various properties of the implementation's
7905 representation of the <del>fundamental</del> <ins>arithmetic</ins>
7909 -2- Specializations shall be provided for each <del>fundamental</del>
7910 <ins>arithmetic</ins> type, both floating point and integer, including
7911 <tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
7912 for all such specializations of <tt>numeric_limits</tt>.
7915 -4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
7916 as <tt>complex<T></tt> (26.3.2), shall not have specializations.
7921 Change 18.2.1.1 [numeric.limits] to:
7926 <del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
7927 between fundamental types, which have specializations, and non-scalar types,
7938 <h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
7939 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
7940 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p>
7941 <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>
7942 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
7943 <p><b>Discussion:</b></p>
7945 What should unique() do if you give it a predicate that is not an
7946 equivalence relation? There are at least two plausible answers:
7952 1. You can't, because 25.2.8 says that it it "eliminates all but
7953 the first element from every consecutive group of equal
7954 elements..." and it wouldn't make sense to interpret "equal" as
7955 meaning anything but an equivalence relation. [It also doesn't
7956 make sense to interpret "equal" as meaning ==, because then there
7957 would never be any sense in giving a predicate as an argument at
7962 2. The word "equal" should be interpreted to mean whatever the
7963 predicate says, even if it is not an equivalence relation
7964 (and in particular, even if it is not transitive).
7970 The example that raised this question is from Usenet:
7975 <pre>int f[] = { 1, 3, 7, 1, 2 };
7976 int* z = unique(f, f+5, greater<int>());</pre>
7981 If one blindly applies the definition using the predicate
7982 greater<int>, and ignore the word "equal", you get:
7988 Eliminates all but the first element from every consecutive group
7989 of elements referred to by the iterator i in the range [first, last)
7990 for which *i > *(i - 1).
7996 The first surprise is the order of the comparison. If we wanted to
7997 allow for the predicate not being an equivalence relation, then we
7998 should surely compare elements the other way: pred(*(i - 1), *i). If
7999 we do that, then the description would seem to say: "Break the
8000 sequence into subsequences whose elements are in strictly increasing
8001 order, and keep only the first element of each subsequence". So the
8002 result would be 1, 1, 2. If we take the description at its word, it
8003 would seem to call for strictly DEcreasing order, in which case the
8004 result should be 1, 3, 7, 2.<br>
8006 In fact, the SGI implementation of unique() does neither: It yields 1,
8011 <p><b>Proposed resolution:</b></p>
8012 <p>Change 25.2.9 [alg.unique] paragraph 1 to:</p>
8014 For a nonempty range, eliminates all but the first element from every
8015 consecutive group of equivalent elements referred to by the iterator
8016 <tt>i</tt> in the range [first+1, last) for which the following
8017 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
8022 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
8023 comparison function must be an equivalence relation."
8026 <p><i>[Redmond: discussed arguments for and against requiring the
8027 comparison function to be an equivalence relation. Straw poll:
8028 14-2-5. First number is to require that it be an equivalence
8029 relation, second number is to explicitly not require that it be an
8030 equivalence relation, third number is people who believe they need
8031 more time to consider the issue. A separate issue: Andy Sawyer
8032 pointed out that "i-1" is incorrect, since "i" can refer to the first
8033 iterator in the range. Matt provided wording to address this
8037 <p><i>[Curaçao: The LWG changed "... the range (first,
8038 last)..." to "... the range [first+1, last)..." for
8039 clarity. They considered this change close enough to editorial to not
8040 require another round of review.]</i></p>
8045 <p><b>Rationale:</b></p>
8046 <p>The LWG also considered an alternative resolution: change
8047 25.2.9 [alg.unique] paragraph 1 to:</p>
8050 For a nonempty range, eliminates all but the first element from every
8051 consecutive group of elements referred to by the iterator
8052 <tt>i</tt> in the range (first, last) for which the following
8053 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
8058 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
8059 comparison function need not be an equivalence relation."
8063 <p>Informally: the proposed resolution imposes an explicit requirement
8064 that the comparison function be an equivalence relation. The
8065 alternative resolution does not, and it gives enough information so
8066 that the behavior of unique() for a non-equivalence relation is
8067 specified. Both resolutions are consistent with the behavior of
8068 existing implementations.</p>
8075 <h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
8076 <p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8077 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p>
8078 <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>
8079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8080 <p><b>Discussion:</b></p>
8081 <p>As specified, the implementation of the nothrow version of operator
8082 new does not necessarily call the ordinary operator new, but may
8083 instead simply call the same underlying allocator and return a null
8084 pointer instead of throwing an exception in case of failure.</p>
8086 <p>Such an implementation breaks code that replaces the ordinary
8087 version of new, but not the nothrow version. If the ordinary version
8088 of new/delete is replaced, and if the replaced delete is not
8089 compatible with pointers returned from the library versions of new,
8090 then when the replaced delete receives a pointer allocated by the
8091 library new(nothrow), crash follows.</p>
8093 <p>The fix appears to be that the lib version of new(nothrow) must
8094 call the ordinary new. Thus when the ordinary new gets replaced, the
8095 lib version will call the replaced ordinary new and things will
8096 continue to work.</p>
8098 <p>An alternative would be to have the ordinary new call
8099 new(nothrow). This seems sub-optimal to me as the ordinary version of
8100 new is the version most commonly replaced in practice. So one would
8101 still need to replace both ordinary and nothrow versions if one wanted
8102 to replace the ordinary version.</p>
8104 <p>Another alternative is to put in clear text that if one version is
8105 replaced, then the other must also be replaced to maintain
8106 compatibility. Then the proposed resolution below would just be a
8107 quality of implementation issue. There is already such text in
8108 paragraph 7 (under the new(nothrow) version). But this nuance is
8109 easily missed if one reads only the paragraphs relating to the
8113 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
8114 has been written explaining the rationale for the proposed resolution below.
8119 <p><b>Proposed resolution:</b></p>
8121 Change 18.5.1.1 [new.delete.single]:
8125 <pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&) throw();
8129 -5- <i>Effects:</i> Same as above, except that it is called by a placement
8130 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
8131 an error indication, instead of a <tt>bad_alloc</tt> exception.
8135 -6- <i>Replaceable:</i> a C++ program may define a function with this function
8136 signature that displaces the default version defined by the C++ Standard
8141 -7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
8142 storage (3.7.4), or else return a null pointer. This nothrow version of operator
8143 new returns a pointer obtained as if acquired from the <ins>(possibly
8144 replaced)</ins> ordinary version. This requirement is binding on a replacement
8145 version of this function.
8149 -8- <i>Default behavior:</i>
8153 Calls <tt>operator new(<i>size</i>)</tt>.
8156 If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
8157 the result of that call, else
8160 if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
8164 Executes a loop: Within the loop, the function first attempts to allocate the
8165 requested storage. Whether the attempt involves a call to the Standard C library
8166 function <tt>malloc</tt> is unspecified.
8169 Returns a pointer to the allocated storage if the attempt is successful.
8170 Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
8171 pointer, return a null pointer.
8174 Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
8175 called function returns, the loop repeats.
8178 The loop terminates when an attempt to allocate the requested storage is
8179 successful or when a called <i>new_handler</i> function does not return. If the
8180 called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
8181 exception</tt>, the function returns a null pointer.
8185 -9- [<i>Example:</i>
8187 <blockquote><pre>T* p1 = new T; <i>// throws bad_alloc if it fails</i>
8188 T* p2 = new(nothrow) T; <i>// returns 0 if it fails</i>
8191 --<i>end example</i>]
8195 <pre>void operator delete(void* <i>ptr</i>) throw();
8196 <del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&) throw();</del>
8201 -10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
8202 <i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
8205 -11- <i>Replaceable:</i> a C++ program may define a function with this function
8206 signature that displaces the default version defined by the C++ Standard
8210 -12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
8211 returned by an earlier call to the <del>default</del> <ins>(possibly
8212 replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
8213 new(std::size_t, const std::nothrow_t&)</tt>.
8216 -13- <i>Default behavior:</i>
8220 For a null value of <tt><i>ptr</i></tt>, do nothing.
8223 Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
8224 call to the default <tt>operator new</tt>, which was not invalidated by an
8225 intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
8226 non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
8227 call to the default <tt>operator new</tt>.
8231 -14- <i>Remarks:</i> It is unspecified under what conditions part or all of
8232 such reclaimed storage is allocated by a subsequent call to <tt>operator
8233 new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
8234 declared in <tt><cstdlib></tt>.
8238 <pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&) throw();</ins>
8243 -15- <i>Effects:</i> Same as above, except that it is called by the
8244 implementation when an exception propagates from a nothrow placement version
8245 of the <i>new-expression</i> (i.e. when the constructor throws an exception).
8248 -16- <i>Replaceable:</i> a C++ program may define a function with this function
8249 signature that displaces the default version defined by the C++ Standard
8253 -17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
8254 value returned by an earlier call to the (possibly replaced) <tt>operator
8255 new(std::size_t)</tt> or <tt>operator new(std::size_t, const
8256 std::nothrow_t&)</tt>. </ins></p>
8258 -18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
8265 Change 18.5.1.2 [new.delete.array]
8269 <pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&) throw();
8274 -5- <i>Effects:</i> Same as above, except that it is called by a placement
8275 version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
8276 an error indication, instead of a <tt>bad_alloc</tt> exception.
8280 -6- <i>Replaceable:</i> a C++ program can define a function with this function
8281 signature that displaces the default version defined by the C++ Standard
8286 -7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
8287 const std::nothrow_t&)</tt>. This nothrow version of operator <tt>new[]</tt>
8288 returns a pointer obtained as if acquired from the ordinary version.</del>
8289 <ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
8290 return a null pointer. This nothrow version of operator new returns a pointer
8291 obtained as if acquired from the (possibly replaced) <tt>operator
8292 new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
8293 replacement version of this function.</ins>
8297 -8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
8298 nothrow)</tt>.</del>
8303 Calls <tt>operator new[](<i>size</i>)</tt>.
8306 If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
8307 the result of that call, else
8310 if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
8316 <pre>void operator delete[](void* <i>ptr</i>) throw();
8317 void operator delete[](void* <i>ptr</i>, const std::nothrow_t&) throw();
8322 -9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
8323 array form of a <i>delete-expression</i> to render the value of
8324 <tt><i>ptr</i></tt> invalid.
8328 -10- <i>Replaceable:</i> a C++ program can define a function with this function
8329 signature that displaces the default version defined by the C++ Standard
8334 -11- <i>Requires:</i> the value of
8335 <tt><i>ptr</i></tt> is null or the value returned by an earlier call to
8336 <tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
8337 std::nothrow_t&)</tt>.
8341 -12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
8342 <tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
8350 <p><b>Rationale:</b></p>
8351 <p>Yes, they may become unlinked, and that is by design. If a user
8352 replaces one, the user should also replace the other.</p>
8355 Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding
8356 or not is visible behavior to the client and it would be useful for the client
8357 to know which behavior it could depend on.
8362 Batavia: Robert voiced serious reservations about backwards compatibility for
8372 <h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
8373 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8374 <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</p>
8375 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
8376 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
8377 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8378 <p><b>Discussion:</b></p>
8379 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
8380 past-the-end values are always non-singular."</p>
8381 <p>This places an unnecessary restriction on past-the-end iterators for
8382 containers with forward iterators (for example, a singly-linked list). If the
8383 past-the-end value on such a container was a well-known singular value, it would
8384 still satisfy all forward iterator requirements.</p>
8385 <p>Removing this restriction would allow, for example, a singly-linked list
8386 without a "footer" node.</p>
8387 <p>This would have an impact on existing code that expects past-the-end
8388 iterators obtained from different (generic) containers being not equal.</p>
8391 <p><b>Proposed resolution:</b></p>
8392 <p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p>
8394 <p>Dereferenceable and past-the-end values are always non-singular.</p>
8398 <p>Dereferenceable values are always non-singular. </p>
8402 <p><b>Rationale:</b></p>
8403 <p>For some kinds of containers, including singly linked lists and
8404 zero-length vectors, null pointers are perfectly reasonable past-the-end
8405 iterators. Null pointers are singular.
8412 <h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
8413 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8414 <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</p>
8415 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
8416 <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>
8417 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8418 <p><b>Discussion:</b></p>
8419 <p>In Section 21.3 [basic.string] the basic_string member function
8420 declarations use a consistent style except for the following functions:</p>
8422 <pre>void push_back(const charT);
8423 basic_string& assign(const basic_string&);
8424 void swap(basic_string<charT,traits,Allocator>&);</pre>
8426 <p>- push_back, assign, swap: missing argument name <br>
8427 - push_back: use of const with charT (i.e. POD type passed by value
8428 not by reference - should be charT or const charT& )<br>
8429 - swap: redundant use of template parameters in argument
8430 basic_string<charT,traits,Allocator>&</p>
8433 <p><b>Proposed resolution:</b></p>
8434 <p>In Section 21.3 [basic.string] change the basic_string member
8435 function declarations push_back, assign, and swap to:</p>
8437 <pre>void push_back(charT c);
8439 basic_string& assign(const basic_string& str);
8440 void swap(basic_string& str);</pre>
8444 <p><b>Rationale:</b></p>
8445 <p>Although the standard is in general not consistent in declaration
8446 style, the basic_string declarations are consistent other than the
8447 above. The LWG felt that this was sufficient reason to merit the
8455 <h3><a name="210"></a>210. distance first and last confused</h3>
8456 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8457 <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</p>
8458 <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>
8459 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8460 <p><b>Discussion:</b></p>
8461 <p>In paragraph 9 of section 25 [algorithms], it is written:</p>
8463 <p> In the description of the algorithms operators + and - are used
8464 for some of the iterator categories for which they do not have to
8465 be defined. In these cases the semantics of [...] a-b is the same
8468 <tt>return distance(a, b);</tt></p>
8472 <p><b>Proposed resolution:</b></p>
8473 <p>On the last line of paragraph 9 of section 25 [algorithms] change
8474 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
8477 <p><b>Rationale:</b></p>
8478 <p>There are two ways to fix the defect; change the description to b-a
8479 or change the return to distance(b,a). The LWG preferred the
8480 former for consistency.</p>
8486 <h3><a name="211"></a>211. operator>>(istream&, string&) doesn't set failbit</h3>
8487 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8488 <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</p>
8489 <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>
8490 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8491 <p><b>Discussion:</b></p>
8492 <p>The description of the stream extraction operator for std::string (section
8493 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
8494 the case that the operator fails to extract any characters from the input
8496 <p>This implies that the typical construction</p>
8498 <pre>std::istream is;
8501 while (is >> str) ... ;</pre>
8503 <p>(which tests failbit) is not required to terminate at EOF.</p>
8504 <p>Furthermore, this is inconsistent with other extraction operators,
8505 which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
8506 requirement is present, either explicitly or implicitly, for the
8507 extraction operators. It is also present explicitly in the description
8508 of getline (istream&, string&, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p>
8511 <p><b>Proposed resolution:</b></p>
8512 <p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p>
8515 <p>If the function extracts no characters, it calls
8516 is.setstate(ios::failbit) which may throw ios_base::failure
8524 <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
8525 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8526 <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
8527 <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>
8528 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8529 <p><b>Discussion:</b></p>
8530 <p>The standard doesn't specify what min_element() and max_element() shall
8531 return if the range is empty (first equals last). The usual implementations
8532 return last. This problem seems also apply to partition(), stable_partition(),
8533 next_permutation(), and prev_permutation().</p>
8536 <p><b>Proposed resolution:</b></p>
8537 <p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
8538 9, append: Returns last if first==last.</p>
8541 <p><b>Rationale:</b></p>
8542 <p>The LWG looked in some detail at all of the above mentioned
8543 algorithms, but believes that except for min_element() and
8544 max_element() it is already clear that last is returned if first ==
8551 <h3><a name="214"></a>214. set::find() missing const overload</h3>
8552 <p><b>Section:</b> 23.3.3 [set], 23.3.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8553 <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-28</p>
8554 <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>
8555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8556 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
8557 <p><b>Discussion:</b></p>
8558 <p>The specification for the associative container requirements in
8559 Table 69 state that the find member function should "return
8560 iterator; const_iterator for constant a". The map and multimap
8561 container descriptions have two overloaded versions of find, but set
8562 and multiset do not, all they have is:</p>
8564 <pre>iterator find(const key_type & x) const;</pre>
8568 <p><b>Proposed resolution:</b></p>
8569 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
8570 equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p>
8572 <pre>iterator find(const key_type & x);
8573 const_iterator find(const key_type & x) const;</pre>
8574 <pre>iterator lower_bound(const key_type & x);
8575 const_iterator lower_bound(const key_type & x) const;</pre>
8576 <pre>iterator upper_bound(const key_type & x);
8577 const_iterator upper_bound(const key_type & x) const;</pre>
8578 <pre>pair<iterator, iterator> equal_range(const key_type & x);
8579 pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre>
8582 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
8583 extending the proposed resolution to lower_bound, upper_bound, and
8584 equal_range.]</i></p>
8592 <h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
8593 <p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8594 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p>
8595 <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>
8596 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8597 <p><b>Discussion:</b></p>
8598 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
8599 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
8600 must be const in order for it to be callable on a const object (a reference to
8601 which which is what std::use_facet<>() returns).</p>
8602 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
8603 name of the namespace `My'.</p>
8604 <p>3) In the definition of `loc' and subsequently in the call to use_facet<>()
8605 in main(), the name of the facet is misspelled: it should read `My::JCtype'
8606 rather than `My::JCType'.</p>
8609 <p><b>Proposed resolution:</b></p>
8610 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
8611 paragraph 11 with the following:</p>
8612 <pre>#include <locale></pre>
8614 using namespace std;
8615 class JCtype : public locale::facet {
8617 static locale::id id; // required for use as a new locale facet
8618 bool is_kanji (wchar_t c) const;
8624 <pre>// file: filt.C
8625 #include <iostream>
8626 #include <locale>
8627 #include "jctype" // above
8628 std::locale::id My::JCtype::id; // the static JCtype member
8629 declared above.</pre>
8632 using namespace std;
8633 typedef ctype<wchar_t> wctype;
8634 locale loc(locale(""), // the user's preferred locale...
8635 new My::JCtype); // and a new feature ...
8636 wchar_t c = use_facet<wctype>(loc).widen('!');
8637 if (!use_facet<My::JCtype>(loc).is_kanji(c))
8638 cout << "no it isn't!" << endl;
8646 <h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
8647 <p><b>Section:</b> 27.4.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8648 <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</p>
8649 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8650 <p><b>Discussion:</b></p>
8651 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
8654 <p>Effects: Destroys an object of class ios_base. Calls each registered
8655 callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
8656 time that any ios_base member function called from within fn has well defined
8659 <p>But what is not clear is: If no callback functions were ever registered, does
8660 it matter whether the ios_base members were ever initialized?</p>
8661 <p>For instance, does this program have defined behavior:</p>
8663 <pre>#include <ios></pre>
8664 <pre>class D : public std::ios_base { };</pre>
8665 <pre>int main() { D d; }</pre>
8667 <p>It seems that registration of a callback function would surely affect the
8668 state of an ios_base. That is, when you register a callback function with an
8669 ios_base, the ios_base must record that fact somehow.</p>
8670 <p>But if after construction the ios_base is in an indeterminate state, and that
8671 state is not made determinate before the destructor is called, then how would
8672 the destructor know if any callbacks had indeed been registered? And if the
8673 number of callbacks that had been registered is indeterminate, then is not the
8674 behavior of the destructor undefined?</p>
8675 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
8676 it explicit that destruction before initialization results in undefined
8680 <p><b>Proposed resolution:</b></p>
8681 <p>Modify 27.4.2.7 paragraph 1 from</p>
8683 <p>Effects: Each ios_base member has an indeterminate value after
8688 <p>Effects: Each ios_base member has an indeterminate
8689 value after construction. These members must be initialized by calling
8690 basic_ios::init. If an ios_base object is destroyed before these
8691 initializations have taken place, the behavior is undefined.</p>
8698 <h3><a name="221"></a>221. num_get<>::do_get stage 2 processing broken</h3>
8699 <p><b>Section:</b> 22.2.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>
8700 <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</p>
8701 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
8702 <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>
8703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8704 <p><b>Discussion:</b></p>
8705 <p>Stage 2 processing of numeric conversion is broken.</p>
8707 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
8708 conversion specifier is %i. A %i specifier determines a number's base
8709 by its prefix (0 for octal, 0x for hex), so the intention is clearly
8710 that a 0x prefix is allowed. Paragraph 8 in the same section,
8711 however, describes very precisely how characters are processed. (It
8712 must be done "as if" by a specified code fragment.) That
8713 description does not allow a 0x prefix to be recognized.</p>
8715 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
8716 ct to a char, not by using narrow but by looking it up in a
8717 translation table that was created by widening the string literal
8718 "0123456789abcdefABCDEF+-". The character "x" is
8719 not found in that table, so it can't be recognized by stage 2
8723 <p><b>Proposed resolution:</b></p>
8724 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
8726 <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
8728 <p>with the line:</p>
8730 <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
8734 <p><b>Rationale:</b></p>
8735 <p>If we're using the technique of widening a string literal, the
8736 string literal must contain every character we wish to recognize.
8737 This technique has the consequence that alternate representations
8738 of digits will not be recognized. This design decision was made
8739 deliberately, with full knowledge of that limitation.</p>
8746 <h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
8747 <p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8748 <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
8749 <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>
8750 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8751 <p><b>Discussion:</b></p>
8752 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
8754 <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
8756 int compare(size_type pos1, size_type n1,
8757 const basic_string<charT,traits,Allocator>& str ,
8758 size_type pos2 , size_type n2 ) const;
8762 basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
8763 basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre>
8765 <p>and the constructor that's implicitly called by the above is
8766 defined to throw an out-of-range exception if pos > str.size(). See
8767 section 21.3.1 [string.require] paragraph 4.</p>
8769 <p>On the other hand, the compare function descriptions themselves don't have
8770 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
8771 that do not apply to a function are omitted.</p>
8772 <p>So it seems there is an inconsistency in the standard -- are the
8773 "Effects" clauses correct, or are the "Throws" clauses
8777 <p><b>Proposed resolution:</b></p>
8778 <p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
8779 the sentence "Descriptions of function semantics contain the
8780 following elements (as appropriate):", insert the word
8781 "further" so that the foot note reads:</p>
8783 <p>To save space, items that do not apply to a function are
8784 omitted. For example, if a function does not specify any further
8785 preconditions, there will be no "Requires" paragraph.</p>
8789 <p><b>Rationale:</b></p>
8790 <p>The standard is somewhat inconsistent, but a failure to note a
8791 throw condition in a throws clause does not grant permission not to
8792 throw. The inconsistent wording is in a footnote, and thus
8793 non-normative. The proposed resolution from the LWG clarifies the
8800 <h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
8801 <p><b>Section:</b> 25.2.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8802 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</p>
8803 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8804 <p><b>Discussion:</b></p>
8805 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
8808 <p><b>Proposed resolution:</b></p>
8809 <p>In 25.2.10 [alg.reverse], replace:</p>
8811 Effects: For each non-negative integer i <= (last - first)/2,
8812 applies swap to all pairs of iterators first + i, (last - i) - 1.
8816 Effects: For each non-negative integer i <= (last - first)/2,
8817 applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
8824 <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
8825 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
8826 <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p>
8827 <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>
8828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
8829 <p><b>Discussion:</b></p>
8830 <p>In the associative container requirements table in 23.1.2 paragraph 7,
8831 a.clear() has complexity "log(size()) + N". However, the meaning of N
8835 <p><b>Proposed resolution:</b></p>
8836 <p>In the associative container requirements table in 23.1.2 paragraph
8837 7, the complexity of a.clear(), change "log(size()) + N" to
8838 "linear in <tt>size()</tt>".</p>
8841 <p><b>Rationale:</b></p>
8842 <p>It's the "log(size())", not the "N", that is in
8843 error: there's no difference between <i>O(N)</i> and <i>O(N +
8844 log(N))</i>. The text in the standard is probably an incorrect
8845 cut-and-paste from the range version of <tt>erase</tt>.</p>
8851 <h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
8852 <p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8853 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8854 <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>
8855 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8856 <p><b>Discussion:</b></p>
8857 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
8858 user namespaces might be found through Koenig lookup?</p>
8859 <p>For example, a popular standard library implementation includes this
8860 implementation of std::unique:</p>
8862 <pre>namespace std {
8863 template <class _ForwardIter>
8864 _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
8865 __first = adjacent_find(__first, __last);
8866 return unique_copy(__first, __last, __first);
8870 <p>Imagine two users on opposite sides of town, each using unique on his own
8871 sequences bounded by my_iterators . User1 looks at his standard library
8872 implementation and says, "I know how to implement a more efficient
8873 unique_copy for my_iterators", and writes:</p>
8875 <pre>namespace user1 {
8877 // faster version for my_iterator
8878 my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
8881 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
8882 <p>User2 has other needs, and writes:</p>
8884 <pre>namespace user2 {
8886 // Returns true iff *c is a unique copy of *a and *b.
8887 bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
8890 <p>User2 is shocked to find later that his fully-qualified use of
8891 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
8892 compile (if he's lucky). Looking in the standard, he sees the following Effects
8893 clause for unique():</p>
8895 <p>Effects: Eliminates all but the first element from every consecutive group
8896 of equal elements referred to by the iterator i in the range [first, last) for
8897 which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
8898 *(i - 1)) != false</p>
8900 <p>The standard gives user2 absolutely no reason to think he can interfere with
8901 std::unique by defining names in namespace user2. His standard library has been
8902 built with the template export feature, so he is unable to inspect the
8903 implementation. User1 eventually compiles his code with another compiler, and
8904 his version of unique_copy silently stops being called. Eventually, he realizes
8905 that he was depending on an implementation detail of his library and had no
8906 right to expect his unique_copy() to be called portably.</p>
8907 <p>On the face of it, and given above scenario, it may seem obvious that the
8908 implementation of unique() shown is non-conforming because it uses unique_copy()
8909 rather than ::std::unique_copy(). Most standard library implementations,
8910 however, seem to disagree with this notion.</p>
8911 <p> <i>[Tokyo: Steve Adamczyk from
8912 the core working group indicates that "std::" is sufficient;
8913 leading "::" qualification is not required because any namespace
8914 qualification is sufficient to suppress Koenig lookup.]</i></p>
8917 <p><b>Proposed resolution:</b></p>
8918 <p>Add a paragraph and a note at the end of
8919 17.4.4.3 [global.functions]:</p>
8922 <p>Unless otherwise specified, no global or non-member function in the
8923 standard library shall use a function from another namespace which is
8924 found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
8926 <p>[Note: the phrase "unless otherwise specified" is intended to
8927 allow Koenig lookup in cases like that of ostream_iterators:<br>
8932 <p>*out_stream << value;<br>
8933 if(delim != 0) *out_stream << delim;<br>
8939 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
8940 is as yet unsure if the proposed resolution is the best
8941 solution. Furthermore, the LWG believes that the same problem of
8942 unqualified library names applies to wording in the standard itself,
8943 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
8944 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
8945 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
8948 <p><i>[Toronto: The LWG is not sure if this is a defect in the
8949 standard. Most LWG members believe that an implementation of
8950 <tt>std::unique</tt> like the one quoted in this issue is already
8951 illegal, since, under certain circumstances, its semantics are not
8952 those specified in the standard. The standard's description of
8953 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
8954 should have any effect.]</i></p>
8957 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
8958 225, 226, and 229. Their conclusion was that the issues should be
8959 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
8960 EWG portion (Dave will write a proposal). The LWG and EWG had
8961 (separate) discussions of this plan the next day. The proposed
8962 resolution for this issue is in accordance with Howard's paper.]</i></p>
8967 <p><b>Rationale:</b></p>
8968 <p>It could be argued that this proposed isn't strictly necessary,
8969 that the Standard doesn't grant implementors license to write a
8970 standard function that behaves differently than specified in the
8971 Standard just because of an unrelated user-defined name in some
8972 other namespace. However, this is at worst a clarification. It is
8973 surely right that algorithsm shouldn't pick up random names, that
8974 user-defined names should have no effect unless otherwise specified.
8975 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
8976 appropriate for the standard to explicitly specify otherwise.</p>
8983 <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
8984 <p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
8985 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
8986 <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>
8987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
8988 <p><b>Discussion:</b></p>
8989 <p>The issues are: </p>
8990 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
8991 algorithm which is specialized to work with his own class template? </p>
8992 <p>2. How can another library implementor (lib2) write a generic algorithm which
8993 will take advantage of the specialized algorithm in lib1?</p>
8994 <p>This appears to be the only viable answer under current language rules:</p>
8998 // arbitrary-precision numbers using T as a basic unit
8999 template <class T>
9000 class big_num { //...
9003 <pre> // defining this in namespace std is illegal (it would be an
9004 // overload), so we hope users will rely on Koenig lookup
9005 template <class T>
9006 void swap(big_int<T>&, big_int<T>&);
9008 <pre>#include <algorithm>
9011 template <class T>
9012 void generic_sort(T* start, T* end)
9015 // using-declaration required so we can work on built-in types
9017 // use Koenig lookup to find specialized algorithm if available
9022 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
9023 and somewhat slippery. The implementor needs to remember to write the
9024 using-declaration, or generic_sort will fail to compile when T is a built-in
9025 type. The second drawback is that the use of this style in lib2 effectively
9026 "reserves" names in any namespace which defines types which may
9027 eventually be used with lib2. This may seem innocuous at first when applied to
9028 names like swap, but consider more ambiguous names like unique_copy() instead.
9029 It is easy to imagine the user wanting to define these names differently in his
9030 own namespace. A definition with semantics incompatible with the standard
9031 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>
9032 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
9033 because the language doesn't allow for partial specialization of function
9034 templates. If you write:</p>
9038 template <class T>
9039 void swap(lib1::big_int<T>&, lib1::big_int<T>&);
9042 <p>You have just overloaded std::swap, which is illegal under the current
9043 language rules. On the other hand, the following full specialization is legal:</p>
9048 void swap(lib1::other_type&, lib1::other_type&);
9052 <p>This issue reflects concerns raised by the "Namespace issue
9053 with specialized swap" thread on comp.lang.c++.moderated. A
9054 similar set of concerns was earlier raised on the boost.org mailing
9055 list and the ACCU-general mailing list. Also see library reflector
9056 message c++std-lib-7354.</p>
9059 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
9060 fact: it's impossible to output a container of std::pair's using copy
9061 and an ostream_iterator, as long as both pair-members are built-in or
9062 std:: types. That's because a user-defined operator<< for (for
9063 example) std::pair<const std::string, int> will not be found:
9064 lookup for operator<< will be performed only in namespace std.
9065 Opinions differed on whether or not this was a defect, and, if so,
9066 whether the defect is that something is wrong with user-defined
9067 functionality and std, or whether it's that the standard library does
9068 not provide an operator<< for std::pair<>.
9073 <p><b>Proposed resolution:</b></p>
9075 <p>Adopt the wording proposed in Howard Hinnant's paper
9076 N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
9079 <p><i>[Tokyo: Summary, "There is no conforming way to extend
9080 std::swap for user defined templates." The LWG agrees that
9081 there is a problem. Would like more information before
9082 proceeding. This may be a core issue. Core issue 229 has been opened
9083 to discuss the core aspects of this problem. It was also noted that
9084 submissions regarding this issue have been received from several
9085 sources, but too late to be integrated into the issues list.
9089 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
9090 J16/00-0029==WG21/N1252, "Shades of namespace std functions
9091 " by Alan Griffiths, is in the Post-Tokyo mailing. It
9092 should be considered a part of this issue.]</i></p>
9095 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
9096 resolution that involves core changes: it would add partial
9097 specialization of function template. The Core Working Group is
9098 reluctant to add partial specialization of function templates. It is
9099 viewed as a large change, CWG believes that proposal presented leaves
9100 some syntactic issues unanswered; if the CWG does add partial
9101 specialization of function templates, it wishes to develop its own
9102 proposal. The LWG continues to believe that there is a serious
9103 problem: there is no good way for users to force the library to use
9104 user specializations of generic standard library functions, and in
9105 certain cases (e.g. transcendental functions called by
9106 <tt>valarray</tt> and <tt>complex</tt>) this is important. Koenig
9107 lookup isn't adequate, since names within the library must be
9108 qualified with <tt>std</tt> (see issue 225), specialization doesn't
9109 work (we don't have partial specialization of function templates), and
9110 users aren't permitted to add overloads within namespace std.
9114 <p><i>[Copenhagen: Discussed at length, with no consensus. Relevant
9115 papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion
9116 focused on four options. (1) Relax restrictions on overloads within
9117 namespace std. (2) Mandate that the standard library use unqualified
9118 calls for <tt>swap</tt> and possibly other functions. (3) Introduce
9119 helper class templates for <tt>swap</tt> and possibly other functions.
9120 (4) Introduce partial specialization of function templates. Every
9121 option had both support and opposition. Straw poll (first number is
9122 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
9126 <p><i>[Redmond: Discussed, again no consensus. Herb presented an
9127 argument that a user who is defining a type <tt>T</tt> with an
9128 associated <tt>swap</tt> should not be expected to put that
9129 <tt>swap</tt> in namespace std, either by overloading or by partial
9130 specialization. The argument is that <tt>swap</tt> is part of
9131 <tt>T</tt>'s interface, and thus should to in the same namespace as
9132 <tt>T</tt> and only in that namespace. If we accept this argument,
9133 the consequence is that standard library functions should use
9134 unqualified call of <tt>swap</tt>. (And which other functions? Any?)
9135 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
9136 try to put together a proposal before the next meeting.]</i></p>
9139 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
9140 225, 226, and 229. Their conclusion was that the issues should be
9141 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
9142 EWG portion (Dave will write a proposal). The LWG and EWG had
9143 (separate) discussions of this plan the next day. The proposed
9144 resolution is the one proposed by Howard.]</i></p>
9147 <p><i>[Santa Cruz: the LWG agreed with the general direction of
9148 Howard's paper, N1387. (Roughly: Koenig lookup is disabled unless
9149 we say otherwise; this issue is about when we do say otherwise.)
9150 However, there were concerns about wording. Howard will provide new
9151 wording. Bill and Jeremy will review it.]</i></p>
9154 <p><i>[Kona: Howard proposed the new wording. The LWG accepted his
9155 proposed resolution.]</i></p>
9160 <p><b>Rationale:</b></p>
9161 <p>Informally: introduce a Swappable concept, and specify that the
9162 value types of the iterators passed to certain standard algorithms
9163 (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
9164 to that concept. The Swappable concept will make it clear that
9165 these algorithms use unqualified lookup for the calls
9166 to <tt>swap</tt>. Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
9167 state that the valarray transcendentals use unqualified lookup.</p>
9174 <h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
9175 <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
9176 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</p>
9177 <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>
9178 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
9179 <p><b>Discussion:</b></p>
9180 <p>25.2.2 reads:</p>
9182 <p><tt> template<class T> void swap(T& a, T& b);</tt><br>
9184 Requires: Type T is Assignable (_lib.container.requirements_).<br>
9185 Effects: Exchanges values stored in two locations.</p>
9187 <p>The only reasonable** generic implementation of swap requires construction of a
9188 new temporary copy of one of its arguments:</p>
9190 <pre>template<class T> void swap(T& a, T& b);
9197 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
9198 <p>**Yes, there's also an unreasonable implementation which would require T to be
9199 DefaultConstructible instead of CopyConstructible. I don't think this is worthy
9200 of consideration:</p>
9202 <pre>template<class T> void swap(T& a, T& b);
9212 <p><b>Proposed resolution:</b></p>
9213 <p>Change 25.2.2 paragraph 1 from:</p>
9215 <p> Requires: Type T is Assignable (23.1).</p>
9219 <p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
9227 <h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
9228 <p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9229 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-20</p>
9230 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
9231 <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>
9232 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9233 <p><b>Discussion:</b></p>
9234 <p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
9235 [locale.codecvt.byname],
9236 sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
9237 [locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
9238 [locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
9240 definitions of the "..._byname" classes by listing a bunch
9241 of virtual functions. At the same time, no semantics of these
9242 functions are defined. Real implementations do not define these
9243 functions because the functional part of the facets is actually
9244 implemented in the corresponding base classes and the constructor of
9245 the "..._byname" version just provides suitable date used by
9246 these implementations. For example, the 'numpunct' methods just return
9247 values from a struct. The base class uses a statically initialized
9248 struct while the derived version reads the contents of this struct
9249 from a table. However, no virtual function is defined in
9250 'numpunct_byname'.</p>
9252 <p>For most classes this does not impose a problem but specifically
9253 for 'ctype' it does: The specialization for 'ctype_byname<char>'
9254 is required because otherwise the semantics would change due to the
9255 virtual functions defined in the general version for 'ctype_byname':
9256 In 'ctype<char>' the method 'do_is()' is not virtual but it is
9257 made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'.
9258 Thus, a class derived from 'ctype_byname<char>' can tell whether
9259 this class is specialized or not under the current specification:
9260 Without the specialization, 'do_is()' is virtual while with
9261 specialization it is not virtual.</p>
9264 <p><b>Proposed resolution:</b></p>
9265 <p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
9266 <pre> namespace std {
9267 template <class charT>
9268 class ctype_byname : public ctype<charT> {
9270 typedef ctype<charT>::mask mask;
9271 explicit ctype_byname(const char*, size_t refs = 0);
9273 ~ctype_byname(); // virtual
9276 <p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
9277 <pre> namespace std {
9278 template <class internT, class externT, class stateT>
9279 class codecvt_byname : public codecvt<internT, externT, stateT> {
9281 explicit codecvt_byname(const char*, size_t refs = 0);
9283 ~codecvt_byname(); // virtual
9287 <p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
9288 <pre> namespace std {
9289 template <class charT>
9290 class numpunct_byname : public numpunct<charT> {
9291 // this class is specialized for char and wchar_t.
9293 typedef charT char_type;
9294 typedef basic_string<charT> string_type;
9295 explicit numpunct_byname(const char*, size_t refs = 0);
9297 ~numpunct_byname(); // virtual
9300 <p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
9301 <pre> namespace std {
9302 template <class charT>
9303 class collate_byname : public collate<charT> {
9305 typedef basic_string<charT> string_type;
9306 explicit collate_byname(const char*, size_t refs = 0);
9308 ~collate_byname(); // virtual
9311 <p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
9312 <pre> namespace std {
9313 template <class charT, class InputIterator = istreambuf_iterator<charT> >
9314 class time_get_byname : public time_get<charT, InputIterator> {
9316 typedef time_base::dateorder dateorder;
9317 typedef InputIterator iter_type</pre>
9318 <pre> explicit time_get_byname(const char*, size_t refs = 0);
9320 ~time_get_byname(); // virtual
9323 <p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
9324 <pre> namespace std {
9325 template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
9326 class time_put_byname : public time_put<charT, OutputIterator>
9329 typedef charT char_type;
9330 typedef OutputIterator iter_type;</pre>
9331 <pre> explicit time_put_byname(const char*, size_t refs = 0);
9333 ~time_put_byname(); // virtual
9336 <p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
9337 <pre> namespace std {
9338 template <class charT, bool Intl = false>
9339 class moneypunct_byname : public moneypunct<charT, Intl> {
9341 typedef money_base::pattern pattern;
9342 typedef basic_string<charT> string_type;</pre>
9343 <pre> explicit moneypunct_byname(const char*, size_t refs = 0);
9345 ~moneypunct_byname(); // virtual
9348 <p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
9349 <pre> namespace std {
9350 template <class charT>
9351 class messages_byname : public messages<charT> {
9353 typedef messages_base::catalog catalog;
9354 typedef basic_string<charT> string_type;</pre>
9355 <pre> explicit messages_byname(const char*, size_t refs = 0);
9357 ~messages_byname(); // virtual
9360 <p>Remove section 22.2.1.4 [locale.codecvt] completely (because in
9361 this case only those members are defined to be virtual which are
9362 defined to be virtual in 'ctype<cT>'.)</p>
9364 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
9365 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>
9368 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
9369 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
9378 <h3><a name="229"></a>229. Unqualified references of other library entities</h3>
9379 <p><b>Section:</b> 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9380 <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</p>
9381 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9382 <p><b>Discussion:</b></p>
9383 <p>Throughout the library chapters, the descriptions of library entities refer
9384 to other library entities without necessarily qualifying the names.</p>
9386 <p>For example, section 25.2.2 "Swap" describes the effect of
9387 swap_ranges in terms of the unqualified name "swap". This section
9388 could reasonably be interpreted to mean that the library must be implemented so
9389 as to do a lookup of the unqualified name "swap", allowing users to
9390 override any ::std::swap function when Koenig lookup applies.</p>
9392 <p>Although it would have been best to use explicit qualification with
9393 "::std::" throughout, too many lines in the standard would have to be
9394 adjusted to make that change in a Technical Corrigendum.</p>
9396 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
9397 <tt>size_t</tt>, is a special case of this.
9401 <p><b>Proposed resolution:</b></p>
9402 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
9404 <p>Whenever a name x defined in the standard library is mentioned, the name x
9405 is assumed to be fully qualified as ::std::x, unless explicitly described
9406 otherwise. For example, if the Effects section for library function F is
9407 described as calling library function G, the function ::std::G is meant.</p>
9410 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
9411 the LWG to solve a problem in the standard itself similar to the
9412 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
9413 coordinated with the resolution of this issue.]</i></p>
9416 <p><i>[post-Toronto: Howard is undecided about whether it is
9417 appropriate for all standard library function names referred to in
9418 other standard library functions to be explicitly qualified by
9419 <tt>std</tt>: it is common advice that users should define global
9420 functions that operate on their class in the same namespace as the
9421 class, and this requires argument-dependent lookup if those functions
9422 are intended to be called by library code. Several LWG members are
9423 concerned that valarray appears to require argument-dependent lookup,
9424 but that the wording may not be clear enough to fall under
9425 "unless explicitly described otherwise".]</i></p>
9428 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
9429 225, 226, and 229. Their conclusion was that the issues should be
9430 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
9431 EWG portion (Dave will write a proposal). The LWG and EWG had
9432 (separate) discussions of this plan the next day. This paper resolves
9433 issues 225 and 226. In light of that resolution, the proposed
9434 resolution for the current issue makes sense.]</i></p>
9443 <h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
9444 <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>
9445 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-04-26</p>
9446 <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>
9447 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9448 <p><b>Discussion:</b></p>
9449 <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
9450 Assignable was specified without also specifying
9451 CopyConstructible. The LWG asked that the standard be searched to
9452 determine if the same defect existed elsewhere.</p>
9454 <p>There are a number of places (see proposed resolution below) where
9455 Assignable is specified without also specifying
9456 CopyConstructible. There are also several cases where both are
9457 specified. For example, 26.4.1 [rand.req].</p>
9460 <p><b>Proposed resolution:</b></p>
9461 <p>In 23.1 [container.requirements] table 65 for value_type:
9462 change "T is Assignable" to "T is CopyConstructible and
9466 <p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change
9467 "Key is Assignable" to "Key is
9468 CopyConstructible and Assignable"<br>
9471 <p>In 24.1.2 [output.iterators] paragraph 1, change:
9474 <p> A class or a built-in type X satisfies the requirements of an
9475 output iterator if X is an Assignable type (23.1) and also the
9476 following expressions are valid, as shown in Table 73:
9482 <p> A class or a built-in type X satisfies the requirements of an
9483 output iterator if X is a CopyConstructible (20.1.3) and Assignable
9484 type (23.1) and also the following expressions are valid, as shown in
9489 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
9490 the LWG. He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that
9491 CopyConstructible is really a requirement and may be
9492 overspecification.]</i></p>
9495 <p><i>[Portions of the resolution for issue 230 have been superceded by
9496 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
9501 <p><b>Rationale:</b></p>
9502 <p>The original proposed resolution also included changes to input
9503 iterator, fill, and replace. The LWG believes that those changes are
9504 not necessary. The LWG considered some blanket statement, where an
9505 Assignable type was also required to be Copy Constructible, but
9506 decided against this because fill and replace really don't require the
9507 Copy Constructible property.</p>
9513 <h3><a name="231"></a>231. Precision in iostream?</h3>
9514 <p><b>Section:</b> 22.2.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>
9515 <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</p>
9516 <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>
9517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9518 <p><b>Discussion:</b></p>
9519 <p>What is the following program supposed to output?</p>
9520 <pre>#include <iostream>
9525 std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
9526 std::cout.precision( 0 ) ;
9527 std::cout << 1.00 << '\n' ;
9530 <p>From my C experience, I would expect "1e+00"; this is what
9531 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
9534 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
9535 where it says "For conversion from a floating-point type, if
9536 (flags & fixed) != 0 or if str.precision() > 0, then
9537 str.precision() is specified in the conversion specification."
9538 This is an obvious error, however, fixed is not a mask for a field,
9539 but a value that a multi-bit field may take -- the results of and'ing
9540 fmtflags with ios::fixed are not defined, at least not if
9541 ios::scientific has been set. G++'s behavior corresponds to what might
9542 happen if you do use (flags & fixed) != 0 with a typical
9543 implementation (floatfield == 3 << something, fixed == 1
9544 << something, and scientific == 2 << something).</p>
9546 <p>Presumably, the intent is either (flags & floatfield) != 0, or
9547 (flags & floatfield) == fixed; the first gives something more or
9548 less like the effect of precision in a printf floating point
9549 conversion. Only more or less, of course. In order to implement printf
9550 formatting correctly, you must know whether the precision was
9551 explicitly set or not. Say by initializing it to -1, instead of 6, and
9552 stating that for floating point conversions, if precision < -1, 6
9553 will be used, for fixed point, if precision < -1, 1 will be used,
9554 etc. Plus, of course, if precision == 0 and flags & floatfield ==
9555 0, 1 should be = used. But it probably isn't necessary to emulate all
9556 of the anomalies of printf:-).</p>
9559 <p><b>Proposed resolution:</b></p>
9561 Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
9565 For conversion from a floating-point type,
9566 <tt><i>str</i>.precision()</tt> is specified in the conversion
9571 <p><b>Rationale:</b></p>
9572 <p>The floatfield determines whether numbers are formatted as if
9573 with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f,
9574 if <tt>scientific</tt> it's %e, and if both bits are set, or
9575 neither, it's %g.</p>
9576 <p>Turning to the C standard, a precision of 0 is meaningful
9577 for %f and %e. For %g, precision 0 is taken to be the same as
9579 <p>The proposed resolution has the effect that if neither
9580 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
9581 specifying a precision of 0, which will be internally
9582 turned into 1. There's no need to call it out as a special
9584 <p>The output of the above program will be "1e+00".</p>
9586 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
9587 where precision is 0 and mode is %g.]</i></p>
9596 <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
9597 <p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9598 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p>
9599 <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>
9600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9601 <p><b>Discussion:</b></p>
9602 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
9603 specializations of standard templates to those that "depend on a
9604 user-defined name of external linkage."</p>
9605 <p>This term, however, is not adequately defined, making it possible to
9606 construct a specialization that is, I believe, technically legal according to
9607 17.4.3.1/1, but that specializes a standard template for a built-in type such as
9609 <p>The following code demonstrates the problem:</p>
9611 <pre>#include <algorithm></pre>
9612 <pre>template<class T> struct X
9618 template<> void swap(::X<int>::type& i, ::X<int>::type& j);
9623 <p><b>Proposed resolution:</b></p>
9624 <p>Change "user-defined name" to "user-defined
9628 <p><b>Rationale:</b></p>
9629 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
9630 Programming Language</i>. It disallows the example in the issue,
9631 since the underlying type itself is not user-defined. The only
9632 possible problem I can see is for non-type templates, but there's no
9633 possible way for a user to come up with a specialization for bitset,
9634 for example, that might not have already been specialized by the
9637 <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>
9640 <p><i>[post-Toronto: Judy provided the above proposed resolution and
9649 <h3><a name="233"></a>233. Insertion hints in associative containers</h3>
9650 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9651 <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p>
9652 <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>
9653 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9654 <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>
9655 <p><b>Discussion:</b></p>
9657 If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
9658 into the multimap, then <tt>mm.insert(p, x)</tt> inserts
9659 <tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
9660 to where it should go. Table 69 claims that the execution time is
9661 amortized constant if the insert winds up taking place adjacent to
9662 <tt>p</tt>, but does not say when, if ever, this is guaranteed to
9663 happen. All it says it that <tt>p</tt> is a hint as to where to
9667 The question is whether there is any guarantee about the relationship
9668 between <tt>p</tt> and the insertion point, and, if so, what it
9672 I believe the present state is that there is no guarantee: The user
9673 can supply <tt>p</tt>, and the implementation is allowed to
9674 disregard it entirely.
9677 <p><b>Additional comments from Nathan:</b><br>
9679 The vote [in Redmond] was on whether to elaborately specify the use of
9680 the hint, or to require behavior only if the value could be inserted
9681 adjacent to the hint. I would like to ensure that we have a chance to
9682 vote for a deterministic treatment: "before, if possible, otherwise
9683 after, otherwise anywhere appropriate", as an alternative to the
9684 proposed "before or after, if possible, otherwise [...]".
9687 <p><i>[Toronto: there was general agreement that this is a real defect:
9688 when inserting an element x into a multiset that already contains
9689 several copies of x, there is no way to know whether the hint will be
9690 used. The proposed resolution was that the new element should always
9691 be inserted as close to the hint as possible. So, for example, if
9692 there is a subsequence of equivalent values, then providing a.begin()
9693 as the hint means that the new element should be inserted before the
9694 subsequence even if a.begin() is far away. JC van Winkel supplied
9695 precise wording for this proposed resolution, and also for an
9696 alternative resolution in which hints are only used when they are
9697 adjacent to the insertion point.]</i></p>
9700 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
9701 in which an insertion hint would be used even when it is far from the
9702 insertion point. This was contingent on seeing a example
9703 implementation showing that it is possible to implement this
9704 requirement without loss of efficiency. John Potter provided such a
9705 example implementation.]</i></p>
9708 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
9709 emerged from Copenhagen: it seemed excessively complicated, and went
9710 beyond fixing the defect that we identified in Toronto. PJP provided
9711 the new wording described in this issue. Nathan agrees that we
9712 shouldn't adopt the more detailed semantics, and notes: "we know that
9713 you can do it efficiently enough with a red-black tree, but there are
9714 other (perhaps better) balanced tree techniques that might differ
9715 enough to make the detailed semantics hard to satisfy."]</i></p>
9718 <p><i>[Curaçao: Nathan should give us the alternative wording he
9719 suggests so the LWG can decide between the two options.]</i></p>
9722 <p><i>[Lillehammer: The LWG previously rejected the more detailed
9723 semantics, because it seemed more loike a new feature than like
9724 defect fixing. We're now more sympathetic to it, but we (especially
9725 Bill) are still worried about performance. N1780 describes a naive
9726 algorithm, but it's not clear whether there is a non-naive
9727 implementation. Is it possible to implement this as efficently as
9728 the current version of insert?]</i></p>
9731 <p><i>[Post Lillehammer:
9732 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
9733 updated in post meeting mailing with
9734 feedback from Lillehammer with more information regarding performance.
9740 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9741 accepted with minor wording changes in the proposed wording (reflected in the
9742 proposed resolution below). Concerns about the performance of the algorithm
9743 were satisfactorily met by
9744 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
9745 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
9746 and so that part of the resolution from
9747 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
9748 is no longer needed (or reflected in the proposed wording below).
9754 <p><b>Proposed resolution:</b></p>
9757 Change the indicated rows of the "Associative container requirements" Table in
9758 23.1.4 [associative.reqmts] to:
9763 <caption>Associative container requirements</caption>
9764 <tbody><tr><th>expression</th> <th>return type</th>
9765 <th>assertion/note<br>pre/post-condition</th>
9766 <th>complexity</th></tr>
9767 <tr><td><tt>a_eq.insert(t)</tt></td>
9768 <td><tt>iterator</tt></td>
9770 inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
9771 element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
9772 <tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
9777 <tr><td><tt>a.insert(p,t)</tt></td>
9778 <td><tt>iterator</tt></td>
9780 inserts <tt>t</tt> if and only if there is no element with key equivalent to the
9781 key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
9782 with equivalent keys. always returns the iterator pointing to the element with key
9783 equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
9784 the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
9785 to the position just prior to <tt>p</tt>.</ins>
9788 logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
9789 <ins>before</ins> <tt>p</tt>.
9800 <h3><a name="234"></a>234. Typos in allocator definition</h3>
9801 <p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9802 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9803 <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>
9804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9805 <p><b>Discussion:</b></p>
9806 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
9807 <tt>destruct()</tt> are described as returns but the functions actually
9808 return <tt>void</tt>.</p>
9811 <p><b>Proposed resolution:</b></p>
9812 <p>Substitute "Returns" by "Effect".</p>
9818 <h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
9819 <p><b>Section:</b> 24.4.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9820 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9822 <p><b>Discussion:</b></p>
9823 <p>The declaration of <tt>reverse_iterator</tt> lists a default
9824 constructor. However, no specification is given what this constructor
9828 <p><b>Proposed resolution:</b></p>
9829 <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following
9832 <p><tt>reverse_iterator()</tt></p>
9834 <p>Default initializes <tt>current</tt>. Iterator operations
9835 applied to the resulting iterator have defined behavior if and
9836 only if the corresponding operations are defined on a default
9837 constructed iterator of type <tt>Iterator</tt>.</p>
9839 <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
9840 resolution.]</i></p>
9848 <h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
9849 <p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9850 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
9851 <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>
9852 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9853 <p><b>Discussion:</b></p>
9854 <p>The complexity specification in paragraph 6 says that the complexity
9855 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
9856 defined on iterators this term is in general undefined because it
9857 would have to be <tt>last - first</tt>.</p>
9860 <p><b>Proposed resolution:</b></p>
9861 <p>Change paragraph 6 from</p>
9862 <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
9864 <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
9870 <h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
9871 <p><b>Section:</b> 27.7.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9872 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-05-11</p>
9873 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9874 <p><b>Discussion:</b></p>
9875 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
9876 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
9877 that far but consider this code:</p>
9879 <pre> std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
9880 std::cout << "'" << sbuf.str() << "'\n";
9883 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
9884 the output sequence nor the input sequence is initialized and
9885 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
9886 returns the input or the output sequence. None of them is initialized,
9887 ie. both are empty, in which case the return from <tt>str()</tt> is
9888 defined to be <tt>basic_string<cT>()</tt>.</p>
9890 <p>However, probably only test cases in some testsuites will detect this
9894 <p><b>Proposed resolution:</b></p>
9895 <p>Remove 27.7.1.1 paragraph 4.</p>
9898 <p><b>Rationale:</b></p>
9899 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
9900 we fixed it, it would say just the same thing as text that's already
9901 in the standard.</p>
9907 <h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
9908 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9909 <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9910 <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>
9911 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9912 <p><b>Discussion:</b></p>
9913 <p>The complexity of unique and unique_copy are inconsistent with each
9914 other and inconsistent with the implementations. The standard
9917 <p>for unique():</p>
9919 <blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
9920 (last - first) - 1 applications of the corresponding predicate, otherwise
9921 no applications of the predicate.</p></blockquote>
9923 <p>for unique_copy():</p>
9925 <blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
9926 predicate.</p></blockquote>
9929 The implementations do it the other way round: unique() applies the
9930 predicate last-first times and unique_copy() applies it last-first-1
9933 <p>As both algorithms use the predicate for pair-wise comparison of
9934 sequence elements I don't see a justification for unique_copy()
9935 applying the predicate last-first times, especially since it is not
9936 specified to which pair in the sequence the predicate is applied
9940 <p><b>Proposed resolution:</b></p>
9941 <p>Change both complexity sections in 25.2.9 [alg.unique] to:</p>
9943 <blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
9944 applications of the corresponding predicate.</p></blockquote>
9952 <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
9953 <p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
9954 <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
9955 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
9956 <p><b>Discussion:</b></p>
9957 <p>The complexity section of adjacent_find is defective:</p>
9960 <pre>template <class ForwardIterator>
9961 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
9962 BinaryPredicate pred);
9965 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
9966 the range [first, last) for which the following corresponding
9967 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
9968 last if no such iterator is found.</p>
9970 <p>-2- Complexity: Exactly find(first, last, value) - first applications
9971 of the corresponding predicate.
9975 <p>In the Complexity section, it is not defined what "value"
9976 is supposed to mean. My best guess is that "value" means an
9977 object for which one of the conditions pred(*i,value) or
9978 pred(value,*i) is true, where i is the iterator defined in the Returns
9979 section. However, the value type of the input sequence need not be
9980 equality-comparable and for this reason the term find(first, last,
9981 value) - first is meaningless.</p>
9983 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
9984 find_if(first, last, bind1st(pred,*i)) - first might come closer to
9985 the intended specification. Binders can only be applied to function
9986 objects that have the function call operator declared const, which is
9987 not required of predicates because they can have non-const data
9988 members. For this reason, a specification using a binder could only be
9989 an "as-if" specification.</p>
9992 <p><b>Proposed resolution:</b></p>
9993 <p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p>
9995 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
9996 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
9997 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
10001 <p><i>[Copenhagen: the original resolution specified an upper
10002 bound. The LWG preferred an exact count.]</i></p>
10011 <h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
10012 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10013 <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
10014 <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>
10015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10016 <p><b>Discussion:</b></p>
10018 <p>Some popular implementations of unique_copy() create temporary
10019 copies of values in the input sequence, at least if the input iterator
10020 is a pointer. Such an implementation is built on the assumption that
10021 the value type is CopyConstructible and Assignable.</p>
10023 <p>It is common practice in the standard that algorithms explicitly
10024 specify any additional requirements that they impose on any of the
10025 types used by the algorithm. An example of an algorithm that creates
10026 temporary copies and correctly specifies the additional requirements
10027 is accumulate(), 26.4.1 [rand.req].</p>
10029 <p>Since the specifications of unique() and unique_copy() do not
10030 require CopyConstructible and Assignable of the InputIterator's value
10031 type the above mentioned implementations are not standard-compliant. I
10032 cannot judge whether this is a defect in the standard or a defect in
10033 the implementations.</p>
10036 <p><b>Proposed resolution:</b></p>
10037 <p>In 25.2.8 change:</p>
10040 -4- Requires: The ranges [first, last) and [result, result+(last-first))
10047 <p>-4- Requires: The ranges [first, last) and [result,
10048 result+(last-first)) shall not overlap. The expression *result =
10049 *first must be valid. If neither InputIterator nor OutputIterator
10050 meets the requirements of forward iterator then the value type of
10051 InputIterator must be copy constructible. Otherwise copy
10052 constructible is not required. </p>
10055 <p><i>[Redmond: the original proposed resolution didn't impose an
10056 explicit requirement that the iterator's value type must be copy
10057 constructible, on the grounds that an input iterator's value type must
10058 always be copy constructible. Not everyone in the LWG thought that
10059 this requirement was clear from table 72. It has been suggested that
10060 it might be possible to implement <tt>unique_copy</tt> without
10061 requiring assignability, although current implementations do impose
10062 that requirement. Howard provided new wording.]</i></p>
10066 Curaçao: The LWG changed the PR editorially to specify
10067 "neither...nor...meet..." as clearer than
10068 "both...and...do not meet...". Change believed to be so
10069 minor as not to require re-review.
10080 <h3><a name="242"></a>242. Side effects of function objects</h3>
10081 <p><b>Section:</b> 25.2.4 [alg.transform], 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10082 <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
10083 <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>
10084 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10085 <p><b>Discussion:</b></p>
10086 <p>The algorithms transform(), accumulate(), inner_product(),
10087 partial_sum(), and adjacent_difference() require that the function
10088 object supplied to them shall not have any side effects.</p>
10090 <p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
10091 <blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
10092 modifying an object, calling a library I/O function, or calling a function
10093 that does any of those operations are all side effects, which are changes
10094 in the state of the execution environment.</p></blockquote>
10096 <p>As a consequence, the function call operator of a function object supplied
10097 to any of the algorithms listed above cannot modify data members, cannot
10098 invoke any function that has a side effect, and cannot even create and
10099 modify temporary objects. It is difficult to imagine a function object
10100 that is still useful under these severe limitations. For instance, any
10101 non-trivial transformator supplied to transform() might involve creation
10102 and modification of temporaries, which is prohibited according to the current
10103 wording of the standard.</p>
10105 <p>On the other hand, popular implementations of these algorithms exhibit
10106 uniform and predictable behavior when invoked with a side-effect-producing
10107 function objects. It looks like the strong requirement is not needed for
10108 efficient implementation of these algorithms.</p>
10110 <p>The requirement of side-effect-free function objects could be
10111 replaced by a more relaxed basic requirement (which would hold for all
10112 function objects supplied to any algorithm in the standard library):</p>
10113 <blockquote><p>A function objects supplied to an algorithm shall not invalidate
10114 any iterator or sequence that is used by the algorithm. Invalidation of
10115 the sequence includes destruction of the sorting order if the algorithm
10116 relies on the sorting order (see section 25.3 - Sorting and related operations
10117 [lib.alg.sorting]).</p></blockquote>
10119 <p>I can't judge whether it is intended that the function objects supplied
10120 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
10121 shall not modify sequence elements through dereferenced iterators.</p>
10123 <p>It is debatable whether this issue is a defect or a change request.
10124 Since the consequences for user-supplied function objects are drastic and
10125 limit the usefulness of the algorithms significantly I would consider it
10129 <p><b>Proposed resolution:</b></p>
10131 <p><i>Things to notice about these changes:</i></p>
10134 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
10135 are intentional. we want to prevent side-effects from
10136 invalidating the end iterators.</i></li>
10138 <li> <i>That has the unintentional side-effect of prohibiting
10139 modification of the end element as a side-effect. This could
10140 conceivably be significant in some cases.</i></li>
10142 <li> <i>The wording also prevents side-effects from modifying elements
10143 of the output sequence. I can't imagine why anyone would want
10144 to do this, but it is arguably a restriction that implementors
10145 don't need to place on users.</i></li>
10147 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
10148 and simple, but would require more verbiage.</i></li>
10151 <p>Change 25.2.3/2 from:</p>
10154 -2- Requires: op and binary_op shall not have any side effects.
10160 -2- Requires: in the ranges [first1, last1], [first2, first2 +
10161 (last1 - first1)] and [result, result + (last1- first1)], op and
10162 binary_op shall neither modify elements nor invalidate iterators or
10164 [Footnote: The use of fully closed ranges is intentional --end footnote]
10168 <p>Change 25.2.3/2 from:</p>
10171 -2- Requires: op and binary_op shall not have any side effects.
10177 -2- Requires: op and binary_op shall not invalidate iterators or
10178 subranges, or modify elements in the ranges [first1, last1],
10179 [first2, first2 + (last1 - first1)], and [result, result + (last1
10181 [Footnote: The use of fully closed ranges is intentional --end footnote]
10185 <p>Change 26.4.1/2 from:</p>
10188 -2- Requires: T must meet the requirements of CopyConstructible
10189 (lib.copyconstructible) and Assignable (lib.container.requirements)
10190 types. binary_op shall not cause side effects.
10196 -2- Requires: T must meet the requirements of CopyConstructible
10197 (lib.copyconstructible) and Assignable
10198 (lib.container.requirements) types. In the range [first, last],
10199 binary_op shall neither modify elements nor invalidate iterators
10201 [Footnote: The use of a fully closed range is intentional --end footnote]
10204 <p>Change 26.4.2/2 from:</p>
10207 -2- Requires: T must meet the requirements of CopyConstructible
10208 (lib.copyconstructible) and Assignable (lib.container.requirements)
10209 types. binary_op1 and binary_op2 shall not cause side effects.
10215 -2- Requires: T must meet the requirements of CopyConstructible
10216 (lib.copyconstructible) and Assignable (lib.container.requirements)
10217 types. In the ranges [first, last] and [first2, first2 + (last -
10218 first)], binary_op1 and binary_op2 shall neither modify elements
10219 nor invalidate iterators or subranges.
10220 [Footnote: The use of fully closed ranges is intentional --end footnote]
10224 <p>Change 26.4.3/4 from:</p>
10227 -4- Requires: binary_op is expected not to have any side effects.
10233 -4- Requires: In the ranges [first, last] and [result, result +
10234 (last - first)], binary_op shall neither modify elements nor
10235 invalidate iterators or subranges.
10236 [Footnote: The use of fully closed ranges is intentional --end footnote]
10239 <p>Change 26.4.4/2 from:</p>
10242 -2- Requires: binary_op shall not have any side effects.
10248 -2- Requires: In the ranges [first, last] and [result, result +
10249 (last - first)], binary_op shall neither modify elements nor
10250 invalidate iterators or subranges.
10251 [Footnote: The use of fully closed ranges is intentional --end footnote]
10254 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
10257 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
10258 added footnotes pointing out that the use of closed ranges was
10259 intentional.]</i></p>
10268 <h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
10269 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10270 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</p>
10271 <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>
10272 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10273 <p><b>Discussion:</b></p>
10274 <p>basic_istream<>::get(), and basic_istream<>::getline(),
10275 are unclear with respect to the behavior and side-effects of the named
10276 functions in case of an error.</p>
10278 <p>27.6.1.3, p1 states that "... If the sentry object returns
10279 true, when converted to a value of type bool, the function endeavors
10280 to obtain the requested input..." It is not clear from this (or
10281 the rest of the paragraph) what precisely the behavior should be when
10282 the sentry ctor exits by throwing an exception or when the sentry
10283 object returns false. In particular, what is the number of characters
10284 extracted that gcount() returns supposed to be?</p>
10286 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
10287 "... In any case, it then stores a null character (using
10288 charT()) into the next successive location of the array." Is not
10289 clear whether this sentence applies if either of the conditions above
10290 holds (i.e., when sentry fails).</p>
10293 <p><b>Proposed resolution:</b></p>
10294 <p>Add to 27.6.1.3, p1 after the sentence</p>
10297 "... If the sentry object returns true, when converted to a value of
10298 type bool, the function endeavors to obtain the requested input."
10301 <p>the following</p>
10305 "Otherwise, if the sentry constructor exits by throwing an exception or
10306 if the sentry object returns false, when converted to a value of type
10307 bool, the function returns without attempting to obtain any input. In
10308 either case the number of extracted characters is set to 0; unformatted
10309 input functions taking a character array of non-zero size as an argument
10310 shall also store a null character (using charT()) in the first location
10315 <p><b>Rationale:</b></p>
10316 <p>Although the general philosophy of the input functions is that the
10317 argument should not be modified upon failure, <tt>getline</tt>
10318 historically added a terminating null unconditionally. Most
10319 implementations still do that. Earlier versions of the draft standard
10320 had language that made this an unambiguous requirement; those words
10321 were moved to a place where their context made them less clear. See
10322 Jerry Schwarz's message c++std-lib-7618.</p>
10328 <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
10329 <p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10330 <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p>
10331 <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>
10332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10333 <p><b>Discussion:</b></p>
10334 <p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
10335 of <tt>vector::insert</tt>:</p>
10338 Complexity: If first and last are forward iterators, bidirectional
10339 iterators, or random access iterators, the complexity is linear in
10340 the number of elements in the range [first, last) plus the distance
10341 to the end of the vector. If they are input iterators, the complexity
10342 is proportional to the number of elements in the range [first, last)
10343 times the distance to the end of the vector.
10346 <p>First, this fails to address the non-iterator forms of
10347 <tt>insert</tt>.</p>
10349 <p>Second, the complexity for input iterators misses an edge case --
10350 it requires that an arbitrary number of elements can be added at
10351 the end of a <tt>vector</tt> in constant time.</p>
10353 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
10354 surprised to find that <tt>deque</tt> places no requirement on the
10355 complexity of inserting multiple elements (23.2.2.3 [deque.modifiers],
10359 Complexity: In the worst case, inserting a single element into a
10360 deque takes time linear in the minimum of the distance from the
10361 insertion point to the beginning of the deque and the distance
10362 from the insertion point to the end of the deque. Inserting a
10363 single element either at the beginning or end of a deque always
10364 takes constant time and causes a single call to the copy constructor
10369 <p><b>Proposed resolution:</b></p>
10371 <p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p>
10373 Complexity: The complexity is linear in the number of elements
10374 inserted plus the distance to the end of the vector.
10377 <p><i>[For input iterators, one may achieve this complexity by first
10378 inserting at the end of the <tt>vector</tt>, and then using
10379 <tt>rotate</tt>.]</i></p>
10382 <p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p>
10385 Complexity: The complexity is linear in the number of elements
10386 inserted plus the shorter of the distances to the beginning and
10387 end of the deque. Inserting a single element at either the
10388 beginning or the end of a deque causes a single call to the copy
10394 <p><b>Rationale:</b></p>
10395 <p>This is a real defect, and proposed resolution fixes it: some
10396 complexities aren't specified that should be. This proposed
10397 resolution does constrain deque implementations (it rules out the
10398 most naive possible implementations), but the LWG doesn't see a
10399 reason to permit that implementation.</p>
10406 <h3><a name="248"></a>248. time_get fails to set eofbit</h3>
10407 <p><b>Section:</b> 22.2.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10408 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-06-22</p>
10409 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10410 <p><b>Discussion:</b></p>
10411 <p>There is no requirement that any of time_get member functions set
10412 ios::eofbit when they reach the end iterator while parsing their input.
10413 Since members of both the num_get and money_get facets are required to
10414 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
10415 should follow the same requirement for consistency.</p>
10418 <p><b>Proposed resolution:</b></p>
10419 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
10422 If the end iterator is reached during parsing by any of the get()
10423 member functions, the member sets ios_base::eofbit in err.
10427 <p><b>Rationale:</b></p>
10428 <p>Two alternative resolutions were proposed. The LWG chose this one
10429 because it was more consistent with the way eof is described for other
10436 <h3><a name="250"></a>250. splicing invalidates iterators</h3>
10437 <p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10438 <b>Submitter:</b> Brian Parker <b>Date:</b> 2000-07-14</p>
10439 <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>
10440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10441 <p><b>Discussion:</b></p>
10443 Section 23.2.4.4 [list.ops] states that
10445 <pre> void splice(iterator position, list<T, Allocator>& x);
10448 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
10452 This is unnecessary and defeats an important feature of splice. In
10453 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
10454 after <tt>splice</tt>.
10458 <p><b>Proposed resolution:</b></p>
10460 <p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p>
10462 [<i>Footnote:</i> As specified in [default.con.req], paragraphs
10463 4-5, the semantics described in this clause applies only to the case
10464 where allocators compare equal. --end footnote]
10467 <p>In 23.2.4.4 [list.ops], replace paragraph 4 with:</p>
10469 Effects: Inserts the contents of x before position and x becomes
10470 empty. Pointers and references to the moved elements of x now refer to
10471 those same elements but as members of *this. Iterators referring to the
10472 moved elements will continue to refer to their elements, but they now
10473 behave as iterators into *this, not into x.
10476 <p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p>
10478 Effects: Inserts an element pointed to by i from list x before
10479 position and removes the element from x. The result is unchanged if
10480 position == i or position == ++i. Pointers and references to *i continue
10481 to refer to this same element but as a member of *this. Iterators to *i
10482 (including i itself) continue to refer to the same element, but now
10483 behave as iterators into *this, not into x.
10486 <p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p>
10488 Requires: [first, last) is a valid range in x. The result is
10489 undefined if position is an iterator in the range [first, last).
10490 Pointers and references to the moved elements of x now refer to those
10491 same elements but as members of *this. Iterators referring to the moved
10492 elements will continue to refer to their elements, but they now behave as
10493 iterators into *this, not into x.
10496 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
10500 <p><b>Rationale:</b></p>
10501 <p>The original proposed resolution said that iterators and references
10502 would remain "valid". The new proposed resolution clarifies what that
10503 means. Note that this only applies to the case of equal allocators.
10504 From [default.con.req] paragraph 4, the behavior of list when
10505 allocators compare nonequal is outside the scope of the standard.</p>
10511 <h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
10512 <p><b>Section:</b> 27.7.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10513 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10515 <p><b>Discussion:</b></p>
10516 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
10517 doesn't list a typedef for the template parameter
10518 <tt>Allocator</tt>. This makes it impossible to determine the type of
10519 the allocator at compile time. It's also inconsistent with all other
10520 template classes in the library that do provide a typedef for the
10521 <tt>Allocator</tt> parameter.</p>
10524 <p><b>Proposed resolution:</b></p>
10525 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
10526 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
10527 basic_stringstream (27.7.4) the typedef:</p>
10528 <pre> typedef Allocator allocator_type;
10535 <h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
10536 <p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10537 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
10538 <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>
10539 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10540 <p><b>Discussion:</b></p>
10541 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
10542 const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
10543 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
10544 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
10545 the cast altogether.</p>
10547 <p>C-style casts have not been deprecated, so the first part of this
10548 issue is stylistic rather than a matter of correctness.</p>
10551 <p><b>Proposed resolution:</b></p>
10552 <p>In 27.7.2.2, p1 replace </p>
10553 <pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
10556 <pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
10559 <p>In 27.7.3.2, p1 replace</p>
10560 <pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
10563 <pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
10565 <p>In 27.7.6, p1, replace</p>
10566 <pre> -1- Returns: &sb</pre>
10569 <pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
10571 <p>In D.7.2.2, p1 replace</p>
10572 <pre> -2- Returns: &sb. </pre>
10575 <pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre>
10581 <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
10582 <p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10583 <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
10584 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
10585 <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>
10586 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10587 <p><b>Discussion:</b></p>
10588 <p>This discussion is adapted from message c++std-lib-7056 posted
10589 November 11, 1999. I don't think that anyone can reasonably claim
10590 that the problem described below is NAD.</p>
10592 <p>These valarray constructors can never be called:</p>
10594 <pre> template <class T>
10595 valarray<T>::valarray(const slice_array<T> &);
10596 template <class T>
10597 valarray<T>::valarray(const gslice_array<T> &);
10598 template <class T>
10599 valarray<T>::valarray(const mask_array<T> &);
10600 template <class T>
10601 valarray<T>::valarray(const indirect_array<T> &);
10604 <p>Similarly, these valarray assignment operators cannot be
10607 <pre> template <class T>
10608 valarray<T> valarray<T>::operator=(const slice_array<T> &);
10609 template <class T>
10610 valarray<T> valarray<T>::operator=(const gslice_array<T> &);
10611 template <class T>
10612 valarray<T> valarray<T>::operator=(const mask_array<T> &);
10613 template <class T>
10614 valarray<T> valarray<T>::operator=(const indirect_array<T> &);
10617 <p>Please consider the following example:</p>
10619 <pre> #include <valarray>
10620 using namespace std;
10624 valarray<double> va1(12);
10625 valarray<double> va2(va1[slice(1,4,3)]); // line 1
10630 <p>Since the valarray va1 is non-const, the result of the sub-expression
10631 va1[slice(1,4,3)] at line 1 is an rvalue of type const
10632 std::slice_array<double>. This slice_array rvalue is then used to
10633 construct va2. The constructor that is used to construct va2 is
10634 declared like this:</p>
10636 <pre> template <class T>
10637 valarray<T>::valarray(const slice_array<T> &);
10640 <p>Notice the constructor's const reference parameter. When the
10641 constructor is called, a slice_array must be bound to this reference.
10642 The rules for binding an rvalue to a const reference are in 8.5.3,
10643 paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5
10644 indicates that a second slice_array rvalue is constructed (in this
10645 case copy-constructed) from the first one; it is this second rvalue
10646 that is bound to the reference parameter. Paragraph 5 also requires
10647 that the constructor that is used for this purpose be callable,
10648 regardless of whether the second rvalue is elided. The
10649 copy-constructor in this case is not callable, however, because it is
10650 private. Therefore, the compiler should report an error.</p>
10652 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
10653 parameter of type const slice_array<T> & can never be called. The
10654 same reasoning applies to the three other constructors and the four
10655 assignment operators that are listed at the beginning of this post.
10656 Furthermore, since these functions cannot be called, the valarray helper
10657 classes are almost entirely useless.</p>
10660 <p><b>Proposed resolution:</b></p>
10661 <p>slice_array:</p>
10663 <li> Make the copy constructor and copy-assignment operator declarations
10664 public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
10665 <li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
10666 <li> remove the copy constructor declaration from [cons.slice.arr]</li>
10667 <li> change paragraph 1 of [cons.slice.arr] to read "This constructor is declared
10668 to be private. This constructor need not be defined."</li>
10669 <li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li>
10670 <li> Change the first three words of the second sentence of paragraph 1 of
10671 26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li>
10674 <p>gslice_array:</p>
10676 <li> Make the copy constructor and copy-assignment operator declarations
10677 public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
10678 <li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
10679 <li> remove the copy constructor declaration from [gslice.array.cons]</li>
10680 <li> change paragraph 1 of [gslice.array.cons] to read "This constructor is declared
10681 to be private. This constructor need not be defined."</li>
10682 <li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li>
10683 <li> Change the first three words of the second sentence of paragraph 1 of
10684 26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li>
10689 <li> Make the copy constructor and copy-assignment operator declarations
10690 public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
10691 <li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
10692 <li> remove the copy constructor declaration from [mask.array.cons]</li>
10693 <li> change paragraph 1 of [mask.array.cons] to read "This constructor is declared
10694 to be private. This constructor need not be defined."</li>
10695 <li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li>
10696 <li> Change the first three words of the second sentence of paragraph 1 of
10697 26.5.8.1 [mask.array.assign] to "These assignment operators have"</li>
10700 <p>indirect_array:</p>
10702 <li>Make the copy constructor and copy-assignment operator declarations
10703 public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
10704 <li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
10705 <li> remove the copy constructor declaration from [indirect.array.cons]</li>
10706 <li> change the descriptive text in [indirect.array.cons] to read "This constructor is
10707 declared to be private. This constructor need not be defined."</li>
10708 <li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li>
10709 <li> Change the first three words of the second sentence of paragraph 1 of
10710 26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li>
10712 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
10713 copy constructor and copy assignment operators public, instead of
10714 removing them.]</i></p>
10718 <p><b>Rationale:</b></p>
10719 <p>Keeping the valarray constructors private is untenable. Merely
10720 making valarray a friend of the helper classes isn't good enough,
10721 because access to the copy constructor is checked in the user's
10724 <p>Making the assignment operator public is not strictly necessary to
10725 solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i>
10726 believed we should make the assignment operators public, in addition
10727 to the copy constructors, for reasons of symmetry and user
10735 <h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
10736 <p><b>Section:</b> 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
10737 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-08-01</p>
10738 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
10739 <p><b>Discussion:</b></p>
10741 Many of the standard exception types which implementations are
10742 required to throw are constructed with a const std::string&
10743 parameter. For example:
10746 <pre> 19.1.5 Class out_of_range [lib.out.of.range]
10748 class out_of_range : public logic_error {
10750 explicit out_of_range(const string& what_arg);
10754 1 The class out_of_range defines the type of objects thrown as excep-
10755 tions to report an argument value not in its expected range.
10757 out_of_range(const string& what_arg);
10760 Constructs an object of class out_of_range.
10762 strcmp(what(), what_arg.c_str()) == 0.
10766 There are at least two problems with this:
10769 <li>A program which is low on memory may end up throwing
10770 std::bad_alloc instead of out_of_range because memory runs out while
10771 constructing the exception object.</li>
10772 <li>An obvious implementation which stores a std::string data member
10773 may end up invoking terminate() during exception unwinding because the
10774 exception object allocates memory (or rather fails to) as it is being
10779 There may be no cure for (1) other than changing the interface to
10780 out_of_range, though one could reasonably argue that (1) is not a
10781 defect. Personally I don't care that much if out-of-memory is reported
10782 when I only have 20 bytes left, in the case when out_of_range would
10783 have been reported. People who use exception-specifications might care
10788 There is a cure for (2), but it isn't completely obvious. I think a
10789 note for implementors should be made in the standard. Avoiding
10790 possible termination in this case shouldn't be left up to chance. The
10791 cure is to use a reference-counted "string" implementation
10792 in the exception object. I am not necessarily referring to a
10793 std::string here; any simple reference-counting scheme for a NTBS
10797 <p><b>Further discussion, in email:</b></p>
10800 ...I'm not so concerned about (1). After all, a library implementation
10801 can add const char* constructors as an extension, and users don't
10802 <i>need</i> to avail themselves of the standard exceptions, though this is
10803 a lame position to be forced into. FWIW, std::exception and
10804 std::bad_alloc don't require a temporary basic_string.
10808 ...I don't think the fixed-size buffer is a solution to the problem,
10809 strictly speaking, because you can't satisfy the postcondition
10811 <tt> strcmp(what(), what_arg.c_str()) == 0</tt>
10813 For all values of what_arg (i.e. very long values). That means that
10814 the only truly conforming solution requires a dynamic allocation.
10817 <p><b>Further discussion, from Redmond:</b></p>
10819 <p>The most important progress we made at the Redmond meeting was
10820 realizing that there are two separable issues here: the const
10821 string& constructor, and the copy constructor. If a user writes
10822 something like <tt>throw std::out_of_range("foo")</tt>, the const
10823 string& constructor is invoked before anything gets thrown. The
10824 copy constructor is potentially invoked during stack unwinding.</p>
10826 <p>The copy constructor is a more serious problem, becuase failure
10827 during stack unwinding invokes <tt>terminate</tt>. The copy
10828 constructor must be nothrow. <i>Curaçao: Howard thinks this
10829 requirement may already be present.</i></p>
10831 <p>The fundamental problem is that it's difficult to get the nothrow
10832 requirement to work well with the requirement that the exception
10833 objects store a string of unbounded size, particularly if you also try
10834 to make the const string& constructor nothrow. Options discussed
10838 <li>Limit the size of a string that exception objects are required to
10839 throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
10840 and 19.1.6 [runtime.error] paragraph 3 to something like this:
10841 "strncmp(what(), what_arg._str(), N) == 0, where N is an
10842 implementation defined constant no smaller than 256".</li>
10843 <li>Allow the const string& constructor to throw, but not the
10844 copy constructor. It's the implementor's responsibility to get it
10845 right. (An implementor might use a simple refcount class.)</li>
10846 <li>Compromise between the two: an implementation is not allowed to
10847 throw if the string's length is less than some N, but, if it doesn't
10848 throw, the string must compare equal to the argument.</li>
10849 <li>Add a new constructor that takes a const char*</li>
10852 <p>(Not all of these options are mutually exclusive.)</p>
10856 <p><b>Proposed resolution:</b></p>
10859 Change 19.1.1 [logic.error]
10863 <pre>namespace std {
10864 class logic_error : public exception {
10866 explicit logic_error(const string& <i>what_arg</i>);
10867 <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
10873 <ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
10877 -4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
10880 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10887 Change 19.1.2 [domain.error]
10891 <pre>namespace std {
10892 class domain_error : public logic_error {
10894 explicit domain_error(const string& <i>what_arg</i>);
10895 <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
10901 <ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
10905 -4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
10908 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10915 Change 19.1.3 [invalid.argument]
10919 <pre>namespace std {
10920 class invalid_argument : public logic_error {
10922 explicit invalid_argument(const string& <i>what_arg</i>);
10923 <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
10929 <ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
10933 -4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
10936 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10943 Change 19.1.4 [length.error]
10947 <pre>namespace std {
10948 class length_error : public logic_error {
10950 explicit length_error(const string& <i>what_arg</i>);
10951 <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
10957 <ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
10961 -4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
10964 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10971 Change 19.1.5 [out.of.range]
10975 <pre>namespace std {
10976 class out_of_range : public logic_error {
10978 explicit out_of_range(const string& <i>what_arg</i>);
10979 <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
10985 <ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
10989 -4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
10992 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
10999 Change 19.1.6 [runtime.error]
11003 <pre>namespace std {
11004 class runtime_error : public exception {
11006 explicit runtime_error(const string& <i>what_arg</i>);
11007 <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
11013 <ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
11017 -4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
11020 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11027 Change 19.1.7 [range.error]
11031 <pre>namespace std {
11032 class range_error : public runtime_error {
11034 explicit range_error(const string& <i>what_arg</i>);
11035 <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
11041 <ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
11045 -4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
11048 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11055 Change 19.1.8 [overflow.error]
11059 <pre>namespace std {
11060 class overflow_error : public runtime_error {
11062 explicit overflow_error(const string& <i>what_arg</i>);
11063 <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
11069 <ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
11073 -4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
11076 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11083 Change 19.1.9 [underflow.error]
11087 <pre>namespace std {
11088 class underflow_error : public runtime_error {
11090 explicit underflow_error(const string& <i>what_arg</i>);
11091 <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
11097 <ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
11101 -4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
11104 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11111 Change 27.4.2.1.1 [ios::failure]
11115 <pre>namespace std {
11116 class ios_base::failure : public exception {
11118 explicit failure(const string& <i>msg</i>);
11119 <ins>explicit failure(const char* <i>msg</i>);</ins>
11120 virtual const char* what() const throw();
11126 <ins><tt>failure(const char* <i>msg</i>);</tt></ins>
11130 -4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
11133 -5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
11141 <p><b>Rationale:</b></p>
11143 <p>Throwing a bad_alloc while trying to construct a message for another
11144 exception-derived class is not necessarily a bad thing. And the
11145 bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
11147 <p><b>Future:</b></p>
11149 <p>All involved would like to see const char* constructors added, but
11150 this should probably be done for C++0X as opposed to a DR.</p>
11152 <p>I believe the no throw specs currently decorating these functions
11153 could be improved by some kind of static no throw spec checking
11154 mechanism (in a future C++ language). As they stand, the copy
11155 constructors might fail via a call to unexpected. I think what is
11156 intended here is that the copy constructors can't fail.</p>
11158 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
11159 Post-Redmond: James Kanze noticed that the copy constructors of
11160 exception-derived classes do not have nothrow clauses. Those
11161 classes have no copy constructors declared, meaning the
11162 compiler-generated implicit copy constructors are used, and those
11163 compiler-generated constructors might in principle throw anything.]</i></p>
11167 Batavia: Merged copy constructor and assignment operator spec into <tt>exception</tt>
11168 and added <tt>ios::failure</tt> into the proposed resolution.
11173 Oxford: The proposed resolution simply addresses the issue of constructing
11174 the exception objects with <tt>const char*</tt> and string literals without
11175 the need to explicit include or construct a <tt>std::string</tt>.
11185 <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
11186 <p><b>Section:</b> 27.4.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>
11187 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p>
11188 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
11189 <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>
11190 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11191 <p><b>Discussion:</b></p>
11197 -17- Before copying any parts of rhs, calls each registered callback
11198 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
11199 exceptions() have been replaced, calls each callback pair that was
11200 copied from rhs as (*fn)(copy_event,*this,index).
11204 The name copy_event isn't defined anywhere. The intended name was
11209 <p><b>Proposed resolution:</b></p>
11210 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
11216 <h3><a name="258"></a>258. Missing allocator requirement</h3>
11217 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11218 <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</p>
11219 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
11220 <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>
11221 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11222 <p><b>Discussion:</b></p>
11228 I've been assuming (and probably everyone else has been assuming) that
11229 allocator instances have a particular property, and I don't think that
11230 property can be deduced from anything in Table 32.
11234 I think we have to assume that allocator type conversion is a
11235 homomorphism. That is, if x1 and x2 are of type X, where
11236 X::value_type is T, and if type Y is X::template
11237 rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2.
11241 Further discussion: Howard Hinnant writes, in lib-7757:
11245 I think I can prove that this is not provable by Table 32. And I agree
11246 it needs to be true except for the "and only if". If x1 != x2, I see no
11247 reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't
11248 think of a practical instance where this would happen, or be valuable.
11249 But I also don't see a need to add that extra restriction. I think we
11254 if (x1 == x2) then Y(x1) == Y(x2)
11258 If we decide that == on allocators is transitive, then I think I can
11259 prove the above. But I don't think == is necessarily transitive on
11260 allocators. That is:
11264 Given x1 == x2 and x2 == x3, this does not mean x1 == x3.
11271 x1 can deallocate pointers from: x1, x2, x3 <br>
11272 x2 can deallocate pointers from: x1, x2, x4 <br>
11273 x3 can deallocate pointers from: x1, x3 <br>
11274 x4 can deallocate pointers from: x2, x4
11278 x1 == x2, and x2 == x4, but x1 != x4
11281 <p><i>[Toronto: LWG members offered multiple opinions. One
11282 opinion is that it should not be required that <tt>x1 == x2</tt>
11283 implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
11284 required that <tt>X(x1) == x1</tt>. Another opinion is that
11285 the second line from the bottom in table 32 already implies the
11286 desired property. This issue should be considered in light of
11287 other issues related to allocator instances.]</i></p>
11291 <p><b>Proposed resolution:</b></p>
11293 Accept proposed wording from
11294 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
11298 <p><i>[Lillehammer: Same conclusion as before: this should be
11299 considered as part of an allocator redesign, not solved on its own.]</i></p>
11303 Batavia: An allocator redesign is not forthcoming and thus we fixed this one issue.
11308 Toronto: Reopened at the request of the project editor (Pete) because the proposed
11309 wording did not fit within the indicated table. The intent of the resolution remains
11310 unchanged. Pablo to work with Pete on improved wording.
11315 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
11316 was subsequently split out into a separate paper N2436 for the purposes of voting.
11317 The resolution in N2436 addresses this issue. The LWG voted to accelerate this
11318 issue to Ready status to be voted into the WP at Kona.
11326 <h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
11327 <p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11328 <b>Submitter:</b> Chris Newton <b>Date:</b> 2000-08-27</p>
11329 <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>
11330 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11331 <p><b>Discussion:</b></p>
11333 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
11337 The standard's description of <tt>basic_string<>::operator[]</tt>
11338 seems to violate const correctness.
11342 The standard (21.3.4/1) says that "If <tt>pos < size()</tt>,
11343 returns <tt>data()[pos]</tt>." The types don't work. The
11344 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
11345 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
11349 <p><b>Proposed resolution:</b></p>
11351 In section 21.3.4, paragraph 1, change
11352 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
11360 <h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
11361 <p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11362 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11363 <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>
11364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11365 <p><b>Discussion:</b></p>
11366 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
11367 it as returning the iterator by value. 24.5.1.2, p5 shows the same
11368 operator as returning the iterator by reference. That's incorrect
11369 given the Effects clause below (since a temporary is returned). The
11370 `&' is probably just a typo.</p>
11373 <p><b>Proposed resolution:</b></p>
11374 <p>Change the declaration in 24.5.1.2, p5 from</p>
11375 <pre> istream_iterator<T,charT,traits,Distance>& operator++(int);
11378 <pre> istream_iterator<T,charT,traits,Distance> operator++(int);
11380 <p>(that is, remove the `&').</p>
11386 <h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
11387 <p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11388 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
11389 <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>
11390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11391 <p><b>Discussion:</b></p>
11393 24.5.1, p3 lists the synopsis for
11396 <pre> template <class T, class charT, class traits, class Distance>
11397 bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
11398 const istream_iterator<T,charT,traits,Distance>& y);
11402 but there is no description of what the operator does (i.e., no Effects
11403 or Returns clause) in 24.5.1.2.
11407 <p><b>Proposed resolution:</b></p>
11409 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
11412 <pre> template <class T, class charT, class traits, class Distance>
11413 bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
11414 const istream_iterator<T,charT,traits,Distance>& y);
11417 <p>-7- Returns: !(x == y).</p>
11423 <h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
11424 <p><b>Section:</b> 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11425 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-09-03</p>
11426 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11427 <p><b>Discussion:</b></p>
11429 The ~ operation should be applied after the cast to int_type.
11433 <p><b>Proposed resolution:</b></p>
11435 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
11438 <pre> bitmask operator~ ( bitmask X )
11439 { return static_cast< bitmask>(static_cast<int_type>(~ X)); }
11446 <pre> bitmask operator~ ( bitmask X )
11447 { return static_cast< bitmask>(~static_cast<int_type>(X)); }
11454 <h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
11455 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11456 <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</p>
11457 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
11458 <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>
11459 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11460 <p><b>Discussion:</b></p>
11462 The note in paragraph 6 suggests that the invalidation rules for
11463 references, pointers, and iterators in paragraph 5 permit a reference-
11464 counted implementation (actually, according to paragraph 6, they permit
11465 a "reference counted implementation", but this is a minor editorial fix).
11469 However, the last sub-bullet is so worded as to make a reference-counted
11470 implementation unviable. In the following example none of the
11471 conditions for iterator invalidation are satisfied:
11474 <pre> // first example: "*******************" should be printed twice
11475 string original = "some arbitrary text", copy = original;
11476 const string & alias = original;
11478 string::const_iterator i = alias.begin(), e = alias.end();
11479 for(string::iterator j = original.begin(); j != original.end(); ++j)
11482 cout << *i++;
11483 cout << endl;
11484 cout << original << endl;
11488 Similarly, in the following example:
11491 <pre> // second example: "some arbitrary text" should be printed out
11492 string original = "some arbitrary text", copy = original;
11493 const string & alias = original;
11495 string::const_iterator i = alias.begin();
11497 while(i != alias.end())
11498 cout << *i++;
11502 I have tested this on three string implementations, two of which were
11503 reference counted. The reference-counted implementations gave
11504 "surprising behavior" because they invalidated iterators on
11505 the first call to non-const begin since construction. The current
11506 wording does not permit such invalidation because it does not take
11507 into account the first call since construction, only the first call
11508 since various member and non-member function calls.
11512 <p><b>Proposed resolution:</b></p>
11514 Change the following sentence in 21.3 paragraph 5 from
11518 Subsequent to any of the above uses except the forms of insert() and
11519 erase() which return iterators, the first call to non-const member
11520 functions operator[](), at(), begin(), rbegin(), end(), or rend().
11526 Following construction or any of the above uses, except the forms of
11527 insert() and erase() that return iterators, the first call to non-
11528 const member functions operator[](), at(), begin(), rbegin(), end(),
11536 <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
11537 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11538 <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p>
11539 <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>
11540 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11541 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
11542 <p><b>Discussion:</b></p>
11544 Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
11545 Consider inserting a sorted range of even integers into a set<int> containing the odd
11546 integers in the same range.
11549 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
11552 <p><b>Proposed resolution:</b></p>
11554 In Table 69, in section 23.1.2, change the complexity clause for
11555 insertion of a range from "N log(size() + N) (N is the distance
11556 from i to j) in general; linear if [i, j) is sorted according to
11557 value_comp()" to "N log(size() + N), where N is the distance
11561 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
11562 parens in the revised wording.]</i></p>
11567 <p><b>Rationale:</b></p>
11569 Testing for valid insertions could be less efficient than simply
11570 inserting the elements when the range is not both sorted and between
11571 two adjacent existing elements; this could be a QOI issue.
11575 The LWG considered two other options: (a) specifying that the
11576 complexity was linear if [i, j) is sorted according to value_comp()
11577 and between two adjacent existing elements; or (b) changing to
11578 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
11579 number of elements which do not insert immediately after the previous
11580 element from [i, j) including the first). The LWG felt that, since
11581 we can't guarantee linear time complexity whenever the range to be
11582 inserted is sorted, it's more trouble than it's worth to say that it's
11583 linear in some special cases.
11590 <h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
11591 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11592 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-11</p>
11593 <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>
11594 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11595 <p><b>Discussion:</b></p>
11597 I don't see any requirements on the types of the elements of the
11598 std::pair container in 20.2.2. From the descriptions of the member
11599 functions it appears that they must at least satisfy the requirements of
11600 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
11601 the case of the [in]equality operators also the requirements of 20.1.1
11602 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
11606 I believe that the the CopyConstructible requirement is unnecessary in
11607 the case of 20.2.2, p2.
11611 <p><b>Proposed resolution:</b></p>
11612 <p>Change the Effects clause in 20.2.2, p2 from</p>
11615 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11616 first(T1()), second(T2()) {} </tt>
11622 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
11623 first(), second() {} </tt>
11627 <p><b>Rationale:</b></p>
11628 <p>The existing specification of pair's constructor appears to be a
11629 historical artifact: there was concern that pair's members be properly
11630 zero-initialized when they are built-in types. At one time there was
11631 uncertainty about whether they would be zero-initialized if the
11632 default constructor was written the obvious way. This has been
11633 clarified by core issue 178, and there is no longer any doubt that
11634 the straightforward implementation is correct.</p>
11640 <h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
11641 <p><b>Section:</b> 18.7.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11642 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-24</p>
11643 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11644 <p><b>Discussion:</b></p>
11646 The synopsis for std::bad_exception lists the function ~bad_exception()
11647 but there is no description of what the function does (the Effects
11648 clause is missing).
11652 <p><b>Proposed resolution:</b></p>
11654 Remove the destructor from the class synopses of
11655 <tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]),
11656 <tt>bad_cast</tt> (18.6.2 [bad.cast]),
11657 <tt>bad_typeid</tt> (18.6.3 [bad.typeid]),
11658 and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]).
11662 <p><b>Rationale:</b></p>
11664 This is a general problem with the exception classes in clause 18.
11665 The proposed resolution is to remove the destructors from the class
11666 synopses, rather than to document the destructors' behavior, because
11667 removing them is more consistent with how exception classes are
11668 described in clause 19.
11675 <h3><a name="268"></a>268. Typo in locale synopsis</h3>
11676 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11677 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
11678 <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>
11679 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11680 <p><b>Discussion:</b></p>
11681 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
11682 the semicolons after the declarations of the default ctor
11683 locale::locale() and the copy ctor locale::locale(const locale&)
11687 <p><b>Proposed resolution:</b></p>
11688 <p>Add the missing semicolons, i.e., change</p>
11690 <pre> // construct/copy/destroy:
11692 locale(const locale& other) throw()
11695 <p>in the synopsis in 22.1.1 to</p>
11697 <pre> // construct/copy/destroy:
11699 locale(const locale& other) throw();
11706 <h3><a name="270"></a>270. Binary search requirements overly strict</h3>
11707 <p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11708 <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p>
11709 <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>
11710 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11711 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
11712 <p><b>Discussion:</b></p>
11714 Each of the four binary search algorithms (lower_bound, upper_bound,
11715 equal_range, binary_search) has a form that allows the user to pass a
11716 comparison function object. According to 25.3, paragraph 2, that
11717 comparison function object has to be a strict weak ordering.
11721 This requirement is slightly too strict. Suppose we are searching
11722 through a sequence containing objects of type X, where X is some
11723 large record with an integer key. We might reasonably want to look
11724 up a record by key, in which case we would want to write something
11727 <pre> struct key_comp {
11728 bool operator()(const X& x, int n) const {
11729 return x.key() < n;
11733 std::lower_bound(first, last, 47, key_comp());
11737 key_comp is not a strict weak ordering, but there is no reason to
11738 prohibit its use in lower_bound.
11742 There's no difficulty in implementing lower_bound so that it allows
11743 the use of something like key_comp. (It will probably work unless an
11744 implementor takes special pains to forbid it.) What's difficult is
11745 formulating language in the standard to specify what kind of
11746 comparison function is acceptable. We need a notion that's slightly
11747 more general than that of a strict weak ordering, one that can encompass
11748 a comparison function that involves different types. Expressing that
11749 notion may be complicated.
11752 <p><i>Additional questions raised at the Toronto meeting:</i></p>
11754 <li> Do we really want to specify what ordering the implementor must
11755 use when calling the function object? The standard gives
11756 specific expressions when describing these algorithms, but it also
11757 says that other expressions (with different argument order) are
11759 <li> If we are specifying ordering, note that the standard uses both
11760 orderings when describing <tt>equal_range</tt>.</li>
11761 <li> Are we talking about requiring these algorithms to work properly
11762 when passed a binary function object whose two argument types
11763 are not the same, or are we talking about requirements when
11764 they are passed a binary function object with several overloaded
11765 versions of <tt>operator()</tt>?</li>
11766 <li> The definition of a strict weak ordering does not appear to give
11767 any guidance on issues of overloading; it only discusses expressions,
11768 and all of the values in these expressions are of the same type.
11769 Some clarification would seem to be in order.</li>
11772 <p><i>Additional discussion from Copenhagen:</i></p>
11774 <li>It was generally agreed that there is a real defect here: if
11775 the predicate is merely required to be a Strict Weak Ordering, then
11776 it's possible to pass in a function object with an overloaded
11777 operator(), where the version that's actually called does something
11778 completely inappropriate. (Such as returning a random value.)</li>
11780 <li>An alternative formulation was presented in a paper distributed by
11781 David Abrahams at the meeting, "Binary Search with Heterogeneous
11782 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
11783 predicate as a Strict Weak Ordering acting on a sorted sequence, view
11784 the predicate/value pair as something that partitions a sequence.
11785 This is almost equivalent to saying that we should view binary search
11786 as if we are given a unary predicate and a sequence, such that f(*p)
11787 is true for all p below a specific point and false for all p above it.
11788 The proposed resolution is based on that alternative formulation.</li>
11792 <p><b>Proposed resolution:</b></p>
11794 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
11797 3 For all algorithms that take Compare, there is a version that uses
11798 operator< instead. That is, comp(*i, *j) != false defaults to *i <
11799 *j != false. For the algorithms to work correctly, comp has to
11800 induce a strict weak ordering on the values.
11806 3 For all algorithms that take Compare, there is a version that uses
11807 operator< instead. That is, comp(*i, *j) != false defaults to *i
11808 < *j != false. For algorithms other than those described in
11809 lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
11810 a strict weak ordering on the values.
11813 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
11816 -6- A sequence [start, finish) is partitioned with respect to an
11817 expression f(e) if there exists an integer n such that
11818 for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
11819 and only if i < n.
11822 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
11825 -1- All of the algorithms in this section are versions of binary
11826 search and assume that the sequence being searched is in order
11827 according to the implied or explicit comparison function. They work
11828 on non-random access iterators minimizing the number of
11829 comparisons, which will be logarithmic for all types of
11830 iterators. They are especially appropriate for random access
11831 iterators, because these algorithms do a logarithmic number of
11832 steps through the data structure. For non-random access iterators
11833 they execute a linear number of steps.
11839 -1- All of the algorithms in this section are versions of binary
11840 search and assume that the sequence being searched is partitioned
11841 with respect to an expression formed by binding the search key to
11842 an argument of the implied or explicit comparison function. They
11843 work on non-random access iterators minimizing the number of
11844 comparisons, which will be logarithmic for all types of
11845 iterators. They are especially appropriate for random access
11846 iterators, because these algorithms do a logarithmic number of
11847 steps through the data structure. For non-random access iterators
11848 they execute a linear number of steps.
11851 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
11854 -1- Requires: Type T is LessThanComparable
11855 (lib.lessthancomparable).
11861 -1- Requires: The elements e of [first, last) are partitioned with
11862 respect to the expression e < value or comp(e, value)
11866 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
11869 -2- Effects: Finds the first position into which value can be
11870 inserted without violating the ordering.
11873 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
11876 -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
11882 -1- Requires: The elements e of [first, last) are partitioned with
11883 respect to the expression !(value < e) or !comp(value, e)
11886 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
11889 -2- Effects: Finds the furthermost position into which value can be
11890 inserted without violating the ordering.
11893 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
11896 -1- Requires: Type T is LessThanComparable
11897 (lib.lessthancomparable).
11903 -1- Requires: The elements e of [first, last) are partitioned with
11904 respect to the expressions e < value and !(value < e) or
11905 comp(e, value) and !comp(value, e). Also, for all elements e of
11906 [first, last), e < value implies !(value < e) or comp(e,
11907 value) implies !comp(value, e)
11910 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
11913 -2- Effects: Finds the largest subrange [i, j) such that the value
11914 can be inserted at any iterator k in it without violating the
11915 ordering. k satisfies the corresponding conditions: !(*k < value)
11916 && !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
11923 make_pair(lower_bound(first, last, value),
11924 upper_bound(first, last, value))
11926 make_pair(lower_bound(first, last, value, comp),
11927 upper_bound(first, last, value, comp))
11930 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
11933 -1- Requires: Type T is LessThanComparable
11934 (lib.lessthancomparable).
11940 -1- Requires: The elements e of [first, last) are partitioned with
11941 respect to the expressions e < value and !(value < e) or comp(e,
11942 value) and !comp(value, e). Also, for all elements e of [first,
11943 last), e < value implies !(value < e) or comp(e, value) implies
11947 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
11950 <p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and
11951 changed the "other than those described in" wording.) Also, the LWG
11952 decided to accept the "optional" part.]</i></p>
11957 <p><b>Rationale:</b></p>
11958 <p>The proposed resolution reinterprets binary search. Instead of
11959 thinking about searching for a value in a sorted range, we view that
11960 as an important special case of a more general algorithm: searching
11961 for the partition point in a partitioned range.</p>
11963 <p>We also add a guarantee that the old wording did not: we ensure
11964 that the upper bound is no earlier than the lower bound, that
11965 the pair returned by equal_range is a valid range, and that the first
11966 part of that pair is the lower bound.</p>
11973 <h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
11974 <p><b>Section:</b> 27.6.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
11975 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
11976 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
11977 <p><b>Discussion:</b></p>
11979 Class template basic_iostream has no typedefs. The typedefs it
11980 inherits from its base classes can't be used, since (for example)
11981 basic_iostream<T>::traits_type is ambiguous.
11985 <p><b>Proposed resolution:</b></p>
11987 <p>Add the following to basic_iostream's class synopsis in
11988 27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
11991 typedef charT char_type;
11992 typedef typename traits::int_type int_type;
11993 typedef typename traits::pos_type pos_type;
11994 typedef typename traits::off_type off_type;
11995 typedef traits traits_type;
12002 <h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
12003 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12004 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
12005 <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>
12006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12007 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
12008 <p><b>Discussion:</b></p>
12010 27.4.4.3, p4 says about the postcondition of the function: If
12011 rdbuf()!=0 then state == rdstate(); otherwise
12012 rdstate()==state|ios_base::badbit.
12016 The expression on the right-hand-side of the operator==() needs to be
12017 parenthesized in order for the whole expression to ever evaluate to
12018 anything but non-zero.
12022 <p><b>Proposed resolution:</b></p>
12024 Add parentheses like so: rdstate()==(state|ios_base::badbit).
12031 <h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
12032 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12033 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
12034 <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>
12035 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12036 <p><b>Discussion:</b></p>
12037 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
12038 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
12039 That's incorrect since the names are members of a dependent base
12040 class (14.6.2 [temp.dep]) and thus not visible.</p>
12043 <p><b>Proposed resolution:</b></p>
12044 <p>Qualify the names with the name of the class of which they are
12045 members, i.e., ios_base.</p>
12051 <h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
12052 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12053 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
12054 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
12055 <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>
12056 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12057 <p><b>Discussion:</b></p>
12059 I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
12060 any type. But the synopsis in 20.4.1 calls for allocator<>::address() to
12061 be overloaded on reference and const_reference, which is ill-formed for
12062 all T = const U. In other words, this won't work:
12066 template class std::allocator<const int>;
12070 The obvious solution is to disallow specializations of allocators on
12071 const types. However, while containers' elements are required to be
12072 assignable (which rules out specializations on const T's), I think that
12073 allocators might perhaps be potentially useful for const values in other
12074 contexts. So if allocators are to allow const types a partial
12075 specialization of std::allocator<const T> would probably have to be
12080 <p><b>Proposed resolution:</b></p>
12081 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
12089 any non-const, non-reference type
12092 <p><i>[Redmond: previous proposed resolution was "any non-const,
12093 non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p>
12098 <p><b>Rationale:</b></p>
12100 Two resolutions were originally proposed: one that partially
12101 specialized std::allocator for const types, and one that said an
12102 allocator's value type may not be const. The LWG chose the second.
12103 The first wouldn't be appropriate, because allocators are intended for
12104 use by containers, and const value types don't work in containers.
12105 Encouraging the use of allocators with const value types would only
12106 lead to unsafe code.
12109 The original text for proposed resolution 2 was modified so that it
12110 also forbids volatile types and reference types.
12113 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
12114 excluded from the PR.]</i></p>
12123 <h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
12124 <p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12125 <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-02</p>
12126 <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>
12127 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12128 <p><b>Discussion:</b></p>
12130 In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
12131 There are eight overloads, all of which are identical except for the
12132 last parameter. The overloads are:
12135 <li> long& </li>
12136 <li> unsigned short& </li>
12137 <li> unsigned int& </li>
12138 <li> unsigned long& </li>
12139 <li> short& </li>
12140 <li> double& </li>
12141 <li> long double& </li>
12142 <li> void*& </li>
12146 There is a similar list, in 22.2.2.1.2, of overloads for
12147 num_get<>::do_get(). In this list, the last parameter has
12151 <li> long& </li>
12152 <li> unsigned short& </li>
12153 <li> unsigned int& </li>
12154 <li> unsigned long& </li>
12155 <li> float& </li>
12156 <li> double& </li>
12157 <li> long double& </li>
12158 <li> void*& </li>
12162 These two lists are not identical. They should be, since
12163 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
12164 the arguments it was given.
12168 <p><b>Proposed resolution:</b></p>
12169 <p>In 22.2.2.1.1 [facet.num.get.members], change</p>
12170 <pre> iter_type get(iter_type in, iter_type end, ios_base& str,
12171 ios_base::iostate& err, short& val) const;
12174 <pre> iter_type get(iter_type in, iter_type end, ios_base& str,
12175 ios_base::iostate& err, float& val) const;
12182 <h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
12183 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12184 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</p>
12185 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
12186 <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>
12187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12188 <p><b>Discussion:</b></p>
12190 23.1/3 states that the objects stored in a container must be
12191 Assignable. 23.3.1 [map], paragraph 2,
12192 states that map satisfies all requirements for a container, while in
12193 the same time defining value_type as pair<const Key, T> - a type
12194 that is not Assignable.
12198 It should be noted that there exists a valid and non-contradictory
12199 interpretation of the current text. The wording in 23.1/3 avoids
12200 mentioning value_type, referring instead to "objects stored in a
12201 container." One might argue that map does not store objects of
12202 type map::value_type, but of map::mapped_type instead, and that the
12203 Assignable requirement applies to map::mapped_type, not
12208 However, this makes map a special case (other containers store objects of
12209 type value_type) and the Assignable requirement is needlessly restrictive in
12214 For example, the proposed resolution of active library issue
12215 <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
12216 means that no set operations can exploit the fact that the stored
12217 objects are Assignable.
12221 This is related to, but slightly broader than, closed issue
12222 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
12226 <p><b>Proposed resolution:</b></p>
12227 <p>23.1/3: Strike the trailing part of the sentence:</p>
12229 , and the additional requirements of Assignable types from 23.1/3
12231 <p>so that it reads:</p>
12233 -3- The type of objects stored in these components must meet the
12234 requirements of CopyConstructible types (lib.copyconstructible).
12237 <p>23.1/4: Modify to make clear that this requirement is not for all
12238 containers. Change to:</p>
12241 -4- Table 64 defines the Assignable requirement. Some containers
12242 require this property of the types to be stored in the container. T is
12243 the type used to instantiate the container. t is a value of T, and u is
12244 a value of (possibly const) T.
12247 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
12248 CopyConstructible".</p>
12250 <p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p>
12253 -2- A deque satisfies all of the requirements of a container and of a
12254 reversible container (given in tables in lib.container.requirements) and
12255 of a sequence, including the optional sequence requirements
12256 (lib.sequence.reqmts). In addition to the requirements on the stored
12257 object described in 23.1[lib.container.requirements], the stored object
12258 must also meet the requirements of Assignable. Descriptions are
12259 provided here only for operations on deque that are not described in one
12260 of these tables or for operations where there is additional semantic
12264 <p>23.2.2/2: Add Assignable requirement to specific methods of list.
12268 <p>-2- A list satisfies all of the requirements of a container and of a
12269 reversible container (given in two tables in lib.container.requirements)
12270 and of a sequence, including most of the the optional sequence
12271 requirements (lib.sequence.reqmts). The exceptions are the operator[]
12272 and at member functions, which are not provided.
12274 [Footnote: These member functions are only provided by containers whose
12275 iterators are random access iterators. --- end foonote]
12278 <p>list does not require the stored type T to be Assignable unless the
12279 following methods are instantiated:
12281 [Footnote: Implementors are permitted but not required to take advantage
12282 of T's Assignable properties for these methods. -- end foonote]
12284 <pre> list<T,Allocator>& operator=(const list<T,Allocator>& x );
12285 template <class InputIterator>
12286 void assign(InputIterator first, InputIterator last);
12287 void assign(size_type n, const T& t);
12291 <p>Descriptions are provided here only for operations on list that are not
12292 described in one of these tables or for operations where there is
12293 additional semantic information.</p>
12296 <p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p>
12299 -2- A vector satisfies all of the requirements of a container and of a
12300 reversible container (given in two tables in lib.container.requirements)
12301 and of a sequence, including most of the optional sequence requirements
12302 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
12303 member functions, which are not provided. In addition to the
12304 requirements on the stored object described in
12305 23.1[lib.container.requirements], the stored object must also meet the
12306 requirements of Assignable. Descriptions are provided here only for
12307 operations on vector that are not described in one of these tables or
12308 for operations where there is additional semantic information.
12312 <p><b>Rationale:</b></p>
12313 <p>list, set, multiset, map, multimap are able to store non-Assignables.
12314 However, there is some concern about <tt>list<T></tt>:
12315 although in general there's no reason for T to be Assignable, some
12316 implementations of the member functions <tt>operator=</tt> and
12317 <tt>assign</tt> do rely on that requirement. The LWG does not want
12318 to forbid such implementations.</p>
12320 <p>Note that the type stored in a standard container must still satisfy
12321 the requirements of the container's allocator; this rules out, for
12322 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>
12326 <p>In principle we could also relax the "Assignable" requirement for
12327 individual <tt>vector</tt> member functions, such as
12328 <tt>push_back</tt>. However, the LWG did not see great value in such
12329 selective relaxation. Doing so would remove implementors' freedom to
12330 implement <tt>vector::push_back</tt> in terms of
12331 <tt>vector::insert</tt>.</p>
12338 <h3><a name="278"></a>278. What does iterator validity mean?</h3>
12339 <p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12340 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p>
12341 <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>
12342 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12343 <p><b>Discussion:</b></p>
12345 Section 23.2.4.4 [list.ops] states that
12347 <pre> void splice(iterator position, list<T, Allocator>& x);
12350 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
12354 But what does the C++ Standard mean by "invalidate"? You
12355 can still dereference the iterator to a spliced list element, but
12356 you'd better not use it to delimit a range within the original
12357 list. For the latter operation, it has definitely lost some of its
12362 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>,
12363 then we'd better clarify that a "valid" iterator need no
12364 longer designate an element within the same container as it once did.
12365 We then have to clarify what we mean by invalidating a past-the-end
12366 iterator, as when a vector or string grows by reallocation. Clearly,
12367 such an iterator has a different kind of validity. Perhaps we should
12368 introduce separate terms for the two kinds of "validity."
12372 <p><b>Proposed resolution:</b></p>
12373 <p>Add the following text to the end of section 24.1 [iterator.requirements],
12374 after paragraph 5:</p>
12376 An <i>invalid</i> iterator is an iterator that may be
12377 singular. [Footnote: This definition applies to pointers, since
12378 pointers are iterators. The effect of dereferencing an iterator that
12379 has been invalidated is undefined.]
12382 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
12385 <p><i>[Redmond: General agreement with the intent, some objections to
12386 the wording. Dave provided new wording.]</i></p>
12390 <p><b>Rationale:</b></p>
12391 <p>This resolution simply defines a term that the Standard uses but
12392 never defines, "invalid", in terms of a term that is defined,
12395 <p>Why do we say "may be singular", instead of "is singular"? That's
12396 becuase a valid iterator is one that is known to be nonsingular.
12397 Invalidating an iterator means changing it in such a way that it's
12398 no longer known to be nonsingular. An example: inserting an
12399 element into the middle of a vector is correctly said to invalidate
12400 all iterators pointing into the vector. That doesn't necessarily
12401 mean they all become singular.</p>
12408 <h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
12409 <p><b>Section:</b> 24.4.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12410 <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
12411 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12412 <p><b>Discussion:</b></p>
12414 This came from an email from Steve Cleary to Fergus in reference to
12415 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
12416 this in Toronto and believed it should be a separate issue. There was
12417 also some reservations about whether this was a worthwhile problem to
12422 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
12423 (and should) be changed to preserve these additional
12424 requirements." He also said in email that it can be done without
12425 breaking user's code: "If you take a look at my suggested
12426 solution, reverse_iterator doesn't have to take two parameters; there
12427 is no danger of breaking existing code, except someone taking the
12428 address of one of the reverse_iterator global operator functions, and
12429 I have to doubt if anyone has ever done that. . . <i>But</i>, just in
12430 case they have, you can leave the old global functions in as well --
12431 they won't interfere with the two-template-argument functions. With
12432 that, I don't see how <i>any</i> user code could break."
12436 <p><b>Proposed resolution:</b></p>
12438 <b>Section:</b> 24.4.1.1 [reverse.iterator]
12439 add/change the following declarations:</p>
12440 <pre> A) Add a templated assignment operator, after the same manner
12441 as the templated copy constructor, i.e.:
12443 template < class U >
12444 reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
12446 B) Make all global functions (except the operator+) have
12447 two template parameters instead of one, that is, for
12448 operator ==, !=, <, >, <=, >=, - replace:
12450 template < class Iterator >
12451 typename reverse_iterator< Iterator >::difference_type operator-(
12452 const reverse_iterator< Iterator >& x,
12453 const reverse_iterator< Iterator >& y);
12457 template < class Iterator1, class Iterator2 >
12458 typename reverse_iterator < Iterator1 >::difference_type operator-(
12459 const reverse_iterator < Iterator1 > & x,
12460 const reverse_iterator < Iterator2 > & y);
12463 Also make the addition/changes for these signatures in
12464 24.4.1.3 [reverse.iter.ops].
12468 Copenhagen: The LWG is concerned that the proposed resolution
12469 introduces new overloads. Experience shows that introducing
12470 overloads is always risky, and that it would be inappropriate to
12471 make this change without implementation experience. It may be
12472 desirable to provide this feature in a different way.
12477 Lillehammer: We now have implementation experience, and agree that
12478 this solution is safe and correct.
12488 <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
12489 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12490 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
12491 <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>
12492 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12493 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
12494 <p><b>Discussion:</b></p>
12495 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
12496 requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
12497 and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]).
12498 Since the functions take and return their arguments and result by
12499 const reference, I believe the <tt>CopyConstructible</tt> requirement
12504 <p><b>Proposed resolution:</b></p>
12505 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
12506 25.3.7, p1 with</p>
12507 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
12508 ( [lessthancomparable]).
12510 <p>and replace 25.3.7, p4 with</p>
12511 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
12512 ( [lessthancomparable]).
12519 <h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
12520 <p><b>Section:</b> 22.2.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>
12521 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</p>
12522 <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>
12523 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12524 <p><b>Discussion:</b></p>
12526 Paragraph 16 mistakenly singles out integral types for inserting
12527 thousands_sep() characters. This conflicts with the syntax for floating
12528 point numbers described under 22.2.3.1/2.
12532 <p><b>Proposed resolution:</b></p>
12533 <p>Change paragraph 16 from:</p>
12536 For integral types, punct.thousands_sep() characters are inserted into
12537 the sequence as determined by the value returned by punct.do_grouping()
12538 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12544 For arithmetic types, punct.thousands_sep() characters are inserted into
12545 the sequence as determined by the value returned by punct.do_grouping()
12546 using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
12550 Copenhagen: Opinions were divided about whether this is actually an
12551 inconsistency, but at best it seems to have been unintentional. This
12552 is only an issue for floating-point output: The standard is
12553 unambiguous that implementations must parse thousands_sep characters
12554 when performing floating-point. The standard is also unambiguous that
12555 this requirement does not apply to the "C" locale.
12560 A survey of existing practice is needed; it is believed that some
12561 implementations do insert thousands_sep characters for floating-point
12562 output and others fail to insert thousands_sep characters for
12563 floating-point input even though this is unambiguously required by the
12568 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
12569 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
12577 <h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
12578 <p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12579 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-15</p>
12580 <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>
12581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12582 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
12583 <p><b>Discussion:</b></p>
12585 (revision of the further discussion)
12586 There are a number of problems with the requires clauses for the
12587 algorithms in 25.1 and 25.2. The requires clause of each algorithm
12588 should describe the necessary and sufficient requirements on the inputs
12589 to the algorithm such that the algorithm compiles and runs properly.
12590 Many of the requires clauses fail to do this. Here is a summary of the kinds
12596 Use of EqualityComparable, which only puts requirements on a single
12597 type, when in fact an equality operator is required between two
12598 different types, typically either T and the iterator's value type
12599 or between the value types of two different iterators.
12602 Use of Assignable for T when in fact what was needed is Assignable
12603 for the value_type of the iterator, and convertability from T to the
12604 value_type of the iterator. Or for output iterators, the requirement
12605 should be that T is writable to the iterator (output iterators do
12606 not have value types).
12611 Here is the list of algorithms that contain mistakes:
12615 <li>25.1.2 std::find</li>
12616 <li>25.1.6 std::count</li>
12617 <li>25.1.8 std::equal</li>
12618 <li>25.1.9 std::search, std::search_n</li>
12619 <li>25.2.4 std::replace, std::replace_copy</li>
12620 <li>25.2.5 std::fill</li>
12621 <li>25.2.7 std::remove, std::remove_copy</li>
12625 Also, in the requirements for EqualityComparable, the requirement that
12626 the operator be defined for const objects is lacking.
12631 <p><b>Proposed resolution:</b></p>
12633 <p>20.1.1 Change p1 from</p>
12635 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12636 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12637 values of type <tt>T</tt>.
12643 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
12644 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
12645 values of type <tt>const T</tt>.
12648 <p>25 Between p8 and p9</p>
12650 <p>Add the following sentence:</p>
12652 <p>When the description of an algorithm gives an expression such as
12653 <tt>*first == value</tt> for a condition, it is required that the expression
12654 evaluate to either true or false in boolean contexts.</p>
12656 <p>25.1.2 Change p1 by deleting the requires clause.</p>
12658 <p>25.1.6 Change p1 by deleting the requires clause.</p>
12662 <p>Change p4 from</p>
12664 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
12665 (20.1.1), type Size is convertible to integral type (4.7.12.3).
12670 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
12671 type (4.7.12.3).</p>
12673 <p>25.2.4 Change p1 from</p>
12675 <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>
12679 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
12681 <p>and change p4 from</p>
12683 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
12684 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
12685 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
12686 (last - first))</tt> shall not overlap.</p>
12690 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
12691 <tt>new_value</tt> must be writable to the result output iterator. The
12692 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
12693 first))</tt> shall not overlap.</p>
12696 <p>25.2.5 Change p1 from</p>
12698 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
12699 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
12703 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
12704 the output iterator. The type <tt>Size</tt> is convertible to an
12705 integral type (4.7.12.3).</p>
12707 <p>25.2.7 Change p1 from</p>
12709 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
12714 -1- Requires: The value type of the iterator must be
12715 <tt>Assignable</tt> (23.1).
12720 <p><b>Rationale:</b></p>
12722 The general idea of the proposed solution is to remove the faulty
12723 requires clauses and let the returns and effects clauses speak for
12724 themselves. That is, the returns clauses contain expressions that must
12725 be valid, and therefore already imply the correct requirements. In
12726 addition, a sentence is added at the beginning of chapter 25 saying
12727 that expressions given as conditions must evaluate to true or false in
12728 a boolean context. An alternative would be to say that the type of
12729 these condition expressions must be literally bool, but that would be
12730 imposing a greater restriction that what the standard currently says
12731 (which is convertible to bool).
12739 <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
12740 <p><b>Section:</b> 20.6.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12741 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
12742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12743 <p><b>Discussion:</b></p>
12744 <p>The example in 20.6.7 [comparisons], p6 shows how to use the C
12745 library function <tt>strcmp()</tt> with the function pointer adapter
12746 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
12747 functions have <tt>extern "C"</tt> or <tt>extern
12748 "C++"</tt> linkage [17.4.2.2 [using.linkage]], and since
12749 function pointers with different the language linkage specifications
12750 (7.5 [dcl.link]) are incompatible, whether this example is
12751 well-formed is unspecified.
12755 <p><b>Proposed resolution:</b></p>
12756 <p>Change 20.6.7 [comparisons] paragraph 6 from:</p>
12758 <p>[<i>Example:</i></p>
12759 <pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
12761 <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
12767 <p>[<i>Example:</i></p>
12768 <pre> int compare(const char*, const char*);
12769 replace_if(v.begin(), v.end(),
12770 not1(bind2nd(ptr_fun(compare), "abc")), "def");
12772 <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
12775 <p>Also, remove footnote 215 in that same paragraph.</p>
12777 <p><i>[Copenhagen: Minor change in the proposed resolution. Since this
12778 issue deals in part with C and C++ linkage, it was believed to be too
12779 confusing for the strings in the example to be "C" and "C++".
12783 <p><i>[Redmond: More minor changes. Got rid of the footnote (which
12784 seems to make a sweeping normative requirement, even though footnotes
12785 aren't normative), and changed the sentence after the footnote so that
12786 it corresponds to the new code fragment.]</i></p>
12794 <h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
12795 <p><b>Section:</b> 27.8.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12796 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-31</p>
12797 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12798 <p><b>Discussion:</b></p>
12799 <p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
12800 27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
12803 <p>... If that function returns a null pointer, calls
12804 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
12807 <p>The parenthetical note doesn't apply since the ctors cannot throw an
12808 exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3
12809 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
12813 <p><b>Proposed resolution:</b></p>
12815 Strike the parenthetical note from the Effects clause in each of the
12816 paragraphs mentioned above.
12823 <h3><a name="286"></a>286. <cstdlib> requirements missing size_t typedef</h3>
12824 <p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12825 <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12826 <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>
12827 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12828 <p><b>Discussion:</b></p>
12830 The <cstdlib> header file contains prototypes for bsearch and
12831 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
12832 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
12833 require the typedef size_t. Yet size_t is not listed in the
12834 <cstdlib> synopsis table 78 in section 25.4.
12838 <p><b>Proposed resolution:</b></p>
12840 Add the type size_t to Table 78 (section 25.4) and add
12841 the type size_t <cstdlib> to Table 97 (section C.2).
12845 <p><b>Rationale:</b></p>
12846 <p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p>
12853 <h3><a name="288"></a>288. <cerrno> requirements missing macro EILSEQ</h3>
12854 <p><b>Section:</b> 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12855 <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
12856 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12857 <p><b>Discussion:</b></p>
12859 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
12860 of macros defined in <errno.h> is adjusted to include a new
12865 ISO/IEC 14882:1998(E) section 19.3 does not refer
12866 to the above amendment.
12871 <p><b>Proposed resolution:</b></p>
12873 Update Table 26 (section 19.3) "Header <cerrno> synopsis"
12874 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
12882 <h3><a name="291"></a>291. Underspecification of set algorithms</h3>
12883 <p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
12884 <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-01-03</p>
12885 <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>
12886 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
12887 <p><b>Discussion:</b></p>
12889 The standard library contains four algorithms that compute set
12890 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
12891 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>. Each
12892 of these algorithms takes two sorted ranges as inputs, and writes the
12893 output of the appropriate set operation to an output range. The elements
12894 in the output range are sorted.
12898 The ordinary mathematical definitions are generalized so that they
12899 apply to ranges containing multiple copies of a given element. Two
12900 elements are considered to be "the same" if, according to an
12901 ordering relation provided by the user, neither one is less than the
12902 other. So, for example, if one input range contains five copies of an
12903 element and another contains three, the output range of <tt>set_union</tt>
12904 will contain five copies, the output range of
12905 <tt>set_intersection</tt> will contain three, the output range of
12906 <tt>set_difference</tt> will contain two, and the output range of
12907 <tt>set_symmetric_difference</tt> will contain two.
12911 Because two elements can be "the same" for the purposes
12912 of these set algorithms, without being identical in other respects
12913 (consider, for example, strings under case-insensitive comparison),
12914 this raises a number of unanswered questions:
12918 <li>If we're copying an element that's present in both of the
12919 input ranges, which one do we copy it from?</li>
12920 <li>If there are <i>n</i> copies of an element in the relevant
12921 input range, and the output range will contain fewer copies (say
12922 <i>m</i>) which ones do we choose? The first <i>m</i>, or the last
12923 <i>m</i>, or something else?</li>
12924 <li>Are these operations stable? That is, does a run of equivalent
12925 elements appear in the output range in the same order as as it
12926 appeared in the input range(s)?</li>
12930 The standard should either answer these questions, or explicitly
12931 say that the answers are unspecified. I prefer the former option,
12932 since, as far as I know, all existing implementations behave the
12938 <p><b>Proposed resolution:</b></p>
12940 <p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p>
12942 If [first1, last1) contains <i>m</i> elements that are equivalent to
12943 each other and [first2, last2) contains <i>n</i> elements that are
12944 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
12945 will be copied to the output range: all <i>m</i> of these elements
12946 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
12947 [first2, last2), in that order.
12950 <p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p>
12952 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12953 other and [first2, last2) contains <i>n</i> elements that are
12954 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
12955 elements from [first1, last1) are copied to the output range.
12958 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference]
12961 If [first1, last1) contains <i>m</i> elements that are equivalent to each
12962 other and [first2, last2) contains <i>n</i> elements that are
12963 equivalent to them, the last max(<i>m-n</i>, 0) elements from
12964 [first1, last1) are copied to the output range.
12967 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference]
12970 If [first1, last1) contains <i>m</i> elements that are equivalent to
12971 each other and [first2, last2) contains <i>n</i> elements that are
12972 equivalent to them, then |<i>m - n</i>| of those elements will be
12973 copied to the output range: the last <i>m - n</i> of these elements
12974 from [first1, last1) if <i>m</i> > <i>n</i>, and the last <i>n -
12975 m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>.
12978 <p><i>[Santa Cruz: it's believed that this language is clearer than
12979 what's in the Standard. However, it's also believed that the
12980 Standard may already make these guarantees (although not quite in
12981 these words). Bill and Howard will check and see whether they think
12982 that some or all of these changes may be redundant. If so, we may
12983 close this issue as NAD.]</i></p>
12988 <p><b>Rationale:</b></p>
12989 <p>For simple cases, these descriptions are equivalent to what's
12990 already in the Standard. For more complicated cases, they describe
12991 the behavior of existing implementations.</p>
12998 <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
12999 <p><b>Section:</b> 27.4.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>
13000 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p>
13001 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
13002 <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>
13003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13004 <p><b>Discussion:</b></p>
13005 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
13006 27.4.4.2, p15 doesn't consider the case where the left-hand side
13007 argument is identical to the argument on the right-hand side, that is
13008 <tt>(this == &rhs)</tt>. If the two arguments are identical there
13009 is no need to copy any of the data members or call any callbacks
13010 registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
13011 points out in message c++std-lib-8149 it appears to be incorrect to
13012 allow the object to fire <tt>erase_event</tt> followed by
13013 <tt>copyfmt_event</tt> since the callback handling the latter event
13014 may inadvertently attempt to access memory freed by the former.
13018 <p><b>Proposed resolution:</b></p>
13019 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
13022 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
13023 the corresponding member objects of <tt>rhs</tt>, except that...
13029 <b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise
13030 assigns to the member objects of <tt>*this</tt> the corresponding member
13031 objects of <tt>rhs</tt>, except that...
13038 <h3><a name="294"></a>294. User defined macros and standard headers</h3>
13039 <p><b>Section:</b> 17.4.3.2.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13040 <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p>
13041 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13042 <p><b>Discussion:</b></p>
13043 <p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
13044 translation unit that includes a header shall not contain any macros
13045 that define names declared in that header." As I read this, it
13046 would mean that the following program is legal:</p>
13048 <pre> #define npos 3.14
13049 #include <sstream>
13052 <p>since npos is not defined in <sstream>. It is, however, defined
13053 in <string>, and it is hard to imagine an implementation in
13054 which <sstream> didn't include <string>.</p>
13056 <p>I think that this phrase was probably formulated before it was
13057 decided that a standard header may freely include other standard
13058 headers. The phrase would be perfectly appropriate for C, for
13059 example. In light of 17.4.4.1 [res.on.headers] paragraph 1, however,
13060 it isn't stringent enough.</p>
13063 <p><b>Proposed resolution:</b></p>
13064 <p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p>
13066 <p>Each name defined as a macro in a header is reserved to the
13067 implementation for any use if the translation unit includes
13068 the header.168)</p>
13070 <p>A translation unit that includes a header shall not contain any
13071 macros that define names declared or defined in that header. Nor shall
13072 such a translation unit define macros for names lexically
13073 identical to keywords.</p>
13075 <p>168) It is not permissible to remove a library macro definition by
13076 using the #undef directive.</p>
13079 <p>with the wording:</p>
13082 <p>A translation unit that includes a standard library header shall not
13083 #define or #undef names declared in any standard library header.</p>
13085 <p>A translation unit shall not #define or #undef names lexically
13086 identical to keywords.</p>
13089 <p><i>[Lillehammer: Beman provided new wording]</i></p>
13097 <h3><a name="295"></a>295. Is abs defined in <cmath>?</h3>
13098 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13099 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
13100 <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>
13101 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13102 <p><b>Discussion:</b></p>
13104 Table 80 lists the contents of the <cmath> header. It does not
13105 list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
13106 signatures present in <cmath>, does say that several overloads
13107 of <tt>abs()</tt> should be defined in <cmath>.
13111 <p><b>Proposed resolution:</b></p>
13113 Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
13114 of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
13118 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
13119 rid of that vestigial list of functions in paragraph 1.]</i></p>
13124 <p><b>Rationale:</b></p>
13125 <p>All this DR does is fix a typo; it's uncontroversial. A
13126 separate question is whether we're doing the right thing in
13127 putting some overloads in <cmath> that we aren't also
13128 putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
13135 <h3><a name="297"></a>297. const_mem_fun_t<>::argument_type should be const T*</h3>
13136 <p><b>Section:</b> 20.6.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13137 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
13138 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13139 <p><b>Discussion:</b></p>
13140 <p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
13141 <tt>const_mem_fun1_t</tt>
13142 in 20.5.8, p9 derive from <tt>unary_function<T*, S></tt>, and
13143 <tt>binary_function<T*,
13144 A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and
13145 <tt>first_argument_type</tt>
13146 members, respectively, are both defined to be <tt>T*</tt> (non-const).
13147 However, their function call member operator takes a <tt>const T*</tt>
13148 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
13149 T*</tt> instead, so that one can easily refer to it in generic code. The
13150 example below derived from existing code fails to compile due to the
13154 <p><tt>template <class T></tt>
13155 <br><tt>void foo (typename T::argument_type arg) // #1</tt>
13157 <br><tt> typename T::result_type (T::*pf) (typename
13159 const = // #2</tt>
13160 <br><tt> &T::operator();</tt>
13164 <p><tt>struct X { /* ... */ };</tt></p>
13166 <p><tt>int main ()</tt>
13168 <br><tt> const X x;</tt>
13169 <br><tt> foo<std::const_mem_fun_t<void, X>
13170 >(&x);
13175 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
13176 <br>#2 the type of the pointer is incompatible with the type of the member
13178 <br>#3 the address of a constant being passed to a function taking a non-const
13183 <p><b>Proposed resolution:</b></p>
13184 <p>Replace the top portion of the definition of the class template
13185 const_mem_fun_t in 20.5.8, p8
13187 <p><tt>template <class S, class T> class const_mem_fun_t</tt>
13188 <br><tt> : public
13189 unary_function<T*, S> {</tt>
13192 <p><tt>template <class S, class T> class const_mem_fun_t</tt>
13193 <br><tt> : public
13194 unary_function<<b>const</b> T*, S> {</tt>
13196 <p>Also replace the top portion of the definition of the class template
13197 const_mem_fun1_t in 20.5.8, p9</p>
13198 <p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
13199 <br><tt> : public
13200 binary_function<T*, A, S> {</tt>
13203 <p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
13204 <br><tt> : public
13205 binary_function<<b>const</b> T*, A, S> {</tt>
13209 <p><b>Rationale:</b></p>
13210 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
13211 and the argument type itself, are not the same.</p>
13218 <h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
13219 <p><b>Section:</b> 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13220 <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p>
13221 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13222 <p><b>Discussion:</b></p>
13224 The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
13225 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
13226 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
13227 correct in all cases. Since the specified <tt>operator new[]</tt> default
13228 behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
13229 replaced, along with <tt>operator delete</tt>, by the user, to implement their
13230 own memory management, the specified default behavior of<tt> operator
13231 delete[]</tt> must be to call <tt>operator delete</tt>.
13235 <p><b>Proposed resolution:</b></p>
13236 <p>Change 18.5.1.2, p12 from</p>
13238 <b>-12-</b> <b>Default behavior:</b></p>
13241 For a null value of <i><tt>ptr</tt></i> , does nothing.
13244 Any other value of <i><tt>ptr</tt></i> shall be a value returned
13245 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
13246 [Footnote: The value must not have been invalidated by an intervening
13247 call to <tt>operator delete[](void*)</tt> (17.4.3.8 [res.on.arguments]).
13249 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
13250 allocated by the earlier call to the default <tt>operator new[]</tt>.
13258 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
13259 delete(</tt><i>ptr</i>)
13260 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
13262 <p>and expunge paragraph 13.</p>
13268 <h3><a name="300"></a>300. list::merge() specification incomplete</h3>
13269 <p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13270 <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p>
13271 <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>
13272 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13273 <p><b>Discussion:</b></p>
13275 The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
13276 appears to be incomplete: it doesn't cover the case where the argument
13277 list is identical to *this (i.e., this == &x). The requirement in the
13278 note in p24 (below) is that x be empty after the merge which is surely
13279 unintended in this case.
13283 <p><b>Proposed resolution:</b></p>
13284 <p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p>
13287 23 Effects: if (&x == this) does nothing; otherwise, merges the two
13288 sorted ranges [begin(), end()) and [x.begin(), x.end()). The result
13289 is a range in which the elements will be sorted in non-decreasing
13290 order according to the ordering defined by comp; that is, for every
13291 iterator i in the range other than the first, the condition comp(*i,
13292 *(i - 1)) will be false.
13296 24 Notes: Stable: if (&x != this), then for equivalent elements in the
13297 two original ranges, the elements from the original range [begin(),
13298 end()) always precede the elements from the original range [x.begin(),
13299 x.end()). If (&x != this) the range [x.begin(), x.end()) is empty
13304 25 Complexity: At most size() + x.size() - 1 applications of comp if
13305 (&x ! = this); otherwise, no applications of comp are performed. If
13306 an exception is thrown other than by a comparison there are no
13312 <p><i>[Copenhagen: The original proposed resolution did not fix all of
13313 the problems in 23.2.4.4 [list.ops], p22-25. Three different
13314 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
13315 Changing p23, without changing the other two, appears to introduce
13316 contradictions. Additionally, "merges the argument list into the
13317 list" is excessively vague.]</i></p>
13320 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
13329 <h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
13330 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13331 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</p>
13332 <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>
13333 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13334 <p><b>Discussion:</b></p>
13336 The effects clause for the basic_string template ctor in 21.3.1, p15
13337 leaves out the third argument of type Allocator. I believe this to be
13342 <p><b>Proposed resolution:</b></p>
13346 <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13347 type, equivalent to</p>
13349 <blockquote><p><tt>basic_string(static_cast<size_type>(begin),
13350 static_cast<value_type>(end))</tt></p></blockquote>
13356 <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
13357 type, equivalent to</p>
13359 <blockquote><p><tt>basic_string(static_cast<size_type>(begin),
13360 static_cast<value_type>(end), <b>a</b>)</tt></p></blockquote>
13367 <h3><a name="303"></a>303. Bitset input operator underspecified</h3>
13368 <p><b>Section:</b> 23.3.5.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13369 <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-02-05</p>
13370 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13371 <p><b>Discussion:</b></p>
13373 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
13374 "Extracts up to <i>N</i> (single-byte) characters from
13375 <i>is</i>.", where <i>is</i> is a stream of type
13376 <tt>basic_istream<charT, traits></tt>.
13380 The standard does not say what it means to extract single byte
13381 characters from a stream whose character type, <tt>charT</tt>, is in
13382 general not a single-byte character type. Existing implementations
13387 A reasonable solution will probably involve <tt>widen()</tt> and/or
13388 <tt>narrow()</tt>, since they are the supplied mechanism for
13389 converting a single character between <tt>char</tt> and
13390 arbitrary <tt>charT</tt>.
13393 <p>Narrowing the input characters is not the same as widening the
13394 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
13395 locales in which more than one wide character maps to the narrow
13396 character <tt>'0'</tt>. Narrowing means that alternate
13397 representations may be used for bitset input, widening means that
13398 they may not be.</p>
13400 <p>Note that for numeric input, <tt>num_get<></tt>
13401 (22.2.2.1.2/8) compares input characters to widened version of narrow
13402 character literals.</p>
13404 <p>From Pete Becker, in c++std-lib-8224:</p>
13407 Different writing systems can have different representations for the
13408 digits that represent 0 and 1. For example, in the Unicode representation
13409 of the Devanagari script (used in many of the Indic languages) the digit 0
13410 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
13411 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
13412 0x0031 for for the Latin representations of '0' and '1', as well as code
13413 points for the same numeric values in several other scripts (Tamil has no
13414 character for 0, but does have the digits 1-9), and any of these values
13415 would also be narrowed to '0' and '1'.
13421 It's fairly common to intermix both native and Latin
13422 representations of numbers in a document. So I think the rule has to be
13423 that if a wide character represents a digit whose value is 0 then the bit
13424 should be cleared; if it represents a digit whose value is 1 then the bit
13425 should be set; otherwise throw an exception. So in a Devanagari locale,
13426 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
13427 would set it. Widen can't do that. It would pick one of those two values,
13428 and exclude the other one.
13433 <p>From Jens Maurer, in c++std-lib-8233:</p>
13437 Whatever we decide, I would find it most surprising if
13438 bitset conversion worked differently from int conversion
13439 with regard to alternate local representations of
13443 <p>Thus, I think the options are:</p>
13445 <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
13446 require the use of narrow().</li>
13448 <li> Have a defect issue for bitset() which describes clearly
13449 that widen() is to be used.</li>
13455 <p><b>Proposed resolution:</b></p>
13457 <p>Replace the first two sentences of paragraph 5 with:</p>
13460 Extracts up to <i>N</i> characters from <i>is</i>. Stores these
13461 characters in a temporary object <i>str</i> of type
13462 <tt>basic_string<charT, traits></tt>, then evaluates the
13463 expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>.
13466 <p>Replace the third bullet item in paragraph 5 with:</p>
13468 the next input character is neither <tt><i>is</i>.widen(0)</tt>
13469 nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
13475 <p><b>Rationale:</b></p>
13476 <p>Input for <tt>bitset</tt> should work the same way as numeric
13477 input. Using <tt>widen</tt> does mean that alternative digit
13478 representations will not be recognized, but this was a known
13479 consequence of the design choice.</p>
13486 <h3><a name="305"></a>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</h3>
13487 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13488 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-01-24</p>
13489 <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>
13490 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13491 <p><b>Discussion:</b></p>
13492 <p>22.2.1.5/3 introduces codecvt in part with:</p>
13495 codecvt<wchar_t,char,mbstate_t> converts between the native
13496 character sets for tiny and wide characters. Instantiations on
13497 mbstate_t perform conversion between encodings known to the library
13501 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
13504 ... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and
13509 The semantics of do_in and do_length are linked. What one does must
13510 be consistent with what the other does. 22.2.1.5/3 leads me to
13511 believe that the vendor is allowed to choose the algorithm that
13512 codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes
13513 his customers happy on a given platform. But 22.2.1.5.2/10 explicitly
13514 says what codecvt<wchar_t,char,mbstate_t>::do_length must
13515 return. And thus indirectly specifies the algorithm that
13516 codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe
13517 that this is not what was intended and is a defect.
13520 <p>Discussion from the -lib reflector:
13522 <br>This proposal would have the effect of making the semantics of
13523 all of the virtual functions in <tt>codecvt<wchar_t, char,
13524 mbstate_t></tt> implementation specified. Is that what we want, or
13525 do we want to mandate specific behavior for the base class virtuals
13526 and leave the implementation specified behavior for the codecvt_byname
13527 derived class? The tradeoff is that former allows implementors to
13528 write a base class that actually does something useful, while the
13529 latter gives users a way to get known and specified---albeit
13530 useless---behavior, and is consistent with the way the standard
13531 handles other facets. It is not clear what the original intention
13535 Nathan has suggest a compromise: a character that is a widened version
13536 of the characters in the basic execution character set must be
13537 converted to a one-byte sequence, but there is no such requirement
13538 for characters that are not part of the basic execution character set.
13542 <p><b>Proposed resolution:</b></p>
13544 Change 22.2.1.5.2/5 from:
13547 The instantiations required in Table 51 (lib.locale.category), namely
13548 codecvt<wchar_t,char,mbstate_t> and
13549 codecvt<char,char,mbstate_t>, store no characters. Stores no more
13550 than (to_limit-to) destination elements. It always leaves the to_next
13551 pointer pointing one beyond the last element successfully stored.
13557 Stores no more than (to_limit-to) destination elements, and leaves the
13558 to_next pointer pointing one beyond the last element successfully
13559 stored. codecvt<char,char,mbstate_t> stores no characters.
13562 <p>Change 22.2.1.5.2/10 from:</p>
13565 -10- Returns: (from_next-from) where from_next is the largest value in
13566 the range [from,from_end] such that the sequence of values in the
13567 range [from,from_next) represents max or fewer valid complete
13568 characters of type internT. The instantiations required in Table 51
13569 (21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and
13570 codecvt<char, char, mbstate_t>, return the lesser of max and
13577 -10- Returns: (from_next-from) where from_next is the largest value in
13578 the range [from,from_end] such that the sequence of values in the range
13579 [from,from_next) represents max or fewer valid complete characters of
13580 type internT. The instantiation codecvt<char, char, mbstate_t> returns
13581 the lesser of max and (from_end-from).
13584 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
13585 above, but require that, in the default encoding, a character from the
13586 basic execution character set would map to a single external
13587 character. The straw poll was 8-1 in favor of the proposed
13588 resolution.]</i></p>
13593 <p><b>Rationale:</b></p>
13594 <p>The default encoding should be whatever users of a given platform
13595 would expect to be the most natural. This varies from platform to
13596 platform. In many cases there is a preexisting C library, and users
13597 would expect the default encoding to be whatever C uses in the default
13598 "C" locale. We could impose a guarantee like the one Nathan suggested
13599 (a character from the basic execution character set must map to a
13600 single external character), but this would rule out important
13601 encodings that are in common use: it would rule out JIS, for
13602 example, and it would rule out a fixed-width encoding of UCS-4.</p>
13604 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
13605 "shift-JIS" changed to "JIS".]</i></p>
13614 <h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
13615 <p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13616 <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p>
13617 <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>
13618 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13619 <p><b>Discussion:</b></p>
13620 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
13622 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
13623 accepts a restricted set of <i>type</i> arguments in this
13624 International Standard. <i>type</i> shall be a POD structure or a POD
13625 union (clause 9). The result of applying the offsetof macro to a field
13626 that is a static data member or a function member is
13629 <p>For the POD requirement, it doesn't say "no diagnostic
13630 required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
13631 It's not clear whether this requirement was intended. While it's
13632 possible to provide such a diagnostic, the extra complication doesn't
13633 seem to add any value.
13637 <p><b>Proposed resolution:</b></p>
13638 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
13639 structure or a POD union the results are undefined."</p>
13641 <p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
13642 agreed that requiring a diagnostic was inadvertent, but some LWG
13643 members thought that diagnostics should be required whenever
13652 <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
13653 <p><b>Section:</b> 23.2.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13654 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p>
13655 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13656 <p><b>Discussion:</b></p>
13658 <p>From reflector message c++std-lib-8330. See also lib-8317.</p>
13661 The standard is currently inconsistent in 23.2.4.2 [list.capacity]
13662 paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
13663 23.2.3.3/1, for example, says:
13667 -1- Any sequence supporting operations back(), push_back() and pop_back()
13668 can be used to instantiate stack. In particular, vector (lib.vector), list
13669 (lib.list) and deque (lib.deque) can be used.
13672 <p>But this is false: vector<bool> can not be used, because the
13673 container adaptors return a T& rather than using the underlying
13674 container's reference type.</p>
13676 <p>This is a contradiction that can be fixed by:</p>
13679 <li>Modifying these paragraphs to say that vector<bool>
13680 is an exception.</li>
13681 <li>Removing the vector<bool> specialization.</li>
13682 <li>Changing the return types of stack and priority_queue to use
13683 reference typedef's.</li>
13687 I propose 3. This does not preclude option 2 if we choose to do it
13688 later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent. Option
13689 3 offers a small step towards support for proxied containers. This
13690 small step fixes a current contradiction, is easy for vendors to
13691 implement, is already implemented in at least one popular lib, and
13692 does not break any code.
13697 <p><b>Proposed resolution:</b></p>
13698 <p>Summary: Add reference and const_reference typedefs to queue,
13699 priority_queue and stack. Change return types of "value_type&" to
13700 "reference". Change return types of "const value_type&" to
13701 "const_reference". Details:</p>
13703 <p>Change 23.2.3.1/1 from:</p>
13705 <pre> namespace std {
13706 template <class T, class Container = deque<T> >
13709 typedef typename Container::value_type value_type;
13710 typedef typename Container::size_type size_type;
13711 typedef Container container_type;
13716 explicit queue(const Container& = Container());
13718 bool empty() const { return c.empty(); }
13719 size_type size() const { return c.size(); }
13720 value_type& front() { return c.front(); }
13721 const value_type& front() const { return c.front(); }
13722 value_type& back() { return c.back(); }
13723 const value_type& back() const { return c.back(); }
13724 void push(const value_type& x) { c.push_back(x); }
13725 void pop() { c.pop_front(); }
13731 <pre> namespace std {
13732 template <class T, class Container = deque<T> >
13735 typedef typename Container::value_type value_type;
13736 typedef typename Container::reference reference;
13737 typedef typename Container::const_reference const_reference;
13738 typedef typename Container::value_type value_type;
13739 typedef typename Container::size_type size_type;
13740 typedef Container container_type;
13745 explicit queue(const Container& = Container());
13747 bool empty() const { return c.empty(); }
13748 size_type size() const { return c.size(); }
13749 reference front() { return c.front(); }
13750 const_reference front() const { return c.front(); }
13751 reference back() { return c.back(); }
13752 const_reference back() const { return c.back(); }
13753 void push(const value_type& x) { c.push_back(x); }
13754 void pop() { c.pop_front(); }
13758 <p>Change 23.2.3.2/1 from:</p>
13760 <pre> namespace std {
13761 template <class T, class Container = vector<T>,
13762 class Compare = less<typename Container::value_type> >
13763 class priority_queue {
13765 typedef typename Container::value_type value_type;
13766 typedef typename Container::size_type size_type;
13767 typedef Container container_type;
13773 explicit priority_queue(const Compare& x = Compare(),
13774 const Container& = Container());
13775 template <class InputIterator>
13776 priority_queue(InputIterator first, InputIterator last,
13777 const Compare& x = Compare(),
13778 const Container& = Container());
13780 bool empty() const { return c.empty(); }
13781 size_type size() const { return c.size(); }
13782 const value_type& top() const { return c.front(); }
13783 void push(const value_type& x);
13786 // no equality is provided
13792 <pre> namespace std {
13793 template <class T, class Container = vector<T>,
13794 class Compare = less<typename Container::value_type> >
13795 class priority_queue {
13797 typedef typename Container::value_type value_type;
13798 typedef typename Container::reference reference;
13799 typedef typename Container::const_reference const_reference;
13800 typedef typename Container::size_type size_type;
13801 typedef Container container_type;
13807 explicit priority_queue(const Compare& x = Compare(),
13808 const Container& = Container());
13809 template <class InputIterator>
13810 priority_queue(InputIterator first, InputIterator last,
13811 const Compare& x = Compare(),
13812 const Container& = Container());
13814 bool empty() const { return c.empty(); }
13815 size_type size() const { return c.size(); }
13816 const_reference top() const { return c.front(); }
13817 void push(const value_type& x);
13820 // no equality is provided
13824 <p>And change 23.2.3.3/1 from:</p>
13826 <pre> namespace std {
13827 template <class T, class Container = deque<T> >
13830 typedef typename Container::value_type value_type;
13831 typedef typename Container::size_type size_type;
13832 typedef Container container_type;
13837 explicit stack(const Container& = Container());
13839 bool empty() const { return c.empty(); }
13840 size_type size() const { return c.size(); }
13841 value_type& top() { return c.back(); }
13842 const value_type& top() const { return c.back(); }
13843 void push(const value_type& x) { c.push_back(x); }
13844 void pop() { c.pop_back(); }
13847 template <class T, class Container>
13848 bool operator==(const stack<T, Container>& x,
13849 const stack<T, Container>& y);
13850 template <class T, class Container>
13851 bool operator< (const stack<T, Container>& x,
13852 const stack<T, Container>& y);
13853 template <class T, class Container>
13854 bool operator!=(const stack<T, Container>& x,
13855 const stack<T, Container>& y);
13856 template <class T, class Container>
13857 bool operator> (const stack<T, Container>& x,
13858 const stack<T, Container>& y);
13859 template <class T, class Container>
13860 bool operator>=(const stack<T, Container>& x,
13861 const stack<T, Container>& y);
13862 template <class T, class Container>
13863 bool operator<=(const stack<T, Container>& x,
13864 const stack<T, Container>& y);
13870 <pre> namespace std {
13871 template <class T, class Container = deque<T> >
13874 typedef typename Container::value_type value_type;
13875 typedef typename Container::reference reference;
13876 typedef typename Container::const_reference const_reference;
13877 typedef typename Container::size_type size_type;
13878 typedef Container container_type;
13883 explicit stack(const Container& = Container());
13885 bool empty() const { return c.empty(); }
13886 size_type size() const { return c.size(); }
13887 reference top() { return c.back(); }
13888 const_reference top() const { return c.back(); }
13889 void push(const value_type& x) { c.push_back(x); }
13890 void pop() { c.pop_back(); }
13893 template <class T, class Container>
13894 bool operator==(const stack<T, Container>& x,
13895 const stack<T, Container>& y);
13896 template <class T, class Container>
13897 bool operator< (const stack<T, Container>& x,
13898 const stack<T, Container>& y);
13899 template <class T, class Container>
13900 bool operator!=(const stack<T, Container>& x,
13901 const stack<T, Container>& y);
13902 template <class T, class Container>
13903 bool operator> (const stack<T, Container>& x,
13904 const stack<T, Container>& y);
13905 template <class T, class Container>
13906 bool operator>=(const stack<T, Container>& x,
13907 const stack<T, Container>& y);
13908 template <class T, class Container>
13909 bool operator<=(const stack<T, Container>& x,
13910 const stack<T, Container>& y);
13914 <p><i>[Copenhagen: This change was discussed before the IS was released
13915 and it was deliberately not adopted. Nevertheless, the LWG believes
13916 (straw poll: 10-2) that it is a genuine defect.]</i></p>
13924 <h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
13925 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13926 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-15</p>
13927 <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>
13928 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13929 <p><b>Discussion:</b></p>
13931 Table 82 in section 27 mentions the header <cstdlib> for String
13932 streams (27.7 [string.streams]) and the headers <cstdio> and
13933 <cwchar> for File streams (27.8 [file.streams]). It's not clear
13934 why these headers are mentioned in this context since they do not
13935 define any of the library entities described by the
13936 subclauses. According to 17.4.1.1 [contents], only such headers
13937 are to be listed in the summary.
13941 <p><b>Proposed resolution:</b></p>
13942 <p>Remove <cstdlib> and <cwchar> from
13945 <p><i>[Copenhagen: changed the proposed resolution slightly. The
13946 original proposed resolution also said to remove <cstdio> from
13947 Table 82. However, <cstdio> is mentioned several times within
13948 section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p>
13956 <h3><a name="310"></a>310. Is errno a macro?</h3>
13957 <p><b>Section:</b> 17.4.1.2 [headers], 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
13958 <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p>
13959 <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>
13960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
13961 <p><b>Discussion:</b></p>
13963 Exactly how should errno be declared in a conforming C++ header?
13967 The C standard says in 7.1.4 that it is unspecified whether errno is a
13968 macro or an identifier with external linkage. In some implementations
13969 it can be either, depending on compile-time options. (E.g., on
13970 Solaris in multi-threading mode, errno is a macro that expands to a
13971 function call, but is an extern int otherwise. "Unspecified" allows
13975 <p>The C++ standard:</p>
13977 <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
13978 <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
13979 name (true), and implies that it is an identifier.</li>
13980 <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
13981 on to say that the contents of of C++ <errno.h> are the
13982 same as in C, begging the question.</li>
13983 <li>C.2, table 95 lists errno as a macro, without comment.</li>
13986 <p>I find no other references to errno.</p>
13988 <p>We should either explicitly say that errno must be a macro, even
13989 though it need not be a macro in C, or else explicitly leave it
13990 unspecified. We also need to say something about namespace std.
13991 A user who includes <cerrno> needs to know whether to write
13992 <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
13993 else <cerrno> is useless.</p>
13995 <p>Two acceptable fixes:</p>
13997 <li><p>errno must be a macro. This is trivially satisfied by adding<br>
13998 #define errno (::std::errno)<br>
13999 to the headers if errno is not already a macro. You then always
14000 write errno without any scope qualification, and it always expands
14001 to a correct reference. Since it is always a macro, you know to
14002 avoid using errno as a local identifer.</p></li>
14003 <li><p>errno is in the global namespace. This fix is inferior, because
14004 ::errno is not guaranteed to be well-formed.</p></li>
14008 This issue was first raised in 1999, but it slipped through
14014 <p><b>Proposed resolution:</b></p>
14015 <p>Change the Note in section 17.4.1.2p5 from</p>
14018 Note: the names defined as macros in C include the following:
14019 assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
14025 Note: the names defined as macros in C include the following:
14026 assert, offsetof, setjmp, va_arg, va_end, and va_start.
14029 <p>In section 19.3, change paragraph 2 from</p>
14032 The contents are the same as the Standard C library header
14039 The contents are the same as the Standard C library header
14040 <errno.h>, except that errno shall be defined as a macro.
14044 <p><b>Rationale:</b></p>
14045 <p>C++ must not leave it up to the implementation to decide whether or
14046 not a name is a macro; it must explicitly specify exactly which names
14047 are required to be macros. The only one that really works is for it
14050 <p><i>[Curaçao: additional rationale added.]</i></p>
14059 <h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
14060 <p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14061 <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-03-21</p>
14062 <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>
14063 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14064 <p><b>Discussion:</b></p>
14066 <p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p>
14068 <pre> // partial specializationss
14069 template<class traits>
14070 basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
14076 <li>Too many 's's at the end of "specializationss" </li>
14077 <li>This is an overload, not a partial specialization</li>
14082 <p><b>Proposed resolution:</b></p>
14083 <p>In the synopsis in 27.6.2.1 [ostream], remove the
14084 <i>// partial specializationss</i> comment. Also remove the same
14085 comment (correctly spelled, but still incorrect) from the synopsis in
14086 27.6.2.6.4 [ostream.inserters.character].
14090 Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
14091 comment in c++std-lib-8939.
14101 <h3><a name="312"></a>312. Table 27 is missing headers</h3>
14102 <p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14103 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-29</p>
14104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14105 <p><b>Discussion:</b></p>
14106 <p>Table 27 in section 20 lists the header <memory> (only) for
14107 Memory (lib.memory) but neglects to mention the headers
14108 <cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].</p>
14111 <p><b>Proposed resolution:</b></p>
14112 <p>Add <cstdlib> and <cstring> to Table 27, in the same row
14113 as <memory>.</p>
14120 <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
14121 <p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14122 <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p>
14123 <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>
14124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14125 <p><b>Discussion:</b></p>
14127 23.2.4.4 [list.ops], Para 21 describes the complexity of
14128 list::unique as: "If the range (last - first) is not empty, exactly
14129 (last - first) -1 applications of the corresponding predicate,
14130 otherwise no applications of the predicate)".
14134 "(last - first)" is not a range.
14138 <p><b>Proposed resolution:</b></p>
14140 Change the "range" from (last - first) to [first, last).
14147 <h3><a name="316"></a>316. Vague text in Table 69</h3>
14148 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14149 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
14150 <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>
14151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14152 <p><b>Discussion:</b></p>
14153 <p>Table 69 says this about a_uniq.insert(t):</p>
14156 inserts t if and only if there is no element in the container with key
14157 equivalent to the key of t. The bool component of the returned pair
14158 indicates whether the insertion takes place and the iterator component of the
14159 pair points to the element with key equivalent to the key of t.
14162 <p>The description should be more specific about exactly how the bool component
14163 indicates whether the insertion takes place.</p>
14166 <p><b>Proposed resolution:</b></p>
14167 <p>Change the text in question to</p>
14170 ...The bool component of the returned pair is true if and only if the insertion
14179 <h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
14180 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14181 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
14182 <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>
14183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14184 <p><b>Discussion:</b></p>
14186 The localization section of the standard refers to specializations of
14187 the facet templates as instantiations even though the required facets
14188 are typically specialized rather than explicitly (or implicitly)
14189 instantiated. In the case of ctype<char> and
14190 ctype_byname<char> (and the wchar_t versions), these facets are
14191 actually required to be specialized. The terminology should be
14192 corrected to make it clear that the standard doesn't mandate explicit
14193 instantiation (the term specialization encompasses both explicit
14194 instantiations and specializations).
14198 <p><b>Proposed resolution:</b></p>
14200 In the following paragraphs, replace all occurrences of the word
14201 instantiation or instantiations with specialization or specializations,
14206 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
14207 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
14208 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
14212 <p>And change the text in 22.1.1.1.1, p4 from</p>
14215 An implementation is required to provide those instantiations
14216 for facet templates identified as members of a category, and
14217 for those shown in Table 52:
14223 An implementation is required to provide those specializations...
14226 <p><i>[Nathan will review these changes, and will look for places where
14227 explicit specialization is necessary.]</i></p>
14232 <p><b>Rationale:</b></p>
14233 <p>This is a simple matter of outdated language. The language to
14234 describe templates was clarified during the standardization process,
14235 but the wording in clause 22 was never updated to reflect that
14245 <h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
14246 <p><b>Section:</b> 22.2.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14247 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-12</p>
14248 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14249 <p><b>Discussion:</b></p>
14250 <p>The definition of the numpunct_byname template contains the following
14253 <pre> namespace std {
14254 template <class charT>
14255 class numpunct_byname : public numpunct<charT> {
14256 // this class is specialized for char and wchar_t.
14260 <p>There is no documentation of the specializations and it seems
14261 conceivable that an implementation will not explicitly specialize the
14262 template at all, but simply provide the primary template.</p>
14265 <p><b>Proposed resolution:</b></p>
14266 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
14267 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
14273 <h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
14274 <p><b>Section:</b> 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14275 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2001-05-15</p>
14276 <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>
14277 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14278 <p><b>Discussion:</b></p>
14279 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Required
14280 behavior" elements describe "the semantics of a function definition
14281 provided by either the implementation or a C++ program."</p>
14283 <p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
14284 elements describe "the preconditions for calling the function."</p>
14286 <p>In the sections noted below, the current wording specifies
14287 "Required Behavior" for what are actually preconditions, and thus
14288 should be specified as "Requires".</p>
14292 <p><b>Proposed resolution:</b></p>
14294 <p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p>
14296 <p>Required behavior: accept a value of ptr that is null or that was
14297 returned by an earlier call ...</p>
14301 <p>Requires: the value of ptr is null or the value returned by an
14302 earlier call ...</p>
14305 <p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p>
14307 <p>Required behavior: accept a value of ptr that is null or that was
14308 returned by an earlier call ...</p>
14312 <p>Requires: the value of ptr is null or the value returned by an
14313 earlier call ...</p>
14321 <h3><a name="320"></a>320. list::assign overspecified</h3>
14322 <p><b>Section:</b> 23.2.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14323 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p>
14324 <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>
14325 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14326 <p><b>Discussion:</b></p>
14328 Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
14329 the "effects" of a call to erase followed by a call to insert.
14333 I would like to document that implementers have the freedom to implement
14334 assign by other methods, as long as the end result is the same and the
14335 exception guarantee is as good or better than the basic guarantee.
14339 The motivation for this is to use T's assignment operator to recycle
14340 existing nodes in the list instead of erasing them and reallocating
14341 them with new values. It is also worth noting that, with careful
14342 coding, most common cases of assign (everything but assignment with
14343 true input iterators) can elevate the exception safety to strong if
14344 T's assignment has a nothrow guarantee (with no extra memory cost).
14345 Metrowerks does this. However I do not propose that this subtlety be
14346 standardized. It is a QoI issue. </p>
14348 <p>Existing practise:
14349 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
14353 <p><b>Proposed resolution:</b></p>
14354 <p>Change 23.2.4.1 [list.cons]/7 from:</p>
14359 <pre> erase(begin(), end());
14360 insert(begin(), first, last);
14367 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
14370 <p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements),
14371 add two new rows:</p>
14372 <pre> a.assign(i,j) void pre: i,j are not iterators into a.
14373 Replaces elements in a with a copy
14376 a.assign(n,t) void pre: t is not a reference into a.
14377 Replaces elements in a with n copies
14381 <p>Change 23.2.4.1 [list.cons]/8 from:</p>
14385 <pre> erase(begin(), end());
14386 insert(begin(), n, t);
14392 <p>Effects: Replaces the contents of the list with n copies of t.</p>
14395 <p><i>[Redmond: Proposed resolution was changed slightly. Previous
14396 version made explicit statement about exception safety, which wasn't
14397 consistent with the way exception safety is expressed elsewhere.
14398 Also, the change in the sequence requirements is new. Without that
14399 change, the proposed resolution would have required that assignment of
14400 a subrange would have to work. That too would have been
14401 overspecification; it would effectively mandate that assignment use a
14402 temporary. Howard provided wording.
14406 <p><i>[Curaçao: Made editorial improvement in wording; changed
14407 "Replaces elements in a with copies of elements in [i, j)."
14408 with "Replaces the elements of a with a copy of [i, j)."
14409 Changes not deemed serious enough to requre rereview.]</i></p>
14418 <h3><a name="321"></a>321. Typo in num_get</h3>
14419 <p><b>Section:</b> 22.2.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>
14420 <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</p>
14421 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
14422 <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>
14423 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14424 <p><b>Discussion:</b></p>
14426 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
14427 the conversion function, if needed, as indicated in Table 56."
14428 However, Table 56 uses the term "length modifier", not "length
14433 <p><b>Proposed resolution:</b></p>
14435 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
14436 to be "A length modifier is added ..."
14440 <p><b>Rationale:</b></p>
14441 <p>C uses the term "length modifier". We should be consistent.</p>
14449 <h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
14450 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14451 <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-05-17</p>
14452 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
14453 <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>
14454 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14455 <p><b>Discussion:</b></p>
14457 It's widely assumed that, if X is a container,
14458 iterator_traits<X::iterator>::value_type and
14459 iterator_traits<X::const_iterator>::value_type should both be
14460 X::value_type. However, this is nowhere stated. The language in
14461 Table 65 is not precise about the iterators' value types (it predates
14462 iterator_traits), and could even be interpreted as saying that
14463 iterator_traits<X::const_iterator>::value_type should be "const
14467 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
14470 <p><b>Proposed resolution:</b></p>
14471 <p>In Table 65 ("Container Requirements"), change the return type for
14472 X::iterator to "iterator type whose value type is T". Change the
14473 return type for X::const_iterator to "constant iterator type whose
14474 value type is T".</p>
14477 <p><b>Rationale:</b></p>
14479 This belongs as a container requirement, rather than an iterator
14480 requirement, because the whole notion of iterator/const_iterator
14481 pairs is specific to containers' iterator.
14484 It is existing practice that (for example)
14485 iterator_traits<list<int>::const_iterator>::value_type
14486 is "int", rather than "const int". This is consistent with
14487 the way that const pointers are handled: the standard already
14488 requires that iterator_traits<const int*>::value_type is int.
14496 <h3><a name="324"></a>324. Do output iterators have value types?</h3>
14497 <p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14498 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-07</p>
14499 <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>
14500 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14501 <p><b>Discussion:</b></p>
14503 <p>Table 73 suggests that output iterators have value types. It
14504 requires the expression "*a = t". Additionally, although Table 73
14505 never lists "a = t" or "X(a) = t" in the "expressions" column, it
14506 contains a note saying that "a = t" and "X(a) = t" have equivalent
14507 (but nowhere specified!) semantics.</p>
14509 <p>According to 24.1/9, t is supposed to be "a value of value type
14513 In the following sections, a and b denote values of X, n denotes a
14514 value of the difference type Distance, u, tmp, and m denote
14515 identifiers, r denotes a value of X&, t denotes a value of
14519 <p>Two other parts of the standard that are relevant to whether
14520 output iterators have value types:</p>
14523 <li>24.1/1 says "All iterators i support the expression *i,
14524 resulting in a value of some class, enumeration, or built-in type
14525 T, called the value type of the iterator".</li>
14528 24.3.1/1, which says "In the case of an output iterator, the types
14529 iterator_traits<Iterator>::difference_type
14530 iterator_traits<Iterator>::value_type are both defined as void."
14534 <p>The first of these passages suggests that "*i" is supposed to
14535 return a useful value, which contradicts the note in 24.1.2/2 saying
14536 that the only valid use of "*i" for output iterators is in an
14537 expression of the form "*i = t". The second of these passages appears
14538 to contradict Table 73, because it suggests that "*i"'s return value
14539 should be void. The second passage is also broken in the case of a an
14540 iterator type, like non-const pointers, that satisfies both the output
14541 iterator requirements and the forward iterator requirements.</p>
14543 <p>What should the standard say about <tt>*i</tt>'s return value when
14544 i is an output iterator, and what should it say about that t is in the
14545 expression "*i = t"? Finally, should the standard say anything about
14546 output iterators' pointer and reference types?</p>
14550 <p><b>Proposed resolution:</b></p>
14551 <p>24.1 p1, change</p>
14554 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
14555 in a value of some class, enumeration, or built-in type <tt>T</tt>,
14556 called the value type of the iterator.</p>
14562 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
14563 resulting in a value of some class, enumeration, or built-in type
14564 <tt>T</tt>, called the value type of the iterator. All output
14565 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
14566 value of some type that is in the set of types that are <i>writable</i> to
14567 the particular iterator type of <tt>i</tt>.
14571 <p>24.1 p9, add</p>
14574 <p><tt>o</tt> denotes a value of some type that is writable to the
14579 <p>Table 73, change</p>
14607 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
14612 <p><b>Rationale:</b></p>
14613 <p>The LWG considered two options: change all of the language that
14614 seems to imply that output iterators have value types, thus making it
14615 clear that output iterators have no value types, or else define value
14616 types for output iterator consistently. The LWG chose the former
14617 option, because it seems clear that output iterators were never
14618 intended to have value types. This was a deliberate design decision,
14619 and any language suggesting otherwise is simply a mistake.</p>
14621 <p>A future revision of the standard may wish to revisit this design
14629 <h3><a name="325"></a>325. Misleading text in moneypunct<>::do_grouping</h3>
14630 <p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14631 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-02</p>
14632 <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>
14633 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14634 <p><b>Discussion:</b></p>
14635 <p>The Returns clause in 22.2.6.3.2, p3 says about
14636 moneypunct<charT>::do_grouping()
14640 Returns: A pattern defined identically as the result of
14641 numpunct<charT>::do_grouping().241)
14644 <p>Footnote 241 then reads</p>
14647 This is most commonly the value "\003" (not "3").
14651 The returns clause seems to imply that the two member functions must
14652 return an identical value which in reality may or may not be true,
14653 since the facets are usually implemented in terms of struct std::lconv
14654 and return the value of the grouping and mon_grouping, respectively.
14655 The footnote also implies that the member function of the moneypunct
14656 facet (rather than the overridden virtual functions in moneypunct_byname)
14657 most commonly return "\003", which contradicts the C standard which
14658 specifies the value of "" for the (most common) C locale.
14663 <p><b>Proposed resolution:</b></p>
14664 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
14667 Returns: A pattern defined identically as, but not necessarily
14668 equal to, the result of numpunct<charT>::do_grouping().241)
14671 <p>and replace the text in Footnote 241 with the following:</p>
14674 To specify grouping by 3s the value is "\003", not "3".
14678 <p><b>Rationale:</b></p>
14680 The fundamental problem is that the description of the locale facet
14681 virtuals serves two purposes: describing the behavior of the base
14682 class, and describing the meaning of and constraints on the behavior
14683 in arbitrary derived classes. The new wording makes that separation a
14684 little bit clearer. The footnote (which is nonnormative) is not
14685 supposed to say what the grouping is in the "C" locale or in any other
14686 locale. It is just a reminder that the values are interpreted as small
14687 integers, not ASCII characters.
14694 <h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
14695 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14696 <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</p>
14697 <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>
14698 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14699 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
14700 <p><b>Discussion:</b></p>
14701 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
14702 <tt>time_get_byname</tt> are listed incorrectly in table 52,
14703 required instantiations. In both cases the second template
14704 parameter is given as OutputIterator. It should instead be
14705 InputIterator, since these are input facets.</p>
14708 <p><b>Proposed resolution:</b></p>
14710 In table 52, required instantiations, in
14711 22.1.1.1.1 [locale.category], change</p>
14712 <pre> time_get<wchar_t, OutputIterator>
14713 time_get_byname<wchar_t, OutputIterator>
14716 <pre> time_get<wchar_t, InputIterator>
14717 time_get_byname<wchar_t, InputIterator>
14720 <p><i>[Redmond: Very minor change in proposed resolution. Original had
14721 a typo, wchart instead of wchar_t.]</i></p>
14729 <h3><a name="328"></a>328. Bad sprintf format modifier in money_put<>::do_put()</h3>
14730 <p><b>Section:</b> 22.2.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14731 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-07</p>
14732 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14733 <p><b>Discussion:</b></p>
14734 <p>The sprintf format string , "%.01f" (that's the digit one), in the
14735 description of the do_put() member functions of the money_put facet in
14736 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
14737 for values of type long double, and second, the precision of 01
14738 doesn't seem to make sense. What was most likely intended was
14739 "%.0Lf"., that is a precision of zero followed by the L length
14743 <p><b>Proposed resolution:</b></p>
14744 <p>Change the format string to "%.0Lf".</p>
14747 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
14753 <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
14754 <p><b>Section:</b> 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14755 <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p>
14756 <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>
14757 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14758 <p><b>Discussion:</b></p>
14760 There is an apparent contradiction about which circumstances can cause
14761 a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and
14762 section 23.2.6.4 [vector.modifiers].
14765 <p>23.2.6.2 [vector.capacity],p5 says:</p>
14767 Notes: Reallocation invalidates all the references, pointers, and iterators
14768 referring to the elements in the sequence. It is guaranteed that no
14769 reallocation takes place during insertions that happen after a call to
14770 reserve() until the time when an insertion would make the size of the vector
14771 greater than the size specified in the most recent call to reserve().
14774 <p>Which implies if I do</p>
14776 <pre> std::vector<int> vec;
14779 vec.insert(vec.end(),1);
14782 <p>then the implementation may reallocate the vector for the insert,
14783 as the size specified in the previous call to reserve was zero.</p>
14785 <p>However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:</p>
14788 (capacity) Returns: The total number of elements the vector
14789 can hold without requiring reallocation
14792 ...After reserve(), capacity() is greater or equal to the
14793 argument of reserve if reallocation happens; and equal to the previous value
14794 of capacity() otherwise...
14799 This implies that vec.capacity() is still 23, and so the insert()
14800 should not require a reallocation, as vec.size() is 0. This is backed
14801 up by 23.2.6.4 [vector.modifiers], p1:
14804 (insert) Notes: Causes reallocation if the new size is greater than the old
14809 Though this doesn't rule out reallocation if the new size is less
14810 than the old capacity, I think the intent is clear.
14815 <p><b>Proposed resolution:</b></p>
14816 <p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p>
14819 Notes: Reallocation invalidates all the references, pointers, and
14820 iterators referring to the elements in the sequence. It is guaranteed
14821 that no reallocation takes place during insertions that happen after a
14822 call to reserve() until the time when an insertion would make the size
14823 of the vector greater than the value of capacity().
14826 <p><i>[Redmond: original proposed resolution was modified slightly. In
14827 the original, the guarantee was that there would be no reallocation
14828 until the size would be greater than the value of capacity() after the
14829 most recent call to reserve(). The LWG did not believe that the
14830 "after the most recent call to reserve()" added any useful
14831 information.]</i></p>
14836 <p><b>Rationale:</b></p>
14837 <p>There was general agreement that, when reserve() is called twice in
14838 succession and the argument to the second invocation is smaller than
14839 the argument to the first, the intent was for the second invocation to
14840 have no effect. Wording implying that such cases have an effect on
14841 reallocation guarantees was inadvertant.</p>
14848 <h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
14849 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14850 <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p>
14851 <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>
14852 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14853 <p><b>Discussion:</b></p>
14855 With the change in 17.4.4.9 [res.on.exception.handling] to state
14856 "An implementation may strengthen the exception-specification for a
14857 non-virtual function by removing listed exceptions."
14858 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
14859 and the following declaration of ~failure() in ios_base::failure
14861 <pre> namespace std {
14862 class ios_base::failure : public exception {
14865 virtual ~failure();
14870 <p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
14871 exception specification:</p>
14872 <pre> namespace std {
14876 virtual ~exception() throw();
14883 <p><b>Proposed resolution:</b></p>
14884 <p>Remove the declaration of ~failure().</p>
14887 <p><b>Rationale:</b></p>
14888 <p>The proposed resolution is consistent with the way that destructors
14889 of other classes derived from <tt>exception</tt> are handled.</p>
14898 <h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
14899 <p><b>Section:</b> 27.6.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14900 <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
14901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14902 <p><b>Discussion:</b></p>
14903 <p>A footnote in 27.6.2.8 [ostream.manip] states:</p>
14905 [Footnote: The effect of executing cout << endl is to insert a
14906 newline character in the output sequence controlled by cout, then
14907 synchronize it with any external file with which it might be
14908 associated. --- end foonote]
14912 Does the term "file" here refer to the external device?
14913 This leads to some implementation ambiguity on systems with fully
14914 buffered files where a newline does not cause a flush to the device.
14918 Choosing to sync with the device leads to significant performance
14919 penalties for each call to endl, while not sync-ing leads to
14920 errors under special circumstances.
14924 I could not find any other statement that explicitly defined
14925 the behavior one way or the other.
14929 <p><b>Proposed resolution:</b></p>
14930 <p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p>
14933 <p><b>Rationale:</b></p>
14934 <p>We already have normative text saying what <tt>endl</tt> does: it
14935 inserts a newline character and calls <tt>flush</tt>. This footnote
14936 is at best redundant, at worst (as this issue says) misleading,
14937 because it appears to make promises about what <tt>flush</tt>
14947 <h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
14948 <p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
14949 <b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p>
14950 <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>
14951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
14952 <p><b>Discussion:</b></p>
14954 The current standard describes map::operator[] using a
14955 code example. That code example is however quite
14956 inefficient because it requires several useless copies
14957 of both the passed key_type value and of default
14958 constructed mapped_type instances.
14959 My opinion is that was not meant by the comitee to
14960 require all those temporary copies.
14963 <p>Currently map::operator[] behaviour is specified as: </p>
14965 (*((insert(make_pair(x, T()))).first)).second.
14969 This specification however uses make_pair that is a
14970 template function of which parameters in this case
14971 will be deduced being of type const key_type& and
14972 const T&. This will create a pair<key_type,T> that
14973 isn't the correct type expected by map::insert so
14974 another copy will be required using the template
14975 conversion constructor available in pair to build
14976 the required pair<const key_type,T> instance.
14979 <p>If we consider calling of key_type copy constructor
14980 and mapped_type default constructor and copy
14981 constructor as observable behaviour (as I think we
14982 should) then the standard is in this place requiring
14983 two copies of a key_type element plus a default
14984 construction and two copy construction of a mapped_type
14985 (supposing the addressed element is already present
14986 in the map; otherwise at least another copy
14987 construction for each type).
14990 <p>A simple (half) solution would be replacing the description with:</p>
14992 (*((insert(value_type(x, T()))).first)).second.
14995 <p>This will remove the wrong typed pair construction that
14996 requires one extra copy of both key and value.</p>
14998 <p>However still the using of map::insert requires temporary
14999 objects while the operation, from a logical point of view,
15000 doesn't require any. </p>
15002 <p>I think that a better solution would be leaving free an
15003 implementer to use a different approach than map::insert
15004 that, because of its interface, forces default constructed
15005 temporaries and copies in this case.
15006 The best solution in my opinion would be just requiring
15007 map::operator[] to return a reference to the mapped_type
15008 part of the contained element creating a default element
15009 with the specified key if no such an element is already
15010 present in the container. Also a logarithmic complexity
15011 requirement should be specified for the operation.
15015 This would allow library implementers to write alternative
15016 implementations not using map::insert and reaching optimal
15017 performance in both cases of the addressed element being
15018 present or absent from the map (no temporaries at all and
15019 just the creation of a new pair inside the container if
15020 the element isn't present).
15021 Some implementer has already taken this option but I think
15022 that the current wording of the standard rules that as
15028 <p><b>Proposed resolution:</b></p>
15031 Replace 23.3.1.2 [map.access] paragraph 1 with
15035 -1- Effects: If there is no key equivalent to x in the map, inserts
15036 value_type(x, T()) into the map.
15039 -2- Returns: A reference to the mapped_type corresponding to x in *this.
15042 -3- Complexity: logarithmic.
15046 <p><i>[This is the second option mentioned above. Howard provided
15047 wording. We may also wish to have a blanket statement somewhere in
15048 clause 17 saying that we do not intend the semantics of sample code
15049 fragments to be interpreted as specifing exactly how many copies are
15050 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>
15055 <p><b>Rationale:</b></p>
15057 This is the second solution described above; as noted, it is
15058 consistent with existing practice.
15061 <p>Note that we now need to specify the complexity explicitly, because
15062 we are no longer defining <tt>operator[]</tt> in terms of
15063 <tt>insert</tt>.</p>
15070 <h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
15071 <p><b>Section:</b> 21.1.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15072 <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-09-06</p>
15073 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15074 <p><b>Discussion:</b></p>
15076 Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
15079 <pre> X::assign(c,d) assigns c = d.
15082 <p>And para 1 says:</p>
15085 [...] c and d denote values of type CharT [...]
15089 Naturally, if c and d are <i>values</i>, then the assignment is
15090 (effectively) meaningless. It's clearly intended that (in the case of
15091 assign, at least), 'c' is intended to be a reference type.
15094 <p>I did a quick survey of the four implementations I happened to have
15095 lying around, and sure enough they all have signatures:</p>
15096 <pre> assign( charT&, const charT& );
15099 <p>(or the equivalent). It's also described this way in Nico's book.
15100 (Not to mention the synopses of char_traits<char> in 21.1.3.1
15101 and char_traits<wchar_t> in 21.1.3.2...)
15105 <p><b>Proposed resolution:</b></p>
15106 <p>Add the following to 21.1.1 para 1:</p>
15108 r denotes an lvalue of CharT
15111 <p>and change the description of assign in the table to:</p>
15112 <pre> X::assign(r,d) assigns r = d
15120 <h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
15121 <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>
15122 <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</p>
15123 <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>
15124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15125 <p><b>Discussion:</b></p>
15126 <p>From c++std-edit-873:</p>
15128 <p>17.4.1.2 [headers], Table 11. In this table, the header
15129 <strstream> is missing.</p>
15131 <p>This shows a general problem: The whole clause 17 refers quite
15132 often to clauses 18 through 27, but D.7 is also a part of the standard
15133 library (though a deprecated one).</p>
15137 <p><b>Proposed resolution:</b></p>
15139 <p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
15140 "<strstream>".</p>
15142 <p>In the following places, change "clauses 17 through 27" to "clauses
15143 17 through 27 and Annex D":</p>
15146 <li>1.2 [intro.refs] Normative references/1/footnote 1</li>
15147 <li>1.3 [intro.defs] Definitions/1</li>
15148 <li>7 [dcl.dcl] Library introduction/9</li>
15149 <li>17.3 [description] Method of description (Informative)/1</li>
15150 <li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li>
15151 <li>17.3.2.2 [functions.within.classes] Functions within classes/1</li>
15152 <li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li>
15153 <li>17.4 [requirements] Library-wide requirements/1</li>
15154 <li>17.4.1.2 [headers] Headers/4</li>
15155 <li>17.4.3.5 [replacement.functions] Replacement functions/1</li>
15156 <li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
15157 <li>17.4.4.7 [protection.within.classes] Protection within classes/1</li>
15167 <h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
15168 <p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15169 <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p>
15170 <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>
15171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15172 <p><b>Discussion:</b></p>
15173 <p>From c++std-edit-876:</p>
15176 In section 25.2.5 [alg.replace] before p4: The name of the first
15177 parameter of template replace_copy_if should be "InputIterator"
15178 instead of "Iterator". According to 17.3.2.1 [type.descriptions] p1 the
15179 parameter name conveys real normative meaning.
15183 <p><b>Proposed resolution:</b></p>
15184 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
15191 <h3><a name="338"></a>338. is whitespace allowed between `-' and a digit?</h3>
15192 <p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15193 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
15194 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
15195 <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>
15196 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15197 <p><b>Discussion:</b></p>
15199 From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
15200 original text or the text corrected by the proposed resolution of
15201 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
15202 within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
15203 format for integer and floating point values, says that whitespace is
15204 optional between a plusminus and a sign.
15208 The text needs to be clarified to either consistently allow or
15209 disallow whitespace between a plusminus and a sign. It might be
15210 worthwhile to consider the fact that the C library stdio facility does
15211 not permit whitespace embedded in numbers and neither does the C or
15212 C++ core language (the syntax of integer-literals is given in 2.13.1
15213 [lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
15218 <p><b>Proposed resolution:</b></p>
15219 <p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p>
15222 The syntax for number formats is as follows, where <tt>digit</tt>
15223 represents the radix set specified by the <tt>fmtflags</tt> argument
15224 value, <tt>whitespace</tt> is as determined by the facet
15225 <tt>ctype<charT></tt> (22.2.1.1), and <tt>thousands-sep</tt> and
15226 <tt>decimal-point</tt> are the results of corresponding
15227 <tt>numpunct<charT></tt> members. Integer values have the
15230 <pre> integer ::= [sign] units
15231 sign ::= plusminus [whitespace]
15232 plusminus ::= '+' | '-'
15233 units ::= digits [thousands-sep units]
15234 digits ::= digit [digits]
15240 The syntax for number formats is as follows, where <tt>digit</tt>
15241 represents the radix set specified by the <tt>fmtflags</tt> argument
15242 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
15243 results of corresponding <tt>numpunct<charT></tt> members.
15244 Integer values have the format:
15246 <pre> integer ::= [sign] units
15248 plusminus ::= '+' | '-'
15249 units ::= digits [thousands-sep units]
15250 digits ::= digit [digits]
15255 <p><b>Rationale:</b></p>
15256 <p>It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
15257 standard says how, or whether, it's used. However, there's no reason
15258 for it to differ gratuitously from the very specific description of
15259 numeric processing in 22.2.2.1.2 [facet.num.get.virtuals]. The proposed
15260 resolution removes all mention of "whitespace" from that format.</p>
15267 <h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
15268 <p><b>Section:</b> 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15269 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
15270 <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>
15271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15272 <p><b>Discussion:</b></p>
15273 <p>The ctype_category::mask type is declared to be an enum in 22.2.1
15274 [category.ctype] with p1 then stating that it is a bitmask type, most
15275 likely referring to the definition of bitmask type in 17.3.2.1.2
15276 [bitmask.types], p1. However, the said definition only applies to
15277 clause 27, making the reference in 22.2.1 somewhat dubious.
15281 <p><b>Proposed resolution:</b></p>
15282 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
15284 Several types defined in clause 27 are bitmask types. Each bitmask type
15285 can be implemented as an enumerated type that overloads certain operators,
15286 as an integer type, or as a bitset (23.3.5 [template.bitset]).
15290 Several types defined in clauses lib.language.support through
15291 lib.input.output and Annex D are bitmask types. Each bitmask type can
15292 be implemented as an enumerated type that overloads certain operators,
15293 as an integer type, or as a bitset (lib.template.bitset).
15297 Additionally, change the definition in 22.2.1 to adopt the same
15298 convention as in clause 27 by replacing the existing text with the
15299 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
15304 <p>22.2.1 The ctype category [lib.category.ctype]</p>
15305 <pre>namespace std {
15308 typedef <b><i>T</i></b> mask;
15310 // numeric values are for exposition only.
15311 static const mask space = 1 << 0;
15312 static const mask print = 1 << 1;
15313 static const mask cntrl = 1 << 2;
15314 static const mask upper = 1 << 3;
15315 static const mask lower = 1 << 4;
15316 static const mask alpha = 1 << 5;
15317 static const mask digit = 1 << 6;
15318 static const mask punct = 1 << 7;
15319 static const mask xdigit = 1 << 8;
15320 static const mask alnum = alpha | digit;
15321 static const mask graph = alnum | punct;
15326 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p>
15329 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
15330 consistent with the rest of the standard.]</i></p>
15341 <h3><a name="340"></a>340. interpretation of <tt>has_facet<Facet>(loc)</tt></h3>
15342 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15343 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-18</p>
15344 <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>
15345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15346 <p><b>Discussion:</b></p>
15348 It's unclear whether 22.1.1.1.1, p3 says that
15349 <tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt>
15350 from Table 51 or whether it includes Table 52 as well:
15354 For any locale <tt>loc</tt> either constructed, or returned by
15355 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
15356 standard category, <tt>has_facet<Facet>(loc)</tt> is true. Each
15357 locale member function which takes a <tt>locale::category</tt>
15358 argument operates on the corresponding set of facets.
15362 It seems that it comes down to which facets are considered to be members of a
15363 standard category. Intuitively, I would classify all the facets in Table 52 as
15364 members of their respective standard categories, but there are an unbounded set
15369 The paragraph implies that, for instance, <tt>has_facet<num_put<C,
15370 OutputIterator> >(loc)</tt> must always return true. I don't think that's
15371 possible. If it were, then <tt>use_facet<num_put<C, OutputIterator>
15372 >(loc)</tt> would have to return a reference to a distinct object for each
15373 valid specialization of <tt>num_put<C, OutputIteratory></tt>, which is
15374 clearly impossible.
15378 On the other hand, if none of the facets in Table 52 is a member of a standard
15379 category then none of the locale member functions that operate on entire
15380 categories of facets will work properly.
15384 It seems that what p3 should mention that it's required (permitted?)
15385 to hold only for specializations of <tt>Facet</tt> from Table 52 on
15386 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
15387 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
15389 {i,o}<tt>streambuf_iterator</tt><{<tt>char</tt>,<tt>wchar_t</tt>}<tt>></tt>
15394 <p><b>Proposed resolution:</b></p>
15395 <p>In 22.1.1.1.1 [locale.category], paragraph 3, change
15396 "that is a member of a standard category" to "shown in Table 51".</p>
15399 <p><b>Rationale:</b></p>
15400 <p>The facets in Table 52 are an unbounded set. Locales should not be
15401 required to contain an infinite number of facets.</p>
15403 <p>It's not necessary to talk about which values of InputIterator and
15404 OutputIterator must be supported. Table 51 already contains a
15405 complete list of the ones we need.</p>
15413 <h3><a name="341"></a>341. Vector reallocation and swap</h3>
15414 <p><b>Section:</b> 23.2.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15415 <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p>
15416 <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>
15417 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15418 <p><b>Discussion:</b></p>
15419 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
15421 <pre> std::vector<SomeType> vec;
15422 // fill vec with data
15423 std::vector<SomeType>().swap(vec);
15424 // vec is now empty, with minimal capacity
15427 <p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
15428 the capacity of a vector being reduced, following a call to
15429 reserve(). This invalidates the idiom, as swap() is thus prevented
15430 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
15431 requires the temporary to be expanded to cater for the contents of
15432 vec, and the contents be copied across. This is a linear-time
15435 <p>However, the container requirements state that swap must have constant
15436 complexity (23.1 [container.requirements] note to table 65).</p>
15438 <p>This is an important issue, as reallocation affects the validity of
15439 references and iterators.</p>
15441 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
15442 references and iterators remain valid after a call to swap, if they refer to
15443 an element before the new end() of the vector into which they originally
15444 pointed, in which case they refer to the element at the same index position.
15445 Iterators and references that referred to an element whose index position
15446 was beyond the new end of the vector are invalidated.</p>
15448 <p>If the note to table 65 is taken as the desired intent, then there are two
15449 possibilities with regard to iterators and references:</p>
15452 <li>All Iterators and references into both vectors are invalidated.</li>
15453 <li>Iterators and references into either vector remain valid, and remain
15454 pointing to the same element. Consequently iterators and references that
15455 referred to one vector now refer to the other, and vice-versa.</li>
15459 <p><b>Proposed resolution:</b></p>
15460 <p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p>
15462 <pre> void swap(vector<T,Allocator>& x);
15464 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
15465 with that of <tt>x</tt>.</p>
15466 <p><b>Complexity:</b> Constant time.</p>
15469 <p><i>[This solves the problem reported for this issue. We may also
15470 have a problem with a circular definition of swap() for other
15471 containers.]</i></p>
15476 <p><b>Rationale:</b></p>
15478 swap should be constant time. The clear intent is that it should just
15479 do pointer twiddling, and that it should exchange all properties of
15480 the two vectors, including their reallocation guarantees.
15488 <h3><a name="345"></a>345. type tm in <cwchar></h3>
15489 <p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15490 <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
15491 <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>
15492 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15493 <p><b>Discussion:</b></p>
15494 <p>C99, and presumably amendment 1 to C90, specify that <wchar.h>
15495 declares struct tm as an incomplete type. However, table 48 in 21.5
15496 [c.strings] does not mention the type tm as being declared in
15497 <cwchar>. Is this omission intentional or accidental?
15501 <p><b>Proposed resolution:</b></p>
15502 <p>In section 21.5 [c.strings], add "tm" to table 48.</p>
15509 <h3><a name="346"></a>346. Some iterator member functions should be const</h3>
15510 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15511 <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</p>
15512 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
15513 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
15514 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15515 <p><b>Discussion:</b></p>
15516 <p>Iterator member functions and operators that do not change the state
15517 of the iterator should be defined as const member functions or as
15518 functions that take iterators either by const reference or by
15519 value. The standard does not explicitly state which functions should
15520 be const. Since this a fairly common mistake, the following changes
15521 are suggested to make this explicit.</p>
15523 <p>The tables almost indicate constness properly through naming: r
15524 for non-const and a,b for const iterators. The following changes
15525 make this more explicit and also fix a couple problems.</p>
15528 <p><b>Proposed resolution:</b></p>
15529 <p>In 24.1 [iterator.requirements] Change the first section of p9 from
15530 "In the following sections, a and b denote values of X..." to
15531 "In the following sections, a and b denote values of type const X...".</p>
15533 <p>In Table 73, change</p>
15534 <pre> a->m U& ...
15539 <pre> a->m const U& ...
15543 <p>In Table 73 expression column, change</p>
15553 <p><i>[Redmond: The container requirements should be reviewed to see if
15554 the same problem appears there.]</i></p>
15563 <h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
15564 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15565 <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 2001-10-23</p>
15566 <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>
15567 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15568 <p><b>Discussion:</b></p>
15570 In 22.1.1.1.1 [locale.category] paragraph 1, the category members
15571 are described as bitmask elements. In fact, the bitmask requirements
15572 in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt>
15573 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
15575 <p>In particular, the requirements for <tt>none</tt> interact poorly
15576 with the requirement that the LC_* constants from the C library must
15577 be recognizable as C++ locale category constants. LC_* values should
15578 not be mixed with these values to make category values.</p>
15580 <p>We have two options for the proposed resolution. Informally:
15581 option 1 removes the requirement that LC_* values be recognized as
15582 category arguments. Option 2 changes the category type so that this
15583 requirement is implementable, by allowing <tt>none</tt> to be some
15584 value such as 0x1000 instead of 0.</p>
15586 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
15587 re-expresses the status quo more clearly, without introducing any
15588 changes beyond resolving the DR.</p>
15592 <p><b>Proposed resolution:</b></p>
15593 <p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p>
15595 <pre> typedef int category;
15598 <p>Valid category values include the <tt>locale</tt> member bitmask
15599 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
15600 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
15601 represents a single locale category. In addition, <tt>locale</tt> member
15602 bitmask constant <tt>none</tt> is defined as zero and represents no
15603 category. And locale member bitmask constant <tt>all</tt> is defined such that
15605 <pre> (collate | ctype | monetary | numeric | time | messages | all) == all
15608 is <tt>true</tt>, and represents the union of all categories. Further
15609 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
15610 represent a single category, represents the union of the two
15615 <tt>locale</tt> member functions expecting a <tt>category</tt>
15616 argument require one of the <tt>category</tt> values defined above, or
15617 the union of two or more such values. Such a <tt>category</tt>
15618 argument identifies a set of locale categories. Each locale category,
15619 in turn, identifies a set of locale facets, including at least those
15623 <p><i>[Curaçao: need input from locale experts.]</i></p>
15628 <p><b>Rationale:</b></p>
15630 <p>The LWG considered, and rejected, an alternate proposal (described
15631 as "Option 2" in the discussion). The main reason for rejecting it
15632 was that library implementors were concerened about implementation
15633 difficult, given that getting a C++ library to work smoothly with a
15634 separately written C library is already a delicate business. Some
15635 library implementers were also concerned about the issue of adding
15636 extra locale categories.</p>
15639 <p><b>Option 2:</b> <br>
15640 Replace the first paragraph of 22.1.1.1 [locale.types] with:</p>
15643 Valid category values include the enumerated values. In addition, the
15644 result of applying commutative operators | and & to any two valid
15645 values is valid, and results in the setwise union and intersection,
15646 respectively, of the argument categories. The values <tt>all</tt> and
15647 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
15648 expressions <tt>(cat | all == all)</tt>, <tt>(cat & all == cat)</tt>,
15649 <tt>(cat | none == cat)</tt> and <tt>(cat & none == none)</tt> are
15650 true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
15651 remaining enumerated values, <tt>(cat1 & cat2 == none)</tt> is true.
15652 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
15653 of <tt>(cat1 & ~cat2)</tt> is valid, and equals the setwise union of
15654 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
15655 [Footnote: it is not required that <tt>all</tt> equal the setwise union
15656 of the other enumerated values; implementations may add extra categories.]
15666 <h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
15667 <p><b>Section:</b> 24.5.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15668 <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-24</p>
15669 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15670 <p><b>Discussion:</b></p>
15671 <p>24.5.2 [lib.ostream.iterator] states:</p>
15675 // basic_ostream<charT,traits>* out_stream; exposition only
15676 // const char* delim; exposition only
15679 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
15680 should be of type 'const charT*'.</p>
15683 <p><b>Proposed resolution:</b></p>
15685 In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with
15686 <tt>const charT* delim</tt>.
15694 <h3><a name="352"></a>352. missing fpos requirements</h3>
15695 <p><b>Section:</b> 21.1.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15696 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
15697 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15698 <p><b>Discussion:</b></p>
15701 There are no requirements on the <tt>stateT</tt> template parameter of
15702 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
15703 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
15704 and I think also DefaultConstructible (to implement the operations in
15708 21.1.2, p3, however, only requires that
15709 <tt>char_traits<charT>::state_type</tt> meet the requirements of
15710 CopyConstructible types.
15714 Additionally, the <tt>stateT</tt> template argument has no
15715 corresponding typedef in fpos which might make it difficult to use in
15720 <p><b>Proposed resolution:</b></p>
15722 Modify 21.1.2, p4 from
15725 Requires: <tt>state_type</tt> shall meet the requirements of
15726 CopyConstructible types (20.1.3).
15729 Requires: state_type shall meet the requirements of Assignable
15730 (23.1, p4), CopyConstructible (20.1.3), and
15731 DefaultConstructible (20.1.4) types.
15736 <p><b>Rationale:</b></p>
15737 <p>The LWG feels this is two issues, as indicated above. The first is
15738 a defect---std::basic_fstream is unimplementable without these
15739 additional requirements---and the proposed resolution fixes it. The
15740 second is questionable; who would use that typedef? The class
15741 template fpos is used only in a very few places, all of which know the
15742 state type already. Unless motivation is provided, the second should
15743 be considered NAD.</p>
15750 <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
15751 <p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15752 <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p>
15753 <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>
15754 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15755 <p><b>Discussion:</b></p>
15757 Discussions in the thread "Associative container lower/upper bound
15758 requirements" on comp.std.c++ suggests that there is a defect in the
15759 C++ standard, Table 69 of section 23.1.2, "Associative containers",
15760 [lib.associative.reqmts]. It currently says:</p>
15764 a.find(k): returns an iterator pointing to an element with the key equivalent to
15765 k, or a.end() if such an element is not found.
15769 a.lower_bound(k): returns an iterator pointing to the first element with
15770 key not less than k.
15774 a.upper_bound(k): returns an iterator pointing to the first element with
15775 key greater than k.
15780 We have "or a.end() if such an element is not found" for
15781 <tt>find</tt>, but not for <tt>upper_bound</tt> or
15782 <tt>lower_bound</tt>. As the text stands, one would be forced to
15783 insert a new element into the container and return an iterator to that
15784 in case the sought iterator does not exist, which does not seem to be
15785 the intention (and not possible with the "const" versions).
15789 <p><b>Proposed resolution:</b></p>
15791 <p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
15796 a.lower_bound(k): returns an iterator pointing to the first element with
15797 key not less than k, or a.end() if such an element is not found.
15801 a.upper_bound(k): returns an iterator pointing to the first element with
15802 key greater than k, or a.end() if such an element is not found.
15806 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
15816 <h3><a name="355"></a>355. Operational semantics for a.back()</h3>
15817 <p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15818 <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p>
15819 <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>
15820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15821 <p><b>Discussion:</b></p>
15823 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
15824 specifies operational semantics for "a.back()" as
15825 "*--a.end()", which may be ill-formed <i>[because calling
15826 operator-- on a temporary (the return) of a built-in type is
15827 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
15828 (this is almost always the case for std::vector::end(), for
15829 example). Thus, the specification is not only incorrect, it
15830 demonstrates a dangerous construct: "--a.end()" may
15831 successfully compile and run as intended, but after changing the type
15832 of the container or the mode of compilation it may produce
15833 compile-time error. </p>
15837 <p><b>Proposed resolution:</b></p>
15838 <p>Change the specification in table 68 "Optional Sequence
15839 Operations" in 23.1.1/12 for "a.back()" from</p>
15842 <blockquote><pre>*--a.end()
15843 </pre></blockquote>
15847 <blockquote><pre> { iterator tmp = a.end(); --tmp; return *tmp; }
15848 </pre></blockquote>
15850 <p>and the specification for "a.pop_back()" from</p>
15852 <blockquote><pre>a.erase(--a.end())
15853 </pre></blockquote>
15857 <blockquote><pre> { iterator tmp = a.end(); --tmp; a.erase(tmp); }
15858 </pre></blockquote>
15860 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
15861 a.end(); return *--tmp; }" to "*a.rbegin()", and from
15862 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
15863 "a.erase(rbegin())".]</i></p>
15866 <p><i>[There is a second possible defect; table 68 "Optional
15867 Sequence Operations" in the "Operational Semantics"
15868 column uses operations present only in the "Reversible
15869 Container" requirements, yet there is no stated dependency
15870 between these separate requirements tables. Ask in Santa Cruz if the
15871 LWG would like a new issue opened.]</i></p>
15874 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
15875 the current standard: erase is undefined for reverse iterator. If
15876 we're going to make the change, we need to define a temporary and
15877 use operator--. Additionally, we don't know how prevalent this is:
15878 do we need to make this change in more than one place? Martin has
15879 volunteered to review the standard and see if this problem occurs
15880 elsewhere.]</i></p>
15883 <p><i>[Oxford: Matt provided new wording to address the concerns raised
15884 in Santa Cruz. It does not appear that this problem appears
15885 anywhere else in clauses 23 or 24.]</i></p>
15888 <p><i>[Kona: In definition of operational semantics of back(), change
15889 "*tmp" to "return *tmp;"]</i></p>
15898 <h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
15899 <p><b>Section:</b> 22.2.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>
15900 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15901 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
15902 <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>
15903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15904 <p><b>Discussion:</b></p>
15906 I don't think <tt>thousands_sep</tt> is being treated correctly after
15907 decimal_point has been seen. Since grouping applies only to the
15908 integral part of the number, the first such occurrence should, IMO,
15909 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
15910 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
15911 interpreted in the fractional part of a number.)
15915 The easiest change I can think of that resolves this issue would be
15916 something like below.
15920 <p><b>Proposed resolution:</b></p>
15922 Change the first sentence of 22.2.2.1.2, p9 from
15926 If discard is true then the position of the character is
15927 remembered, but the character is otherwise ignored. If it is not
15928 discarded, then a check is made to determine if c is allowed as
15929 the next character of an input field of the conversion specifier
15930 returned by stage 1. If so it is accumulated.
15936 If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
15937 accumulated, then the position of the character is remembered, but
15938 the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
15939 already been accumulated, the character is discarded and Stage 2
15945 <p><b>Rationale:</b></p>
15946 <p>We believe this reflects the intent of the Standard. Thousands sep
15947 characters after the decimal point are not useful in any locale.
15948 Some formatting conventions do group digits that follow the decimal
15949 point, but they usually introduce a different grouping character
15950 instead of reusing the thousand sep character. If we want to add
15951 support for such conventions, we need to do so explicitly.</p>
15959 <h3><a name="359"></a>359. num_put<>::do_put (..., bool) undocumented</h3>
15960 <p><b>Section:</b> 22.2.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
15961 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
15962 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
15963 <p><b>Discussion:</b></p>
15964 <p>22.2.2.2.1, p1:</p>
15966 <pre> iter_type put (iter_type out, ios_base& str, char_type fill,
15970 1 Returns: do_put (out, str, fill, val).
15973 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
15974 however, 22.2.2.2.2, p23:</p>
15977 <pre>iter_type put (iter_type out, ios_base& str, char_type fill,
15982 <p>Effects: If (str.flags() & ios_base::boolalpha) == 0 then do
15983 out = do_put(out, str, fill, (int)val)
15985 <pre> string_type s =
15986 val ? use_facet<ctype<charT> >(loc).truename()
15987 : use_facet<ctype<charT> >(loc).falsename();
15989 <p>and then insert the characters of s into out. <i>out</i>.</p>
15993 This means that the bool overload of <tt>do_put()</tt> will never be called,
15994 which contradicts the first paragraph. Perhaps the declaration
15995 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
15999 Note also that there is no <b>Returns</b> clause for this function, which
16000 should probably be corrected, just as should the second occurrence
16001 of <i>"out."</i> in the text.
16005 I think the least invasive change to fix it would be something like
16010 <p><b>Proposed resolution:</b></p>
16011 <p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
16012 the <tt>bool</tt> overload.</p>
16015 In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
16019 Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
16020 of the member function.
16024 Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
16025 avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
16026 do_put (..., bool))</tt>
16031 23 <b>Returns</b>: If <tt>(str.flags() &
16032 ios_base::boolalpha) == 0</tt> then
16033 <tt>do_put (out, str, fill, (long)val)</tt>
16034 Otherwise the function obtains a string <tt>s</tt> as if by</p>
16035 <pre> string_type s =
16036 val ? use_facet<ctype<charT> >(loc).truename()
16037 : use_facet<ctype<charT> >(loc).falsename();
16039 <p>and then inserts each character <tt>c</tt> of s into out via
16040 <tt>*out++ = c</tt>
16041 and returns <tt>out</tt>.</p>
16046 <p><b>Rationale:</b></p><p>
16047 This fixes a couple of obvious typos, and also fixes what appears to
16048 be a requirement of gratuitous inefficiency.
16055 <h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
16056 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16057 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
16058 <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>
16059 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16060 <p><b>Discussion:</b></p>
16062 22.1.1, p7 (copied below) allows iostream formatters and extractors
16063 to make assumptions about the values returned from facet members.
16064 However, such assumptions are apparently not guaranteed to hold
16065 in other cases (e.g., when the facet members are being called directly
16066 rather than as a result of iostream calls, or between successive
16067 calls to the same iostream functions with no interevening calls to
16068 <tt>imbue()</tt>, or even when the facet member functions are called
16069 from other member functions of other facets). This restriction
16070 prevents locale from being implemented efficiently.
16074 <p><b>Proposed resolution:</b></p>
16075 <p>Change the first sentence in 22.1.1, p7 from</p>
16077 In successive calls to a locale facet member function during
16078 a call to an iostream inserter or extractor or a streambuf member
16079 function, the returned result shall be identical. [Note: This
16080 implies that such results may safely be reused without calling
16081 the locale facet member function again, and that member functions
16082 of iostream classes cannot safely call <tt>imbue()</tt>
16083 themselves, except as specified elsewhere. --end note]
16089 In successive calls to a locale facet member function on a facet
16090 object installed in the same locale, the returned result shall be
16096 <p><b>Rationale:</b></p>
16097 <p>This change is reasonable becuase it clarifies the intent of this
16098 part of the standard.</p>
16105 <h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
16106 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16107 <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p>
16108 <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>
16109 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16110 <p><b>Discussion:</b></p>
16112 The definition of bind1st() (D.8 [depr.lib.binders]) can result in
16113 the construction of an unsafe binding between incompatible pointer
16114 types. For example, given a function whose first parameter type is
16115 'pointer to T', it's possible without error to bind an argument of
16116 type 'pointer to U' when U does not derive from T:
16118 <pre> foo(T*, int);
16128 for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding
16132 The definition of bind1st() includes a functional-style conversion to
16133 map its argument to the expected argument type of the bound function
16136 <pre> typename Operation::first_argument_type(x)
16139 <p>A functional-style conversion (D.8 [depr.lib.binders]) is defined to
16141 semantically equivalent to an explicit cast expression (D.8
16142 [depr.lib.binders]), which may (according to 5.4, paragraph 5) be
16144 as a reinterpret_cast, thus masking the error.
16147 <p>The problem and proposed change also apply to D.8 [depr.lib.binders].</p>
16150 <p><b>Proposed resolution:</b></p>
16151 <p>Add this sentence to the end of D.8 [depr.lib.binders]/1:
16152 "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
16153 favor of <tt>std::tr1::bind</tt>."</p>
16155 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
16156 the standard, "std::tr1::bind" should be changed to "std::bind". (2)
16157 20.5.6 should probably be moved to Annex D.</p>
16160 <p><b>Rationale:</b></p>
16161 <p>There is no point in fixing bind1st and bind2nd. tr1::bind is a
16162 superior solution. It solves this problem and others.</p>
16169 <h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
16170 <p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16171 <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 2002-05-20</p>
16172 <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>
16173 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16174 <p><b>Discussion:</b></p>
16176 The destructor of ios_base::failure should have an empty throw
16177 specification, because the destructor of its base class, exception, is
16178 declared in this way.
16182 <p><b>Proposed resolution:</b></p>
16183 <p>Change the destructor to</p>
16184 <pre> virtual ~failure() throw();
16188 <p><b>Rationale:</b></p>
16189 <p>Fixes an obvious glitch. This is almost editorial.</p>
16196 <h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
16197 <p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16198 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
16199 <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>
16200 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16201 <p><b>Discussion:</b></p>
16203 27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
16204 clause for seekoff.
16208 <p><b>Proposed resolution:</b></p>
16210 Make this paragraph, the Effects clause for setbuf, consistent in wording
16211 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
16212 to indicate the purpose of setbuf:
16215 <p>Original text:</p>
16218 1 Effects: Performs an operation that is defined separately for each
16219 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
16222 <p>Proposed text:</p>
16225 1 Effects: Influences stream buffering in a way that is defined separately
16226 for each class derived from basic_streambuf in this clause
16227 (27.7.1.3, 27.8.1.4).
16232 <p><b>Rationale:</b></p>
16233 <p>The LWG doesn't believe there is any normative difference between
16234 the existing wording and what's in the proposed resolution, but the
16235 change may make the intent clearer.</p>
16242 <h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
16243 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16244 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
16245 <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>
16246 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16247 <p><b>Discussion:</b></p>
16249 Some stream and streambuf member functions are declared non-const,
16250 even thought they appear only to report information rather than to
16251 change an object's logical state. They should be declared const. See
16252 document N1360 for details and rationale.
16255 <p>The list of member functions under discussion: <tt>in_avail</tt>,
16256 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
16258 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
16262 <p><b>Proposed resolution:</b></p>
16263 <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>
16265 <pre> bool is_open();
16268 <pre> bool is_open() const;
16272 <p><b>Rationale:</b></p>
16273 <p>Of the changes proposed in N1360, the only one that is safe is
16274 changing the filestreams' is_open to const. The LWG believed that
16275 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
16276 member function, after all,is already const.</p>
16278 <p>The other proposed changes are less safe, because some streambuf
16279 functions that appear merely to report a value do actually perform
16280 mutating operations. It's not even clear that they should be
16281 considered "logically const", because streambuf has two interfaces, a
16282 public one and a protected one. These functions may, and often do,
16283 change the state as exposed by the protected interface, even if the
16284 state exposed by the public interface is unchanged.</p>
16286 <p>Note that implementers can make this change in a binary compatible
16287 way by providing both overloads; this would be a conforming extension.</p>
16295 <h3><a name="369"></a>369. io stream objects and static ctors</h3>
16296 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16297 <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p>
16298 <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>
16299 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16300 <p><b>Discussion:</b></p>
16302 Is it safe to use standard iostream objects from constructors of
16303 static objects? Are standard iostream objects constructed and are
16304 their associations established at that time?
16307 <p>Surpisingly enough, Standard does NOT require that.</p>
16310 27.3/2 [lib.iostream.objects] guarantees that standard iostream
16311 objects are constructed and their associations are established before
16312 the body of main() begins execution. It also refers to ios_base::Init
16313 class as the panacea for constructors of static objects.
16317 However, there's nothing in 27.3 [lib.iostream.objects],
16318 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
16319 that would require implementations to allow access to standard
16320 iostream objects from constructors of static objects.
16325 <p>Core text refers to some magic object ios_base::Init, which will
16326 be discussed below:</p>
16329 "The [standard iostream] objects are constructed, and their
16330 associations are established at some time prior to or during
16331 first time an object of class basic_ios<charT,traits>::Init
16332 is constructed, and in any case before the body of main
16333 begins execution." (27.3/2 [lib.iostream.objects])
16337 The first <i>non-normative</i> footnote encourages implementations
16338 to initialize standard iostream objects earlier than required.
16341 <p>However, the second <i>non-normative</i> footnote makes an explicit
16342 and unsupported claim:</p>
16345 "Constructors and destructors for static objects can access these
16346 [standard iostream] objects to read input from stdin or write output
16347 to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
16351 The only bit of magic is related to that ios_base::Init class. AFAIK,
16352 the rationale behind ios_base::Init was to bring an instance of this
16353 class to each translation unit which #included <iostream> or
16354 related header. Such an inclusion would support the claim of footnote
16355 quoted above, because in order to use some standard iostream object it
16356 is necessary to #include <iostream>.
16360 However, while Standard explicitly describes ios_base::Init as
16361 an appropriate class for doing the trick, I failed to found a
16362 mention of an _instance_ of ios_base::Init in Standard.
16366 <p><b>Proposed resolution:</b></p>
16368 <p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence
16369 of the paragraph, the following two sentences:</p>
16372 If a translation unit includes <iostream>, or explicitly
16373 constructs an ios_base::Init object, these stream objects shall
16374 be constructed before dynamic initialization of non-local
16375 objects defined later in that translation unit, and these stream
16376 objects shall be destroyed after the destruction of dynamically
16377 initialized non-local objects defined later in that translation unit.
16380 <p><i>[Lillehammer: Matt provided wording.]</i></p>
16382 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
16386 <p><b>Rationale:</b></p>
16388 The original proposed resolution unconditionally required
16389 implementations to define an ios_base::Init object of some
16390 implementation-defined name in the header <iostream>. That's an
16391 overspecification. First, defining the object may be unnecessary
16392 and even detrimental to performance if an implementation can
16393 guarantee that the 8 standard iostream objects will be initialized
16394 before any other user-defined object in a program. Second, there
16395 is no need to require implementations to document the name of the
16399 The new proposed resolution gives users guidance on what they need to
16400 do to ensure that stream objects are constructed during startup.</p>
16407 <h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
16408 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16409 <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</p>
16410 <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>
16411 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16412 <p><b>Discussion:</b></p>
16413 <p>Defect report for description of basic_istream::get (section
16414 27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
16416 with the following signature:</p>
16418 <pre> basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
16422 <p>is incorrect. It reads</p>
16425 Effects: Calls get(s,n,widen('\n'))
16428 <p>which I believe should be:</p>
16431 Effects: Calls get(sb,widen('\n'))
16435 <p><b>Proposed resolution:</b></p>
16436 <p>Change the <b>Effects</b> paragraph to:</p>
16438 Effects: Calls get(sb,this->widen('\n'))
16441 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
16442 with 'this->widen'.]</i></p>
16447 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16453 <h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
16454 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16455 <b>Submitter:</b> Frank Compagner <b>Date:</b> 2002-07-20</p>
16456 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
16457 <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>
16458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16459 <p><b>Discussion:</b></p>
16461 The requirements for multiset and multimap containers (23.1
16462 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
16463 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
16464 the stability of the required (mutating) member functions. It appears
16465 the standard allows these functions to reorder equivalent elements of
16466 the container at will, yet the pervasive red-black tree implementation
16467 appears to provide stable behaviour.
16470 <p>This is of most concern when considering the behaviour of erase().
16471 A stability requirement would guarantee the correct working of the
16472 following 'idiom' that removes elements based on a certain predicate
16476 <pre> multimap<int, int> m;
16477 multimap<int, int>::iterator i = m.begin();
16478 while (i != m.end()) {
16487 Although clause 23.1.2/8 guarantees that i remains a valid iterator
16488 througout this loop, absence of the stability requirement could
16489 potentially result in elements being skipped. This would make
16490 this code incorrect, and, furthermore, means that there is no way
16491 of erasing these elements without iterating first over the entire
16492 container, and second over the elements to be erased. This would
16493 be unfortunate, and have a negative impact on both performance and
16498 If the stability requirement is intended, it should be made explicit
16499 (probably through an extra paragraph in clause 23.1.2).
16502 If it turns out stability cannot be guaranteed, i'd argue that a
16503 remark or footnote is called for (also somewhere in clause 23.1.2) to
16504 warn against relying on stable behaviour (as demonstrated by the code
16505 above). If most implementations will display stable behaviour, any
16506 problems emerging on an implementation without stable behaviour will
16507 be hard to track down by users. This would also make the need for an
16508 erase_if() member function that much greater.
16511 <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>
16515 <p><b>Proposed resolution:</b></p>
16517 <p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4:
16518 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
16519 are <i>stable</i>: they preserve the relative ordering of equivalent
16522 <p><i>[Lillehammer: Matt provided wording]</i></p>
16524 <p><i>[Joe Gottman points out that the provided wording does not address
16525 multimap and multiset. N1780 also addresses this issue and suggests
16529 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
16534 <p><b>Rationale:</b></p>
16535 <p>The LWG agrees that this guarantee is necessary for common user
16536 idioms to work, and that all existing implementations provide this
16537 property. Note that this resolution guarantees stability for
16538 multimap and multiset, not for all associative containers in
16547 <h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</h3>
16548 <p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16549 <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p>
16550 <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>
16551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16552 <p><b>Discussion:</b></p>
16555 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
16556 (exception()&badbit) != 0 is used in testing for rethrow, yet
16557 exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
16558 exceptions() found in 27.4.4 [ios] be used instead?
16563 <p><b>Proposed resolution:</b></p>
16565 In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
16566 "(exception()&badbit) != 0" to "(exceptions()&badbit) != 0".
16570 <p><b>Rationale:</b></p>
16571 <p>Fixes an obvious typo.</p>
16578 <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
16579 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16580 <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16581 <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>
16582 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16583 <p><b>Discussion:</b></p>
16585 In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
16586 14 all contain references to "basic_ios::" which should be
16591 <p><b>Proposed resolution:</b></p>
16593 Change all references to "basic_ios" in Table 90, Table 91, and
16594 paragraph 14 to "ios_base".
16598 <p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
16604 <h3><a name="376"></a>376. basic_streambuf semantics</h3>
16605 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16606 <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
16607 <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>
16608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16609 <p><b>Discussion:</b></p>
16611 In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
16612 the four conditions should be mutually exclusive, but they are not.
16613 The first two cases, as written, are subcases of the third.</p>
16616 As written, it is unclear what should be the result if cases 1 and 2
16617 are both true, but case 3 is false.
16622 <p><b>Proposed resolution:</b></p>
16624 <p>Rewrite these conditions as:</p>
16627 (which & (ios_base::in|ios_base::out)) == ios_base::in
16631 (which & (ios_base::in|ios_base::out)) == ios_base::out
16635 (which & (ios_base::in|ios_base::out)) ==
16636 (ios_base::in|ios_base::out)
16637 and way == either ios_base::beg or ios_base::end
16645 <p><b>Rationale:</b></p>
16646 <p>It's clear what we wanted to say, we just failed to say it. This
16654 <h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
16655 <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16656 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16657 <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>
16658 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16659 <p><b>Discussion:</b></p>
16661 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
16663 <pre> charT do_widen (char c) const;
16665 -11- Effects: Applies the simplest reasonable transformation from
16666 a char value or sequence of char values to the corresponding
16667 charT value or values. The only characters for which unique
16668 transformations are required are those in the basic source
16669 character set (2.2). For any named ctype category with a
16670 ctype<charT> facet ctw and valid ctype_base::mask value
16671 M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
16674 Shouldn't the last sentence instead read
16676 <pre> For any named ctype category with a ctype<char> facet ctc
16677 and valid ctype_base::mask value M
16678 (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16681 I.e., if the narrow character c is not a member of a class of
16682 characters then neither is the widened form of c. (To paraphrase
16687 <p><b>Proposed resolution:</b></p>
16689 Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
16692 <pre> For any named ctype category with a ctype<char> facet ctc
16693 and valid ctype_base::mask value M,
16694 (ctc.is(M, c) || !is(M, do_widen(c))) is true.
16697 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
16702 <p><b>Rationale:</b></p>
16703 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
16710 <h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
16711 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16712 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16713 <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>
16714 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16715 <p><b>Discussion:</b></p>
16717 Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
16718 result values," when surely "do_in/do_out result values" must have
16719 been intended for Table 53 and "do_unshift result values" for Table
16723 Table 54, row 3 says that the meaning of partial is "more characters
16724 needed to be supplied to complete termination." The function is not
16725 supplied any characters, it is given a buffer which it fills with
16726 characters or, more precisely, destination elements (i.e., an escape
16727 sequence). So partial means that space for more than (to_limit - to)
16728 destination elements was needed to terminate a sequence given the
16733 <p><b>Proposed resolution:</b></p>
16735 Change the title of Table 53 to "do_in/do_out result values" and
16736 the title of Table 54 to "do_unshift result values."
16739 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
16740 heading Meaning, to "space for more than (to_limit - to) destination
16741 elements was needed to terminate a sequence given the value of state."
16748 <h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
16749 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16750 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
16751 <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>
16752 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16753 <p><b>Discussion:</b></p>
16755 All but one codecvt member functions that take a state_type argument
16756 list as one of their preconditions that the state_type argument have
16757 a valid value. However, according to 22.2.1.5.2, p6,
16758 codecvt::do_unshift() is the only codecvt member that is supposed to
16759 return error if the state_type object is invalid.
16763 It seems to me that the treatment of state_type by all codecvt member
16764 functions should be the same and the current requirements should be
16765 changed. Since the detection of invalid state_type values may be
16766 difficult in general or computationally expensive in some specific
16767 cases, I propose the following:
16771 <p><b>Proposed resolution:</b></p>
16773 Add a new paragraph before 22.2.1.5.2, p5, and after the function
16776 <pre> result do_unshift(stateT& state,
16777 externT* to, externT* to_limit, externT*& to_next) const;
16782 <pre> Requires: (to <= to_end) well defined and true; state initialized,
16783 if at the beginning of a sequence, or else equal to the result of
16784 converting the preceding characters in the sequence.
16787 and change the text in Table 54, row 4, the <b>error</b> row, under
16788 the heading Meaning, from
16790 <pre> state has invalid value
16795 <pre> an unspecified error has occurred
16799 <p><b>Rationale:</b></p>
16800 <p>The intent is that implementations should not be required to detect
16801 invalid state values; such a requirement appears nowhere else. An
16802 invalid state value is a precondition violation, <i>i.e.</i> undefined
16803 behavior. Implementations that do choose to detect invalid state
16804 values, or that choose to detect any other kind of error, may return
16805 <b>error</b> as an indication.</p>
16812 <h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
16813 <p><b>Section:</b> 24.1.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16814 <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</p>
16815 <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>
16816 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16817 <p><b>Discussion:</b></p>
16819 Following a discussion on the boost list regarding end iterators and
16820 the possibility of performing operator--() on them, it seems to me
16821 that there is a typo in the standard. This typo has nothing to do
16822 with that discussion.
16826 I have checked this newsgroup, as well as attempted a search of the
16827 Active/Defect/Closed Issues List on the site for the words "s is
16828 derefer" so I believe this has not been proposed before. Furthermore,
16829 the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
16830 24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
16834 The standard makes the following assertion on bidirectional iterators,
16835 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
16838 <pre> operational assertion/note
16839 expression return type semantics pre/post-condition
16841 --r X& pre: there exists s such
16843 post: s is dereferenceable.
16845 --r == --s implies r == s.
16846 &r == &--r.
16850 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
16854 In particular, "s is dereferenceable" seems to be in error. It seems
16855 that the intention was to say "r is dereferenceable".
16859 If it were to say "r is dereferenceable" it would
16860 make perfect sense. Since s must be dereferenceable prior to
16861 operator++, then the natural result of operator-- (to undo operator++)
16862 would be to make r dereferenceable. Furthermore, without other
16863 assertions, and basing only on precondition and postconditions, we
16864 could not otherwise know this. So it is also interesting information.
16869 <p><b>Proposed resolution:</b></p>
16871 Change the guarantee to "postcondition: r is dereferenceable."
16875 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
16881 <h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
16882 <p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
16883 <b>Submitter:</b> Hans Bos <b>Date:</b> 2002-10-18</p>
16884 <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>
16885 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
16886 <p><b>Discussion:</b></p>
16888 Section 25.3.3.3 [equal.range]
16889 states that at most 2 * log(last - first) + 1
16890 comparisons are allowed for equal_range.
16893 <p>It is not possible to implement equal_range with these constraints.</p>
16895 <p>In a range of one element as in:</p>
16897 equal_range(&x, &x + 1, 1)
16900 <p>it is easy to see that at least 2 comparison operations are needed.</p>
16902 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
16904 <p>I have checked a few libraries and they all use the same (nonconforming)
16905 algorithm for equal_range that has a complexity of</p>
16906 <pre> 2* log(distance(first, last)) + 2.
16908 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
16911 It is easy to see that 2 * log(distance) + 2 comparisons are enough
16912 since equal range can be implemented with lower_bound and upper_bound
16913 (both log(distance) + 1).
16917 I think it is better to require something like 2log(distance) + O(1) (or
16918 even logarithmic as multiset::equal_range).
16919 Then an implementation has more room to optimize for certain cases (e.g.
16920 have log(distance) characteristics when at most match is found in the range
16921 but 2log(distance) + 4 for the worst case).
16926 <p><b>Proposed resolution:</b></p>
16927 <p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
16928 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16930 <p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
16931 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16933 <p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
16934 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
16936 <p><i>[Matt provided wording]</i></p>
16940 <p><b>Rationale:</b></p>
16941 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
16942 decided that threw away too much valuable information. The fact
16943 that lower_bound is twice as fast as equal_range is important.
16944 However, it's better to allow an arbitrary additive constant than to
16945 specify an exact count. An exact count would have to
16946 involve <tt>floor</tt> or <tt>ceil</tt>. It would be too easy to
16947 get this wrong, and don't provide any substantial value for users.</p>
16953 <h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
16954 <p><b>Section:</b> 24.4.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
16955 <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
16956 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
16957 <p><b>Discussion:</b></p>
16958 <p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator<>::operator[]</tt>
16959 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
16960 which is the same as <tt>iterator_traits<Iterator>::reference</tt>.
16961 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
16963 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
16964 necessarily have a return type
16965 of <tt>iterator_traits<Iterator>::reference</tt>. Its
16966 return type is merely required to be convertible
16967 to <tt>Iterator</tt>'s value type. The return type specified for
16968 reverse_iterator's operator[] would thus appear to be impossible.</p>
16970 <p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
16971 <tt>a[n]</tt> will continue to be required (for random access
16972 iterators) to be convertible to the value type, and also <tt>a[n] =
16973 t</tt> will be a valid expression. Implementations of
16974 <tt>reverse_iterator</tt> will likely need to return a proxy from
16975 <tt>operator[]</tt> to meet these requirements. As mentioned in the
16976 comment from Dave Abrahams, the simplest way to specify that
16977 <tt>reverse_iterator</tt> meet this requirement to just mandate
16978 it and leave the return type of <tt>operator[]</tt> unspecified.</p>
16982 <p><b>Proposed resolution:</b></p>
16984 <p>In 24.4.1.2 [reverse.iter.requirements] change:</p>
16987 <pre>reference operator[](difference_type n) const;
16994 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
17002 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
17003 that the return type of reverse_iterator's operator[] is
17004 unspecified, allowing the random access iterator requirements to
17005 impose an appropriate return type. If we accept 299's proposed
17006 resolution (and I think we should), the return type will be
17007 readable and writable, which is about as good as we can do.
17016 <h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
17017 <p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17018 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
17019 <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>
17020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17021 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
17022 <p><b>Discussion:</b></p>
17023 <p>Consider the following program:</p>
17024 <pre> #include <iostream>
17025 #include <ostream>
17026 #include <vector>
17027 #include <valarray>
17028 #include <algorithm>
17029 #include <iterator>
17030 template<typename Array>
17031 void print(const Array& a)
17033 using namespace std;
17034 typedef typename Array::value_type T;
17035 copy(&a[0], &a[0] + a.size(),
17036 ostream_iterator<T>(std::cout, " "));
17038 template<typename T, unsigned N>
17039 unsigned size(T(&)[N]) { return N; }
17042 double array[] = { 0.89, 9.3, 7, 6.23 };
17043 std::vector<double> v(array, array + size(array));
17044 std::valarray<double> w(array, size(array));
17046 std::cout << std::endl;
17048 std::cout << std::endl;
17052 <p>While the call numbered #1 succeeds, the call numbered #2 fails
17053 because the const version of the member function
17054 valarray<T>::operator[](size_t) returns a value instead of a
17055 const-reference. That seems to be so for no apparent reason, no
17056 benefit. Not only does that defeats users' expectation but it also
17057 does hinder existing software (written either in C or Fortran)
17058 integration within programs written in C++. There is no reason why
17059 subscripting an expression of type valarray<T> that is const-qualified
17060 should not return a const T&.</p>
17063 <p><b>Proposed resolution:</b></p>
17064 <p>In the class synopsis in 26.5.2 [template.valarray], and in
17065 26.5.2.3 [valarray.access] just above paragraph 1, change</p>
17066 <pre> T operator[](size_t const);
17069 <pre> const T& operator[](size_t const);
17072 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
17073 wehre it belongs.]</i></p>
17078 <p><b>Rationale:</b></p>
17079 <p>Return by value seems to serve no purpose. Valaray was explicitly
17080 designed to have a specified layout so that it could easily be
17081 integrated with libraries in other languages, and return by value
17082 defeats that purpose. It is believed that this change will have no
17083 impact on allowable optimizations.</p>
17090 <h3><a name="391"></a>391. non-member functions specified as const</h3>
17091 <p><b>Section:</b> 22.1.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17092 <b>Submitter:</b> James Kanze <b>Date:</b> 2002-12-10</p>
17093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17094 <p><b>Discussion:</b></p>
17096 The specifications of toupper and tolower both specify the functions as
17097 const, althought they are not member functions, and are not specified as
17098 const in the header file synopsis in section 22.1 [locales].
17102 <p><b>Proposed resolution:</b></p>
17103 <p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function
17104 declarations of std::toupper and std::tolower</p>
17107 <p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
17113 <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
17114 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17115 <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
17116 <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>
17117 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17118 <p><b>Discussion:</b></p>
17120 In 26.7 [c.math], the C++ standard refers to the C standard for the
17121 definition of rand(); in the C standard, it is written that "The
17122 implementation shall behave as if no library function calls the rand
17127 In 25.2.12 [alg.random.shuffle], there is no specification as to
17128 how the two parameter version of the function generates its random
17129 value. I believe that all current implementations in fact call rand()
17130 (in contradiction with the requirement avove); if an implementation does
17131 not call rand(), there is the question of how whatever random generator
17132 it does use is seeded. Something is missing.
17137 <p><b>Proposed resolution:</b></p>
17139 In [lib.c.math], add a paragraph specifying that the C definition of
17140 rand shal be modified to say that "Unless otherwise specified, the
17141 implementation shall behave as if no library function calls the rand
17146 In [lib.alg.random.shuffle], add a sentence to the effect that "In
17147 the two argument form of the function, the underlying source of
17148 random numbers is implementation defined. [Note: in particular, an
17149 implementation is permitted to use <tt>rand</tt>.]
17153 <p><b>Rationale:</b></p>
17154 <p>The original proposed resolution proposed requiring the
17155 two-argument from of <tt>random_shuffle</tt> to
17156 use <tt>rand</tt>. We don't want to do that, because some existing
17157 implementations already use something else: gcc
17158 uses <tt>lrand48</tt>, for example. Using <tt>rand</tt> presents a
17159 problem if the number of elements in the sequence is greater than
17167 <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
17168 <p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17169 <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17170 <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>
17171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17172 <p><b>Discussion:</b></p>
17174 20.7.5.1 [allocator.members] allocator members, contains
17175 the following 3 lines:
17178 <pre> 12 Returns: new((void *) p) T( val)
17179 void destroy(pointer p);
17180 13 Returns: ((T*) p)->~T()
17184 The type cast "(T*) p" in the last line is redundant cause
17185 we know that std::allocator<T>::pointer is a typedef for T*.
17189 <p><b>Proposed resolution:</b></p>
17191 Replace "((T*) p)" with "p".
17195 <p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
17201 <h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</h3>
17202 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17203 <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17204 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
17205 <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>
17206 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17207 <p><b>Discussion:</b></p>
17209 I think that in par2 of [default.con.req] the last two
17210 lines of table 32 contain two incorrect type casts. The lines are ...
17213 <pre> a.construct(p,t) Effect: new((void*)p) T(t)
17214 a.destroy(p) Effect: ((T*)p)?->~T()
17218 .... with the prerequisits coming from the preceding two paragraphs, especially
17222 <pre> alloc<T> a ;// an allocator for T
17223 alloc<T>::pointer p ;// random access iterator
17224 // (may be different from T*)
17225 alloc<T>::reference r = *p;// T&
17230 For that two type casts ("(void*)p" and "(T*)p") to be well-formed
17231 this would require then conversions to T* and void* for all
17232 alloc<T>::pointer, so it would implicitely introduce extra
17233 requirements for alloc<T>::pointer, additionally to the only
17234 current requirement (being a random access iterator).
17238 <p><b>Proposed resolution:</b></p>
17241 Accept proposed wording from
17242 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
17246 Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with
17247 "p?->dtor_name", but AFAICS this is not possible cause of an omission
17248 in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
17251 <p><i>[Kona: The LWG thinks this is somewhere on the border between
17252 Open and NAD. The intend is clear: <tt>construct</tt> constructs an
17253 object at the location <i>p</i>. It's reading too much into the
17254 description to think that literally calling <tt>new</tt> is
17255 required. Tweaking this description is low priority until we can do
17256 a thorough review of allocators, and, in particular, allocators with
17257 non-default pointer types.]</i></p>
17261 Batavia: Proposed resolution changed to less code and more description.
17266 post Oxford: This would be rendered NAD Editorial by acceptance of
17267 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
17272 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
17273 was subsequently split out into a separate paper N2436 for the purposes of voting.
17274 The resolution in N2436 addresses this issue. The LWG voted to accelerate this
17275 issue to Ready status to be voted into the WP at Kona.
17285 <h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
17286 <p><b>Section:</b> 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17287 <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
17288 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
17289 <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>
17290 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17291 <p><b>Discussion:</b></p>
17293 This applies to the new expression that is contained in both par12 of
17294 20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req].
17295 I think this new expression is wrong, involving unintended side
17300 <p>20.7.5.1 [allocator.members] contains the following 3 lines:</p>
17302 <pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed.
17303 void construct(pointer p, const_reference val);
17304 12 Returns: new((void *) p) T( val)
17308 <p> [default.con.req] in table 32 has the following line:</p>
17309 <pre> a.construct(p,t) Effect: new((void*)p) T(t)
17313 .... with the prerequisits coming from the preceding two paragraphs,
17314 especially from table 31:
17317 <pre> alloc<T> a ;// an allocator for T
17318 alloc<T>::pointer p ;// random access iterator
17319 // (may be different from T*)
17320 alloc<T>::reference r = *p;// T&
17325 Cause of using "new" but not "::new", any existing "T::operator new"
17326 function will hide the global placement new function. When there is no
17327 "T::operator new" with adequate signature,
17328 every_alloc<T>::construct(..) is ill-formed, and most
17329 std::container<T,every_alloc<T>> use it; a workaround
17330 would be adding placement new and delete functions with adequate
17331 signature and semantic to class T, but class T might come from another
17332 party. Maybe even worse is the case when T has placement new and
17333 delete functions with adequate signature but with "unknown" semantic:
17334 I dont like to speculate about it, but whoever implements
17335 any_container<T,any_alloc> and wants to use construct(..)
17336 probably must think about it.
17340 <p><b>Proposed resolution:</b></p>
17342 Replace "new" with "::new" in both cases.
17352 <h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
17353 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17354 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2003-03-25</p>
17355 <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>
17356 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17357 <p><b>Discussion:</b></p>
17360 std::basic_string, 21.3 [basic.string] paragraph 2 says that
17361 basic_string "conforms to the requirements of a Sequence, as specified
17362 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
17363 include any prohibition on swap members throwing exceptions.
17367 Section 23.1 [container.requirements] paragraph 10 does limit conditions under
17368 which exceptions may be thrown, but applies only to "all container
17369 types defined in this clause" and so excludes basic_string::swap
17370 because it is defined elsewhere.
17374 Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
17375 permits basic_string::swap to invalidates iterators, which is
17376 disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
17377 be contradictory if it were read or extended to read as having
17378 basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
17382 Yet several LWG members have expressed the belief that the original
17383 intent was that basic_string::swap should not throw exceptions as
17384 specified by 23.1 [container.requirements] paragraph 10, and that the standard is
17385 unclear on this issue. The complexity of basic_string::swap is
17386 specified as "constant time", indicating the intent was to avoid
17387 copying (which could cause a bad_alloc or other exception). An
17388 important use of swap is to ensure that exceptions are not thrown in
17389 exception-safe code.
17393 Note: There remains long standing concern over whether or not it is
17394 possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
17395 requirements when allocators are unequal. The specification of
17396 basic_string::swap exception requirements is in no way intended to
17397 address, prejudice, or otherwise impact that concern.
17406 <p><b>Proposed resolution:</b></p>
17408 In 21.3.6.8 [string::swap], add a throws clause:
17412 Throws: Shall not throw exceptions.
17420 <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
17421 <p><b>Section:</b> 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17422 <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p>
17423 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17424 <p><b>Discussion:</b></p>
17426 The eight basic dynamic memory allocation functions (single-object
17427 and array versions of ::operator new and ::operator delete, in the
17428 ordinary and nothrow forms) are replaceable. A C++ program may
17429 provide an alternative definition for any of them, which will be used
17430 in preference to the implementation's definition.
17434 Three different parts of the standard mention requirements on
17435 replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single]
17436 and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
17439 <p>None of these three places say whether a replacement function may
17440 be declared inline. 18.5.1.1 [new.delete.single] paragraph 2 specifies a
17441 signature for the replacement function, but that's not enough:
17442 the <tt>inline</tt> specifier is not part of a function's signature.
17443 One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
17444 requires that "an inline function shall be defined in every
17445 translation unit in which it is used," but this may not be quite
17446 specific enough either. We should either explicitly allow or
17447 explicitly forbid inline replacement memory allocation
17451 <p><b>Proposed resolution:</b></p>
17453 Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
17454 "The program's definitions shall not be specified as <tt>inline</tt>.
17455 No diagnostic is required."
17458 <p><i>[Kona: added "no diagnostic is required"]</i></p>
17463 <p><b>Rationale:</b></p>
17465 The fact that <tt>inline</tt> isn't mentioned appears to have been
17466 nothing more than an oversight. Existing implementations do not
17467 permit inline functions as replacement memory allocation functions.
17468 Providing this functionality would be difficult in some cases, and is
17469 believed to be of limited value.
17477 <h3><a name="405"></a>405. qsort and POD</h3>
17478 <p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17479 <b>Submitter:</b> Ray Lischner <b>Date:</b> 2003-04-08</p>
17480 <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>
17481 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17482 <p><b>Discussion:</b></p>
17484 Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
17485 standard library. Paragraph 4 does not list any restrictions on qsort,
17486 but it should limit the base parameter to point to POD. Presumably,
17487 qsort sorts the array by copying bytes, which requires POD.
17491 <p><b>Proposed resolution:</b></p>
17493 In 25.4 [alg.c.library] paragraph 4, just after the declarations and
17494 before the nonnormative note, add these words: "both of which have the
17495 same behavior as the original declaration. The behavior is undefined
17496 unless the objects in the array pointed to by <i>base</i> are of POD
17500 <p><i>[Something along these lines is clearly necessary. Matt
17501 provided wording.]</i></p>
17509 <h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
17510 <p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17511 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p>
17512 <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>
17513 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17514 <p><b>Discussion:</b></p>
17516 There is a possible defect in the standard: the standard text was
17517 never intended to prevent arbitrary ForwardIterators, whose operations
17518 may throw exceptions, from being passed, and it also wasn't intended
17519 to require a temporary buffer in the case where ForwardIterators were
17520 passed (and I think most implementations don't use one). As is, the
17521 standard appears to impose requirements that aren't met by any
17522 existing implementation.
17526 <p><b>Proposed resolution:</b></p>
17527 <p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p>
17529 1- Notes: Causes reallocation if the new size is greater than the
17530 old capacity. If no reallocation happens, all the iterators and
17531 references before the insertion point remain valid. If an exception
17532 is thrown other than by the copy constructor or assignment operator
17533 of T or by any InputIterator operation there are no effects.
17536 <p><i>[We probably need to say something similar for deque.]</i></p>
17545 <h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
17546 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17547 <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17548 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
17549 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
17550 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17551 <p><b>Discussion:</b></p>
17553 Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
17554 that is defined for a singular iterator is "an assignment of a
17555 non-singular value to an iterator that holds a singular value". This
17556 means that destroying a singular iterator (e.g. letting an automatic
17557 variable go out of scope) is technically undefined behavior. This
17558 seems overly strict, and probably unintentional.
17562 <p><b>Proposed resolution:</b></p>
17564 Change the sentence in question to "... the only exceptions are
17565 destroying an iterator that holds a singular value, or the assignment
17566 of a non-singular value to an iterator that holds a singular value."
17574 <h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
17575 <p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17576 <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
17577 <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>
17578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17579 <p><b>Discussion:</b></p>
17581 A strict reading of 27.8.1 [fstreams] shows that opening or
17582 closing a basic_[io]fstream does not affect the error bits. This
17583 means, for example, that if you read through a file up to EOF, and
17584 then close the stream and reopen it at the beginning of the file,
17585 the EOF bit in the stream's error state is still set. This is
17589 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>,
17590 and put in a footnote to clarify that the strict reading was indeed
17591 correct. We did that because we believed the standard was
17592 unambiguous and consistent, and that we should not make architectural
17593 changes in a TC. Now that we're working on a new revision of the
17594 language, those considerations no longer apply.
17598 <p><b>Proposed resolution:</b></p>
17600 <p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p>
17603 Calls rdbuf()->open(s,mode|in). If that function returns a null
17604 pointer, calls setstate(failbit) (which may throw ios_base::failure
17605 [Footnote: (lib.iostate.flags)].
17610 <blockquote><p>Calls rdbuf()->open(s,mode|in). If that function
17611 returns a null pointer, calls setstate(failbit) (which may throw
17612 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17615 <p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p>
17617 <blockquote><p>Calls rdbuf()->open(s,mode|out). If that function
17618 returns a null pointer, calls setstate(failbit) (which may throw
17619 ios_base::failure [Footnote: (lib.iostate.flags)).
17624 <blockquote><p>Calls rdbuf()->open(s,mode|out). If that function
17625 returns a null pointer, calls setstate(failbit) (which may throw
17626 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
17629 <p>Change 27.8.1.17 [fstream.members], para. 3 from:</p>
17631 <blockquote><p>Calls rdbuf()->open(s,mode), If that function returns
17632 a null pointer, calls setstate(failbit), (which may throw
17633 ios_base::failure). (lib.iostate.flags) )
17638 <blockquote><p>Calls rdbuf()->open(s,mode), If that function returns
17639 a null pointer, calls setstate(failbit), (which may throw
17640 ios_base::failure). (lib.iostate.flags) ), else calls clear().
17645 <p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill
17646 provided wording. He suggests having open, not close, clear the error
17650 <p><i>[Post-Sydney: Howard provided a new proposed resolution. The
17651 old one didn't make sense because it proposed to fix this at the
17652 level of basic_filebuf, which doesn't have access to the stream's
17653 error state. Howard's proposed resolution fixes this at the level
17654 of the three fstream class template instead.]</i></p>
17664 <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
17665 <p><b>Section:</b> 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17666 <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p>
17667 <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>
17668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17669 <p><b>Discussion:</b></p>
17671 Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
17672 comparison operators (==, !=, <, <=, >, =>) for queue and
17673 stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons]
17678 <p><b>Proposed resolution:</b></p>
17680 <p>Add the following new paragraphs after 23.2.4.1 [list.cons]
17687 <p>Returns: <tt>x.c != y.c</tt></p>
17691 <p>Returns: <tt>x.c > y.c</tt></p>
17693 <pre> operator<=
17695 <p>Returns: <tt>x.c <= y.c</tt></p>
17697 <pre> operator>=
17699 <p>Returns: <tt>x.c >= y.c</tt></p>
17703 <p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p>
17709 <p>Returns: <tt>x.c == y.c</tt></p>
17713 <p>Returns: <tt>x.c < y.c</tt></p>
17717 <p>Returns: <tt>x.c != y.c</tt></p>
17721 <p>Returns: <tt>x.c > y.c</tt></p>
17723 <pre> operator<=
17725 <p>Returns: <tt>x.c <= y.c</tt></p>
17727 <pre> operator>=
17729 <p>Returns: <tt>x.c >= y.c</tt></p>
17734 <p><i>[Kona: Matt provided wording.]</i></p>
17739 <p><b>Rationale:</b></p>
17740 <p>There isn't any real doubt about what these operators are
17741 supposed to do, but we ought to spell it out.</p>
17748 <h3><a name="411"></a>411. Wrong names of set member functions</h3>
17749 <p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17750 <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p>
17751 <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>
17752 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17753 <p><b>Discussion:</b></p>
17755 25.3.5 [alg.set.operations] paragraph 1 reads:
17756 "The semantics of the set operations are generalized to multisets in a
17757 standard way by defining union() to contain the maximum number of
17758 occurrences of every element, intersection() to contain the minimum, and
17763 This is wrong. The name of the functions are set_union() and
17764 set_intersection(), not union() and intersection().
17768 <p><b>Proposed resolution:</b></p>
17769 <p>Change that sentence to use the correct names.</p>
17776 <h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
17777 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17778 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p>
17779 <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>
17780 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17781 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
17782 <p><b>Discussion:</b></p>
17784 The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
17785 function only throws if the respective bits are already set prior to
17786 the function call. That's obviously not the intent. The typo ought to
17787 be corrected and the text reworded as: "If (<i>state</i> &
17788 exceptions()) == 0, returns. ..."
17792 <p><b>Proposed resolution:</b></p>
17794 In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &
17795 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
17796 & exceptions()) == 0".
17799 <p><i>[Kona: the original proposed resolution wasn't quite right. We
17800 really do mean rdstate(); the ambiguity is that the wording in the
17801 standard doesn't make it clear whether we mean rdstate() before
17802 setting the new state, or rdsate() after setting it. We intend the
17803 latter, of course. Post-Kona: Martin provided wording.]</i></p>
17812 <h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
17813 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
17814 <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p>
17815 <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>
17816 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
17817 <p><b>Discussion:</b></p>
17819 The second sentence of the proposed resolution says:
17823 "If it inserted no characters because it caught an exception thrown
17824 while extracting characters from sb and ..."
17828 However, we are not extracting from sb, but extracting from the
17829 basic_istream (*this) and inserting into sb. I can't really tell if
17830 "extracting" or "sb" is a typo.
17834 Sydney: Definitely a real issue. We are, indeed, extracting characters
17835 from an istream and not from sb. The problem was there in the FDIS and
17836 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
17837 to have *this instead of sb. We're talking about the exception flag
17838 state of a basic_istream object, and there's only one basic_istream
17839 object in this discussion, so that would be a consistent
17840 interpretation. (But we need to be careful: the exception policy of
17841 this member function must be consistent with that of other
17842 extractors.) PJP will provide wording.
17848 <p><b>Proposed resolution:</b></p>
17849 <p>Change the sentence from:</p>
17852 If it inserted no characters because it caught an exception thrown
17853 while extracting characters from sb and failbit is on in exceptions(),
17854 then the caught exception is rethrown.
17860 If it inserted no characters because it caught an exception thrown
17861 while extracting characters from *this and failbit is on in exceptions(),
17862 then the caught exception is rethrown.
17870 <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
17871 <p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17872 <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p>
17873 <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>
17874 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17875 <p><b>Discussion:</b></p>
17877 Consider the following code fragment:
17880 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
17881 std::vector<int> v(A, A+8);
17883 std::vector<int>::iterator i1 = v.begin() + 3;
17884 std::vector<int>::iterator i2 = v.begin() + 4;
17890 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
17895 On all existing implementations that I know of, the status of i1 and
17896 i2 is the same: both of them will be iterators that point to some
17897 elements of the vector (albeit not the same elements they did
17898 before). You won't get a crash if you use them. Depending on
17899 exactly what you mean by "invalidate", you might say that neither one
17900 has been invalidated because they still point to <i>something</i>,
17901 or you might say that both have been invalidated because in both
17902 cases the elements they point to have been changed out from under the
17907 The standard doesn't say either of those things. It says that erase
17908 invalidates all iterators and references "after the point of the
17909 erase". This doesn't include i1, since it's at the point of the
17910 erase instead of after it. I can't think of any sensible definition
17911 of invalidation by which one can say that i2 is invalidated but i1
17916 (This issue is important if you try to reason about iterator validity
17917 based only on the guarantees in the standard, rather than reasoning
17918 from typical implementation techniques. Strict debugging modes,
17919 which some programmers find useful, do not use typical implementation
17924 <p><b>Proposed resolution:</b></p>
17926 In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
17927 iterators and references after the point of the erase" to
17928 "Invalidates iterators and references at or after the point of the
17933 <p><b>Rationale:</b></p>
17934 <p>I believe this was essentially a typographical error, and that it
17935 was taken for granted that erasing an element invalidates iterators
17936 that point to it. The effects clause in question treats iterators
17937 and references in parallel, and it would seem counterintuitive to
17938 say that a reference to an erased value remains valid.</p>
17945 <h3><a name="415"></a>415. behavior of std::ws</h3>
17946 <p><b>Section:</b> 27.6.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17947 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17949 <p><b>Discussion:</b></p>
17951 According to 27.6.1.4, the ws() manipulator is not required to construct
17952 the sentry object. The manipulator is also not a member function so the
17953 text in 27.6.1, p1 through 4 that describes the exception policy for
17954 istream member functions does not apply. That seems inconsistent with
17955 the rest of extractors and all the other input functions (i.e., ws will
17956 not cause a tied stream to be flushed before extraction, it doesn't check
17957 the stream's exceptions or catch exceptions thrown during input, and it
17958 doesn't affect the stream's gcount).
17962 <p><b>Proposed resolution:</b></p>
17964 Add to 27.6.1.4 [istream.manip], immediately before the first sentence
17965 of paragraph 1, the following text:
17969 Behaves as an unformatted input function (as described in
17970 27.6.1.3, paragraph 1), except that it does not count the number
17971 of characters extracted and does not affect the value returned by
17972 subsequent calls to is.gcount(). After constructing a sentry
17976 <p><i>[Post-Kona: Martin provided wording]</i></p>
17984 <h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
17985 <p><b>Section:</b> 18.2.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
17986 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
17987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
17988 <p><b>Discussion:</b></p>
17991 Given two overloads of the function foo(), one taking an argument of type
17992 int and the other taking a long, which one will the call foo(LONG_MAX)
17993 resolve to? The expected answer should be foo(long), but whether that
17994 is true depends on the #defintion of the LONG_MAX macro, specifically
17995 its type. This issue is about the fact that the type of these macros
17996 is not actually required to be the same as the the type each respective
18000 Section 18.2.2 of the C++ Standard does not specify the exact types of
18001 the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h>
18002 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
18005 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
18006 these constants] shall be replaced by constant expressions suitable for use
18007 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
18008 the following shall be replaced by expressions that have the same type as
18009 would an expression that is an object of the corresponding type converted
18010 according to the integer promotions."
18013 The "corresponding type converted according to the integer promotions" for
18014 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
18015 converted to the first of the following set of types that can represent it:
18016 int, long int, long long int. So on an implementation where (sizeof(long)
18017 == sizeof(int)) this type is actually int, while on an implementation where
18018 (sizeof(long) > sizeof(int)) holds this type will be long.
18021 This is not an issue in C since the type of the macro cannot be detected
18022 by any conforming C program, but it presents a portability problem in C++
18023 where the actual type is easily detectable by overload resolution.
18026 <p><i>[Kona: the LWG does not believe this is a defect. The C macro
18027 definitions are what they are; we've got a better
18028 mechanism, <tt>std::numeric_limits</tt>, that is specified more
18029 precisely than the C limit macros. At most we should add a
18030 nonnormative note recommending that users who care about the exact
18031 types of limit quantities should use <limits> instead of
18032 <climits>.]</i></p>
18037 <p><b>Proposed resolution:</b></p>
18040 Change 18.2.2 [c.limits], paragraph 2:
18044 -2- The contents are the same as the Standard C library header <tt><limits.h></tt>.
18045 <ins>[<i>Note:</i> The types of the macros in <tt><climits></tt> are not guaranteed
18046 to match the type to which they refer.<i>--end note</i>]</ins>
18054 <h3><a name="420"></a>420. is std::FILE a complete type?</h3>
18055 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18056 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18057 <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>
18058 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18059 <p><b>Discussion:</b></p>
18061 7.19.1, p2, of C99 requires that the FILE type only be declared in
18062 <stdio.h>. None of the (implementation-defined) members of the
18063 struct is mentioned anywhere for obvious reasons.
18067 C++ says in 27.8.1, p2 that FILE is a type that's defined in <cstdio>. Is
18068 it really the intent that FILE be a complete type or is an implementation
18069 allowed to just declare it without providing a full definition?
18073 <p><b>Proposed resolution:</b></p>
18074 <p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change
18075 "defined" to "declared".</p>
18078 <p><b>Rationale:</b></p>
18079 <p>We don't want to impose any restrictions beyond what the C standard
18080 already says. We don't want to make anything implementation defined,
18081 because that imposes new requirements in implementations.</p>
18088 <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
18089 <p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18090 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18091 <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>
18092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18093 <p><b>Discussion:</b></p>
18095 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
18096 explicitly specialize members of standard templates on user-defined types.
18097 The answer to the question might have an impact where library requirements
18098 are given using the "as if" rule. I.e., if programs are allowed to specialize
18099 member functions they will be able to detect an implementation's strict
18100 conformance to Effects clauses that describe the behavior of the function
18101 in terms of the other member function (the one explicitly specialized by
18102 the program) by relying on the "as if" rule.
18106 <p><b>Proposed resolution:</b></p>
18109 Add the following sentence to 17.4.3.2 [reserved.names], p1:
18113 It is undefined for a C++ program to add declarations or definitions to
18114 namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
18115 program may add template specializations for any standard library template to
18116 namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
18117 template results in undefined behavior unless the declaration depends on a
18118 user-defined type of external linkage and unless the specialization meets the
18119 standard library requirements for the original template.<sup>168)</sup>
18120 <ins>A program has undefined behavior if it declares</ins>
18123 <li><ins>an explicit specialization of any member function of a standard
18124 library class template, or</ins></li>
18125 <li><ins>an explicit specialization of any member function template of a
18126 standard library class or class template, or</ins></li>
18127 <li><ins>an explicit or partial specialization of any member class
18128 template of a standard library class or class template.</ins></li>
18131 A program may explicitly instantiate any templates in the standard library only
18132 if the declaration depends on the name of a user-defined type of external
18133 linkage and the instantiation meets the standard library requirements for the
18137 <p><i>[Kona: straw poll was 6-1 that user programs should not be
18138 allowed to specialize individual member functions of standard
18139 library class templates, and that doing so invokes undefined
18140 behavior. Post-Kona: Martin provided wording.]</i></p>
18143 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
18144 to specialize individual member functions unless they specialize the
18145 whole class, but we're not sure these words say what we want them to;
18146 they could be read as prohibiting the specialization of any standard
18147 library class templates. We need to consult with CWG to make sure we
18148 use the right wording.]</i></p>
18156 <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
18157 <p><b>Section:</b> 20.7.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18158 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18160 <p><b>Discussion:</b></p>
18162 The standard is not clear about the requirements on the value returned from
18163 a call to get_temporary_buffer(0). In particular, it fails to specify whether
18164 the call should return a distinct pointer each time it is called (like
18165 operator new), or whether the value is unspecified (as if returned by
18166 malloc). The standard also fails to mention what the required behavior
18167 is when the argument is less than 0.
18171 <p><b>Proposed resolution:</b></p>
18172 <p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
18173 values if no storage can be obtained" to "...or a pair of 0 values if
18174 no storage can be obtained or if <i>n</i> <= 0."</p>
18175 <p><i>[Kona: Matt provided wording]</i></p>
18182 <h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
18183 <p><b>Section:</b> 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18184 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18185 <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>
18186 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18187 <p><b>Discussion:</b></p>
18189 The complexity requirements for these function templates are incorrect
18190 (or don't even make sense) for negative n:</p>
18192 <p>25.1.9, p7 (search_n):
18194 Complexity: At most (last1 - first1) * count applications
18195 of the corresponding predicate.</p>
18197 <p>25.2.5, p3 (fill_n):
18199 Complexity: Exactly last - first (or n) assignments.</p>
18201 <p>25.2.6, p3 (generate_n):
18203 Complexity: Exactly last - first (or n) assignments.</p>
18206 In addition, the Requirements or the Effects clauses for the latter two
18207 templates don't say anything about the behavior when n is negative.
18211 <p><b>Proposed resolution:</b></p>
18212 <p>Change 25.1.9, p7 to</p>
18215 Complexity: At most (last1 - first1) * count applications
18216 of the corresponding predicate if count is positive,
18220 <p>Change 25.2.5, p2 to</p>
18222 Effects: Assigns value through all the iterators in the range [first,
18223 last), or [first, first + n) if n is positive, none otherwise.
18226 <p>Change 25.2.5, p3 to:</p>
18228 Complexity: Exactly last - first (or n if n is positive,
18229 or 0 otherwise) assignments.
18234 to (notice the correction for the misspelled "through"):
18237 Effects: Invokes the function object genand assigns the return
18238 value of gen through all the iterators in the range [first, last),
18239 or [first, first + n) if n is positive, or [first, first)
18243 <p>Change 25.2.6, p3 to:</p>
18245 Complexity: Exactly last - first (or n if n is positive,
18246 or 0 otherwise) assignments.
18250 <p><b>Rationale:</b></p>
18251 <p>Informally, we want to say that whenever we see a negative number
18252 we treat it the same as if it were zero. We believe the above
18253 changes do that (although they may not be the minimal way of saying
18254 so). The LWG considered and rejected the alternative of saying that
18255 negative numbers are undefined behavior.</p>
18262 <h3><a name="428"></a>428. string::erase(iterator) validity</h3>
18263 <p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18264 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
18265 <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>
18266 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18267 <p><b>Discussion:</b></p>
18269 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
18270 that q must be a valid dereferenceable iterator into the sequence a.
18274 However, 21.3.5.5, p5 describing string::erase(p) only requires that
18275 p be a valid iterator.
18279 This may be interepreted as a relaxation of the general requirement,
18280 which is most likely not the intent.
18284 <p><b>Proposed resolution:</b></p>
18285 <p>Remove 21.3.6.5 [string::erase] paragraph 5.</p>
18288 <p><b>Rationale:</b></p>
18289 <p>The LWG considered two options: changing the string requirements to
18290 match the general container requirements, or just removing the
18291 erroneous string requirements altogether. The LWG chose the latter
18292 option, on the grounds that duplicating text always risks the
18293 possibility that it might be duplicated incorrectly.</p>
18300 <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
18301 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18302 <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p>
18303 <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>
18304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18305 <p><b>Discussion:</b></p>
18306 <p>27.7.1.3 par 8 says:</p>
18308 Notes: The function can make a write position available only if
18309 ( mode & ios_base::out) != 0. To make a write position
18310 available, the function reallocates (or initially allocates) an
18311 array object with a sufficient number of elements to hold the
18312 current array object (if any), plus one additional write position.
18313 If ( mode & ios_base::in) != 0, the function alters the read end
18314 pointer egptr() to point just past the new write position (as
18315 does the write end pointer epptr()).
18319 The sentences "plus one additional write position." and especially
18320 "(as does the write end pointer epptr())" COULD by interpreted
18321 (and is interpreted by at least my library vendor) as:
18325 post-condition: epptr() == pptr()+1
18329 This WOULD force sputc() to call the virtual overflow() each time.
18332 <p>The proposed change also affects Defect Report 169.</p>
18336 <p><b>Proposed resolution:</b></p>
18337 <p>27.7.1.1/2 Change:</p>
18340 2- Notes: The function allocates no array object.
18348 2- Postcondition: str() == "".
18357 -3- Effects: Constructs an object of class basic_stringbuf,
18358 initializing the base class with basic_streambuf()
18359 (lib.streambuf.cons), and initializing mode with which . Then copies
18360 the content of str into the basic_stringbuf underlying character
18361 sequence and initializes the input and output sequences according to
18362 which. If which & ios_base::out is true, initializes the output
18363 sequence with the underlying sequence. If which & ios_base::in is
18364 true, initializes the input sequence with the underlying sequence.
18372 -3- Effects: Constructs an object of class basic_stringbuf,
18373 initializing the base class with basic_streambuf()
18374 (lib.streambuf.cons), and initializing mode with which. Then copies
18375 the content of str into the basic_stringbuf underlying character
18376 sequence. If which & ios_base::out is true, initializes the output
18377 sequence such that pbase() points to the first underlying character,
18378 epptr() points one past the last underlying character, and if (which &
18379 ios_base::ate) is true, pptr() is set equal to
18380 epptr() else pptr() is set equal to pbase(). If which & ios_base::in
18381 is true, initializes the input sequence such that eback() and gptr()
18382 point to the first underlying character and egptr() points one past
18383 the last underlying character.
18387 <p>27.7.1.2/1 Change:</p>
18391 -1- Returns: A basic_string object whose content is equal to the
18392 basic_stringbuf underlying character sequence. If the buffer is only
18393 created in input mode, the underlying character sequence is equal to
18394 the input sequence; otherwise, it is equal to the output sequence. In
18395 case of an empty underlying character sequence, the function returns
18396 basic_string<charT,traits,Allocator>().
18404 -1- Returns: A basic_string object whose content is equal to the
18405 basic_stringbuf underlying character sequence. If the basic_stringbuf
18406 was created only in input mode, the resultant basic_string contains
18407 the character sequence in the range [eback(), egptr()). If the
18408 basic_stringbuf was created with (which & ios_base::out) being true
18409 then the resultant basic_string contains the character sequence in the
18410 range [pbase(), high_mark) where high_mark represents the position one
18411 past the highest initialized character in the buffer. Characters can
18412 be initialized either through writing to the stream, or by
18413 constructing the basic_stringbuf with a basic_string, or by calling
18414 the str(basic_string) member function. In the case of calling the
18415 str(basic_string) member function, all characters initialized prior to
18416 the call are now considered uninitialized (except for those
18417 characters re-initialized by the new basic_string). Otherwise the
18418 basic_stringbuf has been created in neither input nor output mode and
18419 a zero length basic_string is returned.
18429 -2- Effects: If the basic_stringbuf's underlying character sequence is
18430 not empty, deallocates it. Then copies the content of s into the
18431 basic_stringbuf underlying character sequence and initializes the
18432 input and output sequences according to the mode stored when creating
18433 the basic_stringbuf object. If (mode&ios_base::out) is true, then
18434 initializes the output sequence with the underlying sequence. If
18435 (mode&ios_base::in) is true, then initializes the input sequence with
18436 the underlying sequence.
18444 -2- Effects: Copies the content of s into the basic_stringbuf
18445 underlying character sequence. If mode & ios_base::out is true,
18446 initializes the output sequence such that pbase() points to the first
18447 underlying character, epptr() points one past the last underlying
18448 character, and if (mode & ios_base::ate) is true,
18449 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
18450 mode & ios_base::in is true, initializes the input sequence such that
18451 eback() and gptr() point to the first underlying character and egptr()
18452 points one past the last underlying character.
18456 <p>Remove 27.2.1.2/3. (Same rationale as issue 238: incorrect and unnecessary.)</p>
18458 <p>27.7.1.3/1 Change:</p>
18462 1- Returns: If the input sequence has a read position available,
18463 returns traits::to_int_type(*gptr()). Otherwise, returns
18472 1- Returns: If the input sequence has a read position available,
18473 returns traits::to_int_type(*gptr()). Otherwise, returns
18474 traits::eof(). Any character in the underlying buffer which has been
18475 initialized is considered to be part of the input sequence.
18479 <p>27.7.1.3/9 Change:</p>
18483 -9- Notes: The function can make a write position available only if (
18484 mode & ios_base::out) != 0. To make a write position available, the
18485 function reallocates (or initially allocates) an array object with a
18486 sufficient number of elements to hold the current array object (if
18487 any), plus one additional write position. If ( mode & ios_base::in) !=
18488 0, the function alters the read end pointer egptr() to point just past
18489 the new write position (as does the write end pointer epptr()).
18497 -9- The function can make a write position available only if ( mode &
18498 ios_base::out) != 0. To make a write position available, the function
18499 reallocates (or initially allocates) an array object with a sufficient
18500 number of elements to hold the current array object (if any), plus one
18501 additional write position. If ( mode & ios_base::in) != 0, the
18502 function alters the read end pointer egptr() to point just past the
18503 new write position.
18507 <p>27.7.1.3/12 Change:</p>
18511 -12- _ If (newoff + off) < 0, or (xend - xbeg) < (newoff + off), the
18512 positioning operation fails. Otherwise, the function assigns xbeg +
18513 newoff + off to the next pointer xnext .
18521 -12- _ If (newoff + off) < 0, or if (newoff + off) refers to an
18522 uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
18523 paragraph 1), the positioning operation fails. Otherwise, the function
18524 assigns xbeg + newoff + off to the next pointer xnext .
18528 <p><i>[post-Kona: Howard provided wording. At Kona the LWG agreed that
18529 something along these lines was a good idea, but the original
18530 proposed resolution didn't say enough about the effect of various
18531 member functions on the underlying character sequences.]</i></p>
18536 <p><b>Rationale:</b></p>
18537 <p>The current basic_stringbuf description is over-constrained in such
18538 a way as to prohibit vendors from making this the high-performance
18539 in-memory stream it was meant to be. The fundamental problem is that
18540 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
18541 observable from a derived client, and the current description
18542 restricts the range [pbase(), epptr()) from being grown geometrically.
18543 This change allows, but does not require, geometric growth of this
18546 <p>Backwards compatibility issues: These changes will break code that
18547 derives from basic_stringbuf, observes epptr(), and depends upon
18548 [pbase(), epptr()) growing by one character on each call to overflow()
18549 (i.e. test suites). Otherwise there are no backwards compatibility
18552 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
18553 binding, would be over specification. The recommended change focuses
18554 on the important observable fact.</p>
18556 <p>27.7.1.1/3: This change does two things: 1. It describes exactly
18557 what must happen in terms of the sequences. The terms "input
18558 sequence" and "output sequence" are not well defined. 2. It
18559 introduces a common extension: open with app or ate mode. I concur
18560 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
18562 <p>27.7.1.2/1: This change is the crux of the efficiency issue. The
18563 resultant basic_string is not dependent upon epptr(), and thus
18564 implementors are free to grow the underlying buffer geometrically
18565 during overflow() *and* place epptr() at the end of that buffer.</p>
18567 <p>27.7.1.2/2: Made consistent with the proposed 27.7.1.1/3.</p>
18569 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
18570 the initially specified string are available for reading in an i/o
18571 basic_streambuf.</p>
18573 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
18574 trailing parenthetical comment concerning epptr().</p>
18576 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
18577 longer allowable since [pbase(), epptr()) may now contain
18578 uninitialized characters. Positioning is only allowable over the
18579 initialized range.</p>
18586 <h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
18587 <p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18588 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18589 <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>
18590 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18591 <p><b>Discussion:</b></p>
18593 It has been pointed out a number of times that the bitset to_string() member
18594 function template is tedious to use since callers must explicitly specify the
18595 entire template argument list (3 arguments). At least two implementations
18596 provide a number of overloads of this template to make it easier to use.
18601 <p><b>Proposed resolution:</b></p>
18602 <p>In order to allow callers to specify no template arguments at all, just the
18603 first one (charT), or the first 2 (charT and traits), in addition to all
18604 three template arguments, add the following three overloads to both the
18605 interface (declarations only) of the class template bitset as well as to
18606 section 23.3.5.2, immediately after p34, the Returns clause of the existing
18607 to_string() member function template:</p>
18609 <pre> template <class charT, class traits>
18610 basic_string<charT, traits, allocator<charT> >
18611 to_string () const;
18613 -34.1- Returns: to_string<charT, traits, allocator<charT> >().
18615 template <class charT>
18616 basic_string<charT, char_traits<charT>, allocator<charT> >
18617 to_string () const;
18619 -34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >().
18621 basic_string<char, char_traits<char>, allocator<char> >
18622 to_string () const;
18624 -34.3- Returns: to_string<char, char_traits<char>, allocator<char> >().
18627 <p><i>[Kona: the LWG agrees that this is an improvement over the
18628 status quo. Dietmar thought about an alternative using a proxy
18629 object but now believes that the proposed resolution above is the
18641 <h3><a name="435"></a>435. bug in DR 25</h3>
18642 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18643 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18644 <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>
18645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18646 <p><b>Discussion:</b></p>
18649 It has been pointed out that the proposed resolution in DR 25 may not be
18650 quite up to snuff: <br>
18651 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
18652 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
18656 It looks like Petur is right. The complete corrected text is copied below.
18657 I think we may have have been confused by the reference to 22.2.2.2.2 and
18658 the subsequent description of `n' which actually talks about the second
18659 argument to sputn(), not about the number of fill characters to pad with.
18663 So the question is: was the original text correct? If the intent was to
18664 follow classic iostreams then it most likely wasn't, since setting width()
18665 to less than the length of the string doesn't truncate it on output. This
18666 is also the behavior of most implementations (except for SGI's standard
18667 iostreams where the operator does truncate).
18672 <p><b>Proposed resolution:</b></p>
18673 <p>Change the text in 21.3.7.9, p4 from</p>
18675 If bool(k) is true, inserts characters as if by calling
18676 os.rdbuf()->sputn(str.data(), n), padding as described in stage 3
18677 of lib.facet.num.put.virtuals, where n is the larger of os.width()
18682 If bool(k) is true, determines padding as described in
18683 lib.facet.num.put.virtuals, and then inserts the resulting
18684 sequence of characters <tt>seq</tt> as if by calling
18685 <tt>os.rdbuf()->sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
18686 <tt>os.width()</tt> and <tt>str.size()</tt>;
18689 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
18690 proposed resolution, is quite what we want. We want to say that
18691 the string will be output, padded to os.width() if necessary. We
18692 don't want to duplicate the padding rules in clause 22, because
18693 they're complicated, but we need to be careful because they weren't
18694 quite written with quite this case in mind. We need to say what
18695 the character sequence is, and then defer to clause 22. Post-Kona:
18696 Benjamin provided wording.]</i></p>
18705 <h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
18706 <p><b>Section:</b> 22.1.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
18707 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
18708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
18709 <p><b>Discussion:</b></p>
18711 Is "const std::ctype<char>" a valid template argument to has_facet, use_facet,
18712 and the locale template ctor? And if so, does it designate the same Facet as
18713 the non-const "std::ctype<char>?" What about "volatile std::ctype<char>?"
18714 Different implementations behave differently: some fail to compile, others
18715 accept such types but behave inconsistently.
18719 <p><b>Proposed resolution:</b></p>
18720 <p>Change 22.1.1.1.2, p1 to read:</p>
18722 <p>Template parameters in this clause which are required to be facets
18723 are those named Facet in declarations. A program that passes a type
18724 that is not a facet, or a type that refers to volatile-qualified
18725 facet, as an (explicit or deduced) template parameter to a locale
18726 function expecting a facet, is ill-formed. A const-qualified facet is
18727 a valid template argument to any locale function that expects a Facet
18728 template parameter.</p>
18730 <p><i>[Kona: changed the last sentence from a footnote to normative
18739 <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
18740 <p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
18741 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p>
18742 <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>
18743 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
18744 <p><b>Discussion:</b></p>
18746 <p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
18747 noticed with statements like:</p>
18748 <pre>vector<int> v(10, 1);
18751 <p>The intent of the above statement was to construct with:</p>
18752 <pre>vector(size_type, const value_type&);
18755 <p>but early implementations failed to compile as they bound to:</p>
18756 <pre>template <class InputIterator>
18757 vector(InputIterator f, InputIterator l);
18761 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
18762 member template constructor will have the same effect as:</p>
18763 <pre>vector<static_cast<size_type>(f), static_cast<value_type>(l));
18765 <p>(and similarly for the other member template functions of sequences).</p>
18767 <p>There is also a note that describes one implementation technique:</p>
18769 One way that sequence implementors can satisfy this requirement is to
18770 specialize the member template for every integral type.
18773 <p>This might look something like:</p>
18775 <pre>template <class T>
18778 typedef unsigned size_type;
18780 explicit vector(size_type) {}
18781 vector(size_type, const T&) {}
18783 template <class I>
18789 template <class T>
18790 template <class I>
18791 vector<T>::vector(I, I) { ... }
18795 vector<int>::vector(int, int) { ... }
18799 vector<int>::vector(unsigned, unsigned) { ... }
18805 <p>Label this solution 'A'.</p>
18807 <p>The standard also says:</p>
18809 Less cumbersome implementation techniques also exist.
18812 A popular technique is to not specialize as above, but instead catch
18813 every call with the member template, detect the type of InputIterator,
18814 and then redirect to the correct logic. Something like:
18817 <pre>template <class T>
18818 template <class I>
18819 vector<T>::vector(I f, I l)
18821 choose_init(f, l, int2type<is_integral<I>::value>());
18824 template <class T>
18825 template <class I>
18826 vector<T>::choose_init(I f, I l, int2type<false>)
18828 // construct with iterators
18831 template <class T>
18832 template <class I>
18833 vector<T>::choose_init(I f, I l, int2type<true>)
18835 size_type sz = static_cast<size_type>(f);
18836 value_type v = static_cast<value_type>(l);
18837 // construct with sz,v
18842 <p>Label this solution 'B'.</p>
18844 <p>Both of these solutions solve the case the standard specifically
18846 <pre>vector<int> v(10, 1); // ok, vector size 10, initialized to 1
18850 However, (and here is the problem), the two solutions have different
18851 behavior in some cases where the value_type of the sequence is not an
18852 integral type. For example consider:
18854 <blockquote><pre> pair<char, char> p('a', 'b');
18855 vector<vector<pair<char, char> > > d('a', 'b');
18856 </pre></blockquote>
18858 The second line of this snippet is likely an error. Solution A catches
18859 the error and refuses to compile. The reason is that there is no
18860 specialization of the member template constructor that looks like:
18862 <pre>template <>
18864 vector<vector<pair<char, char> > >::vector(char, char) { ... }
18868 So the expression binds to the unspecialized member template
18869 constructor, and then fails (compile time) because char is not an
18874 Solution B compiles the above example though. 'a' is casted to an
18875 unsigned integral type and used to size the outer vector. 'b' is
18876 static casted to the inner vector using it's explicit constructor:
18879 <pre>explicit vector(size_type n);
18883 and so you end up with a static_cast<size_type>('a') by
18884 static_cast<size_type>('b') matrix.
18888 It is certainly possible that this is what the coder intended. But the
18889 explicit qualifier on the inner vector has been thwarted at any rate.
18893 The standard is not clear whether the expression:
18896 <pre> vector<vector<pair<char, char> > > d('a', 'b');
18900 (and similar expressions) are:
18904 <li> undefined behavior.</li>
18905 <li> illegal and must be rejected.</li>
18906 <li> legal and must be accepted.</li>
18909 <p>My preference is listed in the order presented.</p>
18911 <p>There are still other techniques for implementing the requirements of
18912 paragraphs 9-11, namely the "restricted template technique" (e.g.
18913 enable_if). This technique is the most compact and easy way of coding
18914 the requirements, and has the behavior of #2 (rejects the above
18919 Choosing 1 would allow all implementation techniques I'm aware of.
18920 Choosing 2 would allow only solution 'A' and the enable_if technique.
18921 Choosing 3 would allow only solution 'B'.
18925 Possible wording for a future standard if we wanted to actively reject
18926 the expression above would be to change "static_cast" in paragraphs
18927 9-11 to "implicit_cast" where that is defined by:
18931 <pre>template <class T, class U>
18933 T implicit_cast(const U& u)
18942 <p><b>Proposed resolution:</b></p>
18944 <p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
18946 <p>For every sequence defined in this clause and in clause lib.strings:</p>
18950 <p>If the constructor</p>
18951 <pre> template <class InputIterator>
18952 X(InputIterator f, InputIterator l,
18953 const allocator_type& a = allocator_type())
18955 <p>is called with a type InputIterator that does not qualify as
18956 an input iterator, then the constructor will behave as if the
18957 overloaded constructor:</p>
18958 <pre> X(size_type, const value_type& = value_type(),
18959 const allocator_type& = allocator_type())
18961 <p>were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.</p>
18965 <p>If the member functions of the forms:</p>
18966 <pre> template <class InputIterator> // such as insert()
18967 rt fx1(iterator p, InputIterator f, InputIterator l);
18969 template <class InputIterator> // such as append(), assign()
18970 rt fx2(InputIterator f, InputIterator l);
18972 template <class InputIterator> // such as replace()
18973 rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
18975 <p>are called with a type InputIterator that does not qualify as
18976 an input iterator, then these functions will behave as if the
18977 overloaded member functions:</p>
18978 <pre> rt fx1(iterator, size_type, const value_type&);
18980 rt fx2(size_type, const value_type&);
18982 rt fx3(iterator, iterator, size_type, const value_type&);
18984 <p>were called instead, with the same arguments.</p>
18988 <p>In the previous paragraph the alternative binding will fail if f
18989 is not implicitly convertible to X::size_type or if l is not implicitly
18990 convertible to X::value_type.</p>
18993 The extent to which an implementation determines that a type cannot be
18994 an input iterator is unspecified, except that as a minimum integral
18995 types shall not qualify as input iterators.
19001 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
19002 to be accepted, and also agreed that this is surprising behavior. The
19003 LWG considered several options, including something like
19004 implicit_cast, which doesn't appear to be quite what we want. We
19005 considered Howards three options: allow acceptance or rejection,
19006 require rejection as a compile time error, and require acceptance. By
19007 straw poll (1-6-1), we chose to require a compile time error.
19008 Post-Kona: Howard provided wording.
19013 Sydney: The LWG agreed with this general direction, but there was some
19014 discomfort with the wording in the original proposed resolution.
19015 Howard submitted new wording, and we will review this again in
19020 <p><i>[Redmond: one very small change in wording: the first argument
19021 is cast to size_t. This fixes the problem of something like
19022 <tt>vector<vector<int> >(5, 5)</tt>, where int is not
19023 implicitly convertible to the value type.]</i></p>
19028 <p><b>Rationale:</b></p>
19029 <p>The proposed resolution fixes:</p>
19031 <pre> vector<int> v(10, 1);
19035 since as integral types 10 and 1 must be disqualified as input
19036 iterators and therefore the (size,value) constructor is called (as
19039 <p>The proposed resolution breaks:</p>
19041 <pre> vector<vector<T> > v(10, 1);
19045 because the integral type 1 is not *implicitly* convertible to
19046 vector<T>. The wording above requires a diagnostic.</p>
19049 The proposed resolution leaves the behavior of the following code
19055 operator int () const {return 10;}
19063 vector<B> v(A(), A());
19067 The implementation may or may not detect that A is not an input
19068 iterator and employee the (size,value) constructor. Note though that
19069 in the above example if the B(A) constructor is qualified explicit,
19070 then the implementation must reject the constructor as A is no longer
19071 implicitly convertible to B.
19079 <h3><a name="441"></a>441. Is fpos::state const?</h3>
19080 <p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19081 <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</p>
19082 <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>
19083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19084 <p><b>Discussion:</b></p>
19086 In section 27.4.3.1 [fpos.members] fpos<stateT>::state() is declared
19087 non const, but in section 27.4.3 [fpos] it is declared const.
19091 <p><b>Proposed resolution:</b></p>
19093 In section 27.4.3.1 [fpos.members], change the declaration of
19094 <tt>fpos<stateT>::state()</tt> to const.
19102 <h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
19103 <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19104 <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</p>
19105 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
19106 <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>
19107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19108 <p><b>Discussion:</b></p>
19110 In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
19111 basic_ostream<charT, traits>::sentry::operator bool() is declared
19112 as non const, but in section 27.6.2.3, in synopsis it is declared
19117 <p><b>Proposed resolution:</b></p>
19119 In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
19120 of <tt>sentry::operator bool()</tt> to const.
19128 <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
19129 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19130 <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
19131 <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>
19132 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19133 <p><b>Discussion:</b></p>
19135 In section 27.8.1.4 [filebuf.members] par6, in effects description of
19136 basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice;
19137 should be overflow(traits::eof()).
19141 <p><b>Proposed resolution:</b></p>
19143 Change overflow(EOF) to overflow(traits::eof()).
19151 <h3><a name="444"></a>444. Bad use of casts in fstream</h3>
19152 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19153 <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
19154 <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>
19155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19156 <p><b>Discussion:</b></p>
19157 <p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
19158 27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
19160 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
19164 <p><b>Proposed resolution:</b></p>
19166 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
19167 constness. The other two places are stylistic: we could change the
19168 C-style casts to const_cast. Post-Sydney: Howard provided wording.
19172 <p>Change 27.8.1.7/1 from:</p>
19174 Returns: (basic_filebuf<charT,traits>*)&sb.
19179 Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
19182 <p>Change 27.8.1.10/1 from:</p>
19184 Returns: (basic_filebuf<charT,traits>*)&sb.
19189 Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
19192 <p>Change 27.8.1.13/1 from:</p>
19199 Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
19210 <h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
19211 <p><b>Section:</b> 24.3.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19212 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-12-09</p>
19213 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19214 <p><b>Discussion:</b></p>
19216 The standard places no restrictions at all on the reference type
19217 of input, output, or forward iterators (for forward iterators it
19218 only specifies that *x must be value_type& and doesn't mention
19219 the reference type). Bidirectional iterators' reference type is
19220 restricted only by implication, since the base iterator's
19221 reference type is used as the return type of reverse_iterator's
19222 operator*, which must be T& in order to be a conforming forward
19227 Here's what I think we ought to be able to expect from an input
19228 or forward iterator's reference type R, where a is an iterator
19229 and V is its value_type
19234 *a is convertible to R
19238 R is convertible to V
19242 static_cast<V>(static_cast<R>(*a)) is equivalent to
19243 static_cast<V>(*a)
19247 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
19248 <pre> { R r = *a; r = x; } is equivalent to *a = x;
19252 I think these requirements capture existing container iterators
19253 (including vector<bool>'s), but render istream_iterator invalid;
19254 its reference type would have to be changed to a constant
19260 (Jeremy Siek) During the discussion in Sydney, it was felt that a
19261 simpler long term solution for this was needed. The solution proposed
19262 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
19263 and <tt>pointer</tt> to be the same type as <tt>a-></tt>. Most
19264 iterators in the Standard Library already meet this requirement. Some
19265 iterators are output iterators, and do not need to meet the
19266 requirement, and others are only specified through the general
19267 iterator requirements (which will change with this resolution). The
19268 sole case where there is an explicit definition of the reference type
19269 that will need to change is <tt>istreambuf_iterator</tt> which returns
19270 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
19271 <tt>charT&</tt>. We propose changing the reference type of
19272 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
19275 <p>The other option for resolving the issue with <tt>pointer</tt>,
19276 mentioned in the note below, is to remove <tt>pointer</tt>
19277 altogether. I prefer placing requirements on <tt>pointer</tt> to
19278 removing it for two reasons. First, <tt>pointer</tt> will become
19279 useful for implementing iterator adaptors and in particular,
19280 <tt>reverse_iterator</tt> will become more well defined. Second,
19281 removing <tt>pointer</tt> is a rather drastic and publicly-visible
19282 action to take.</p>
19284 <p>The proposed resolution technically enlarges the requirements for
19285 iterators, which means there are existing iterators (such as
19286 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
19287 iterators) that will no longer meet the requirements. Will this break
19288 existing code? The scenario in which it would is if an algorithm
19289 implementation (say in the Standard Library) is changed to rely on
19290 <tt>iterator_traits::reference</tt>, and then is used with one of the
19291 iterators that do not have an appropriately defined
19292 <tt>iterator_traits::reference</tt>.
19296 <p>The proposed resolution makes one other subtle change. Previously,
19297 it was required that output iterators have a <tt>difference_type</tt>
19298 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
19299 iterator could not be an output iterator. This is clearly a mistake,
19300 so I've changed the wording to say that those types may be
19306 <p><b>Proposed resolution:</b></p>
19308 <p>In 24.3.1 [iterator.traits], after:</p>
19311 be defined as the iterator's difference type, value type and iterator
19312 category, respectively.
19318 In addition, the types</p>
19319 <pre>iterator_traits<Iterator>::reference
19320 iterator_traits<Iterator>::pointer
19322 <p>must be defined as the iterator's reference and pointer types, that
19323 is, the same type as the type of <tt>*a</tt> and <tt>a-></tt>,
19327 <p>In 24.3.1 [iterator.traits], change:</p>
19330 In the case of an output iterator, the types</p>
19331 <pre>iterator_traits<Iterator>::difference_type
19332 iterator_traits<Iterator>::value_type
19334 <p>are both defined as <tt>void</tt>.</p>
19339 In the case of an output iterator, the types</p>
19340 <pre>iterator_traits<Iterator>::difference_type
19341 iterator_traits<Iterator>::value_type
19342 iterator_traits<Iterator>::reference
19343 iterator_traits<Iterator>::pointer
19345 <p>may be defined as <tt>void</tt>.</p>
19348 <p>In 24.5.3 [istreambuf.iterator], change:</p>
19350 <pre>typename traits::off_type, charT*, charT&>
19355 <pre>typename traits::off_type, charT*, charT>
19360 Redmond: there was concern in Sydney that this might not be the only place
19361 where things were underspecified and needed to be changed. Jeremy
19362 reviewed iterators in the standard and confirmed that nothing else
19363 needed to be changed.
19375 <h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
19376 <p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19377 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-01-07</p>
19378 <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>
19379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19380 <p><b>Discussion:</b></p>
19382 Table 76, the random access iterator requirement table, says that the
19383 return type of a[n] must be "convertible to T". When an iterator's
19384 value_type T is an abstract class, nothing is convertible to T.
19385 Surely this isn't an intended restriction?
19389 <p><b>Proposed resolution:</b></p>
19391 Change the return type to "convertible to T const&".
19399 <h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
19400 <p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19401 <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p>
19402 <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>
19403 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19404 <p><b>Discussion:</b></p>
19405 <p>Original text:</p>
19407 The macro offsetof accepts a restricted set of type arguments in this
19408 International Standard. type shall be a POD structure or a POD union
19409 (clause 9). The result of applying the offsetof macro to a field that
19410 is a static data member or a function member is undefined."
19413 <p>Revised text:</p>
19415 "If type is not a POD structure or a POD union the results are undefined."
19419 Looks to me like the revised text should have replaced only the second
19420 sentence. It doesn't make sense standing alone.
19425 <p><b>Proposed resolution:</b></p>
19426 <p>Change 18.1, paragraph 5, to:</p>
19429 The macro offsetof accepts a restricted set of type arguments in this
19430 International Standard. If type is not a POD structure or a POD union
19431 the results are undefined. The result of applying the offsetof macro
19432 to a field that is a static data member or a function member is
19441 <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
19442 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19443 <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19444 <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>
19445 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19446 <p><b>Discussion:</b></p>
19447 <pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
19448 ios_base::openmode);
19451 is obliged to fail if nothing has been inserted into the stream. This
19452 is unnecessary and undesirable. It should be permissible to seek to
19453 an effective offset of zero.</p>
19456 Sydney: Agreed that this is an annoying problem: seeking to zero should be
19457 legal. Bill will provide wording.
19463 <p><b>Proposed resolution:</b></p>
19464 <p>Change the sentence from:</p>
19466 For a sequence to be positioned, if its next pointer (either
19467 gptr() or pptr()) is a null pointer, the positioning operation
19474 For a sequence to be positioned, if its next pointer (either
19475 gptr() or pptr()) is a null pointer and the new offset newoff
19476 is nonzero, the positioning operation fails.
19484 <h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
19485 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19486 <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19487 <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>
19488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19489 <p><b>Discussion:</b></p>
19491 Both cerr::tie() and wcerr::tie() are obliged to be null at program
19492 startup. This is overspecification and overkill. It is both traditional
19493 and useful to tie cerr to cout, to ensure that standard output is drained
19494 whenever an error message is written. This behavior should at least be
19495 permitted if not required. Same for wcerr::tie().
19499 <p><b>Proposed resolution:</b></p>
19501 <p>Add to the description of cerr:</p>
19503 After the object cerr is initialized, cerr.tie() returns &cout.
19504 Its state is otherwise the same as required for basic_ios<char>::init
19505 (lib.basic.ios.cons).
19508 <p>Add to the description of wcerr:</p>
19511 After the object wcerr is initialized, wcerr.tie() returns &wcout.
19512 Its state is otherwise the same as required for basic_ios<wchar_t>::init
19513 (lib.basic.ios.cons).
19516 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
19517 permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will
19518 provide wording.]</i></p>
19526 <h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
19527 <p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19528 <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
19529 <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>
19530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19531 <p><b>Discussion:</b></p>
19533 <p>The C++ Standard effectively requires that the traditional C headers
19534 (of the form <xxx.h>) be defined in terms of the newer C++
19535 headers (of the form <cxxx>). Clauses 17.4.1.2/4 and D.5 combine
19536 to require that:</p>
19539 <li>Including the header <cxxx> declares a C name in namespace std.</li>
19541 <li> Including the header <xxx.h> declares a C name in namespace std
19542 (effectively by including <cxxx>), then imports it into the global
19543 namespace with an individual using declaration.</li>
19547 The rules were left in this form despited repeated and heated objections
19548 from several compiler vendors. The C headers are often beyond the direct
19549 control of C++ implementors. In some organizations, it's all they can do
19550 to get a few #ifdef __cplusplus tests added. Third-party library vendors
19551 can perhaps wrap the C headers. But neither of these approaches supports
19552 the drastic restructuring required by the C++ Standard. As a result, it is
19553 still widespread practice to ignore this conformance requirement, nearly
19554 seven years after the committee last debated this topic. Instead, what is
19555 often implemented is:
19559 <li> Including the header <xxx.h> declares a C name in the
19560 global namespace.</li>
19562 <li> Including the header <cxxx> declares a C name in the
19563 global namespace (effectively by including <xxx.h>), then
19564 imports it into namespace std with an individual using declaration.</li>
19568 The practical benefit for implementors with the second approach is that
19569 they can use existing C library headers, as they are pretty much obliged
19570 to do. The practical cost for programmers facing a mix of implementations
19571 is that they have to assume weaker rules:</p>
19574 <li> If you want to assuredly declare a C name in the global
19575 namespace, include <xxx.h>. You may or may not also get the
19576 declaration in namespace std.</li>
19578 <li> If you want to assuredly declare a C name in namespace std,
19579 include <cxxx>. You may or may not also get the declaration in
19580 the global namespace.</li>
19584 There also exists the <i>possibility</i> of subtle differences due to
19585 Koenig lookup, but there are so few non-builtin types defined in the C
19586 headers that I've yet to see an example of any real problems in this
19591 It is worth observing that the rate at which programmers fall afoul of
19592 these differences has remained small, at least as measured by newsgroup
19593 postings and our own bug reports. (By an overwhelming margin, the
19594 commonest problem is still that programmers include <string> and can't
19595 understand why the typename string isn't defined -- this a decade after
19596 the committee invented namespace std, nominally for the benefit of all
19601 We should accept the fact that we made a serious mistake and rectify it,
19602 however belatedly, by explicitly allowing either of the two schemes for
19603 declaring C names in headers.
19606 <p><i>[Sydney: This issue has been debated many times, and will
19607 certainly have to be discussed in full committee before any action
19608 can be taken. However, the preliminary sentiment of the LWG was in
19609 favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer
19610 suggests that we might also want to undeprecate the
19611 C-style <tt>.h</tt> headers.]</i></p>
19616 <p><b>Proposed resolution:</b></p>
19618 Add to 17.4.1.2 [headers], para. 4:
19622 Except as noted in clauses 18 through 27 and Annex D, the contents of each
19623 header <i>cname</i> shall be the same as that of the corresponding header
19624 <i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
19625 7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
19626 7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
19627 the declarations <del>and definitions</del> (except for names which are defined
19628 as macros in C) are within namespace scope (3.3.5) of the namespace std.
19629 <ins>It is unspecified whether these names are first declared within the global
19630 namespace scope and are then injected into namespace std by explicit
19631 using-declarations (7.3.3 [namespace.udecl]).</ins>
19635 Change D.5 [depr.c.headers], para. 2-3:
19640 -2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
19641 as if each name placed in the Standard library namespace by the corresponding
19642 <i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
19643 namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
19644 by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
19645 <ins>It is unspecified whether these names are first declared or defined within
19646 namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
19647 <tt>std</tt> and are then injected into the global namespace scope by explicit
19648 using-declarations (7.3.3 [namespace.udecl]).</ins>
19651 -3- [<i>Example:</i> The header <tt><cstdlib></tt> <ins>assuredly</ins>
19652 provides its declarations and definitions within the namespace <tt>std</tt>.
19653 <ins>It may also provide these names within the global namespace.</ins> The
19654 header <tt><stdlib.h></tt> <del>makes these available also in</del>
19655 <ins>assuredly provides the same declarations and definitions within</ins> the
19656 global namespace, much as in the C Standard. <ins>It may also provide these
19657 names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
19666 <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
19667 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19668 <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
19669 <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>
19670 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19671 <p><b>Discussion:</b></p>
19673 The constructor from unsigned long says it initializes "the first M
19674 bit positions to the corresponding bit values in val. M is the smaller
19675 of N and the value CHAR_BIT * sizeof(unsigned long)."
19679 Object-representation vs. value-representation strikes again. CHAR_BIT *
19680 sizeof (unsigned long) does not give us the number of bits an unsigned long
19681 uses to hold the value. Thus, the first M bit position above is not
19682 guaranteed to have any corresponding bit values in val.
19686 <p><b>Proposed resolution:</b></p>
19687 <p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
19688 N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
19689 "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
19690 the value representation (section 3.9 [basic.types]) of <tt>unsigned
19699 <h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
19700 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
19701 <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</p>
19702 <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>
19703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
19704 <p><b>Discussion:</b></p>
19706 The second parameters of the non-default constructor and of the open
19707 member function for basic_fstream, named "mode", are optional
19708 according to the class declaration in 27.8.1.11 [lib.fstream]. The
19709 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
19710 27.8.1.13 lib.fstream.members] disagree with this, though the
19711 constructor declaration has the "explicit" function-specifier implying
19712 that it is intended to be callable with one argument.
19716 <p><b>Proposed resolution:</b></p>
19717 <p>In 27.8.1.15 [fstream.cons], change</p>
19718 <pre> explicit basic_fstream(const char* s, ios_base::openmode mode);
19721 <pre> explicit basic_fstream(const char* s,
19722 ios_base::openmode mode = ios_base::in|ios_base::out);
19724 <p>In 27.8.1.17 [fstream.members], change</p>
19725 <pre> void open(const char*s, ios_base::openmode mode);
19728 <pre> void open(const char*s,
19729 ios_base::openmode mode = ios_base::in|ios_base::out);
19737 <h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
19738 <p><b>Section:</b> 22.2.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19739 <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
19740 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19741 <p><b>Discussion:</b></p>
19743 Template time_get currently contains difficult, if not impossible,
19744 requirements for do_date_order, do_get_time, and do_get_date. All require
19745 the implementation to scan a field generated by the %x or %X conversion
19746 specifier in strftime. Yes, do_date_order can always return no_order, but
19747 that doesn't help the other functions. The problem is that %x can be
19748 nearly anything, and it can vary widely with locales. It's horribly
19749 onerous to have to parse "third sunday after Michaelmas in the year of
19750 our Lord two thousand and three," but that's what we currently ask of
19751 do_get_date. More practically, it leads some people to think that if
19752 %x produces 10.2.04, we should know to look for dots as separators. Still
19757 Note that this is the <i>opposite</i> effect from the intent stated in the
19758 footnote earlier in this subclause:
19762 "In other words, user confirmation is required for reliable parsing of
19763 user-entered dates and times, but machine-generated formats can be
19764 parsed reliably. This allows parsers to be aggressive about interpreting
19765 user variations on standard formats."
19769 We should give both implementers and users an easier and more reliable
19770 alternative: provide a (short) list of alternative delimiters and say
19771 what the default date order is for no_order. For backward compatibility,
19772 and maximum latitude, we can permit an implementation to parse whatever
19773 %x or %X generates, but we shouldn't require it.
19777 <p><b>Proposed resolution:</b></p>
19779 <p><b>In the description:</b></p>
19780 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base& str,
19781 ios_base::iostate& err, tm* t) const;
19785 2 Effects: Reads characters starting at suntil it has extracted those
19786 struct tm members, and remaining format characters, used by
19787 time_put<>::put to produce the format specified by 'X', or until it
19788 encounters an error or end of sequence.
19791 <p><b>change:</b> 'X'</p>
19793 <p><b>to:</b> "%H:%M:%S"</p>
19797 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
19798 ios_base::iostate& err, tm* t) const;
19800 4 Effects: Reads characters starting at s until it has extracted those
19801 struct tm members, and remaining format characters, used by
19802 time_put<>::put to produce the format specified by 'x', or until it
19803 encounters an error.
19807 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
19808 ios_base::iostate& err, tm* t) const;
19812 4 Effects: Reads characters starting at s until it has extracted those
19813 struct tm members, and remaining format characters, used by
19814 time_put<>::put to produce one of the following formats, or until it
19815 encounters an error. The format depends on the value returned by
19816 date_order() as follows:
19819 <pre> date_order() format
19821 no_order "%m/%d/%y"
19828 An implementation may also accept additional implementation-defined formats.
19831 <p><i>[Redmond: agreed that this is a real problem. The solution is
19832 probably to match C99's parsing rules. Bill provided wording.
19842 <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
19843 <p><b>Section:</b> 23.2.6 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19844 <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</p>
19845 <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>
19846 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19847 <p><b>Discussion:</b></p>
19849 <p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p>
19851 <li> add vector<T>::data() member (const and non-const version)
19852 semantics: if( empty() ) return 0; else return buffer_;</li>
19853 <li> add map<Key,T>::at( const Key& k ) member (const and non-const version)
19854 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
19860 <li>To obtain a pointer to the vector's buffer, one must use either
19861 operator[]() (which can give undefined behavior for empty vectors) or
19862 at() (which will then throw if the vector is empty). </li>
19863 <li>tr1::array<T,sz> already has a data() member</li>
19864 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
19865 <li>Neither when the map is const.</li>
19866 <li>when we want to make sure we don't add an element accidently</li>
19867 <li>when it should be considered an error if a key is not in the map</li>
19872 <p><b>Proposed resolution:</b></p>
19873 <p>In 23.2.6 [vector], add the following to the <tt>vector</tt>
19874 synopsis after "element access" and before "modifiers":</p>
19875 <pre> // <i>[lib.vector.data] data access</i>
19877 const_pointer data() const;
19880 <p>Add a new subsection of 23.2.6 [vector]:</p>
19882 <p>23.2.4.x <tt>vector</tt> data access</p>
19883 <pre> pointer data();
19884 const_pointer data() const;
19886 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
19887 range. For a non-empty vector, data() == &front().</p>
19888 <p><b>Complexity:</b> Constant time.</p>
19889 <p><b>Throws:</b> Nothing.</p>
19892 <p>In 23.3.1 [map], add the following to the <tt>map</tt>
19893 synopsis immediately after the line for operator[]:</p>
19894 <pre> T& at(const key_type& x);
19895 const T& at(const key_type& x) const;
19898 <p>Add the following to 23.3.1.2 [map.access]:</p>
19900 <pre> T& at(const key_type& x);
19901 const T& at(const key_type& x) const;
19904 <p><b>Returns:</b> A reference to the element whose key is equivalent
19905 to x, if such an element is present in the map.</p>
19906 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
19912 <p><b>Rationale:</b></p>
19913 <p>Neither of these additions provides any new functionality but the
19914 LWG agreed that they are convenient, especially for novices. The
19915 exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
19916 was chosen to match <tt>vector::at</tt>.</p>
19923 <h3><a name="465"></a>465. Contents of <ciso646></h3>
19924 <p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19925 <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p>
19926 <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>
19927 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19928 <p><b>Discussion:</b></p>
19929 <p>C header <iso646.h> defines macros for some operators, such as
19932 <p>Section 17.4.1.2 [headers] "Headers" says that except as noted in
19933 clauses 18 through 27, the <cname> C++ header contents are the same
19934 as the C header <name.h>. In particular, table 12 lists
19935 <ciso646> as a C++ header.</p>
19937 <p>I don't find any other mention of <ciso646>, or any mention of
19938 <iso646.h>, in clauses 17 thorough 27. That implies that the
19939 contents of <ciso646> are the same as C header <iso646.h>.</p>
19941 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
19942 "Header <iso646.h>" says that the alternative tokens are not
19943 defined as macros in <ciso646>, but does not mention the contents
19944 of <iso646.h>.</p>
19946 <p>I don't find any normative text to support C.2.2.2.</p>
19950 <p><b>Proposed resolution:</b></p>
19951 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
19952 paragraph 6 (the one about functions must be functions):</p>
19955 <p>Identifiers that are keywords or operators in C++ shall not be defined
19956 as macros in C++ standard library headers.
19957 [Footnote:In particular, including the standard header <iso646.h>
19958 or <ciso646> has no effect. </p>
19961 <p><i>[post-Redmond: Steve provided wording.]</i></p>
19970 <h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
19971 <p><b>Section:</b> 21.1.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
19972 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
19973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19974 <p><b>Discussion:</b></p>
19977 Table 37 describes the requirements on Traits::compare() in terms of
19978 those on Traits::lt(). 21.1.3.1, p6 requires char_traits<char>::lt()
19979 to yield the same result as operator<(char, char).
19983 Most, if not all, implementations of char_traits<char>::compare()
19984 call memcmp() for efficiency. However, the C standard requires both
19985 memcmp() and strcmp() to interpret characters under comparison as
19986 unsigned, regardless of the signedness of char. As a result, all
19987 these char_traits implementations fail to meet the requirement
19988 imposed by Table 37 on compare() when char is signed.
19992 <p>Read email thread starting with c++std-lib-13499 for more. </p>
19995 <p><b>Proposed resolution:</b></p>
19998 <p>Change 21.1.3.1, p6 from</p>
20000 The two-argument members assign, eq, and lt are defined identically
20001 to the built-in operators =, ==, and < respectively.
20005 The two-argument member assign is defined identically to
20006 the built-in operator =. The two
20007 argument members eq and lt are defined identically to
20008 the built-in operators == and < for type unsigned char.
20011 <p><i>[Redmond: The LWG agreed with this general direction, but we
20012 also need to change <tt>eq</tt> to be consistent with this change.
20013 Post-Redmond: Martin provided wording.]</i></p>
20021 <h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
20022 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20023 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
20024 <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>
20025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20026 <p><b>Discussion:</b></p>
20028 <p>The program below is required to compile but when run it typically
20029 produces unexpected results due to the user-defined conversion from
20030 std::cout or any object derived from basic_ios to void*.
20033 <pre> #include <cassert>
20034 #include <iostream>
20038 assert (std::cin.tie () == std::cout);
20039 // calls std::cout.ios::operator void*()
20044 <p><b>Proposed resolution:</b></p>
20047 Replace std::basic_ios<charT, traits>::operator void*() with another
20048 conversion operator to some unspecified type that is guaranteed not
20049 to be convertible to any other type except for bool (a pointer-to-member
20050 might be one such suitable type). In addition, make it clear that the
20051 pointer type need not be a pointer to a complete type and when non-null,
20052 the value need not be valid.
20055 <p>Specifically, change in [lib.ios] the signature of</p>
20056 <pre> operator void*() const;
20059 <pre> operator unspecified-bool-type() const;
20061 <p>and change [lib.iostate.flags], p1 from</p>
20062 <pre> operator void*() const;
20065 <pre>operator unspecified-bool-type() const;
20067 -1- Returns: if fail() then a value that will evaluate false in a
20068 boolean context; otherwise a value that will evaluate true in a
20069 boolean context. The value type returned shall not be
20070 convertible to int.
20072 -2- [Note: This conversion can be used in contexts where a bool
20073 is expected (e.g., an if condition); however, implicit
20074 conversions (e.g., to int) that can occur with bool are not
20075 allowed, eliminating some sources of user error. One possible
20076 implementation choice for this type is pointer-to-member. - end
20080 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
20082 <p><i>[Lillehammer: Doug provided revised wording for
20083 "unspecified-bool-type".]</i></p>
20093 <h3><a name="469"></a>469. vector<bool> ill-formed relational operators</h3>
20094 <p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
20095 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
20096 <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>
20097 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
20098 <p><b>Discussion:</b></p>
20101 The overloads of relational operators for vector<bool> specified
20102 in [lib.vector.bool] are redundant (they are semantically identical
20103 to those provided for the vector primary template) and may even be
20104 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
20105 in c++std-lib-13647).
20110 <p><b>Proposed resolution:</b></p>
20112 Remove all overloads of overloads of relational operators for
20113 vector<bool> from [lib.vector.bool].
20120 <h3><a name="474"></a>474. confusing Footnote 297</h3>
20121 <p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20122 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
20123 <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>
20124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20125 <p><b>Discussion:</b></p>
20128 I think Footnote 297 is confused. The paragraph it applies to seems
20129 quite clear in that widen() is only called if the object is not a char
20130 stream (i.e., not basic_ostream<char>), so it's irrelevant what the
20131 value of widen(c) is otherwise.
20135 <p><b>Proposed resolution:</b></p>
20137 I propose to strike the Footnote.
20144 <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
20145 <p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20146 <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p>
20147 <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>
20148 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20149 <p><b>Discussion:</b></p>
20151 It is not clear whether the function object passed to for_each is allowed to
20152 modify the elements of the sequence being iterated over.
20156 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
20157 Non-modifying sequence operations". 'Non-modifying sequence operation' is
20162 25(5) says: "If an algorithm's Effects section says that a value pointed to
20163 by any iterator passed as an argument is modified, then that algorithm has
20164 an additional type requirement: The type of that argument shall satisfy the
20165 requirements of a mutable iterator (24.1)."
20168 <p>for_each's Effects section does not mention whether arguments can be
20172 "Effects: Applies f to the result of dereferencing every iterator in the
20173 range [first, last), starting from first and proceeding to last - 1."
20177 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
20178 the sense that neither the algorithms themselves nor the function objects
20179 passed to the algorithms may modify the sequences or elements in any way.
20180 This DR affects only for_each.
20184 We suspect that for_each's classification in "non-modifying sequence
20185 operations" means that the algorithm itself does not inherently modify the
20186 sequence or the elements in the sequence, but that the function object
20187 passed to it may modify the elements it operates on.
20191 The original STL document by Stepanov and Lee explicitly prohibited the
20192 function object from modifying its argument.
20193 The "obvious" implementation of for_each found in several standard library
20194 implementations, however, does not impose this restriction.
20195 As a result, we suspect that the use of for_each with function objects that modify
20196 their arguments is wide-spread.
20197 If the restriction was reinstated, all such code would become non-conforming.
20198 Further, none of the other algorithms in the Standard
20199 could serve the purpose of for_each (transform does not guarantee the order in
20200 which its function object is called).
20204 We suggest that the standard be clarified to explicitly allow the function object
20205 passed to for_each modify its argument.</p>
20209 <p><b>Proposed resolution:</b></p>
20210 <p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
20211 the type of 'first' satisfies the requirements of a mutable iterator,
20212 'f' may apply nonconstant functions through the dereferenced iterators
20218 <p><b>Rationale:</b></p>
20219 <p>The LWG believes that nothing in the standard prohibits function
20220 objects that modify the sequence elements. The problem is that
20221 for_each is in a secion entitled "nonmutating algorithms", and the
20222 title may be confusing. A nonnormative note should clarify that.</p>
20229 <h3><a name="478"></a>478. Should forward iterator requirements table have a line for r->m?</h3>
20230 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20231 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
20232 <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>
20233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20234 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
20235 <p><b>Discussion:</b></p>
20237 The Forward Iterator requirements table contains the following:
20239 <pre> expression return type operational precondition
20241 ========== ================== =========== ==========================
20242 a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined.
20243 otherwise const U&
20245 r->m U& (*r).m pre: (*r).m is well-defined.
20248 <p>The second line may be unnecessary. Paragraph 11 of
20249 [lib.iterator.requirements] says:
20253 In the following sections, a and b denote values of type const X, n
20254 denotes a value of the difference type Distance, u, tmp, and m
20255 denote identifiers, r denotes a value of X&, t denotes a value of
20256 value type T, o denotes a value of some type that is writable to
20257 the output iterator.
20261 Because operators can be overloaded on an iterator's const-ness, the
20262 current requirements allow iterators to make many of the operations
20263 specified using the identifiers a and b invalid for non-const
20266 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
20269 <p><b>Proposed resolution:</b></p>
20271 <p>Remove the "r->m" line from the Forward Iterator requirements
20283 <p>in paragraph 11 of [lib.iterator.requirements].</p>
20288 <p><b>Rationale:</b></p>
20290 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
20298 <h3><a name="488"></a>488. rotate throws away useful information</h3>
20299 <p><b>Section:</b> 25.2.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20300 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2004-11-22</p>
20301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20302 <p><b>Discussion:</b></p>
20304 rotate takes 3 iterators: first, middle and last which point into a
20305 sequence, and rearranges the sequence such that the subrange [middle,
20306 last) is now at the beginning of the sequence and the subrange [first,
20307 middle) follows. The return type is void.
20311 In many use cases of rotate, the client needs to know where the
20312 subrange [first, middle) starts after the rotate is performed. This
20315 <pre> rotate(first, middle, last);
20316 Iterator i = advance(first, distance(middle, last));
20320 Unless the iterators are random access, the computation to find the
20321 start of the subrange [first, middle) has linear complexity. However,
20322 it is not difficult for rotate to return this information with
20323 negligible additional computation expense. So the client could code:
20325 <pre> Iterator i = rotate(first, middle, last);
20329 and the resulting program becomes significantly more efficient.
20333 While the backwards compatibility hit with this change is not zero, it
20334 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
20335 a significant benefit to the change.
20340 <p><b>Proposed resolution:</b></p>
20341 <p>In 25 [algorithms] p2, change:</p>
20343 <blockquote><pre> template<class ForwardIterator>
20344 <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
20345 ForwardIterator last);
20346 </pre></blockquote>
20348 <p>In 25.2.11 [alg.rotate], change:</p>
20350 <blockquote><pre> template<class ForwardIterator>
20351 <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
20352 ForwardIterator last);
20353 </pre></blockquote>
20355 <p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p>
20358 <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
20362 The LWG agrees with this idea, but has one quibble: we want to make
20363 sure not to give the impression that the function "advance" is
20364 actually called, just that the nth iterator is returned. (Calling
20365 advance is observable behavior, since users can specialize it for
20366 their own iterators.) Howard will provide wording.
20370 <p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
20374 Toronto: moved to Ready.
20384 <h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
20385 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20386 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</p>
20387 <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>
20388 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20389 <p><b>Discussion:</b></p>
20390 <p>It appears that there are no requirements specified for many of the
20391 template parameters in clause 22. It looks like this issue has never
20392 come up, except perhaps for Facet.</p>
20394 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
20395 either, which is the wording that allows requirements on template
20396 parameters to be identified by name.</p>
20398 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
20399 changed to cover clause 22. A better change, which will cover us in
20400 the future, would be to say that it applies to all the library
20401 clauses. Then if a template gets added to any library clause we are
20404 <p>charT, InputIterator, and other names with requirements defined
20405 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
20406 But there are a few template arguments names which I don't think have
20407 requirements given elsewhere:</p>
20410 <li>internT and externT. The fix is to add wording saying that internT
20411 and externT must meet the same requirements as template arguments
20414 <li>stateT. I'm not sure about this one. There already is some wording,
20415 but it seems a bit vague.</li>
20417 <li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to
20418 rename "Intl" to "International". The name is important because other
20419 text identifies the requirements for the name International but not
20423 <p><b>Proposed resolution:</b></p>
20424 <p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p>
20426 The Requirements subclauses may describe names that are used to
20427 specify constraints on template arguments.153) These names are used in
20428 clauses 20, 23, 25, and 26 to describe the types that may be supplied
20429 as arguments by a C++ program when instantiating template components
20434 The Requirements subclauses may describe names that are used to
20435 specify constraints on template arguments.153) These names are used in
20436 library clauses to describe the types that may be supplied as
20437 arguments by a C++ program when instantiating template components from
20441 <p>In the front matter of class 22, locales, add:</p>
20443 Template parameter types internT and externT shall meet the
20444 requirements of charT (described in 21 [strings]).
20448 <p><b>Rationale:</b></p>
20450 Again, a blanket clause isn't blanket enough. Also, we've got a
20451 couple of names that we don't have blanket requirement statements
20452 for. The only issue is what to do about stateT. This wording is
20453 thin, but probably adequate.</p>
20460 <h3><a name="496"></a>496. Illegal use of "T" in vector<bool></h3>
20461 <p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20462 <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
20463 <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>
20464 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20465 <p><b>Discussion:</b></p>
20467 In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector],
20468 the non-template assign() function has the signature</p>
20470 <pre> void assign( size_type n, const T& t );
20473 <p>The type, T, is not defined in this context.</p>
20476 <p><b>Proposed resolution:</b></p>
20477 <p>Replace "T" with "value_type".</p>
20484 <h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
20485 <p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20486 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p>
20487 <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>
20488 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20489 <p><b>Discussion:</b></p>
20491 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
20494 <p>static const bool traps;<br>
20495 -59- true if trapping is implemented for the type.204)
20497 Footnote 204: Required by LIA-1.
20501 <p>It's not clear what is meant by "is implemented" here.</p>
20504 In the context of floating point numbers it seems reasonable to expect
20505 to be able to use traps to determine whether a program can "safely" use
20506 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
20507 without causing a trap (i.e., on UNIX without having to worry about
20508 getting a signal). When traps is true, I would expect any of the
20509 operations in section 7 of IEEE 754 to cause a trap (and my program
20510 to get a SIGFPE). So, for example, on Alpha, I would expect traps
20511 to be true by default (unless I compiled my program with the -ieee
20512 option), false by default on most other popular architectures,
20513 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
20514 traps to be explicitly enabled by the program.
20518 Another possible interpretation of p59 is that traps should be true
20519 on any implementation that supports traps regardless of whether they
20520 are enabled by default or not. I don't think such an interpretation
20521 makes the traps member very useful, even though that is how traps is
20522 implemented on several platforms. It is also the only way to implement
20523 traps on platforms that allow programs to enable and disable trapping
20528 <p><b>Proposed resolution:</b></p>
20529 <p>Change p59 to read:</p>
20530 <blockquote><p>True if, at program startup, there exists a value of the type that
20531 would cause an arithmetic operation using that value to trap.</p></blockquote>
20534 <p><b>Rationale:</b></p>
20536 Real issue, since trapping can be turned on and off. Unclear what a
20537 static query can say about a dynamic issue. The real advice we should
20538 give users is to use cfenv for these sorts of queries. But this new
20539 proposed resolution is at least consistent and slightly better than
20547 <h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
20548 <p><b>Section:</b> 26.4.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#WP">WP</a>
20549 <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20550 <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>
20551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20552 <p><b>Discussion:</b></p>
20554 Table 17: Random distribution requirements
20557 Row 1 requires that each random distribution provide a nested type "input_type";
20558 this type denotes the type of the values that the distribution consumes.
20561 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
20562 provides a second typedef ("result_type") that denotes the type of the values the
20563 distribution produces when called.
20567 <p><b>Proposed resolution:</b></p>
20569 It seems to me that this is also a requirement
20570 for all distributions and should therefore be indicated as such via a new second
20571 row to this table 17:
20573 <table border="1" cellpadding="5">
20574 <tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
20578 Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1.
20588 <h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
20589 <p><b>Section:</b> 26.4 [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#WP">WP</a>
20590 <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20591 <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>
20592 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20593 <p><b>Discussion:</b></p>
20595 Paragraph 11 of [tr.rand.var] equires that the member template
20597 <blockquote><pre>template<class T> result_type operator() (T value);
20598 </pre></blockquote>
20602 <blockquote><pre>distribution()(e, value)
20603 </pre></blockquote>
20605 However, not all distributions have an operator() with a corresponding signature.
20609 Berlin: As a working group we voted in favor of N1932 which makes this moot:
20610 variate_generator has been eliminated. Then in full committee we voted to give
20611 this issue WP status (mistakenly).
20617 <p><b>Proposed resolution:</b></p>
20619 We therefore recommend that we insert the following precondition before paragraph 11:
20622 Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed.
20630 <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
20631 <p><b>Section:</b> 26.4.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#WP">WP</a>
20632 <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
20633 <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>
20634 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20635 <p><b>Discussion:</b></p>
20637 The fifth of these engines with predefined parameters, ranlux64_base_01,
20638 appears to have an unintentional error for which there is a simple correction.
20639 The two pre-defined subtract_with_carry_01 engines are given as:
20641 <blockquote><pre>typedef subtract_with_carry_01<float, 24, 10, 24> ranlux_base_01;
20642 typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01;
20643 </pre></blockquote>
20645 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
20646 random number generation proposal, but that the simple correction to
20648 <blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01;
20649 </pre></blockquote>
20651 does meet the intent of defining well-known good parameterizations.
20654 The ranlux64_base_01 engine as presented fails to meet the intent for
20655 predefined engines, stated in proposal N1398 (section E):
20658 In order to make good random numbers available to a large number of library
20659 users, this proposal not only defines generic random-number engines, but also
20660 provides a number of predefined well-known good parameterizations for those.
20663 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
20664 long period and so meets this criterion. This property makes it suitable for
20665 use in the excellent discard_block engines defined subsequently. The proof
20666 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
20667 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
20668 as defined in [tr.rand.eng.sub1]).
20671 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
20672 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
20673 explicit factorization would be a challenge). In consequence, while it is
20674 certainly possible for some seeding states that this engine would have a very
20675 long period, it is not at all "well-known" that this is the case. The intent
20676 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
20677 use in the physics community. This is isomorphic to the predefined ranlux_base_01,
20678 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
20679 to deliver 48 random bits at a time rather than 24.
20683 <p><b>Proposed resolution:</b></p>
20685 To achieve this intended behavior, the correct template parameteriztion would be:
20687 <blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01;
20688 </pre></blockquote>
20690 The sequence of mantissa bits delivered by this is isomorphic (treating each
20691 double as having the bits of two floats) to that delivered by ranlux_base_01.
20697 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
20698 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
20699 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
20703 Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5,
20704 just above paragraph 5.
20714 <h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
20715 <p><b>Section:</b> 23.1.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#WP">WP</a>
20716 <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
20717 <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>
20718 <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>
20719 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20720 <p><b>Discussion:</b></p>
20722 Issue 371 deals with stability of multiset/multimap under insert and erase
20723 (i.e. do they preserve the relative order in ranges of equal elements).
20724 The same issue applies to unordered_multiset and unordered_multimap.
20727 Moved to open (from review): There is no resolution.
20732 Toronto: We have a resolution now. Moved to Review. Some concern was noted
20733 as to whether this conflicted with existing practice or not. An additional
20734 concern was in specifying (partial) ordering for an unordered container.
20740 <p><b>Proposed resolution:</b></p>
20742 Wording for the proposed resolution is taken from the equivalent text for associative containers.
20746 Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
20750 An unordered associative container supports <i>unique</i> keys if it may
20751 contain at most one element for each key. Otherwise, it supports <i>equivalent
20752 keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support
20753 unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt>
20754 support equivalent keys. In containers that support equivalent keys, elements
20755 with equivalent keys are adjacent to each other. <ins>For
20756 <tt>unordered_multiset</tt>
20757 and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt>
20758 preserve the relative ordering of equivalent elements.</ins>
20762 Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
20766 <p>The elements of an unordered associative container are organized into <i>
20767 buckets</i>. Keys with the same hash code appear in the same bucket. The number
20768 of buckets is automatically increased as elements are added to an unordered
20769 associative container, so that the average number of elements per bucket is kept
20770 below a bound. Rehashing invalidates iterators, changes ordering between
20771 elements, and changes which buckets elements appear in, but does not invalidate
20772 pointers or references to elements. <ins>For <tt>unordered_multiset</tt>
20773 and <tt>unordered_multimap</tt>, rehashing
20774 preserves the relative ordering of equivalent elements.</ins></p>
20783 <h3><a name="519"></a>519. Data() undocumented</h3>
20784 <p><b>Section:</b> 23.2.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#WP">WP</a>
20785 <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20786 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
20787 <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>
20788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20789 <p><b>Discussion:</b></p>
20791 <tt>array<>::data()</tt> is present in the class synopsis, but not documented.
20795 <p><b>Proposed resolution:</b></p>
20797 Add a new section, after 6.2.2.3:
20799 <blockquote><pre>T* data()
20800 const T* data() const;
20801 </pre></blockquote>
20803 <b>Returns:</b> <tt>elems</tt>.
20806 Change 6.2.2.4/2 to:
20809 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
20810 of <tt>data()</tt> is unspecified.
20818 <h3><a name="520"></a>520. Result_of and pointers to data members</h3>
20819 <p><b>Section:</b> 20.6.11.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#WP">WP</a>
20820 <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20822 <p><b>Discussion:</b></p>
20824 In the original proposal for binders, the return type of bind() when
20825 called with a pointer to member data as it's callable object was
20826 defined to be mem_fn(ptr); when Peter Dimov and I unified the
20827 descriptions of the TR1 function objects we hoisted the descriptions
20828 of return types into the INVOKE pseudo-function and into result_of.
20829 Unfortunately, we left pointer to member data out of result_of, so
20830 bind doesn't have any specified behavior when called with a pointer
20835 <p><b>Proposed resolution:</b></p>
20837 Pete and Peter will provide wording.
20842 In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
20845 <li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
20846 shall be <tt><i>cv</i> R&</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&</tt>,
20847 <tt>R</tt> otherwise.</li>
20851 Peter provided wording.
20861 <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
20862 <p><b>Section:</b> 20.6.5 [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#WP">WP</a>
20863 <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
20864 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20865 <p><b>Discussion:</b></p>
20867 2.1.2/3, second bullet item currently says that reference_wrapper<T> is
20868 derived from unary_function<T, R> if T is:
20871 a pointer to member function type with cv-qualifier cv and no arguments;
20872 the type T1 is cv T* and R is the return type of the pointer to member function;
20875 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
20876 function. It should be a pointer to the class that T is a pointer to member of.
20880 a pointer to a member function R T0::f() cv (where cv represents the member
20881 function's cv-qualifiers); the type T1 is cv T0*
20884 Similarly, bullet item 2 in 2.1.2/4 should be:
20887 a pointer to a member function R T0::f(T2) cv (where cv represents the member
20888 function's cv-qualifiers); the type T1 is cv T0*
20892 <p><b>Proposed resolution:</b></p>
20895 Change bullet item 2 in 2.1.2/3:
20901 a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
20902 the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
20903 type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
20904 (where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
20905 the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20911 Change bullet item 2 in 2.1.2/4:
20917 a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
20918 of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
20919 <tt>R</tt> is the return type of the pointer to member function</del>
20920 <ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
20921 function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
20932 <h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
20933 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
20934 <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
20935 <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>
20936 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
20937 <p><b>Discussion:</b></p>
20939 This defect is also being discussed on the Boost developers list. The
20940 full discussion can be found here:
20941 http://lists.boost.org/boost/2005/07/29546.php
20944 -- Begin original message --
20947 Also, I may have found another issue, closely related to the one under
20948 discussion. It regards case-insensitive matching of named character
20949 classes. The regex_traits<> provides two functions for working with
20950 named char classes: lookup_classname and isctype. To match a char class
20951 such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
20952 bitmask. Later, you pass a char and the bitmask to isctype and get a
20953 bool yes/no answer.
20956 But how does case-insensitivity work in this scenario? Suppose we're
20957 doing a case-insensitive match on [[:lower:]]. It should behave as if it
20958 were [[:lower:][:upper:]], right? But there doesn't seem to be enough
20959 smarts in the regex_traits interface to do this.
20962 Imagine I write a traits class which recognizes [[:fubar:]], and the
20963 "fubar" char class happens to be case-sensitive. How is the regex engine
20964 to know that? And how should it do a case-insensitive match of a
20965 character against the [[:fubar:]] char class? John, can you confirm this
20966 is a legitimate problem?
20972 1) Add a bool icase parameter to lookup_classname. Then,
20973 lookup_classname( "upper", true ) will know to return lower|upper
20974 instead of just upper.
20977 2) Add a isctype_nocase function
20980 I prefer (1) because the extra computation happens at the time the
20981 pattern is compiled rather than when it is executed.
20984 -- End original message --
20988 For what it's worth, John has also expressed his preference for option
20993 <p><b>Proposed resolution:</b></p>
20995 Adopt the proposed resolution in
20996 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
21001 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
21002 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
21010 <h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
21011 <p><b>Section:</b> 20.6.11.1.3 [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#WP">WP</a>
21012 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
21013 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
21014 <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>
21015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21016 <p><b>Discussion:</b></p>
21018 The original bind proposal gives the guarantee that tr1::bind(f, t1,
21019 ..., tN) does not throw when the copy constructors of f, t1, ..., tN
21024 This guarantee is not present in the final version of TR1.
21028 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
21032 Berlin: not quite editorial, needs proposed wording.
21036 Batavia: Doug to translate wording to variadic templates.
21041 Toronto: We agree but aren't quite happy with the wording. The "t"'s no
21042 longer refer to anything. Alan to provide improved wording.
21048 Pre-Bellevue: Alisdair provided wording.
21053 TR1 proposed resolution:
21058 In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
21061 <i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
21062 throws an exception.
21066 Add a new paragraph after p4:
21069 <i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
21070 throws an exception.
21077 <p><b>Proposed resolution:</b></p>
21079 In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
21083 <i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
21084 in the <tt>BoundArgs...</tt> pack expansion throws an exception.
21088 In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
21092 <i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
21093 in the <tt>BoundArgs...</tt> pack expansion throws an exception.
21102 <h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
21103 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21104 <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p>
21105 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
21106 <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>
21107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21108 <p><b>Discussion:</b></p>
21109 <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
21110 that the elements of a vector must be stored in contiguous memory.
21111 Should the same also apply to <tt>basic_string</tt>?</p>
21113 <p>We almost require contiguity already. Clause 23.3.4 [multiset]
21114 defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
21115 is a similar guarantee if we access the string's elements via the
21116 iterator interface.</p>
21118 <p>Given the existence of <tt>data()</tt>, and the definition of
21119 <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
21120 I don't believe it's possible to write a useful and standard-
21121 conforming <tt>basic_string</tt> that isn't contiguous. I'm not
21122 aware of any non-contiguous implementation. We should just require
21127 <p><b>Proposed resolution:</b></p>
21128 <p>Add the following text to the end of 21.3 [basic.string],
21132 <p>The characters in a string are stored contiguously, meaning that if
21133 <tt>s</tt> is a <tt>basic_string<charT, Allocator></tt>, then
21134 it obeys the identity
21135 <tt>&*(s.begin() + n) == &*s.begin() + n</tt>
21136 for all <tt>0 <= n < s.size()</tt>.
21141 <p><b>Rationale:</b></p>
21143 Not standardizing this existing practice does not give implementors more
21144 freedom. We thought it might a decade ago. But the vendors have spoken
21145 both with their implementations, and with their voice at the LWG
21146 meetings. The implementations are going to be contiguous no matter what
21147 the standard says. So the standard might as well give string clients
21148 more design choices.
21156 <h3><a name="531"></a>531. array forms of unformatted input functions</h3>
21157 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21158 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</p>
21159 <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>
21160 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21161 <p><b>Discussion:</b></p>
21163 The array forms of unformatted input functions don't seem to have well-defined
21164 semantics for zero-element arrays in a couple of cases. The affected ones
21165 (<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
21166 terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
21167 never be true when <tt>(n == 0)</tt> holds to start with. See
21172 <p><b>Proposed resolution:</b></p>
21174 I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
21178 <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters
21183 Change 27.6.1.3, p9:
21187 If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
21188 may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n
21189 > 0)</tt> is true</ins> it then stores a null character into the next
21190 successive location of the array.
21195 and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
21200 <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters
21201 are stored (in which case the function calls
21202 <tt>setstate(failbit)</tt>).
21208 In addition, to clarify that <tt>istream::getline()</tt> must not store the
21209 terminating NUL character unless the the array has non-zero size, Robert
21210 Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
21215 In any case, provided <tt>(n > 0)</tt> is true, it then stores a null character
21216 (using charT()) into the next successive location of the array.
21221 post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires
21222 writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix.
21232 <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
21233 <p><b>Section:</b> 20.7.12.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#DR">DR</a>
21234 <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
21235 <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>
21236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
21237 <p><b>Discussion:</b></p>
21239 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
21243 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
21246 but <tt>get_deleter</tt> is a free function!
21250 <p><b>Proposed resolution:</b></p>
21252 Therefore, I think should be:
21255 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
21263 <h3><a name="534"></a>534. Missing basic_string members</h3>
21264 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21265 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</p>
21266 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
21267 <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>
21268 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21269 <p><b>Discussion:</b></p>
21271 OK, we all know std::basic_string is bloated and already has way too
21272 many members. However, I propose it is missing 3 useful members that
21273 are often expected by users believing it is a close approximation of the
21274 container concept. All 3 are listed in table 71 as 'optional'
21282 This is the one I feel most strongly about, as I only just discovered it
21283 was missing as we are switching to a more conforming standard library
21288 I find it particularly inconsistent to support push_back, but not
21297 There are certainly cases where I want to examine the last character of
21298 a string before deciding to append, or to trim trailing path separators
21299 from directory names etc. *rbegin() somehow feels inelegant.
21307 This one I don't feel strongly about, but if I can get the first two,
21308 this one feels that it should be added as a 'me too' for consistency.
21312 I believe this would be similarly useful to the data() member recently
21313 added to vector, or at() member added to the maps.
21317 <p><b>Proposed resolution:</b></p>
21319 Add the following members to definition of class template basic_string, 21.3p7
21321 <blockquote><pre>void pop_back ()
21323 const charT & front() const
21324 charT & front()
21326 const charT & back() const
21328 </pre></blockquote>
21330 Add the following paragraphs to basic_string description
21337 <pre>const charT & front() const
21338 charT & front()
21341 <i>Precondition:</i> <tt>!empty()</tt>
21344 <i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
21352 <pre>const charT & back() const
21356 <i>Precondition:</i> <tt>!empty()</tt>
21359 <i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
21367 <pre>void pop_back ()
21370 <i>Precondition:</i> <tt>!empty()</tt>
21373 <i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
21378 Update Table 71: (optional sequence operations)
21379 Add basic_string to the list of containers for the following operations.
21381 <blockquote><pre>a.front()
21386 </pre></blockquote>
21389 Berlin: Has support. Alisdair provided wording.
21398 <h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
21399 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21400 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-12-14</p>
21401 <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>
21402 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21403 <p><b>Discussion:</b></p>
21405 std::string::swap currently says for effects and postcondition:
21410 <i>Effects:</i> Swaps the contents of the two strings.
21414 <i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
21415 <tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
21420 Specifying both Effects and Postcondition seems redundant, and the postcondition
21421 needs to be made stronger. Users would be unhappy if the characters were not in
21422 the same order after the swap.
21426 <p><b>Proposed resolution:</b></p>
21429 <del><i>Effects:</i> Swaps the contents of the two strings.</del>
21433 <i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
21434 characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
21435 <tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
21436 <del>were</del> <ins>was</ins> in <tt>*this</tt>.
21445 <h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
21446 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21447 <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</p>
21448 <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>
21449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21450 <p><b>Discussion:</b></p>
21452 In the most recent working draft, I'm still seeing:
21455 <blockquote><pre>seekg(off_type& off, ios_base::seekdir dir)
21456 </pre></blockquote>
21462 <blockquote><pre>seekp(pos_type& pos)
21464 seekp(off_type& off, ios_base::seekdir dir)
21465 </pre></blockquote>
21468 that is, by reference off and pos arguments.
21472 <p><b>Proposed resolution:</b></p>
21474 After 27.6.1.3p42 change:
21477 <blockquote><pre>basic_istream<charT,traits>& seekg(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
21478 </pre></blockquote>
21481 After 27.6.2.4p1 change:
21484 <blockquote><pre>basic_ostream<charT,traits>& seekp(pos_type<del>&</del> <i>pos</i>);
21485 </pre></blockquote>
21488 After 27.6.2.4p3 change:
21491 <blockquote><pre>basic_ostream<charT,traits>& seekp(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
21492 </pre></blockquote>
21499 <h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
21500 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21501 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-09</p>
21502 <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>
21503 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21504 <p><b>Discussion:</b></p>
21506 I believe I botched the resolution of
21507 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
21508 241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
21513 This talks about <tt>unique_copy</tt> requirements and currently reads:
21517 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
21518 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
21519 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
21520 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
21521 requirements of forward iterator then the value type of <tt>InputIterator</tt>
21522 must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
21526 The problem (which Paolo discovered) is that when the iterators are at their
21527 most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
21528 <tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
21529 <tt>CopyAssignable</tt> (for the most efficient implementation). However this
21530 proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
21531 and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
21532 This latter requirement does not necessarily imply that you can:
21535 <blockquote><pre>*<i>first</i> = *<i>first</i>;
21536 </pre></blockquote>
21539 <p><b>Proposed resolution:</b></p>
21541 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
21542 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
21543 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
21545 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
21546 requirements of forward iterator then the <del>value type</del>
21547 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
21548 must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
21549 Otherwise CopyConstructible is not required.
21557 <h3><a name="540"></a>540. shared_ptr<void>::operator*()</h3>
21558 <p><b>Section:</b> 20.7.12.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#WP">WP</a>
21559 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
21560 <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>
21561 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21562 <p><b>Discussion:</b></p>
21564 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
21565 that talks about the operator*() member function of shared_ptr:
21569 Notes: When T is void, attempting to instantiate this member function
21570 renders the program ill-formed. [Note: Instantiating shared_ptr<void>
21571 does not necessarily result in instantiating this member function.
21576 with the requirement in temp.inst, p1:
21580 The implicit instantiation of a class template specialization causes
21581 the implicit instantiation of the declarations, but not of the
21586 I assume that what the note is really trying to say is that
21587 "instantiating shared_ptr<void> *must not* result in instantiating
21588 this member function." That is, that this function must not be
21589 declared a member of shared_ptr<void>. Is my interpretation
21594 <p><b>Proposed resolution:</b></p>
21600 -6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
21601 this member function renders the program ill-formed. [<i>Note:</i>
21602 Instantiating <tt>shared_ptr<void></tt> does not necessarily result in
21603 instantiating this member function. <i>--end note</i>]</del> <ins>it is
21604 unspecified whether this member function is declared or not, and if so, what its
21605 return type is, except that the declaration (although not necessarily the
21606 definition) of the function shall be well-formed.</ins>
21615 <h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
21616 <p><b>Section:</b> 20.7.12.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#WP">WP</a>
21617 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
21618 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
21619 <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>
21620 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21621 <p><b>Discussion:</b></p>
21623 Is the void specialization of the template assignment operator taking
21624 a shared_ptr<void> as an argument supposed be well-formed?
21627 I.e., is this snippet well-formed:
21629 <blockquote><pre>shared_ptr<void> p;
21630 p.operator=<void>(p);
21631 </pre></blockquote>
21634 Gcc complains about auto_ptr<void>::operator*() returning a reference
21635 to void. I suspect it's because shared_ptr has two template assignment
21636 operators, one of which takes auto_ptr, and the auto_ptr template gets
21637 implicitly instantiated in the process of overload resolution.
21641 The only way I see around it is to do the same trick with auto_ptr<void>
21642 operator*() as with the same operator in shared_ptr<void>.
21646 PS Strangely enough, the EDG front end doesn't mind the code, even
21647 though in a small test case (below) I can reproduce the error with
21651 <blockquote><pre>template <class T>
21652 struct A { T& operator*() { return *(T*)0; } };
21654 template <class T>
21656 void operator= (const B&) { }
21657 template <class U>
21658 void operator= (const B<U>&) { }
21659 template <class U>
21660 void operator= (const A<U>&) { }
21666 b.operator=<void>(b);
21668 </pre></blockquote>
21671 <p><b>Proposed resolution:</b></p>
21673 In [lib.memory] change:
21675 <blockquote><pre>template<class X> class auto_ptr;
21676 <ins>template<> class auto_ptr<void>;</ins>
21677 </pre></blockquote>
21680 In [lib.auto.ptr]/2 add the following before the last closing brace:
21683 <blockquote><pre>template<> class auto_ptr<void>
21686 typedef void element_type;
21688 </pre></blockquote>
21696 <h3><a name="542"></a>542. shared_ptr observers</h3>
21697 <p><b>Section:</b> 20.7.12.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#WP">WP</a>
21698 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
21699 <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>
21700 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21701 <p><b>Discussion:</b></p>
21704 To: C++ libraries mailing list
21705 Message c++std-lib-15614
21707 The intent is for both use_count() and unique() to work in a threaded environment.
21708 They are intrinsically prone to race conditions, but they never return garbage.
21712 This is a crucial piece of information that I really wish were
21713 captured in the text. Having this in a non-normative note would
21714 have made everything crystal clear to me and probably stopped
21715 me from ever starting this discussion :) Instead, the sentence
21716 in p12 "use only for debugging and testing purposes, not for
21717 production code" very strongly suggests that implementations
21718 can and even are encouraged to return garbage (when threads
21719 are involved) for performance reasons.
21722 How about adding an informative note along these lines:
21725 Note: Implementations are encouraged to provide well-defined
21726 behavior for use_count() and unique() even in the presence of
21730 I don't necessarily insist on the exact wording, just that we
21731 capture the intent.
21735 <p><b>Proposed resolution:</b></p>
21737 Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
21740 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21741 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21745 Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
21748 [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
21749 debugging and testing purposes, not for production code.</del> --<i>end note</i>]
21757 <h3><a name="543"></a>543. valarray slice default constructor</h3>
21758 <p><b>Section:</b> 26.5.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21759 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2005-11-03</p>
21760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21761 <p><b>Discussion:</b></p>
21763 If one explicitly constructs a slice or glice with the default
21764 constructor, does the standard require this slice to have any usable
21765 state? It says "creates a slice which specifies no elements", which
21766 could be interpreted two ways:
21769 <li>There are no elements to which the slice refers (i.e. undefined).</li>
21770 <li>The slice specifies an array with no elements in it (i.e. defined).</li>
21773 Here is a bit of code to illustrate:
21775 <blockquote><pre>#include <iostream>
21776 #include <valarray>
21780 std::valarray<int> v(10);
21781 std::valarray<int> v2 = v[std::slice()];
21782 std::cout << "v[slice()].size() = " << v2.size() << '\n';
21784 </pre></blockquote>
21787 Is the behavior undefined? Or should the output be:
21790 <blockquote><pre>v[slice()].size() = 0
21791 </pre></blockquote>
21794 There is a similar question and wording for gslice at 26.3.6.1p1.
21798 <p><b>Proposed resolution:</b></p>
21800 <p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p>
21804 Change 26.5.4.1 [cons.slice]:
21808 1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
21809 which specifies no elements.</del> <ins>The default constructor is equivalent to
21810 <tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
21811 the declaration of arrays of slices. The constructor with arguments for a slice
21812 takes a start, length, and stride parameter.
21816 Change 26.5.6.1 [gslice.cons]:
21820 1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
21821 elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
21822 valarray<size_t>(), valarray<size_t>())</tt>.</ins> The constructor
21823 with arguments builds a <tt>gslice</tt> based on a specification of start,
21824 lengths, and strides, as explained in the previous section.
21833 <h3><a name="545"></a>545. When is a deleter deleted?</h3>
21834 <p><b>Section:</b> 20.7.12.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#WP">WP</a>
21835 <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
21836 <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>
21837 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21838 <p><b>Discussion:</b></p>
21840 The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
21841 any, is destroyed. In principle there are two possibilities: it is destroyed
21842 unconditionally whenever ~shared_ptr is executed (which, from an implementation
21843 standpoint, means that the deleter is copied whenever the shared_ptr is copied),
21844 or it is destroyed immediately after the owned pointer is destroyed (which, from
21845 an implementation standpoint, means that the deleter object is shared between
21846 instances). We should say which it is.
21850 <p><b>Proposed resolution:</b></p>
21852 Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
21856 The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
21857 that owns <tt><i>d</i></tt>.
21860 [<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
21861 This can happen if the implementation doesn't destroy the deleter until all
21862 <tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
21871 <h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
21872 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
21873 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
21874 <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>
21875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
21876 <p><b>Discussion:</b></p>
21878 Assuming we adopt the
21879 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
21880 compatibility package from C99</a> what should be the return type of the
21881 following signature be:
21883 <blockquote><pre>? pow(float, int);
21884 </pre></blockquote>
21886 C++03 says that the return type should be <tt>float</tt>.
21887 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
21888 TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put
21889 clients into a situation where C++03 provides answers that are not as high
21890 quality as C90/C99/TR1. For example:
21892 <blockquote><pre>#include <math.h>
21896 float x = 2080703.375F;
21897 double y = pow(x, 2);
21899 </pre></blockquote>
21901 Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
21904 <blockquote><pre>y = 4329326534736.390625
21905 </pre></blockquote>
21908 which is exactly right. While C++98/C++03 demands:
21911 <blockquote><pre>y = 4329326510080.
21912 </pre></blockquote>
21915 which is only approximately right.
21919 I recommend that C++0X adopt the mixed mode arithmetic already adopted by
21920 Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
21925 Kona (2007): Other functions that are affected by this issue include
21926 <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
21927 26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
21928 nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
21929 resolution appears above, rather than below, the heading "Proposed
21940 Unfortunately I strongly disagree with a part of the resolution
21941 from Kona. I am moving from New to Open instead of to Review because I do not believe
21942 we have consensus on the intent of the resolution.
21945 This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
21946 the second integral parameter in each of these signatures (from C99) is <b>not</b> a
21947 <i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are
21948 intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
21951 For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
21952 <tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the
21953 correct signature is:
21956 <pre>float nexttoward(float, long double);
21960 which is what both the C++0X working paper and C99 state (as far as I currently understand).
21963 This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one
21964 route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt><tgmath.h></tt>.
21965 The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
21977 This signature was not picked up from C99. Instead, if one types
21978 pow(2.0f,2), the promotion rules will invoke "double pow(double,
21979 double)", which generally gives special treatment for integral
21980 exponents, preserving full accuracy of the result. New proposed
21985 <p><b>Proposed resolution:</b></p>
21987 Change 26.7 [c.math] p10:
21992 The added signatures are:
21994 <blockquote><pre>...
21995 <del>float pow(float, int);</del>
21997 <del>double pow(double, int);</del>
21999 <del>long double pow(long double, int);</del>
22000 </pre></blockquote>
22009 <h3><a name="551"></a>551. <ccomplex></h3>
22010 <p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22011 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
22012 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22013 <p><b>Discussion:</b></p>
22015 Previously xxx.h was parsable by C++. But in the case of C99's <complex.h>
22016 it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>:
22020 <li><string> : C++ API in namespace std</li>
22021 <li><cstring> : C API in namespace std</li>
22022 <li><string.h> : C API in global namespace</li>
22026 In the case of C's complex, the C API won't compile in C++. So we have:
22030 <li><complex> : C++ API in namespace std</li>
22031 <li><ccomplex> : ?</li>
22032 <li><complex.h> : ?</li>
22036 The ? can't refer to the C API. TR1 currently says:
22040 <li><complex> : C++ API in namespace std</li>
22041 <li><ccomplex> : C++ API in namespace std</li>
22042 <li><complex.h> : C++ API in global namespace</li>
22047 <p><b>Proposed resolution:</b></p>
22049 Change 26.3.11 [cmplxh]:
22054 The header behaves as if it includes the header
22055 <tt><ccomplex></tt><ins>.</ins><del>, and provides sufficient using
22056 declarations to declare in the global namespace all function and type names
22057 declared or defined in the neader <tt><complex></tt>.</del>
22058 <ins>[<i>Note:</i> <tt><complex.h></tt> does not promote any interface
22059 into the global namespace as there is no C interface to promote. <i>--end
22070 <h3><a name="552"></a>552. random_shuffle and its generator</h3>
22071 <p><b>Section:</b> 25.2.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22072 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-01-25</p>
22073 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22074 <p><b>Discussion:</b></p>
22076 ...is specified to shuffle its range by calling swap but not how
22077 (or even that) it's supposed to use the RandomNumberGenerator
22078 argument passed to it.
22081 Shouldn't we require that the generator object actually be used
22082 by the algorithm to obtain a series of random numbers and specify
22083 how many times its operator() should be invoked by the algorithm?
22087 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
22088 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
22089 for some further discussion.
22094 <p><b>Proposed resolution:</b></p>
22096 Adopt the proposed resolution in
22097 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
22102 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
22103 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
22111 <h3><a name="559"></a>559. numeric_limits<const T></h3>
22112 <p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22113 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p>
22114 <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>
22115 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22116 <p><b>Discussion:</b></p>
22119 18.2.1 [limits], p2 requires implementations to provide specializations of the
22120 <code>numeric_limits</code> template for each scalar type. While this
22121 could be interepreted to include cv-qualified forms of such types such
22122 an interepretation is not reflected in the synopsis of the
22123 <code><limits></code> header.
22128 The absence of specializations of the template on cv-qualified forms
22129 of fundamental types makes <code>numeric_limits</code> difficult to
22130 use in generic code where the constness (or volatility) of a type is
22131 not always immediately apparent. In such contexts, the primary
22132 template ends up being instantiated instead of the provided
22133 specialization, typically yielding unexpected behavior.
22138 Require that specializations of <code>numeric_limits</code> on
22139 cv-qualified fundamental types have the same semantics as those on the
22140 unqualifed forms of the same types.
22145 <p><b>Proposed resolution:</b></p>
22148 Add to the synopsis of the <code><limits></code> header,
22149 immediately below the declaration of the primary template, the
22154 template <class T> class numeric_limits<const T>;
22155 template <class T> class numeric_limits<volatile T>;
22156 template <class T> class numeric_limits<const volatile T>;
22162 Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following
22168 -new-para- The value of each member of a <code>numeric_limits</code>
22169 specialization on a cv-qualified T is equal to the value of the same
22170 member of <code>numeric_limits<T></code>.
22175 Portland: Martin will clarify that user-defined types get cv-specializations
22186 <h3><a name="561"></a>561. inserter overly generic</h3>
22187 <p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22188 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p>
22189 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22190 <p><b>Discussion:</b></p>
22192 The declaration of <tt>std::inserter</tt> is:
22195 <blockquote><pre>template <class Container, class Iterator>
22196 insert_iterator<Container>
22197 inserter(Container& x, Iterator i);
22198 </pre></blockquote>
22201 The template parameter <tt>Iterator</tt> in this function is completely unrelated
22202 to the template parameter <tt>Container</tt> when it doesn't need to be. This
22203 causes the code to be overly generic. That is, any type at all can be deduced
22204 as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of
22205 <tt>Container</tt>. However, for every free (unconstrained) template parameter
22206 one has in a signature, the opportunity for a mistaken binding grows geometrically.
22210 It would be much better if <tt>inserter</tt> had the following signature instead:
22213 <blockquote><pre>template <class Container>
22214 insert_iterator<Container>
22215 inserter(Container& x, typename Container::iterator i);
22216 </pre></blockquote>
22219 Now there is only one free template parameter. And the second argument to
22220 <tt>inserter</tt> must be implicitly convertible to the container's iterator,
22221 else the call will not be a viable overload (allowing other functions in the
22222 overload set to take precedence). Furthermore, the first parameter must have a
22223 nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
22224 is not viable. Contrast this with the current situation
22225 where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
22226 types need not be anything closely related to containers or iterators.
22230 This can adversely impact well written code. Consider:
22233 <blockquote><pre>#include <iterator>
22234 #include <string>
22239 template <class String>
22242 struct my_container
22244 template <class String>
22245 void push_back(const my_type<String>&);
22248 template <class String>
22249 void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);}
22255 my::my_container c;
22256 my::my_type<std::string> m;
22259 </pre></blockquote>
22262 Today this code fails because the call to <tt>inserter</tt> binds to
22263 <tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the
22264 proposed change <tt>std::inserter</tt> will no longer be a viable function which
22265 leaves only <tt>my::inserter</tt> in the overload resolution set. Everything
22266 works as the client intends.
22270 To make matters a little more insidious, the above example works today if you
22271 simply change the first argument to an rvalue:
22274 <blockquote><pre> inserter(my::my_type(), c);
22275 </pre></blockquote>
22278 It will also work if instantiated with some string type other than
22279 <tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if
22280 <tt><iterator></tt> happens to not get included.
22284 And it will fail again for such inocuous reaons as <tt>my_type</tt> or
22285 <tt>my_container</tt> privately deriving from any <tt>std</tt> type.
22289 It seems unfortunate that such simple changes in the client's code can result
22290 in such radically differing behavior.
22295 <p><b>Proposed resolution:</b></p>
22301 <b>24.2 Header</b> <tt><iterator></tt> <b>synopsis</b>
22303 <blockquote><pre>...
22304 template <class Container<del>, class Iterator</del>>
22305 insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
22307 </pre></blockquote>
22315 <b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
22316 <blockquote><pre>...
22317 template <class Container<del>, class Iterator</del>>
22318 insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
22320 </pre></blockquote>
22329 <b>24.4.2.6.5</b> <tt>inserter</tt>
22331 <pre>template <class Container<del>, class Inserter</del>>
22332 insert_iterator<Container> inserter(Container& x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
22335 -1- <i>Returns:</i> <tt>insert_iterator<Container>(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
22342 Kona (2007): This issue will probably be addressed as a part of the
22343 concepts overhaul of the library anyway, but the proposed resolution is
22344 correct in the absence of concepts. Proposed Disposition: Ready
22352 <h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
22353 <p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22354 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
22355 <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>
22356 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22357 <p><b>Discussion:</b></p>
22360 For better efficiency, the requirement on the stringbuf ctor that
22361 takes a string argument should be loosened up to let it set
22362 <code>epptr()</code> beyond just one past the last initialized
22363 character just like <code>overflow()</code> has been changed to be
22364 allowed to do (see issue 432). That way the first call to
22365 <code>sputc()</code> on an object won't necessarily cause a call to
22366 <code>overflow</code>. The corresponding change should be made to the
22367 string overload of the <code>str()</code> member function.
22372 <p><b>Proposed resolution:</b></p>
22375 Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
22379 <blockquote><pre>explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& <i>s<del>tr</del></i>,
22380 ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
22384 -3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>,
22385 initializing the base class with <tt>basic_streambuf()</tt>
22386 (27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
22387 Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
22388 <i>str</i> into the <tt>basic_stringbuf</tt> underlying character
22389 sequence. If <tt><i>which</i> & ios_base::out</tt> is true, initializes the
22390 output sequence such that <tt>pbase()</tt> points to the first underlying
22391 character, <tt>epptr()</tt> points one past the last underlying character, and
22392 <tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> & ios_base::ate</tt>
22393 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
22394 <tt>which & ios_base::in</tt> is true, initializes the input sequence such
22395 that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
22396 character and <tt>egptr()</tt> points one past the last underlying character.</del>
22402 Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
22408 -2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
22409 <tt>basic_stringbuf</tt> underlying character sequence <ins>and
22410 initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
22412 <tt><i>mode</i> & ios_base::out</tt> is true, initializes the output
22413 sequence such that <tt>pbase()</tt> points to the first underlying character,
22414 <tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
22415 is equal to <tt>epptr()</tt> if <tt><i>mode</i> & ios_base::in</tt>
22416 is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
22417 <tt>mode & ios_base::in</tt> is true, initializes the input sequence
22418 such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
22419 character and <tt>egptr()</tt> points one past the last underlying character.</del>
22424 <ins>-3- <i>Postconditions:</i> If <code>mode & ios_base::out</code> is true,
22425 <code>pbase()</code> points to the first underlying character and
22426 <code>(epptr() >= pbase() + s.size())</code> holds; in addition, if
22427 <code>mode & ios_base::in</code> is true, <code>(pptr() == pbase()
22428 + s.data())</code> holds, otherwise <code>(pptr() == pbase())</code>
22429 is true. If <code>mode & ios_base::in</code> is true,
22430 <code>eback()</code> points to the first underlying character, and
22431 <code>(gptr() == eback())</code> and <code>(egptr() == eback() +
22432 s.size())</code> hold.</ins>
22439 Kona (2007) Moved to Ready.
22447 <h3><a name="563"></a>563. stringbuf seeking from end</h3>
22448 <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22449 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
22450 <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>
22451 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22452 <p><b>Discussion:</b></p>
22454 According to Table 92 (unchanged by issue 432), when <code>(way ==
22455 end)</code> the <code>newoff</code> value in out mode is computed as
22456 the difference between <code>epptr()</code> and <code>pbase()</code>.
22460 This value isn't meaningful unless the value of <code>epptr()</code>
22461 can be precisely controlled by a program. That used to be possible
22462 until we accepted the resolution of issue 432, but since then the
22463 requirements on <code>overflow()</code> have been relaxed to allow it
22464 to make more than 1 write position available (i.e., by setting
22465 <code>epptr()</code> to some unspecified value past
22466 <code>pptr()</code>). So after the first call to
22467 <code>overflow()</code> positioning the output sequence relative to
22468 end will have unspecified results.
22473 In addition, in <code>in|out</code> mode, since <code>(egptr() ==
22474 epptr())</code> need not hold, there are two different possible values
22475 for <code>newoff</code>: <code>epptr() - pbase()</code> and
22476 <code>egptr() - eback()</code>.
22481 <p><b>Proposed resolution:</b></p>
22484 Change the <code>newoff</code> column in the last row of Table 94 to
22490 the <del>end</del> <ins>high mark</ins> pointer minus the beginning
22491 pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
22497 Kona (2007) Moved to Ready.
22505 <h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
22506 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22507 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
22508 <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>
22509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22510 <p><b>Discussion:</b></p>
22513 The array forms of unformatted input functions don't have well-defined
22514 semantics for zero-element arrays in a couple of cases. The affected
22515 ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to
22516 terminate when <tt>(n - 1)</tt> characters are stored, which obviously
22517 can never be true when <tt>(n == 0)</tt> to start with.
22522 <p><b>Proposed resolution:</b></p>
22525 I propose the following changes (references are relative to the
22526 Working Draft (document N1804).
22531 Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
22537 <ins>if <tt>(n < 1)</tt> is true or </ins> <tt>(n - 1)</tt>
22538 characters are stored;
22544 Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
22551 <ins><tt>(n < 1)</tt> is true or </ins><tt>(n - 1)</tt> characters
22552 are stored (in which case the function calls
22553 <tt>setstate(failbit)</tt>).
22559 Finally, change p21 as follows:
22565 In any case, <ins>provided <tt>(n > 0)</tt> is true, </ins>it then
22566 stores a null character (using charT()) into the next successive
22567 location of the array.
22577 <h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
22578 <p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22579 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
22580 <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>
22581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22582 <p><b>Discussion:</b></p>
22585 Issue 60 explicitly made the extractor and inserter operators that
22586 take a <tt>basic_streambuf*</tt> argument formatted input and output
22587 functions, respectively. I believe that's wrong, certainly in the
22588 case of the extractor, since formatted functions begin by extracting
22589 and discarding whitespace. The extractor should not discard any
22595 <p><b>Proposed resolution:</b></p>
22598 I propose to change each operator to behave as unformatted input and
22599 output function, respectively. The changes below are relative to the
22600 working draft document number N1804.
22605 Specifically, change 27.6.1.2.3, p14 as follows:
22612 <i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function
22613 (as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph
22620 And change 27.6.2.5.3, p7 as follows:
22627 <i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function
22628 (as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph
22636 Kona (2007): Proposed Disposition: Ready
22644 <h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
22645 <p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22646 <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
22647 <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>
22648 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22649 <p><b>Discussion:</b></p>
22651 lib.iostream.objects requires that the standard stream objects are never
22652 destroyed, and it requires that they be destroyed.
22655 DR 369 adds words to say that we really mean for ios_base::Init objects to force
22656 construction of standard stream objects. It ends, though, with the phrase "these
22657 stream objects shall be destroyed after the destruction of dynamically ...".
22658 However, the rule for destruction is stated in the standard: "The objects are
22659 not destroyed during program execution."
22663 <p><b>Proposed resolution:</b></p>
22665 Change 27.3 [iostream.objects]/1:
22670 -2- The objects are constructed and the associations are established at
22671 some time prior to or during the first time an object of class
22672 <tt>ios_base::Init</tt> is constructed, and in any case before the body of main
22673 begins execution.<sup>290)</sup> The objects are not destroyed during program
22674 execution.<sup>291)</sup> If a translation unit includes <tt><iostream&t;</tt> or explicitly
22675 constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
22676 constructed before dynamic initialization of non-local objects defined
22677 later in that translation unit<del>, and these stream objects shall be
22678 destroyed after the destruction of dynamically initialized non-local
22679 objects defined later in that translation unit</del>.
22685 Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
22686 shall be destroyed after the destruction of dynamically initialized
22687 non-local objects defined later in that translation unit." Proposed
22688 Disposition: Review
22696 <h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
22697 <p><b>Section:</b> 20.7.12.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#WP">WP</a>
22698 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
22699 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22700 <p><b>Discussion:</b></p>
22702 [tr.util.smartptr.shared.dest] says in its second bullet:
22706 "If *this shares ownership with another shared_ptr instance (use_count() > 1),
22707 decrements that instance's use count."
22711 The problem with this formulation is that it presupposes the existence of an
22712 "use count" variable that can be decremented and that is part of the state of a
22713 shared_ptr instance (because of the "that instance's use count".)
22717 This is contrary to the spirit of the rest of the specification that carefully
22718 avoids to require an use count variable. Instead, use_count() is specified to
22719 return a value, a number of instances.
22723 In multithreaded code, the usual implicit assumption is that a shared variable
22724 should not be accessed by more than one thread without explicit synchronization,
22725 and by introducing the concept of an "use count" variable, the current wording
22726 implies that two shared_ptr instances that share ownership cannot be destroyed
22731 In addition, if we allow the interpretation that an use count variable is part
22732 of shared_ptr's state, this would lead to other undesirable consequences WRT
22733 multiple threads. For example,
22736 <blockquote><pre>p1 = p2;
22737 </pre></blockquote>
22740 would now visibly modify the state of p2, a "write" operation, requiring a lock.
22744 <p><b>Proposed resolution:</b></p>
22746 Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
22751 <li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
22752 <tt>shared_ptr</tt> instance (<tt>use_count() > 1</tt>)</ins>, there are no side effects.</li>
22753 <li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
22754 (<tt>use_count() > 1</tt>), decrements that instance's use count.</del></li>
22759 Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
22763 [<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
22764 <tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
22765 with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
22766 after <tt>*this</tt> is destroyed. <i>--end note</i>]
22774 <h3><a name="576"></a>576. find_first_of is overconstrained</h3>
22775 <p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22776 <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
22777 <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>
22778 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22779 <p><b>Discussion:</b></p>
22781 In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
22782 find_first_of are specified to require Forward Iterators, as follows:
22785 <blockquote><pre>template<class ForwardIterator1, class ForwardIterator2>
22787 find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
22788 ForwardIterator2 first2, ForwardIterator2 last2);
22789 template<class ForwardIterator1, class ForwardIterator2,
22790 class BinaryPredicate>
22792 find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
22793 ForwardIterator2 first2, ForwardIterator2 last2,
22794 BinaryPredicate pred);
22795 </pre></blockquote>
22798 However, ForwardIterator1 need not actually be a Forward Iterator; an Input
22799 Iterator suffices, because we do not need the multi-pass property of the Forward
22800 Iterator or a true reference.
22804 <p><b>Proposed resolution:</b></p>
22806 Change the declarations of <tt>find_first_of</tt> to:
22809 <blockquote><pre>template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2>
22810 <del>ForwardIterator1</del><ins>InputIterator1</ins>
22811 find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
22812 ForwardIterator2 first2, ForwardIterator2 last2);
22813 template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
22814 class BinaryPredicate>
22815 <del>ForwardIterator1</del><ins>InputIterator1</ins>
22816 find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
22817 ForwardIterator2 first2, ForwardIterator2 last2,
22818 BinaryPredicate pred);
22819 </pre></blockquote>
22827 <h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
22828 <p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22829 <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
22830 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22831 <p><b>Discussion:</b></p>
22833 ISO/IEC 14882:2003 says:
22838 25.3.3.2 upper_bound
22841 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
22842 <tt>[<i>first</i>, <i>last</i>)</tt> such that
22843 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
22844 conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
22849 From the description above, upper_bound cannot return last, since it's
22850 not in the interval [first, last). This seems to be a typo, because if
22851 value is greater than or equal to any other values in the range, or if
22852 the range is empty, returning last seems to be the intended behaviour.
22853 The corresponding interval for lower_bound is also [first, last].
22857 <p><b>Proposed resolution:</b></p>
22859 Change [lib.upper.bound]:
22864 <i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
22865 <tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
22866 for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
22867 conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
22877 <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
22878 <p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22879 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
22880 <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>
22881 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22882 <p><b>Discussion:</b></p>
22885 The description of the allocator member function
22886 <code>allocate()</code> requires that the <i>hint</i> argument be
22887 either 0 or a value previously returned from <code>allocate()</code>.
22888 Footnote 227 further suggests that containers may pass the address of
22889 an adjacent element as this argument.
22894 I believe that either the footnote is wrong or the normative
22895 requirement that the argument be a value previously returned from a
22896 call to <code>allocate()</code> is wrong. The latter is supported by
22897 the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan
22898 Myers. In addition, the <i>hint</i> is an ordinary void* and not the
22899 <code>pointer</code> type returned by <code>allocate()</code>, with
22900 the two types potentially being incompatible and the requirement
22901 impossible to satisfy.
22906 See also c++std-lib-14323 for some more context on where this came up
22912 <p><b>Proposed resolution:</b></p>
22915 Remove the requirement in 20.6.1.1, p4 that the hint be a value
22916 previously returned from <code>allocate()</code>. Specifically, change
22917 the paragraph as follows:
22921 <del><i>Requires</i>: <i>hint</i> either 0 or previously obtained from member
22922 <code>allocate</code> and not yet passed to member <code>deallocate</code>.
22923 The value hint may be used by an implementation to help improve performance
22924 <sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
22925 implementation to help improve performance. -- <i>end note</i>]</ins>
22928 <del>[Footnote: <sup>223)</sup>In a container member function, the address of an
22929 adjacent element is often a good choice to pass for this argument.</del>
22936 <h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
22937 <p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22938 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
22939 <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>
22940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22941 <p><b>Discussion:</b></p>
22944 The resolution of issue 60 changed <code>basic_ostream::flush()</code>
22945 so as not to require it to behave as an unformatted output function.
22946 That has at least two in my opinion problematic consequences:
22951 First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code>
22952 unconditionally, without regard to the state of the stream. I can't
22953 think of any reason why <code>flush()</code> should behave differently
22954 from the vast majority of stream functions in this respect.
22959 Second, <code>flush()</code> is not required to catch exceptions from
22960 <code>pubsync()</code> or set <code>badbit</code> in response to such
22961 events. That doesn't seem right either, as most other stream functions
22967 <p><b>Proposed resolution:</b></p>
22970 I propose to revert the resolution of issue 60 with respect to
22971 <code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7
22977 Effects: <ins>Behaves as an unformatted output function (as described
22978 in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
22979 pointer, <ins>constructs a sentry object. If this object returns
22980 <code>true</code> when converted to a value of type bool the function
22981 </ins>calls <code>rdbuf()->pubsync()</code>. If that function returns
22982 -1 calls <code>setstate(badbit)</code> (which may throw
22983 <code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the
22984 sentry object returns <code>false</code>, does nothing.</ins><del>Does
22985 not behave as an unformatted output function (as described in
22986 27.6.2.6, paragraph 1).</del>
22992 Kona (2007): Proposed Disposition: Ready
23000 <h3><a name="586"></a>586. string inserter not a formatted function</h3>
23001 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23002 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
23003 <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>
23004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23005 <p><b>Discussion:</b></p>
23008 Section and paragraph numbers in this paper are relative to the
23009 working draft document number N2009 from 4/21/2006.
23015 The <code>basic_string</code> extractor in 21.3.7.9, p1 is clearly
23016 required to behave as a formatted input function, as is the
23017 <code>std::getline()</code> overload for string described in p7.
23022 However, the <code>basic_string</code> inserter described in p5 of the
23023 same section has no such requirement. This has implications on how the
23024 operator responds to exceptions thrown from <code>xsputn()</code>
23025 (formatted output functions are required to set <code>badbit</code>
23026 and swallow the exception unless <code>badbit</code> is also set in
23027 <code>exceptions()</code>; the string inserter doesn't have any such
23033 I don't see anything in the spec for the string inserter that would
23034 justify requiring it to treat exceptions differently from all other
23035 similar operators. (If it did, I think it should be made this explicit
23036 by saying that the operator "does not behave as a formatted output
23037 function" as has been made customary by the adoption of the resolution
23043 <p><b>Proposed resolution:</b></p>
23046 I propose to change the Effects clause in 21.3.7.9, p5, as follows:
23052 <i>Effects</i>: <del>Begins by constructing a sentry object k as if k
23053 were constructed by typename <code>basic_ostream<charT,
23054 traits>::sentry k (os)</code>. If <code>bool(k)</code> is
23055 <code>true</code>, </del><ins>Behaves as a formatted output function
23056 (27.6.2.5.1). After constructing a <code>sentry</code> object, if
23057 this object returns <code>true</code> when converted to a value of
23058 type <code>bool</code>, determines padding as described in
23059 22.2.2.2.2</ins>, then inserts the resulting sequence of characters
23060 <code><i>seq</i></code> as if by calling <code>os.rdbuf()->sputn(seq ,
23061 n)</code>, where <code><i>n</i></code> is the larger of
23062 <code>os.width()</code> and <code>str.size()</code>; then calls
23063 <code>os.width(0)</code>. <del>If the call to sputn fails, calls
23064 <code>os.setstate(ios_base::failbit)</code>.</del>
23070 This proposed resilution assumes the resolution of issue 394 (i.e.,
23071 that all formatted output functions are required to set
23072 <code>ios_base::badbit</code> in response to any kind of streambuf
23073 failure), and implicitly assumes that a return value of
23074 <code>sputn(seq, <i>n</i>)</code> other than <code><i>n</i></code>
23075 indicates a failure.
23083 <h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
23084 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23085 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</p>
23086 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
23087 <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>
23088 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23089 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
23090 <p><b>Discussion:</b></p>
23092 There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
23093 terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
23094 (requires InputIterator::value_type be the same type as the container's value_type).
23098 <p><b>Proposed resolution:</b></p>
23104 In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
23105 value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
23106 iterator requirements <ins>and refer to elements <ins>implicitly
23107 convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
23108 range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
23109 valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
23110 iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
23111 and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
23119 In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
23120 of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
23121 unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
23122 multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
23123 refer to elements <del>of</del> <ins>implicitly convertible to</ins>
23124 <tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
23125 iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
23126 <tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
23127 value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
23128 and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
23133 <p><b>Rationale:</b></p>
23135 Concepts will probably come in and rewrite this section anyway. But just in case it is
23136 easy to fix this up as a safety net and as a clear statement of intent.
23144 <h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
23145 <p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23146 <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
23147 <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>
23148 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23149 <p><b>Discussion:</b></p>
23151 Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
23152 <cstdint> and <stdint.h>. These are of course based on the C99 header
23153 <stdint.h>, and were part of TR1.
23157 Per 18.3.1/1, these headers define a number of macros and function macros.
23158 While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
23159 footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The
23160 header defines all ... macros the same as C99 subclause 7.18."
23164 Therefore, if I wish to have the above-referenced macros and function macros
23165 defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or
23166 does the C++ header define these macros/function macros unconditionally?
23170 <p><b>Proposed resolution:</b></p>
23172 To put this issue to rest for C++0X, I propose the following addition to
23173 18.3.1/2 of the Working Paper N2009:
23177 [Note: The macros defined by <cstdint> are provided unconditionally: in
23178 particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
23179 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
23187 <h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3>
23188 <p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23189 <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
23190 <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>
23191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23192 <p><b>Discussion:</b></p>
23194 TR1 introduced, in the C compatibility chapter, the function
23195 fabs(complex<T>):
23197 <blockquote><pre>----- SNIP -----
23198 8.1.1 Synopsis [tr.c99.cmplx.syn]
23203 template<class T> complex<T> fabs(const complex<T>& x);
23209 8.1.8 Function fabs [tr.c99.cmplx.fabs]
23211 1 Effects: Behaves the same as C99 function cabs, defined in
23214 </pre></blockquote>
23217 The current C++0X draft document (n2009.pdf) adopted this
23218 definition in chapter 26.3.1 (under the comment // 26.3.7 values)
23222 But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
23223 n1124), the referenced subclause reads
23226 <blockquote><pre>----- SNIP -----
23227 7.3.8.1 The cabs functions
23231 1 #include <complex.h>
23232 double cabs(double complex z);
23233 float cabsf(float complex z);
23234 long double cabsl(long double z);
23238 2 The cabs functions compute the complex absolute value (also called
23239 norm, modulus, or magnitude) of z.
23243 3 The cabs functions return the complex absolute value.
23245 </pre></blockquote>
23248 Note that the return type of the cabs*() functions is not a complex
23249 type. Thus, they are equivalent to the already well established
23250 template<class T> T abs(const complex<T>& x);
23251 (26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
23252 document n2009.pdf).
23255 So either the return value of fabs() is specified wrongly, or fabs()
23256 does not behave the same as C99's cabs*().
23259 <b>Possible Resolutions</b>
23262 This depends on the intention behind the introduction of fabs().
23265 If the intention was to provide a /complex/ valued function that
23266 calculates the magnitude of its argument, this should be
23267 explicitly specified. In TR1, the categorization under "C
23268 compatibility" is definitely wrong, since C99 does not provide
23269 such a complex valued function.
23272 Also, it remains questionable if such a complex valued function
23273 is really needed, since complex<T> supports construction and
23274 assignment from real valued arguments. There is no difference
23275 in observable behaviour between
23277 <blockquote><pre> complex<double> x, y;
23279 complex<double> z(fabs(x));
23280 </pre></blockquote>
23284 <blockquote><pre> complex<double> x, y;
23286 complex<double> z(abs(x));
23287 </pre></blockquote>
23289 If on the other hand the intention was to provide the intended
23290 functionality of C99, fabs() should be either declared deprecated
23291 or (for C++0X) removed from the standard, since the functionality
23292 is already provided by the corresponding overloads of abs().
23301 Bill believes that abs() is a suitable overload. We should remove fabs().
23305 <p><b>Proposed resolution:</b></p>
23308 Change the synopsis in 26.3.1 [complex.synopsis]:
23311 <blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del>
23312 </pre></blockquote>
23315 Remove 26.3.7 [complex.value.ops], p7:
23319 <pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del>
23323 <del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
23331 Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
23332 Proposed Disposition: Ready
23340 <h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
23341 <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
23342 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
23343 <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>
23344 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
23345 <p><b>Discussion:</b></p>
23347 In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
23349 <blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
23350 </pre></blockquote>
23352 and we expect the open to fail, because out|in|app is not listed in
23353 Table 92, and just before the table we see very specific words:
23356 If mode is not some combination of flags shown in the table
23357 then the open fails.
23360 But the corresponding table in the C standard, 7.19.5.3, provides two
23361 modes "a+" and "a+b", to which the C++ modes out|in|app and
23362 out|in|app|binary would presumably apply.
23365 We would like to argue that the intent of Table 112 was to match the
23366 semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
23367 unintentional. (Otherwise there would be valid and useful behaviors
23368 available in C file I/O which are unavailable using C++, for no
23369 valid functional reason.)
23372 We further request that the missing modes be explicitly restored to
23373 the WP, for inclusion in C++0x.
23382 ...besides "a+" and "a+b" the C++ table is also missing a row
23383 for a lone app bit which in at least two current implementation
23384 as well as in Classic Iostreams corresponds to the C stdio "a"
23385 mode and has been traditionally documented as implying ios::out.
23386 Which means the table should also have a row for in|app meaning
23387 the same thing as "a+" already proposed in the issue.
23391 <p><b>Proposed resolution:</b></p>
23393 Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
23398 <caption> File open modes</caption>
23400 <th colspan="5"><tt>ios_base</tt> Flag combination</th>
23401 <th><tt>stdio</tt> equivalent</th>
23404 <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> </tt></th>
23408 <td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"w"</tt></td>
23411 <td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
23414 <td> </td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
23417 <td> </td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w"</tt></td>
23420 <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"r"</tt></td>
23423 <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+"</tt></td>
23426 <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+"</tt></td>
23429 <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
23432 <td> </td> <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
23436 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"wb"</tt></td>
23439 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
23442 <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
23445 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"wb"</tt></td>
23448 <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"rb"</tt></td>
23451 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+b"</tt></td>
23454 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+b"</tt></td>
23456 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
23459 <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
23469 Kona (2007) Added proposed wording and moved to Review.
23477 <h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
23478 <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>
23479 <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
23480 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
23481 <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>
23482 <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>
23483 <p><b>Discussion:</b></p>
23486 In a private email, Daniel writes:
23491 ask, what where the reason for the decision to
23492 define the semantics of the integral conversion of the decimal types, namely
23494 <pre>"operator long long() const;
23496 Returns: Returns the result of the
23497 conversion of *this to the type long long, as if
23498 performed by the expression llrounddXX(*this)."
23501 where XX stands for either 32, 64, or 128,
23502 corresponding to the proper decimal type. The
23503 exact meaning of llrounddXX is not given in that
23504 paper, so I compared it to the corresponding
23505 definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
23508 "The lround and llround functions round their
23509 argument to the nearest integer value,
23510 rounding halfway cases away from zero, regardless
23511 of the current rounding direction. [..]"
23514 Now considering the fact that integral conversion
23515 of the usual floating-point types ("4.9
23516 Floating-integral conversions") has truncation
23517 semantic I wonder why this conversion behaviour
23518 has not been transferred for the decimal types.
23525 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>.
23530 <p><b>Proposed resolution:</b></p>
23532 Change the <b>Returns:</b> clause in 3.2.2.4 to:
23535 <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>.
23538 Change the <b>Returns:</b> clause in 3.2.3.4 to:
23541 <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>.
23544 Change the <b>Returns:</b> clause in 3.2.4.4 to:
23547 <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>.
23556 <h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
23557 <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>
23558 <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
23559 <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>
23560 <p><b>Discussion:</b></p>
23562 Daniel writes in a private email:
23567 - 3.1 'Decimal type encodings' says in its note:
23569 <pre>"this implies that
23570 sizeof(std::decimal::decimal32) == 4,
23571 sizeof(std::decimal::decimal64) == 8, and
23572 sizeof(std::decimal::decimal128) == 16."
23575 This is a wrong assertion, because the definition
23576 of 'byte' in 1.7 'The C+ + memory model' of ISO
23577 14882 (2nd edition) does not specify that a byte
23578 must be necessarily 8 bits large, which would be
23579 necessary to compare with the specified bit sizes
23580 of the types decimal32, decimal64, and decimal128.
23585 <p><b>Proposed resolution:</b></p>
23587 Change 3.1 as follows:
23591 The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
23595 decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
23598 decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
23602 decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
23606 <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>
23614 <h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
23615 <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>
23616 <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
23617 <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>
23618 <p><b>Discussion:</b></p>
23623 - 3.9.1 'Additions to <cwchar>' provides wrong
23624 signatures to the wcstod32, wcstod64, and
23625 wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
23629 <p><b>Proposed resolution:</b></p>
23631 Change "3.9.1 Additions to <code><cwchar></code> synopsis" to:
23633 <pre> namespace std {
23634 namespace decimal {
23635 // 3.9.2 wcstod functions:
23636 decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
23637 decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
23638 decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
23647 <h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
23648 <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>
23649 <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
23650 <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>
23651 <p><b>Discussion:</b></p>
23653 Daniel writes in a private email:
23658 - 3.3 'Additions to header <limits>' contains two
23659 errors in the specialisation of numeric_limits<decimal::decimal128>:
23662 <li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
23663 <li>The static member digits is assigned to 384,
23664 this should be 34 (Probably mixed up with the
23665 max. exponent for decimal::decimal64).</li>
23670 <p><b>Proposed resolution:</b></p>
23672 In "3.3 Additions to header <code><limits></code>" change numeric_limits<decimal::decimal128> as follows:
23674 <pre> template<> class numeric_limits<decimal::decimal128> {
23676 static const bool is_specialized = true;
23678 static decimal::decimal128 min() throw() { return DEC128_MIN; }
23679 static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
23681 static const int digits = <del>384</del> <ins>34</ins>;
23689 <h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
23690 <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>
23691 <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
23692 <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>
23693 <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>
23694 <p><b>Discussion:</b></p>
23696 The document uses the term "generic floating types," but defines it nowhere.
23700 <p><b>Proposed resolution:</b></p>
23702 Change the first paragraph of "3 Decimal floating-point types" as follows:
23705 This Technical Report introduces three decimal floating-point types, named
23706 decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
23707 subset of the set of values of type decimal64; the set of values of the type
23708 decimal64 is a subset of the set of values of the type decimal128. Support for
23709 decimal128 is optional. <ins>These types supplement the Standard C++ types
23710 <code>float</code>, <code>double</code>, and <code>long double</code>, which are
23711 collectively described as the <i>basic floating types</i></ins>.
23718 <h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
23719 <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>
23720 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
23721 <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>
23722 <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>
23723 <p><b>Discussion:</b></p>
23724 <p>In c++std-lib-17198, Martin writes:</p>
23727 Each of the three classes proposed in the paper (decimal32, decimal64,
23728 and decimal128) explicitly declares and specifies the semantics of its
23729 copy constructor, copy assignment operator, and destructor. Since the
23730 semantics of all three functions are identical to the trivial versions
23731 implicitly generated by the compiler in the absence of any declarations
23732 it is safe to drop them from the spec. This change would make the
23733 proposed classes consistent with other similar classes already in the
23734 standard (e.g., std::complex).
23738 <p><b>Proposed resolution:</b></p>
23740 Change "3.2.2 Class <code>decimal32</code>" as follows:
23742 <pre> namespace std {
23743 namespace decimal {
23746 // 3.2.2.1 construct/copy/destroy:
23748 <del>decimal32(const decimal32 & d32);</del>
23749 <del>decimal32 & operator=(const decimal32 & d32);</del>
23750 <del>~decimal32();</del>
23754 Change "3.2.2.1 construct/copy/destroy" as follows:
23758 Effects: Constructs an object of type decimal32 with the value 0;
23760 <del>decimal32(const decimal32 & d32);</del>
23761 <del>decimal32 & operator=(const decimal32 & d32);</del>
23763 <del>Effects: Copies an object of type decimal32.</del>
23765 <del>~decimal32();</del>
23767 <del>Effects: Destroys an object of type decimal32.</del>
23771 Change "3.2.3 Class <code>decimal64</code>" as follows:
23773 <pre> namespace std {
23774 namespace decimal {
23777 // 3.2.3.1 construct/copy/destroy:
23779 <del>decimal64(const decimal64 & d64);</del>
23780 <del>decimal64 & operator=(const decimal64 & d64);</del>
23781 <del>~decimal64();</del>
23785 Change "3.2.3.1 construct/copy/destroy" as follows:
23789 Effects: Constructs an object of type decimal64 with the value 0;
23791 <del>decimal64(const decimal64 & d64);</del>
23792 <del>decimal64 & operator=(const decimal64 & d64);</del>
23794 <del>Effects: Copies an object of type decimal64.</del>
23796 <del>~decimal64();</del>
23798 <del>Effects: Destroys an object of type decimal64.</del>
23802 Change "3.2.4 Class <code>decimal128</code>" as follows:
23804 <pre> namespace std {
23805 namespace decimal {
23808 // 3.2.4.1 construct/copy/destroy:
23810 <del>decimal128(const decimal128 & d128);</del>
23811 <del>decimal128 & operator=(const decimal128 & d128);</del>
23812 <del>~decimal128();</del>
23816 Change "3.2.4.1 construct/copy/destroy" as follows:
23818 <pre> decimal128();
23820 Effects: Constructs an object of type decimal128 with the value 0;
23822 <del>decimal128(const decimal128 & d128);</del>
23823 <del>decimal128 & operator=(const decimal128 & d128);</del>
23825 <del>Effects: Copies an object of type decimal128.</del>
23827 <del>~decimal128();</del>
23829 <del>Effects: Destroys an object of type decimal128.</del>
23837 <h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
23838 <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>
23839 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
23840 <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>
23841 <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>
23842 <p><b>Discussion:</b></p>
23844 In c++std-lib-17197, Martin writes:
23847 The extended_num_get and extended_num_put facets are designed
23848 to store a reference to a num_get or num_put facet which the
23849 extended facets delegate the parsing and formatting of types
23850 other than decimal. One form of the extended facet's ctor (the
23851 default ctor and the size_t overload) obtains the reference
23852 from the global C++ locale while the other form takes this
23853 reference as an argument.
23856 The problem with storing a reference to a facet in another
23857 object (as opposed to storing the locale object in which the
23858 facet is installed) is that doing so bypasses the reference
23859 counting mechanism designed to prevent a facet that is still
23860 being referenced (i.e., one that is still installed in some
23861 locale) from being destroyed when another locale that contains
23862 it is destroyed. Separating a facet reference from the locale
23863 it comes from van make it cumbersome (and in some cases might
23864 even make it impossible) for programs to prevent invalidating
23865 the reference. (The danger of this design is highlighted in
23869 This problem could be easily avoided by having the extended
23870 facets store a copy of the locale from which they would extract
23871 the base facet either at construction time or when needed. To
23872 make it possible, the forms of ctors of the extended facets that
23873 take a reference to the base facet would need to be changed to
23874 take a locale argument instead.
23878 <p><b>Proposed resolution:</b></p>
23880 1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
23882 <pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
23886 <del>// <i>const std::num_get<charT, InputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del>
23887 <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
23890 2. Change the description of the above constructor in 3.10.2.1:
23892 <pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
23897 <b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
23899 <pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0)
23900 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
23905 <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>
23909 3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to
23912 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
23915 4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
23917 <pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
23921 <del>// <i>const std::num_put<charT, OutputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del>
23922 <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
23925 5. Change the description of the above constructor in 3.10.3.1:
23927 <pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
23931 <b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
23933 <pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0)
23934 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
23939 <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>
23943 6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &, char_type, bool &) const</code>, <i>et al</i> to
23946 <b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
23950 Redmond: We would prefer to rename "extended" to "decimal".
23959 <h3><a name="605"></a>605. Decimal: <decfloat.h> doesn't live here anymore.</h3>
23960 <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>
23961 <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
23962 <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>
23963 <p><b>Discussion:</b></p>
23965 In Berlin, WG14 decided to drop the <decfloat.h> header. The
23966 contents of that header have been moved into <float.h>. For the
23967 sake of C compatibility, we should make corresponding changes.
23971 <p><b>Proposed resolution:</b></p>
23973 1. Change the heading of subclause 3.4, "Headers <code><cdecfloat></code> and <code><decfloat.h></code>" to "Additions to headers <code><cfloat></code> and <code><float.h></code>."
23976 2. Change the text of subclause 3.4 as follows:
23980 <del>The standard C++ headers <code><cfloat></code> and <code><float.h></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>
23983 <del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
23986 <ins>The header <code><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></code>
23987 is described in [tr.c99.floath]. These headers are extended by this
23988 Technical Report to define characteristics of the decimal
23989 floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><float.h></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>
23993 3. Change the heading of subclause 3.4.1, "Header <code><cdecfloat></code> synopsis" to "Additions to header <code><cfloat></code> synopsis."
23996 4. Change the heading of subclause 3.4.2, "Header <code><decfloat.h></code> synopsis" to "Additions to header <code><float.h></code> synopsis."
23999 5. Change the contents of 3.4.2 as follows:
24001 <pre> <del>#include <cdecfloat></del>
24003 // <i>C-compatibility convenience typedefs:</i>
24005 typedef std::decimal::decimal32 _Decimal32;
24006 typedef std::decimal::decimal64 _Decimal64;
24007 typedef std::decimal::decimal128 _Decimal128;
24015 <h3><a name="607"></a>607. Concern about short seed vectors</h3>
24016 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24017 <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
24018 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
24019 <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>
24020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24021 <p><b>Discussion:</b></p>
24023 Short seed vectors of 32-bit quantities all result in different states. However
24024 this is not true of seed vectors of 16-bit (or smaller) quantities. For example
24028 <blockquote><pre>unsigned short seed = {1, 2, 3};
24029 unsigned short seed = {1, 2, 3, 0};
24030 </pre></blockquote>
24036 <blockquote><pre>unsigned seed = {0x20001, 0x3};
24037 </pre></blockquote>
24040 yielding the same state.
24044 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24045 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24046 for some further discussion.
24050 <p><b>Proposed resolution:</b></p>
24052 Adopt the proposed resolution in
24053 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24058 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24059 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24067 <h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
24068 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24069 <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
24070 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
24071 <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>
24072 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24073 <p><b>Discussion:</b></p>
24075 In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
24076 treatment of signed quantities is unclear. Better to spell it out.
24080 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
24081 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
24082 for some further discussion.
24086 <p><b>Proposed resolution:</b></p>
24088 Adopt the proposed resolution in
24089 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
24094 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
24095 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
24103 <h3><a name="609"></a>609. missing static const</h3>
24104 <p><b>Section:</b> 26.4.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#WP">WP</a>
24105 <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
24106 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24107 <p><b>Discussion:</b></p>
24109 In preparing N2111, an error on my part resulted in the omission of the
24110 following line from the template synopsis in the cited section:
24113 <blockquote><pre>static const size_t word_size = w;
24114 </pre></blockquote>
24117 (This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
24121 <p><b>Proposed resolution:</b></p>
24123 Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
24126 <blockquote><pre>// engine characteristics
24127 <ins>static const size_t word_size = w;</ins>
24128 </pre></blockquote>
24131 and accept my apologies for the oversight.
24139 <h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
24140 <p><b>Section:</b> 20.6.15.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#WP">WP</a>
24141 <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
24142 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24143 <p><b>Discussion:</b></p>
24145 My suggestion is that implementers of both tr1::function and its
24146 official C++0x successor be explicitly encouraged (but not required) to
24147 optimize for the cases mentioned above, i.e., function pointers and
24148 small function objects. They could do this by using a small internal
24149 buffer akin to the buffer used by implementations of the small string
24150 optimization. (That would make this the small functor optimization --
24151 SFO :-}) The form of this encouragement could be a note in the standard
24152 akin to footnote 214 of the current standard.
24156 Dave Abrahams notes:
24160 "shall not throw exceptions" should really be "nothing," both to be more
24161 grammatical and to be consistent with existing wording in the standard.
24165 Doug Gregor comments: I think this is a good idea. Currently, implementations of
24166 tr1::function are required to have non-throwing constructors and assignment
24167 operators when the target function object is a function pointer or a
24168 reference_wrapper. The common case, however, is for a tr1::function to store
24169 either an empty function object or a member pointer + an object pointer.
24172 The function implementation in the upcoming Boost 1.34.0 uses the
24173 "SFO", so that the function objects for typical bind expressions like
24175 <blockquote><pre>bind(&X::f, this, _1, _2, _3)
24176 </pre></blockquote>
24179 do not require heap allocation when stored in a boost::function. I
24180 believe Dinkumware's implementation also performs this optimization.
24185 <p><b>Proposed resolution:</b></p>
24187 Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
24192 <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
24193 pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
24194 may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
24195 the stored function object.
24198 <ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
24199 allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
24200 is an object holding only a pointer or reference to an object and a member
24201 function pointer (a "bound member function").</ins>
24210 <h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
24211 <p><b>Section:</b> 17.4.3.7 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24212 <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
24213 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24214 <p><b>Discussion:</b></p>
24216 In the latest available draft standard
24217 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
24218 § 17.4.3.6 [res.on.functions] states:
24223 -1- In certain cases (replacement functions, handler functions, operations on
24224 types used to instantiate standard library template components), the C++
24225 Standard Library depends on components supplied by a C++ program. If these
24226 components do not meet their requirements, the Standard places no requirements
24227 on the implementation.
24231 -2- In particular, the effects are undefined in the following cases:
24237 <li>if an incomplete type (3.9) is used as a template argument when
24238 instantiating a template component. </li>
24243 This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
24253 The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
24258 <p><b>Proposed resolution:</b></p>
24260 Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
24266 <li>if an incomplete type (3.9) is used as a template argument when
24267 instantiating a template component<ins>, unless specifically allowed for the
24268 component</ins>. </li>
24278 <h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
24279 <p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24280 <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
24281 <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>
24282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24283 <p><b>Discussion:</b></p>
24285 18.2.1.2 55 states that "A type is modulo if it is possible to add two
24286 positive numbers together and have a result that wraps around to a
24287 third number that is less".
24288 This seems insufficient for the following reasons:
24292 <li>Doesn't define what that value received is.</li>
24293 <li>Doesn't state the result is repeatable</li>
24294 <li> Doesn't require that doing addition, subtraction and other
24295 operations on all values is defined behaviour.</li>
24299 Batavia: Related to
24300 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
24301 Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined.
24306 Bellevue: accept resolution, move to ready status.
24307 Does this mandate that is_modulo be true on platforms for which int
24308 happens to b modulo? A: the standard already seems to require that.
24313 <p><b>Proposed resolution:</b></p>
24315 Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to:
24319 A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
24320 and have a result that wraps around to a third number that is less.</del>
24321 <ins>given any operation involving +,- or * on values of that type whose value
24322 would fall outside the range <tt>[min(), max()]</tt>, then the value returned
24323 differs from the true value by an integer multiple of <tt>(max() - min() +
24333 <h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
24334 <p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24335 <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
24336 <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>
24337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24338 <p><b>Discussion:</b></p>
24340 Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided
24341 for all specializations."
24344 Then it goes on to show specializations for float and bool, where one member
24345 is missing (max_digits10).
24349 Maarten Kronenburg adds:
24353 I agree, just adding the comment that the exact number of decimal digits
24354 is digits * ln(radix) / ln(10), where probably this real number is
24355 rounded downward for digits10, and rounded upward for max_digits10
24356 (when radix=10, then digits10=max_digits10).
24357 Why not add this exact definition also to the standard, so the user
24358 knows what these numbers exactly mean.
24366 For reference, here are the correct formulas from
24367 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
24370 <blockquote><pre>digits10 = floor((digits-1) * log10(2))
24371 max_digits10 = ceil((1 + digits) * log10(2))
24372 </pre></blockquote>
24375 We are also missing a statement regarding for what specializations this member has meaning.
24380 <p><b>Proposed resolution:</b></p>
24382 Change and add after 18.2.1.2 [numeric.limits.members], p11:
24386 <pre>static const int max_digits10;</pre>
24389 -11- Number of base 10 digits required to ensure that values which
24390 differ <del>by only one epsilon</del> are always differentiated.
24393 -12- Meaningful for all floating point types.
24399 Change 18.2.1.5 [numeric.special], p2:
24402 <blockquote><pre>template<> class numeric_limits<float> {
24404 static const bool is_specialized = true;
24406 static const int digits10 = 6;
24407 <ins>static const int max_digits10 = 9</ins>;
24409 </pre></blockquote>
24412 Change 18.2.1.5 [numeric.special], p3:
24415 <blockquote><pre>template<> class numeric_limits<bool> {
24417 static const bool is_specialized = true;
24419 static const int digits10 = 0;
24420 <ins>static const int max_digits10 = 0</ins>;
24422 </pre></blockquote>
24431 <h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
24432 <p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24433 <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
24434 <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>
24435 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24436 <p><b>Discussion:</b></p>
24438 Section 22.2.1.2 defines the ctype_byname class template. It contains the
24442 <blockquote><pre>typedef ctype<charT>::mask mask;
24443 </pre></blockquote>
24447 <p><b>Proposed resolution:</b></p>
24449 as this is a dependent type, it should obviously be
24452 <blockquote><pre>typedef <ins>typename</ins> ctype<charT>::mask mask;
24453 </pre></blockquote>
24460 <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
24461 <p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24462 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
24463 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24464 <p><b>Discussion:</b></p>
24466 I would respectfully request an issue be opened with the intention to
24467 clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
24471 <p><b>Proposed resolution:</b></p>
24473 Change 26.5.2.7 [valarray.members], paragraph 10:
24478 <pre>valarray<T> cshift(int <i>n</i>) const;
24483 This function returns an object of class <tt>valarray<T></tt>, of
24484 length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
24485 <tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
24486 the leftmost element, a positive value of <i>n</i> shifts the elements
24487 circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
24488 element zero is taken as the leftmost element, a non-negative value of
24489 <i>n</i> shifts the elements circularly left <i>n</i> places and a
24490 negative value of <i>n</i> shifts the elements circularly right
24491 -<i>n</i> places.</ins>
24498 <p><b>Rationale:</b></p>
24500 We do not believe that there is any real ambiguity about what happens
24501 when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
24502 expression causes more trouble that it solves. The expression is
24503 certainly wrong when <tt>n < 0</tt>, since the sign of % with negative arguments
24504 is implementation defined.
24509 Kona (2007) Changed proposed wording, added rationale and set to Review.
24517 <h3><a name="619"></a>619. Longjmp wording problem</h3>
24518 <p><b>Section:</b> 18.9 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24519 <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
24520 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24521 <p><b>Discussion:</b></p>
24523 The wording for <tt>longjmp</tt> is confusing.
24526 18.9 [support.runtime] -4- Other runtime support
24529 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
24530 behavior in this International Standard. If any automatic objects would
24531 be destroyed by a thrown exception transferring control to another
24532 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
24533 the throw point that transfers control to the same (destination) point has
24534 undefined behavior.
24537 Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
24538 *at* the throw point that transfers control".
24541 Bill Gibbons thinks it should say something like "If any automatic objects
24542 would be destroyed by an exception thrown at the point of the longjmp and
24543 caught only at the point of the setjmp, the behavior is undefined."
24547 <p><b>Proposed resolution:</b></p>
24549 In general, accept Bill Gibbons' recommendation,
24550 but add "call" to indicate that the undefined behavior
24551 comes from the dynamic call, not from its presence in the code.
24552 In 18.9 [support.runtime] paragraph 4, change
24556 The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
24557 restricted behavior in this International Standard. <del>If any automatic
24558 objects would be destroyed by a thrown exception transferring control to another
24559 (destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
24560 that the throw point that transfers control to the same (destination) point has
24561 undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
24562 undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
24563 <tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
24571 <h3><a name="620"></a>620. valid uses of empty valarrays</h3>
24572 <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24573 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
24574 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
24575 <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>
24576 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24577 <p><b>Discussion:</b></p>
24580 The <i>Effects</i> clause for the default <code>valarray</code> ctor
24581 suggests that it is possible to increase the size of an empty
24582 <code>valarray</code> object by calling other non-const member
24583 functions of the class besides <code>resize()</code>. However, such an
24584 interpretation would be contradicted by the requirement on the copy
24585 assignment operator (and apparently also that on the computed
24586 assignments) that the assigned arrays be the same size. See the
24587 reflector discussion starting with c++std-lib-17871.
24592 In addition, <i>Footnote</i> 280 uses some questionable normative
24598 <p><b>Proposed resolution:</b></p>
24601 Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]):
24607 <code>valarray();</code>
24612 <i>Effects</i>: Constructs an object of class
24613 <code>valarray<T></code>,<sup>279)</sup> which has zero
24614 length<del> until it is passed into a library function as a modifiable
24615 lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
24620 <ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
24625 <i>Footnote 280</i>: This default constructor is essential, since
24626 arrays of <code>valarray</code> <del>are likely to prove useful.
24627 There shall also be a way to change the size of an array after
24628 initialization; this is supplied by the semantics</del> <ins>may be
24629 useful. The length of an empty array can be increased after
24630 initialization by means</ins> of the <code>resize()</code> member
24641 <h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
24642 <p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24643 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
24644 <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>
24645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24646 <p><b>Discussion:</b></p>
24649 The computed and "fill" assignment operators of <code>valarray</code>
24650 helper array class templates (<code>slice_array</code>,
24651 <code>gslice_array</code>, <code>mask_array</code>, and
24652 <code>indirect_array</code>) are const member functions of each class
24653 template (the latter by the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
24654 since they have reference semantics and thus do not affect
24655 the state of the object on which they are called. However, the copy
24656 assignment operators of these class templates, which also have
24657 reference semantics, are non-const. The absence of constness opens
24658 the door to speculation about whether they really are intended to have
24659 reference semantics (existing implementations vary widely).
24664 Pre-Kona, Martin adds:
24668 I realized that adding the const qualifier to the
24669 functions as I suggested would break the const correctness of the
24670 classes. A few possible solutions come to mind:
24674 <li>Add the const qualifier to the return types of these functions.</li>
24675 <li>Change the return type of all the functions to void to match
24676 the signatures of all the other assignment operators these classes
24678 <li>Prohibit the copy assignment of these classes by declaring the
24679 copy assignment operators private (as is done and documented by
24680 some implementations).</li>
24685 <p><b>Proposed resolution:</b></p>
24688 Declare the copy assignment operators of all four helper array
24689 class templates const.
24694 Specifically, make the following edits:
24699 Change the signature in 26.5.5 [template.slice.array] and
24700 26.5.5.1 [slice.arr.assign] as follows:
24704 <code><ins>const</ins> slice_array& operator= (const slice_array&)<ins> const</ins>;</code>
24706 </pre></blockquote>
24709 Change the signature in 26.5.7 [template.gslice.array] and
24710 26.5.7.1 [gslice.array.assign] as follows:
24714 <code><ins>const</ins> gslice_array& operator= (const gslice_array&)<ins> const</ins>;</code>
24716 </pre></blockquote>
24719 Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as
24724 <code><ins>const</ins> mask_array& operator= (const mask_array&)<ins> const</ins>;</code>
24726 </pre></blockquote>
24729 Change the signature in 26.5.9 [template.indirect.array] and
24730 26.5.9.1 [indirect.array.assign] as follows:
24734 <code><ins>const</ins> indirect_array& operator= (const indirect_array&)<ins> const</ins>;</code>
24736 </pre></blockquote>
24740 Kona (2007) Added const qualification to the return types and set to Ready.
24748 <h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
24749 <p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24750 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
24751 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24752 <p><b>Discussion:</b></p>
24755 <code>basic_filebuf</code> dtor is specified to have the following
24756 straightforward effects:
24761 <i>Effects</i>: Destroys an object of class
24762 <code>basic_filebuf</code>. Calls <code>close()</code>.
24767 <code>close()</code> does a lot of potentially complicated processing,
24768 including calling <code>overflow()</code> to write out the termination
24769 sequence (to bring the output sequence to its initial shift
24770 state). Since any of the functions called during the processing can
24771 throw an exception, what should the effects of an exception be on the
24772 dtor? Should the dtor catch and swallow it or should it propagate it
24773 to the caller? The text doesn't seem to provide any guidance in this
24774 regard other than the general restriction on throwing (but not
24775 propagating) exceptions from destructors of library classes in
24776 17.4.4.9 [res.on.exception.handling].
24781 Further, the last thing <code>close()</code> is specified to do is
24782 call <code>fclose()</code> to close the <code>FILE</code> pointer. The
24783 last sentence of the <i>Effects</i> clause reads:
24788 ... If any of the calls to <code>overflow</code> or
24789 <code>std::fclose</code> fails then <code>close</code> fails.
24794 This suggests that <code>close()</code> might be required to call
24795 <code>fclose()</code> if and only if none of the calls to
24796 <code>overflow()</code> fails, and avoid closing the <code>FILE</code>
24797 otherwise. This way, if <code>overflow()</code> failed to flush out
24798 the data, the caller would have the opportunity to try to flush it
24799 again (perhaps after trying to deal with whatever problem may have
24800 caused the failure), rather than losing it outright.
24805 On the other hand, the function's <i>Postcondition</i> specifies that
24806 <code>is_open() == false</code>, which suggests that it should call
24807 <code>fclose()</code> unconditionally. However, since
24808 <i>Postcondition</i> clauses are specified for many functions in the
24809 standard, including constructors where they obviously cannot apply
24810 after an exception, it's not clear whether this <i>Postcondition</i>
24811 clause is intended to apply even after an exception.
24816 It might be worth noting that the traditional behavior (Classic
24817 Iostreams <code>fstream::close()</code> and C <code>fclose()</code>)
24818 is to close the <code>FILE</code> unconditionally, regardless of
24824 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues.
24830 <p><b>Proposed resolution:</b></p>
24833 After discussing this on the reflector (see the thread starting with
24834 c++std-lib-17650) we propose that <code>close()</code> be clarified to
24835 match the traditional behavior, that is to close the <code>FILE</code>
24836 unconditionally, even after errors or exceptions. In addition, we
24837 propose the dtor description be amended so as to explicitly require it
24838 to catch and swallow any exceptions thrown by <code>close()</code>.
24843 Specifically, we propose to make the following edits in
24844 27.8.1.4 [filebuf.members]:
24849 <code>basic_filebuf<charT,traits>* close();</code>
24854 <i>Effects</i>: If <code>is_open() == false</code>, returns a null
24855 pointer. If a put area exists, calls
24856 <code>overflow(traits::eof())</code> to flush characters. If the last
24857 virtual member function called on <code>*this</code> (between
24858 <code>underflow</code>, <code>overflow</code>, <code>seekoff</code>,
24859 and <code>seekpos</code>) was <code>overflow</code> then calls
24860 <code>a_codecvt.unshift</code> (possibly several times) to determine a
24861 termination sequence, inserts those characters and calls
24862 <code>overflow(traits::eof())</code> again. Finally<ins>, regardless
24863 of whether any of the preceding calls fails or throws an exception,
24864 the function</ins> <del>it</del> closes the file ("as if" by calling
24865 <code>std::fclose(file)</code>).<sup>334)</sup> If any of the calls
24866 <ins>made by the function</ins><del>to <code>overflow</code>
24867 or</del><ins>, including </ins><code>std::fclose</code><ins>, </ins>
24868 fails then <code>close</code> fails<ins> by returning a null pointer.
24869 If one of these calls throws an exception, the exception is caught and
24870 rethrown after closing the file.</ins>
24876 And to make the following edits in 27.8.1.2 [filebuf.cons].
24881 <code>virtual ~basic_filebuf();</code>
24886 <i>Effects</i>: Destroys an object of class
24887 <code>basic_filebuf<charT,traits></code>. Calls
24888 <code>close()</code>. <ins>If an exception occurs during the
24889 destruction of the object, including the call to <code>close()</code>,
24890 the exception is caught but not rethrown (see
24891 17.4.4.9 [res.on.exception.handling]).</ins>
24901 <h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
24902 <p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24903 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
24904 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24905 <p><b>Discussion:</b></p>
24908 27.1.1 [iostream.limits.imbue] specifies that "no function described in
24909 clause 27 except for <code>ios_base::imbue</code> causes any instance
24910 of <code>basic_ios::imbue</code> or
24911 <code>basic_streambuf::imbue</code> to be called."
24916 That contradicts the <i>Effects</i> clause for
24917 <code>basic_streambuf::pubimbue()</code> which requires the function
24918 to do just that: call <code>basic_streambuf::imbue()</code>.
24923 <p><b>Proposed resolution:</b></p>
24926 To fix this, rephrase the sentence above to allow
24927 <code>pubimbue</code> to do what it was designed to do. Specifically.
24928 change 27.1.1 [iostream.limits.imbue], p1 to read:
24933 No function described in clause 27 except for
24934 <code>ios_base::imbue</code> <ins>and <code>basic_filebuf::pubimbue</code></ins>
24935 causes any instance of <code>basic_ios::imbue</code> or
24936 <code>basic_streambuf::imbue</code> to be called. ...
24945 <h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
24946 <p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
24947 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
24948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24949 <p><b>Discussion:</b></p>
24952 The behavior of the <code>valarray</code> copy assignment operator is
24953 defined only when both sides have the same number of elements and the
24954 spec is explicit about assignments of arrays of unequal lengths having
24955 undefined behavior.
24960 However, the generalized subscripting assignment operators overloaded
24961 on <code>slice_array</code> et al (26.5.2.2 [valarray.assign]) don't have any
24962 such restriction, leading the reader to believe that the behavior of
24963 these overloads is well defined regardless of the lengths of the
24969 For example, based on the reading of the spec the behavior of the
24970 snippet below can be expected to be well-defined:
24973 <pre> const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2
24974 const std::valarray<int> a (1, 3); // a = { 1, 1, 1 }
24975 std::valarray<int> b (2, 4); // b = { 2, 2, 2, 2 }
24977 b = a [from_0_to_3];
24981 In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
24982 <code>{ 1, 1, 1, 2 }</code>, or anything else, indicating that
24983 existing implementations vary.
24988 Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
24989 Proposal for Standard C++ Array Classes (see c++std-lib-704;
24990 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
24993 ...if the size of the array on the right hand side of the equal
24994 sign differs from the size of the array on the left, a run time
24995 error occurs. How this error is handled is implementation
24996 dependent; for compilers which support it, throwing an exception
24997 would be reasonable.
25001 And see more history in
25002 <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
25007 It has been argued in discussions on the committee's reflector that
25008 the semantics of all <code>valarray</code> assignment operators should
25009 be permitted to be undefined unless the length of the arrays being
25010 assigned is the same as the length of the one being assigned from. See
25011 the thread starting at c++std-lib-17786.
25016 In order to reflect such views, the standard must specify that the
25017 size of the array referred to by the argument of the assignment must
25018 match the size of the array under assignment, for example by adding a
25019 <i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows:
25024 <i>Requires</i>: The length of the array to which the argument refers
25025 equals <code>size()</code>.
25031 Note that it's far from clear that such leeway is necessary in order
25032 to implement <code>valarray</code> efficiently.
25037 <p><b>Proposed resolution:</b></p>
25039 Insert new paragraph into 26.5.2.2 [valarray.assign]:
25043 <pre>valarray<T>& operator=(const slice_array<T>&);
25044 valarray<T>& operator=(const gslice_array<T>&);
25045 valarray<T>& operator=(const mask_array<T>&);
25046 valarray<T>& operator=(const indirect_array<T>&);
25050 <i>Requires</i>: The length of the array to which the argument refers
25051 equals <code>size()</code>.
25054 These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
25064 <h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
25065 <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>
25066 <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</p>
25067 <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>
25068 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25069 <p><b>Discussion:</b></p>
25071 Section 28.8 [re.regex] lists a constructor
25074 <blockquote><pre>template<class InputIterator>
25075 basic_regex(InputIterator first, InputIterator last,
25076 flag_type f = regex_constants::ECMAScript);
25077 </pre></blockquote>
25080 However, in section 28.8.2 [re.regex.construct], this constructor takes a
25081 pair of <tt>ForwardIterator</tt>.
25085 <p><b>Proposed resolution:</b></p>
25087 Change 28.8.2 [re.regex.construct]:
25090 <blockquote><pre>template <class <del>ForwardIterator</del> <ins>InputIterator</ins>>
25091 basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last,
25092 flag_type f = regex_constants::ECMAScript);
25093 </pre></blockquote>
25101 <h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&</tt></h3>
25102 <p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25103 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
25104 <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>
25105 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25106 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
25107 <p><b>Discussion:</b></p>
25110 20.7.5.1 [allocator.members] says:
25113 <pre>pointer address(reference <i>x</i>) const;</pre>
25116 -1- <i>Returns:</i> <tt>&<i>x</i></tt>.
25122 20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
25123 only defines the semantics of copy construction, but also restricts what an overloaded
25124 <tt>operator&</tt> may do. I believe proposals are in the works (such as concepts
25125 and rvalue reference) to decouple these two requirements. Indeed it is not evident
25126 that we should disallow overloading <tt>operator&</tt> to return something other
25127 than the address of <tt>*this</tt>.
25131 An example of when you want to overload <tt>operator&</tt> to return something
25132 other than the object's address is proxy references such as <tt>vector<bool></tt>
25133 (or its replacement, currently code-named <tt>bit_vector</tt>). Taking the address of
25134 such a proxy reference should logically yield a proxy pointer, which when dereferenced,
25135 yields a copy of the original proxy reference again.
25139 On the other hand, some code truly needs the address of an object, and not a proxy
25140 (typically for determining the identity of an object compared to a reference object).
25141 <a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with
25142 <a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
25143 It appears to me that this would be useful functionality for the default allocator. Adopting
25144 this definition for <tt>allocator::address</tt> would free the standard of requiring
25145 anything special from types which overload <tt>operator&</tt>. Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
25146 is expected to make use of <tt>allocator::address</tt> mandatory for containers.
25151 <p><b>Proposed resolution:</b></p>
25153 Change 20.7.5.1 [allocator.members]:
25157 <pre>pointer address(reference <i>x</i>) const;</pre>
25160 -1- <i>Returns:</i> <del><tt>&<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
25161 even in the presence of an overloaded <tt>operator&</tt>.</ins>
25165 <pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
25168 -2- <i>Returns:</i> <del><tt>&<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
25169 even in the presence of an overloaded <tt>operator&</tt>.</ins>
25175 post Oxford: This would be rendered NAD Editorial by acceptance of
25176 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
25181 Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
25182 was subsequently split out into a separate paper N2436 for the purposes of voting.
25183 The resolution in N2436 addresses this issue. The LWG voted to accelerate this
25184 issue to Ready status to be voted into the WP at Kona.
25194 <h3><a name="638"></a>638. deque end invalidation during erase</h3>
25195 <p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25196 <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
25197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25198 <p><b>Discussion:</b></p>
25200 The standard states at 23.2.2.3 [deque.modifiers]/4:
25202 <blockquote><pre>deque erase(...)
25205 <i>Effects:</i> ... An erase at either end of the deque invalidates only
25206 the iterators and the references to the erased elements.
25210 This does not state that iterators to end will be invalidated.
25211 It needs to be amended in such a way as to account for end invalidation.
25217 Any time the last element is erased, iterators to end are invalidated.
25221 This would handle situations like:
25223 <blockquote><pre>erase(begin(), end())
25226 resize(n, ...) where n < size()
25227 pop_front() with size() == 1
25229 </pre></blockquote>
25232 Post Kona, Steve LoBasso notes:
25237 My only issue with the proposed resolution is that it might not be clear
25238 that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
25244 <p><b>Proposed resolution:</b></p>
25246 Change 23.2.2.3 [deque.modifiers], p4:
25250 <pre>iterator erase(const_iterator position);
25251 iterator erase(const_iterator first, const_iterator last);
25256 -4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
25257 invalidates all the iterators and references to elements of the
25258 <tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
25259 either end of the <tt>deque</tt> invalidates only the iterators and the
25260 references to the erased elements<ins>, except that erasing at the end
25261 also invalidates the past-the-end iterator</ins>.
25269 Kona (2007): Proposed wording added and moved to Review.
25279 Note that there is existing code that relies on iterators not being
25280 invalidated, but there are also existing implementations that do
25281 invalidate iterators. Thus, such code is not portable in any case. There
25282 is a pop_front() note, which should possibly be a separate issue. Mike
25283 Spertus to evaluate and, if need be, file an issue.
25290 <h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
25291 <p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25292 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
25293 <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>
25294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25295 <p><b>Discussion:</b></p>
25297 The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
25298 Although the section starts with a listing of the inserters including
25302 <blockquote><pre>operator<<(long long val );
25303 operator<<(unsigned long long val );
25304 </pre></blockquote>
25307 the text in paragraph 1, which describes the corresponding effects
25308 of the inserters, depending on the actual type of val, does not
25309 handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
25313 Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
25314 misses any reference to extended integral types supplied by the
25315 implementation - one of the additions by core a couple of working papers
25322 <p><b>Proposed resolution:</b></p>
25324 In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
25328 When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
25329 long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
25330 <tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
25331 occurs as if it performed the following code fragment:
25339 <h3><a name="643"></a>643. Impossible "as if" clauses</h3>
25340 <p><b>Section:</b> 27.8.1.1 [filebuf], 22.2.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>
25341 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
25342 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25343 <p><b>Discussion:</b></p>
25345 The current standard 14882:2003(E) as well as N2134 have the
25351 27.8.1.1 [filebuf]/5 says:
25356 In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a
25357 facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
25359 <blockquote><pre>codecvt<charT,char,typename traits::state_type> <i>a_codecvt</i> =
25360 use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
25361 </pre></blockquote>
25365 <tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
25366 copyconstructible, so the codecvt construction should fail to compile.
25370 A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
25374 <p><b>Proposed resolution:</b></p>
25376 In 27.8.1.1 [filebuf]/5 change the "as if" code
25379 <blockquote><pre><ins>const </ins>codecvt<charT,char,typename traits::state_type><ins>&</ins> <i>a_codecvt</i> =
25380 use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
25381 </pre></blockquote>
25384 In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
25389 A local variable <tt><i>punct</i></tt> is initialized via
25391 <blockquote><pre><ins>const </ins>numpunct<charT><ins>&</ins> <i>punct</i> = use_facet< numpunct<charT> >(<i>str</i>.getloc() )<ins>;</ins>
25392 </pre></blockquote>
25396 (Please note also the additional provided trailing semicolon)
25405 <h3><a name="646"></a>646. const incorrect match_result members</h3>
25406 <p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25407 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
25408 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25409 <p><b>Discussion:</b></p>
25411 28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
25412 members format as non-const functions, although they are declared
25413 as const in 28.10 [re.results]/3.
25417 <p><b>Proposed resolution:</b></p>
25419 Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
25420 in section 28.10.4 [re.results.form].
25428 <h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
25429 <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>
25430 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
25431 <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>
25432 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25433 <p><b>Discussion:</b></p>
25435 Both the class definition of regex_token_iterator (28.12.2
25436 [re.tokiter]/6) and the latter member specifications (28.12.2.2
25437 [re.tokiter.comp]/1+2) declare both comparison operators as
25438 non-const functions. Furtheron, both dereference operators are
25439 unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
25440 as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
25444 <p><b>Proposed resolution:</b></p>
25446 1) In (28.12.2 [re.tokiter]/6) change the current declarations
25449 <blockquote><pre>bool operator==(const regex_token_iterator&) <ins>const</ins>;
25450 bool operator!=(const regex_token_iterator&) <ins>const</ins>;
25451 const value_type& operator*() <ins>const</ins>;
25452 const value_type* operator->() <ins>const</ins>;
25453 </pre></blockquote>
25456 2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
25459 <blockquote><pre>bool operator==(const regex_token_iterator& right) <ins>const</ins>;
25460 bool operator!=(const regex_token_iterator& right) <ins>const</ins>;
25461 </pre></blockquote>
25464 3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
25467 <blockquote><pre>const value_type& operator*() <ins>const</ins>;
25468 const value_type* operator->() <ins>const</ins>;
25469 </pre></blockquote>
25473 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
25474 is to adopt the proposed wording in this issue).
25475 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25483 <h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
25484 <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#WP">WP</a>
25485 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
25486 <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>
25487 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25488 <p><b>Discussion:</b></p>
25490 The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
25491 the effects of the three non-default constructors of class
25492 template regex_token_iterator but is does not clarify which values
25493 are legal values for submatch/submatches. This becomes
25494 an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
25495 the notion of a "current match" by saying:
25499 The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
25500 == -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
25505 It's not clear to me, whether other negative values except -1
25506 are legal arguments or not - it seems they are not.
25510 <p><b>Proposed resolution:</b></p>
25512 Add the following precondition paragraph just before the current
25513 28.12.2.1 [re.tokiter.cnstr]/2:
25517 <i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>>= -1</tt>.
25522 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
25523 is to adopt the proposed wording in this issue).
25524 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25532 <h3><a name="652"></a>652. regex_iterator and const correctness</h3>
25533 <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#WP">WP</a>
25534 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
25535 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25536 <p><b>Discussion:</b></p>
25537 <p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
25538 and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
25539 declare both comparison operators as
25540 non-const functions. Furtheron, both dereference operators are
25541 unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
25542 as well as in (28.12.1.3 [re.regiter.deref]/1+2).
25546 <p><b>Proposed resolution:</b></p>
25548 1) In (28.12.1 [re.regiter]/1) change the current declarations
25551 <blockquote><pre>bool operator==(const regex_iterator&) <ins>const</ins>;
25552 bool operator!=(const regex_iterator&) <ins>const</ins>;
25553 const value_type& operator*() <ins>const</ins>;
25554 const value_type* operator->() <ins>const</ins>;
25555 </pre></blockquote>
25558 2) In 28.12.1.3 [re.regiter.deref] change the following declarations
25561 <blockquote><pre>const value_type& operator*() <ins>const</ins>;
25562 const value_type* operator->() <ins>const</ins>;
25563 </pre></blockquote>
25566 3) In 28.12.1.2 [re.regiter.comp] change the following declarations
25569 <blockquote><pre>bool operator==(const regex_iterator& right) <ins>const</ins>;
25570 bool operator!=(const regex_iterator& right) <ins>const</ins>;
25571 </pre></blockquote>
25575 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
25576 is to adopt the proposed wording in this issue).
25577 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25585 <h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
25586 <p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25587 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
25588 <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>
25589 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25590 <p><b>Discussion:</b></p>
25592 Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
25593 the IO insertion and extraction semantic of random
25594 number engines. It can be shown, v.i., that the specification
25595 of the extractor cannot guarantee to fulfill the requirement
25600 If a textual representation written via os << x was
25601 subsequently read via is >> v, then x == v provided that
25602 there have been no intervening invocations of x or of v.
25606 The problem is, that the extraction process described in
25607 table 98 misses to specify that it will initially set the
25608 if.fmtflags to ios_base::dec, see table 104:
25612 dec: converts integer input or generates integer output
25617 Proof: The following small program demonstrates the violation
25618 of requirements (exception safety not fulfilled):
25621 <blockquote><pre>#include <cassert>
25622 #include <ostream>
25623 #include <iostream>
25624 #include <iomanip>
25625 #include <sstream>
25627 class RanNumEngine {
25630 RanNumEngine() : state(42) {}
25632 bool operator==(RanNumEngine other) const {
25633 return state == other.state;
25636 template <typename Ch, typename Tr>
25637 friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
25638 Ch old = os.fill(os.widen(' ')); // Sets space character
25639 std::ios_base::fmtflags f = os.flags();
25640 os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
25641 os.fill(old); // Undo
25646 template <typename Ch, typename Tr>
25647 friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
25648 // Uncomment only for the fix.
25650 //std::ios_base::fmtflags f = is.flags();
25651 //is >> std::dec;
25652 is >> engine.state;
25659 std::stringstream s;
25660 s << std::setfill('#'); // No problem
25661 s << std::oct; // Yikes!
25662 // Here starts para 5 requirements:
25667 assert(x == v); // Fails: 42 == 34
25669 </pre></blockquote>
25672 A second, minor issue seems to be, that the insertion
25673 description from table 98 unnecessarily requires the
25674 addition of ios_base::fixed (which only influences floating-point
25675 numbers). Its not entirely clear to me whether the proposed
25676 standard does require that the state of random number engines
25677 is stored in integral types or not, but I have the impression
25678 that this is the indent, see e.g. p. 3
25682 The specification of each random number engine defines the
25683 size of its state in multiples of the size of its result_type.
25687 If other types than integrals are supported, then I wonder why
25688 no requirements are specified for the precision of the stream.
25692 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
25693 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
25694 for some further discussion.
25698 <p><b>Proposed resolution:</b></p>
25700 Adopt the proposed resolution in
25701 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
25706 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
25707 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25715 <h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
25716 <p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25717 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
25718 <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>
25719 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25720 <p><b>Discussion:</b></p>
25722 In 26.4.2 [rand.synopsis] we have the declaration
25725 <blockquote><pre>template<class RealType, class UniformRandomNumberGenerator,
25727 result_type generate_canonical(UniformRandomNumberGenerator& g);
25728 </pre></blockquote>
25731 Besides the "result_type" issue (already recognized by Bo Persson
25732 at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
25733 the template parameter order is not reasonably choosen: Obviously
25734 one always needs to specify all three parameters, although usually
25735 only two are required, namely the result type RealType and the
25736 wanted bits, because UniformRandomNumberGenerator can usually
25741 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
25742 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
25743 for some further discussion.
25747 <p><b>Proposed resolution:</b></p>
25749 Adopt the proposed resolution in
25750 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
25755 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
25756 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25764 <h3><a name="660"></a>660. Missing Bitwise Operations</h3>
25765 <p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25766 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
25767 <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>
25768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25769 <p><b>Discussion:</b></p>
25770 <p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span>
25771 <span id="st" name="st" class="st">objects</span> for some unary and binary
25772 operations, but others are missing. In a LWG reflector discussion, beginning
25773 with c++std-lib-18078, pros and cons of adding some of the missing operations
25774 were discussed. Bjarne Stroustrup commented "Why standardize what isn't used?
25775 Yes, I see the chicken and egg problems here, but it would be nice to see a
25776 couple of genuine uses before making additions."</p>
25777 <p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have
25778 already added these functions, either publicly or for internal use. For example,
25779 Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we
25780 need those <span id="st" name="st" class="st">function</span>
25781 <span id="st" name="st" class="st">objects</span> to represent various parallel
25782 collective operations (reductions, prefix reductions, etc.) in the new Message
25783 Passing Interface (MPI) library."</p>
25784 <p>Because the bitwise operators have the strongest use cases, the proposed
25785 resolution is limited to them.</p>
25788 <p><b>Proposed resolution:</b></p>
25789 <p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header
25790 <functional> synopsis:</p>
25792 <pre>template <class T> struct bit_and;
25793 template <class T> struct bit_or;
25794 template <class T> struct bit_xor;</pre>
25796 <p>At a location in clause 20 to be determined by the Project Editor, add:</p>
25798 <p>The library provides basic function object classes for all of the bitwise
25799 operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
25800 <pre>template <class T> struct bit_and : binary_function<T,T,T> {
25801 T operator()(const T& x , const T& y ) const;
25804 <p><code>operator()</code> returns<code> x & y</code> .</p>
25806 <pre>template <class T> struct bit_or : binary_function<T,T,T> {
25807 T operator()(const T& x , const T& y ) const;
25810 <p><code>operator()</code> returns <code>x | y</code> .</p>
25812 <pre>template <class T> struct bit_xor : binary_function<T,T,T> {
25813 T operator()(const T& x , const T& y ) const;
25816 <p><code>operator()</code> returns <code>x ^ y</code> .</p>
25825 <h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
25826 <p><b>Section:</b> 27.6.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>
25827 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p>
25828 <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>
25829 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25830 <p><b>Discussion:</b></p>
25832 To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
25833 the explicit description of the extraction of the types short and int in
25834 terms of as-if code fragments.
25839 The corresponding as-if extractions in paragraph 2 and 3 will never
25840 result in a change of the operator>> argument val, because the
25841 contents of the local variable lval is in no case written into val.
25842 Furtheron both fragments need a currently missing parentheses in the
25843 beginning of the if-statement to be valid C++.
25845 <li>I would like to ask whether the omission of a similar explicit
25846 extraction of unsigned short and unsigned int in terms of long -
25847 compared to their corresponding new insertions, as described in
25848 27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
25855 <p><b>Proposed resolution:</b></p>
25859 In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
25861 <blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
25864 use_facet<numget>(loc).get(*this, 0, *this, err, lval );
25865 if (err == 0) <ins>{</ins>
25866 <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del>
25867 err = ios_base::failbit;
25869 val = static_cast<short>(lval);
25872 </pre></blockquote>
25875 Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
25878 <blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
25881 use_facet<numget>(loc).get(*this, 0, *this, err, lval );
25882 if (err == 0) <ins>{</ins>
25883 <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del>
25884 err = ios_base::failbit;
25886 val = static_cast<int>(lval);
25889 </pre></blockquote>
25898 Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
25899 is incorrectly italicized in the code fragments corresponding to
25900 <tt>operator>>(short &)</tt> and <tt>operator >>(int &)</tt>. Also, val -- which appears
25901 twice on the line with the <tt>static_cast</tt> in the proposed resolution --
25902 should be italicized. Also, in response to part two of the issue: this
25911 <h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></tt></h3>
25912 <p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25913 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
25914 <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>
25915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25916 <p><b>Discussion:</b></p>
25918 22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
25922 <i>Effects:</i> Places characters starting at to that should be appended to
25923 terminate a sequence when the current <tt>stateT</tt> is given by
25924 <tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
25925 <i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
25926 pointer pointing one beyond the last element successfully stored.
25927 <em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em>
25931 The following objection has been raised:
25935 Since the C++ Standard permits a nontrivial conversion for the required
25936 instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
25937 <tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
25941 [Plum ref _222152Y50]
25945 <p><b>Proposed resolution:</b></p>
25947 Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
25952 <i>Effects:</i> Places characters starting at <i>to</i> that should be
25953 appended to terminate a sequence when the current <tt>stateT</tt> is
25954 given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
25955 destination elements, and leaves the <i>to_next</i> pointer pointing one
25956 beyond the last element successfully stored. <del><tt>codecvt<char, char,
25957 mbstate_t></tt> stores no characters.</del>
25966 <h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
25967 <p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
25968 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
25969 <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>
25970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
25971 <p><b>Discussion:</b></p>
25973 22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
25977 <tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.
25981 The following objection has been raised:
25985 Despite what the C++ Standard
25986 says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since
25987 they can be nontrivial. At least one implementation does whatever the
25992 [Plum ref _222152Y62]
25996 <p><b>Proposed resolution:</b></p>
25998 Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
26002 <p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
26005 <del><tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.</del>
26015 <h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
26016 <p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26017 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
26018 <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>
26019 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26020 <p><b>Discussion:</b></p>
26022 22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
26026 <sup>257)</sup> For international
26027 specializations (second template parameter <tt>true</tt>) this is always four
26028 characters long, usually three letters and a space.
26032 The following objection has been raised:
26036 The international currency
26037 symbol is whatever the underlying locale says it is, not necessarily
26038 four characters long.
26042 [Plum ref _222632Y41]
26046 <p><b>Proposed resolution:</b></p>
26048 Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
26053 <sup>253)</sup> For international specializations (second template
26054 parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
26055 four characters long, usually three letters and a space.
26064 <h3><a name="672"></a>672. Swappable requirements need updating</h3>
26065 <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26066 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
26067 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
26068 <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>
26069 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26070 <p><b>Discussion:</b></p>
26072 The current <tt>Swappable</tt> is:
26077 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
26078 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
26079 <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
26080 held by <tt>t</tt></td></tr>
26081 <tr><td colspan="3">
26083 The Swappable requirement is met by satisfying one or more of the following conditions:
26087 <tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
26088 and the <tt>CopyAssignable</tt> requirements (Table 36);
26091 <tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
26092 namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
26093 and has the semantics described in this table.
26101 With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
26102 require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum.
26106 Additionally we may want to support proxy references such that the following code is acceptable:
26109 <blockquote><pre>namespace Mine {
26111 template <class T>
26112 struct proxy {...};
26114 template <class T>
26115 struct proxied_iterator
26117 typedef T value_type;
26118 typedef proxy<T> reference;
26119 reference operator*() const;
26125 // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
26130 void swap(A&, A&);
26131 void swap(proxy<A>, A&);
26132 void swap(A&, proxy<A>);
26133 void swap(proxy<A>, proxy<A>);
26139 Mine::proxied_iterator<Mine::A> i(...)
26142 </pre></blockquote>
26145 I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
26146 itself. We do not need to anything in terms of implementation except not block their way with overly
26147 constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
26148 between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
26153 <p><b>Proposed resolution:</b></p>
26156 Change 20.1.1 [utility.arg.requirements]:
26162 -1- The template definitions in the C++ Standard Library refer to various
26163 named requirements whose details are set out in tables 31-38. In these
26164 tables, <tt>T</tt> is a type to be supplied by a C++ program
26165 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
26166 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
26167 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
26168 <tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
26169 rvalue of type <tt>T</tt>.
26173 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
26174 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
26175 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
26176 <td><tt>t</tt> has the value originally
26177 held by <tt>u</tt>, and
26178 <tt>u</tt> has the value originally held
26179 by <tt>t</tt></td></tr>
26180 <tr><td colspan="3">
26182 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
26186 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
26187 <del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
26188 requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
26189 requirements (Table <del>36</del> <ins>35</ins>);
26192 <tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
26193 <tt>swap</tt> exists in the same namespace as the definition of
26194 <tt>T</tt>, such that the expression
26195 <tt>swap(t,u)</tt> is valid and has the
26196 semantics described in this table.
26206 Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
26207 move semantics. The issue relating to the support of proxies is
26208 separable from the one relating to move semantics, and it's bigger than
26209 just swap. We'd like to address only the move semantics changes under
26210 this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
26211 may be a third issue, in that the current definition of <tt>Swappable</tt> does
26212 not permit rvalues to be operands to a swap operation, and Howard's
26213 proposed resolution would allow the right-most operand to be an rvalue,
26214 but it would not allow the left-most operand to be an rvalue (some swap
26215 functions in the library have been overloaded to permit left operands to
26216 swap to be rvalues).
26224 <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
26225 <p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26226 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
26227 <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>
26228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26229 <p><b>Discussion:</b></p>
26231 Since the publication of
26232 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
26233 there have been a few small but significant advances which should be included into
26234 <tt>unique_ptr</tt>. There exists a
26235 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
26236 for all of these changes.
26243 Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>),
26244 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt>
26245 even if it is never used. For example see
26246 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
26247 happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
26248 type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with
26249 <tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt>
26250 the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
26251 This is simpler than creating a <tt>unique_ptr<void></tt> specialization which isn't robust in the
26252 face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
26256 This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt>
26257 which could be very useful to the client.
26264 Efforts have been made to better support containers and smart pointers in shared
26265 memory contexts. One of the key hurdles in such support is not assuming that a
26266 pointer type is actually a <tt>T*</tt>. This can easily be accomplished
26267 for <tt>unique_ptr</tt> by having the deleter define the pointer type:
26268 <tt>D::pointer</tt>. Furthermore this type can easily be defaulted to
26269 <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
26270 type (example implementation
26271 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
26272 This change has no run time overhead. It has no interface overhead on
26273 authors of custom delter types. It simply allows (but not requires)
26274 authors of custom deleter types to define a smart pointer for the
26275 storage type of <tt>unique_ptr</tt> if they find such functionality
26276 useful. <tt>std::default_delete</tt> is an example of a deleter which
26277 defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
26278 and not including a <tt>pointer typedef</tt>.
26284 When the deleter type is a function pointer then it is unsafe to construct
26285 a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
26286 This case is easy to check for with a <tt>static_assert</tt> assuring that the
26287 deleter is not a pointer type in those constructors which do not accept deleters.
26290 <blockquote><pre>unique_ptr<A, void(*)(void*)> p(new A); // error, no function given to delete the pointer!
26291 </pre></blockquote>
26298 Kona (2007): We don't like the solution given to the first bullet in
26299 light of concepts. The second bullet solves the problem of supporting
26300 fancy pointers for one library component only. The full LWG needs to
26301 decide whether to solve the problem of supporting fancy pointers
26302 piecemeal, or whether a paper addressing the whole library is needed. We
26303 think that the third bullet is correct.
26308 Post Kona: Howard adds example user code related to the first bullet:
26313 <pre>void legacy_code(void*, std::size_t);
26315 void foo(std::size_t N)
26317 std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
26318 legacy_code(ptr.get(), N);
26319 } // unique_ptr used for exception safety purposes
26324 I.e. <tt>unique_ptr<void></tt> <i>is</i> a useful tool that we don't want
26325 to disable with concepts. The only part of <tt>unique_ptr<void></tt> we
26326 want to disable (with concepts or by other means) are the two member functions:
26329 <blockquote><pre>T& operator*() const;
26330 T* operator->() const;
26331 </pre></blockquote>
26335 <p><b>Proposed resolution:</b></p>
26338 I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
26339 the proposed resolutions below.
26347 Change 20.7.11.2 [unique.ptr.single]:
26350 <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
26352 <del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
26355 </pre></blockquote>
26358 Change 20.7.11.2.4 [unique.ptr.single.observers]:
26361 <blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
26362 </pre></blockquote>
26368 Change 20.7.11.2 [unique.ptr.single]:
26371 <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
26373 <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
26375 explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
26377 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
26378 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
26380 <del>T*</del> <ins>pointer</ins> operator->() const;
26381 <del>T*</del> <ins>pointer</ins> get() const;
26383 <del>T*</del> <ins>pointer</ins> release();
26384 void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
26386 </pre></blockquote>
26390 -3- If the type <tt>remove_reference<D>::type::pointer</tt>
26391 exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to
26392 <tt>remove_reference<D>::type::pointer</tt>. Otherwise
26393 <tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>.
26394 The type <tt>unique_ptr<T, D>::pointer</tt> shall be <tt>CopyConstructible</tt>
26395 and <tt>CopyAssignable</tt>.
26400 Change 20.7.11.2.1 [unique.ptr.single.ctor]:
26403 <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
26405 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26406 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26408 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
26409 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
26411 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A& d);
26412 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
26414 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
26415 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d);
26417 </pre></blockquote>
26420 -23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
26421 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
26422 <del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
26423 reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
26424 (diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins>
26425 <del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
26426 <ins>pointer</ins>.
26430 -25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
26431 the construction, modulo any required offset adjustments resulting from
26432 the cast from <del><tt>U*</tt></del>
26433 <ins><tt>unique_ptr<U,E>::pointer</tt></ins> to <del><tt>T*</tt></del>
26434 <ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
26435 internally stored deleter which was constructed from
26436 <tt>u.get_deleter()</tt>.
26440 Change 20.7.11.2.3 [unique.ptr.single.asgn]:
26445 -8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
26446 <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
26447 <ins><tt>unique_ptr<U,E>::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
26448 convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
26453 Change 20.7.11.2.4 [unique.ptr.single.observers]:
26457 <pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre>
26459 <pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
26463 Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
26467 <pre><del>T*</del> <ins>pointer</ins> release();</pre>
26469 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
26473 Change 20.7.11.3 [unique.ptr.runtime]:
26476 <blockquote><pre>template <class T, class D> class unique_ptr<T[], D> {
26478 <ins>typedef <i>implementation</i> pointer;</ins>
26480 explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
26482 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26483 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26485 <del>T*</del> <ins>pointer</ins> get() const;
26487 <del>T*</del> <ins>pointer</ins> release();
26488 void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
26490 </pre></blockquote>
26493 Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
26497 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
26498 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26499 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
26503 These constructors behave the same as in the primary template except
26504 that they do not accept pointer types which are convertible to
26505 <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
26506 implementation technique is to create private templated overloads of
26507 these members. <i>-- end note</i>]
26512 Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
26516 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
26520 -1- <i>Requires:</i> Does not accept pointer types which are convertible
26521 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
26522 required). [<i>Note:</i> One implementation technique is to create a private
26523 templated overload. <i>-- end note</i>]
26532 Change 20.7.11.2.1 [unique.ptr.single.ctor]:
26536 <pre>unique_ptr();</pre>
26539 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
26540 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
26541 reference type <ins>or pointer type (diagnostic required)</ins>.
26544 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
26547 <i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
26548 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
26549 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
26565 <h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
26566 <p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26567 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p>
26568 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
26569 <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>
26570 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26571 <p><b>Discussion:</b></p>
26573 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
26574 any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
26575 and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
26579 <p><b>Proposed resolution:</b></p>
26582 Change 20.7.12.2 [util.smartptr.shared] as follows:
26586 <pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);
26587 <ins>template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete;
26588 template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins>
26590 template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);
26591 <ins>template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete;
26592 template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
26596 Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
26600 <pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre>
26604 Add to 20.7.12.2.1 [util.smartptr.shared.const]:
26608 <pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre>
26612 <i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
26613 not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
26618 <i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
26625 Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
26629 <pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre>
26633 Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
26637 <pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
26641 -4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
26644 -5- <i>Returns:</i> <tt>*this</tt>.
26653 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
26654 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
26662 <h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
26663 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26664 <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
26665 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
26666 <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>
26667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26668 <p><b>Discussion:</b></p>
26670 <tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
26671 engines which ideally would yield "distant" states when given "close"
26672 seeds. The algorithm for <tt>seed_seq::randomize</tt> given in the current
26673 Working Draft for C++,
26674 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
26675 (2007-05-08), has 3 weaknesses
26680 <p> Collisions in state. Because of the way the state is initialized,
26681 seeds of different lengths may result in the same state. The
26682 current version of seed_seq has the following properties:</p>
26684 <li> For a given <tt>s <= n</tt>, each of the 2^(32s) seed vectors results in a
26685 distinct state.</li>
26688 The proposed algorithm (below) has the considerably stronger
26691 <li> All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s < n</tt>
26692 result in distinct states.
26694 <li> All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
26700 <p> Poor mixing of <tt>v'</tt>s entropy into the state. Consider <tt>v.size() == n</tt>
26701 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>,
26702 a total of <tt>2^(16n)</tt> possibilities. Because of the simple recursion
26703 used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
26704 possible states.</p>
26706 <p> The proposed algorithm uses a more complex recursion which results
26707 in much better mixing.</p>
26709 <li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>. The proposed
26710 algorithm remedies this.
26714 The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
26715 initialization procedure for the Mersenne Twister by Makoto Matsumoto
26716 and Takuji Nishimura. The weakness (2) given above was communicated to
26717 me by Matsumoto last year.
26720 The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
26721 a student of Matsumoto, and is given in the implementation of the
26722 SIMD-oriented Fast Mersenne Twister random number generator SFMT.
26723 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
26724 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-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>
26729 An Application of Finite Field: Design and Implementation of 128-bit
26730 Instruction-Based Fast Pseudorandom Number Generator,
26731 Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
26732 <a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
26735 One change has been made here, namely to treat the case of small <tt>n</tt>
26736 (setting <tt>t = (n-1)/2</tt> for <tt>n < 7</tt>).
26739 Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
26740 in making this incompatible improvement to it.
26744 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
26745 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
26746 for some further discussion.
26750 <p><b>Proposed resolution:</b></p>
26752 Adopt the proposed resolution in
26753 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
26758 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
26759 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
26767 <h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
26768 <p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26769 <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
26770 <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>
26771 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26772 <p><b>Discussion:</b></p>
26774 Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
26778 This change follows naturally from the proposed change to
26779 <tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
26783 In table 104 the description of <tt>X(q)</tt> contains a special treatment of
26784 the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons:
26788 <li>It replicates the functionality provided by <tt>X()</tt>.</li>
26789 <li>It leads to the possibility of a collision in the state provided
26790 by some other <tt>X(q)</tt> with <tt>q.size() > 0</tt>.</li>
26791 <li>It is inconsistent with the description of the <tt>X(q)</tt> in
26792 paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
26793 there is no special treatment of <tt>q.size() == 0</tt>.</li>
26794 <li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
26795 allows for the case <tt>q.size() == 0</tt>.</li>
26799 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
26800 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
26801 for some further discussion.
26805 <p><b>Proposed resolution:</b></p>
26807 Adopt the proposed resolution in
26808 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
26813 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
26814 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
26822 <h3><a name="679"></a>679. resize parameter by value</h3>
26823 <p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26824 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
26825 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26826 <p><b>Discussion:</b></p>
26828 The C++98 standard specifies that one member function alone of the containers
26829 passes its parameter (<tt>T</tt>) by value instead of by const reference:
26832 <blockquote><pre>void resize(size_type sz, T c = T());
26833 </pre></blockquote>
26836 This fact has been discussed / debated repeatedly over the years, the first time
26837 being even before C++98 was ratified. The rationale for passing this parameter by
26843 So that self referencing statements are guaranteed to work, for example:
26845 <blockquote><pre>v.resize(v.size() + 1, v[0]);
26846 </pre></blockquote>
26850 However this rationale is not convincing as the signature for <tt>push_back</tt> is:
26853 <blockquote><pre>void push_back(const T& x);
26854 </pre></blockquote>
26857 And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
26858 And <tt>push_back</tt> must also work in the self referencing case:
26861 <blockquote><pre>v.push_back(v[0]); // must work
26862 </pre></blockquote>
26865 The problem with passing <tt>T</tt> by value is that it can be significantly more
26866 expensive than passing by reference. The converse is also true, however when it is
26867 true it is usually far less dramatic (e.g. for scalar types).
26871 Even with move semantics available, passing this parameter by value can be expensive.
26872 Consider for example <tt>vector<vector<int>></tt>:
26875 <blockquote><pre>std::vector<int> x(1000);
26876 std::vector<std::vector<int>> v;
26878 v.resize(v.size()+1, x);
26879 </pre></blockquote>
26882 In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
26883 <tt>resize</tt>. And then internally, since the code can not know at compile
26884 time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
26885 usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
26886 within the <tt>vector</tt>.
26890 With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
26891 only once. In this case, <tt>x</tt> has an expensive copy constructor and so any
26892 copies that can be saved represents a significant savings.
26896 If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
26897 as well. The resize taking a reference parameter has been coded and shipped in the
26898 CodeWarrior library with no reports of problems which I am aware of.
26903 <p><b>Proposed resolution:</b></p>
26905 Change 23.2.2 [deque], p2:
26908 <blockquote><pre>class deque {
26910 void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26911 </pre></blockquote>
26914 Change 23.2.2.2 [deque.capacity], p3:
26917 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26918 </pre></blockquote>
26921 Change 23.2.4 [list], p2:
26924 <blockquote><pre>class list {
26926 void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26927 </pre></blockquote>
26930 Change 23.2.4.2 [list.capacity], p3:
26933 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26934 </pre></blockquote>
26937 Change 23.2.6 [vector], p2:
26940 <blockquote><pre>class vector {
26942 void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26943 </pre></blockquote>
26946 Change 23.2.6.2 [vector.capacity], p11:
26949 <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
26950 </pre></blockquote>
26958 <h3><a name="680"></a>680. move_iterator operator-> return</h3>
26959 <p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
26960 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
26961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
26962 <p><b>Discussion:</b></p>
26964 <tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt>
26965 does not consistently match the type which is returned in the description
26966 in 24.4.3.3.5 [move.iter.op.ref].
26969 <blockquote><pre>template <class Iterator>
26970 class move_iterator {
26973 typedef typename iterator_traits<Iterator>::pointer pointer;
26975 pointer operator->() const {return current;}
26978 Iterator current; // exposition only
26980 </pre></blockquote>
26984 There are two possible fixes.
26988 <li><tt>pointer operator->() const {return &*current;}</tt></li>
26989 <li><tt>typedef Iterator pointer;</tt></li>
26993 The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential
26994 disadvantage of this is it may not work well with iterators which return a
26995 proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy
26996 references often need to overloaad <tt>operator&()</tt> to return a proxy
26997 pointer. That proxy pointer may or may not be the same type as the iterator's
26998 <tt>pointer</tt> type.
27002 By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
27003 the language forwards calls to <tt>operator-></tt> automatically until it
27004 finds a non-class type, the second solution avoids the issue of an overloaded
27005 <tt>operator&()</tt> entirely.
27008 <p><b>Proposed resolution:</b></p>
27010 Change the synopsis in 24.4.3.1 [move.iterator]:
27013 <blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
27014 </pre></blockquote>
27022 <h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
27023 <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>
27024 <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
27025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27026 <p><b>Discussion:</b></p>
27028 In 28.9.2 [re.submatch.op] of N2284,
27029 operator functions numbered 31-42 seem impossible to compare. E.g.:
27033 <pre>template <class BiIter>
27034 bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
27035 const sub_match<BiIter>& rhs);
27039 -31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
27045 When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits<BiIter>::value_type</tt> would be
27046 <tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object
27047 of <tt>std::basic_string<char></tt>. However, the behaviour of comparison between
27048 these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
27049 This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
27053 <p><b>Proposed resolution:</b></p>
27055 Adopt the proposed resolution in
27056 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
27061 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
27062 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27070 <h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
27071 <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>
27072 <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
27073 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27074 <p><b>Discussion:</b></p>
27076 Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
27079 <blockquote><pre>template <class InputIterator>
27080 basic_regex(InputIterator first, InputIterator last,
27081 flag_type f = regex_constants::ECMAScript);
27082 </pre></blockquote>
27085 In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
27088 <blockquote><pre>template <class ForwardIterator>
27089 basic_regex(ForwardIterator first, ForwardIterator last,
27090 flag_type f = regex_constants::ECMAScript);
27091 </pre></blockquote>
27094 <tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
27104 I think either could be implemented? Although an input iterator would
27105 probably require an internal copy of the string being made.
27108 I have no strong feelings either way, although I think my original intent
27109 was <tt>InputIterator</tt>.
27114 <p><b>Proposed resolution:</b></p>
27116 Adopt the proposed resolution in
27117 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
27122 Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
27123 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27131 <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
27132 <p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27133 <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
27134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27135 <p><b>Discussion:</b></p>
27137 In C++03 the difference between two <tt>reverse_iterators</tt>
27139 <blockquote><pre>ri1 - ri2
27140 </pre></blockquote>
27142 is possible to compute only if both iterators have the same base
27143 iterator. The result type is the <tt>difference_type</tt> of the base iterator.
27146 In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
27148 <blockquote><pre>template<class Iterator1, class Iterator2>
27149 typename reverse_iterator<Iterator>::difference_type
27150 operator-(const reverse_iterator<Iterator1>& x,
27151 const reverse_iterator<Iterator2>& y);
27152 </pre></blockquote>
27154 The return type is the same as the C++03 one, based on the no longer
27155 present <tt>Iterator</tt> template parameter.
27158 Besides being slightly invalid, should this operator work only when
27159 <tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
27160 implementation choose one of them? Which one?
27163 The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
27164 24.4.3.3.14 [move.iter.nonmember].
27168 <p><b>Proposed resolution:</b></p>
27170 Change the synopsis in 24.4.1.1 [reverse.iterator]:
27174 <pre>template <class Iterator1, class Iterator2>
27175 <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
27176 const reverse_iterator<Iterator1>& x,
27177 const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>;
27182 Change 24.4.1.3.19 [reverse.iter.opdiff]:
27186 <pre>template <class Iterator1, class Iterator2>
27187 <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
27188 const reverse_iterator<Iterator1>& x,
27189 const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>;
27193 <i>Returns:</i> <tt>y.current - x.current</tt>.
27200 Change the synopsis in 24.4.3.1 [move.iterator]:
27204 <pre>template <class Iterator1, class Iterator2>
27205 <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
27206 const move_iterator<Iterator1>& x,
27207 const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>;
27212 Change 24.4.3.3.14 [move.iter.nonmember]:
27216 <pre>template <class Iterator1, class Iterator2>
27217 <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
27218 const move_iterator<Iterator1>& x,
27219 const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>;
27223 <i>Returns:</i> <tt>x.base() - y.base()</tt>.
27229 Pre Bellevue: This issue needs to wait until the <tt>auto -> return</tt> language feature
27240 <h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
27241 <p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27242 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
27243 <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>
27244 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27245 <p><b>Discussion:</b></p>
27247 Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same
27248 rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
27249 code that works with raw pointers fails with <tt>shared_ptr</tt>:
27252 <blockquote><pre>void f( shared_ptr<void> );
27253 void f( shared_ptr<int> );
27257 f( shared_ptr<double>() ); // ambiguous
27259 </pre></blockquote>
27262 Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
27263 and the corresponding assignment operator to only participate in the
27264 overload resolution when the pointer types are compatible.
27268 <p><b>Proposed resolution:</b></p>
27270 In 20.7.12.2.1 [util.smartptr.shared.const], change:
27274 -14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
27275 second constructor shall not participate in the overload resolution
27276 unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
27281 In 20.7.12.3.1 [util.smartptr.weak.const], change:
27285 <pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del>
27286 <del>weak_ptr(weak_ptr const& r);</del>
27287 <del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del>
27288 <ins>weak_ptr(weak_ptr const& r);</ins>
27289 <ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins>
27290 <ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins>
27293 -4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
27294 third constructors<del>,</del> <ins>shall not participate in the
27295 overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
27296 <ins>is implicitly</ins> convertible to <tt>T*</tt>.
27306 <h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
27307 <p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27308 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
27309 <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>
27310 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27311 <p><b>Discussion:</b></p>
27313 The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
27314 motivation behind this is the safety problem with respect to rvalues,
27315 which is addressed by the proposed resolution of the previous issue.
27316 Therefore we should consider relaxing the requirements on the
27317 constructor since requests for the implicit conversion keep resurfacing.
27320 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
27324 <p><b>Proposed resolution:</b></p>
27326 Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
27327 proposed resolution of the previous issue is accepted, remove the
27328 <tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync.
27336 <h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
27337 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27338 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
27339 <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>
27340 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27341 <p><b>Discussion:</b></p>
27343 The <code>bitset</code> class template provides the member function
27344 <code>any()</code> to determine whether an object of the type has any
27345 bits set, and the member function <code>none()</code> to determine
27346 whether all of an object's bits are clear. However, the template does
27347 not provide a corresponding function to discover whether a
27348 <code>bitset</code> object has all its bits set. While it is
27349 possible, even easy, to obtain this information by comparing the
27350 result of <code>count()</code> with the result of <code>size()</code>
27351 for equality (i.e., via <code>b.count() == b.size()</code>) the
27352 operation is less efficient than a member function designed
27353 specifically for that purpose could be. (<code>count()</code> must
27354 count all non-zero bits in a <code>bitset</code> a word at a time
27355 while <code>all()</code> could stop counting as soon as it encountered
27356 the first word with a zero bit).
27360 <p><b>Proposed resolution:</b></p>
27362 Add a declaration of the new member function <code>all()</code> to the
27363 defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
27364 right above the declaration of <code>any()</code> as shown below:
27367 <blockquote><pre>bool operator!=(const bitset<N>& rhs) const;
27368 bool test(size_t pos) const;
27369 <ins>bool all() const;</ins>
27372 </pre></blockquote>
27375 Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
27378 <code>bool all() const;</code>
27381 <i>Returns</i>: <code>count() == size()</code>.
27386 In addition, change the description of <code>any()</code> and
27387 <code>none()</code> for consistency with <code>all()</code> as
27391 <code>bool any() const;</code>
27395 <i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
27396 is one</del><ins><code>count() != 0</code></ins>.
27400 <code>bool none() const;</code>
27404 <i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
27405 is one</del><ins><code>count() == 0</code></ins>.
27415 <h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
27416 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27417 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
27418 <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>
27419 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27420 <p><b>Discussion:</b></p>
27422 Objects of the <code>bitset</code> class template specializations can
27423 be constructed from and explicitly converted to values of the widest
27424 C++ integer type, <code>unsigned long</code>. With the introduction
27425 of <code>long long</code> into the language the template should be
27426 enhanced to make it possible to interoperate with values of this type
27427 as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for
27428 a brief discussion in support of this change.
27432 <p><b>Proposed resolution:</b></p>
27434 For simplicity, instead of adding overloads for <code>unsigned long
27435 long</code> and dealing with possible ambiguities in the spec, replace
27436 the <code>bitset</code> ctor that takes an <code>unsigned long</code>
27437 argument with one taking <code>unsigned long long</code> in the
27438 definition of the template as shown below. (The standard permits
27439 implementations to add overloads on other integer types or employ
27440 template tricks to achieve the same effect provided they don't cause
27441 ambiguities or changes in behavior.)
27444 <pre>// [bitset.cons] constructors:
27446 bitset(unsigned <ins>long</ins> long val);
27447 template<class charT, class traits, class Allocator>
27449 const basic_string<charT,traits,Allocator>& str,
27450 typename basic_string<charT,traits,Allocator>::size_type pos = 0,
27451 typename basic_string<charT,traits,Allocator>::size_type n =
27452 basic_string<charT,traits,Allocator>::npos);
27456 Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
27460 <code>bitset(unsigned <ins>long</ins> long val);</code>
27463 <i>Effects</i>: Constructs an object of class bitset<N>,
27464 initializing the first <code><i>M</i></code> bit positions to the
27465 corresponding bit values in <code><i>val</i></code>.
27466 <code><i>M</i></code> is the smaller of <code><i>N</i></code> and the
27467 number of bits in the value representation (section [basic.types]) of
27468 <code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> <
27469 <i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit
27470 positions are initialized to zero.
27475 Additionally, introduce a new member function <code>to_ullong()</code>
27476 to make it possible to convert <code>bitset</code> to values of the
27477 new type. Add the following declaration to the definition of the
27478 template, immediate after the declaration of <code>to_ulong()</code>
27479 in 23.3.5 [template.bitset], p1, as shown below:
27482 <pre>// element access:
27483 bool operator[](size_t pos) const; // for b[i];
27484 reference operator[](size_t pos); // for b[i];
27485 unsigned long to_ulong() const;
27486 <ins>unsigned long long to_ullong() const;</ins>
27487 template <class charT, class traits, class Allocator>
27488 basic_string<charT, traits, Allocator> to_string() const;
27492 And add a description of the new member function to 23.3.5.2 [bitset.members],
27493 below the description of the existing <code>to_ulong()</code> (if
27494 possible), with the following text:
27498 <code>unsigned long long to_ullong() const;</code>
27501 <i>Throws</i>: <code>overflow_error</code> if the integral value
27502 <code><i>x</i></code> corresponding to the bits in <code>*this</code>
27503 cannot be represented as type <code>unsigned long long</code>.
27506 <i>Returns:</i> <code><i>x</i></code>.
27515 <h3><a name="695"></a>695. ctype<char>::classic_table() not accessible</h3>
27516 <p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27517 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
27518 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27519 <p><b>Discussion:</b></p>
27521 The <code>ctype<char>::classic_table()</code> static member
27522 function returns a pointer to an array of const
27523 <code>ctype_base::mask</code> objects (enums) that contains
27524 <code>ctype<char>::table_size</code> elements. The table
27525 describes the properties of the character set in the "C" locale (i.e.,
27526 whether a character at an index given by its value is alpha, digit,
27527 punct, etc.), and is typically used to initialize the
27528 <code>ctype<char></code> facet in the classic "C" locale (the
27529 protected <code>ctype<char></code> member function
27530 <code>table()</code> then returns the same value as
27531 <code>classic_table()</code>).
27534 However, while <code>ctype<char>::table_size</code> (the size of
27535 the table) is a public static const member of the
27536 <code>ctype<char></code> specialization, the
27537 <code>classic_table()</code> static member function is protected. That
27538 makes getting at the classic data less than convenient (i.e., one has
27539 to create a whole derived class just to get at the masks array). It
27540 makes little sense to expose the size of the table in the public
27541 interface while making the table itself protected, especially when the
27542 table is a constant object.
27545 The same argument can be made for the non-static protected member
27546 function <code>table()</code>.
27550 <p><b>Proposed resolution:</b></p>
27552 Make the <code>ctype<char>::classic_table()</code> and
27553 <code>ctype<char>::table()</code> member functions public by
27554 moving their declarations into the public section of the definition of
27555 specialization in 22.2.1.3 [facet.ctype.special] as shown below:
27558 <pre> static locale::id id;
27559 static const size_t table_size = IMPLEMENTATION_DEFINED;
27560 <del>protected:</del>
27561 const mask* table() const throw();
27562 static const mask* classic_table() throw();
27563 <ins>protected:</ins>
27565 ~ctype(); // virtual
27566 virtual char do_toupper(char c) const;
27575 <h3><a name="699"></a>699. N2111 changes min/max</h3>
27576 <p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27577 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
27578 <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>
27579 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27580 <p><b>Discussion:</b></p>
27582 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
27583 changes <tt>min/max</tt> in several places in random from member
27584 functions to static data members. I believe this introduces
27585 a needless backward compatibility problem between C++0X and
27586 TR1. I'd like us to find new names for the static data members,
27587 or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
27591 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
27592 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
27593 for some further discussion.
27597 <p><b>Proposed resolution:</b></p>
27599 Adopt the proposed resolution in
27600 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
27605 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
27606 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27614 <h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
27615 <p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27616 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
27617 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
27618 <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>
27619 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27620 <p><b>Discussion:</b></p>
27622 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
27623 defines struct <tt>identity</tt> in <tt><utility></tt> which clashes with
27624 the traditional definition of struct <tt>identity</tt> in <tt><functional></tt>
27625 (not standard, but a common extension from old STL). Be nice
27626 if we could avoid this name clash for backward compatibility.
27630 <p><b>Proposed resolution:</b></p>
27632 Change 20.2.2 [forward]:
27636 <pre>template <class T> struct identity
27639 <ins>const T& operator()(const T& x) const;</ins>
27643 <pre><ins>const T& operator()(const T& x) const;</ins>
27647 <ins><i>Returns:</i> <tt>x</tt>.</ins>
27660 <h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
27661 <p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27662 <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
27663 <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>
27664 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27665 <p><b>Discussion:</b></p>
27667 <tt>map::at()</tt> need a complexity specification.
27671 <p><b>Proposed resolution:</b></p>
27673 Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
27677 <i>Complexity:</i> logarithmic.
27686 <h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
27687 <p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27688 <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
27689 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
27690 <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>
27691 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27692 <p><b>Discussion:</b></p>
27694 The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other].
27698 Its use is to turn C++03 pass-by-value parameters into efficient C++0x
27699 pass-by-rvalue-reference parameters. However, the current definition
27700 introduces an incompatible change where the cv-qualification of the
27701 parameter type is retained. The deduced type should loose such
27702 cv-qualification, as pass-by-value does.
27706 <p><b>Proposed resolution:</b></p>
27708 In 20.5.7 [meta.trans.other] change the last sentence:
27712 Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U<ins>>::type</ins></tt>.
27716 In 20.4.1.3 [tuple.creation]/1 change:
27720 <del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&</tt> if, for the
27721 corresponding type <tt>Ti</tt> in <tt>Types</tt>,
27722 <tt>remove_cv<remove_reference<Ti>::type>::type</tt> equals
27723 <tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is
27724 <tt>decay<Ti>::type</tt>.</del>
27725 <ins>Let <tt>Ui</tt> be <tt>decay<Ti>::type</tt> for each
27726 <tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
27727 is <tt>X&</tt> if <tt>Ui</tt> equals
27728 <tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is
27738 <h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
27739 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27740 <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
27741 <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>
27742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27743 <p><b>Discussion:</b></p>
27745 The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
27746 and <tt>make_tuple()</tt> in 20.4.1.3 [tuple.creation].
27747 <tt>make_tuple()</tt> detects the presence of
27748 <tt>reference_wrapper<X></tt> arguments and "unwraps" the reference in
27749 such cases. <tt>make_pair()</tt> would OTOH create a
27750 <tt>reference_wrapper<X></tt> member. I suggest that the two
27751 functions are made to behave similar in this respect to minimize
27756 <p><b>Proposed resolution:</b></p>
27758 In 20.2 [utility] change the synopsis for make_pair() to read
27761 <blockquote><pre>template <class T1, class T2>
27762 pair<<del>typename decay<T1>::type</del> <ins>V1</ins>, <del>typename decay<T2>::type</del> <ins>V2</ins>> make_pair(T1&&, T2&&);
27763 </pre></blockquote>
27766 In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
27767 Then change the 20.2.3 [pairs]/17 to:
27772 <i>Returns:</i> <tt>pair<<del>typename decay<T1>::type</del> <ins>V1</ins>,<del>typename decay<T2>::type</del> <ins>V2</ins>>(forward<T1>(x),forward<T2>(y))</tt> <ins>where <tt>V1</tt> and
27773 <tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
27774 <tt>decay<Ti>::type</tt> for each <tt>Ti</tt>. Then each
27775 <tt>Vi</tt> is <tt>X&</tt> if <tt>Ui</tt> equals
27776 <tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is
27787 <h3><a name="710"></a>710. Missing postconditions</h3>
27788 <p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27789 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
27790 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
27791 <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>
27792 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27793 <p><b>Discussion:</b></p>
27796 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
27797 has identified a contradiction in the <tt>shared_ptr</tt> specification.
27798 The <tt>shared_ptr</tt> move constructor and the cast functions are
27799 missing postconditions for the <tt>get()</tt> accessor.
27809 Move to "ready", adopting the first (Peter's) proposed resolution.
27812 Note to the project editor: there is an editorial issue here. The
27813 wording for the postconditions of the casts is slightly awkward, and the
27814 editor should consider rewording "If w is the return value...", e. g. as
27815 "For a return value w...".
27820 <p><b>Proposed resolution:</b></p>
27822 Add to 20.7.12.2.1 [util.smartptr.shared.const]:
27826 <pre>shared_ptr(shared_ptr&& r);
27827 template<class Y> shared_ptr(shared_ptr<Y>&& r);
27831 <i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
27832 shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
27838 Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
27842 <pre>template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
27846 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
27847 <tt>w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
27853 <pre>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
27857 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins>
27863 <pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
27867 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
27868 <tt>w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
27874 Alberto Ganesh Barbati has written an
27875 <a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
27876 where he suggests (among other things) that the casts be respecified in terms of
27877 the aliasing constructor as follows:
27881 Change 20.7.12.2.10 [util.smartptr.shared.cast]:
27886 -2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
27887 shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
27888 object that stores <tt>static_cast<T*>(r.get())</tt> and shares ownership with
27889 <tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, static_cast<T*>(r.get())</tt>.</ins>
27895 -6- <i>Returns:</i>
27898 <li><del>When <tt>dynamic_cast<T*>(r.get())</tt> returns a nonzero value,
27899 a <tt>shared_ptr<T></tt> object that stores a copy
27900 of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
27901 <li><del>Otherwise, an <i>empty</i> <tt>shared_ptr<T></tt> object.</del></li>
27902 <li><ins>If <tt>p = dynamic_cast<T*>(r.get())</tt> is a non-null pointer, <tt>shared_ptr<T>(r, p);</tt></ins></li>
27903 <li><ins>Otherwise, <tt>shared_ptr<T>()</tt>.</ins></li>
27909 -10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
27910 shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
27911 object that stores <tt>const_cast<T*>(r.get())</tt> and shares ownership with
27912 <tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, const_cast<T*>(r.get())</tt>.</ins>
27917 This takes care of the missing postconditions for the casts by bringing
27918 in the aliasing constructor postcondition "by reference".
27927 <h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
27928 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27929 <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
27930 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
27931 <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>
27932 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27933 <p><b>Discussion:</b></p>
27935 One of the motivations for incorporating <tt>seed_seq::size()</tt>
27936 was to simplify the wording
27937 in other parts of 26.4 [rand].
27938 As a side effect of resolving related issues,
27939 all such references
27940 to <tt>seed_seq::size()</tt> will have been excised.
27942 the present specification is contradictory,
27943 as "The number of 32-bit units the object can deliver"
27944 is not the same as "the result of <tt>v.size()</tt>."
27948 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
27949 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
27950 for some further discussion.
27954 <p><b>Proposed resolution:</b></p>
27956 Adopt the proposed resolution in
27957 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
27962 Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
27963 The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27971 <h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
27972 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
27973 <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
27974 <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>
27975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27976 <p><b>Discussion:</b></p>
27978 The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
27979 (last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
27980 i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
27981 <tt>max_element</tt> separately. This is gratuitously inefficient. There is a
27982 well known technique that does better: see section 9.1 of CLRS
27983 (Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
27987 <p><b>Proposed resolution:</b></p>
27989 Change 25.3.7 [alg.min.max] to:
27993 <pre>template<class ForwardIterator>
27994 pair<ForwardIterator, ForwardIterator>
27995 minmax_element(ForwardIterator first , ForwardIterator last);
27996 template<class ForwardIterator, class Compare>
27997 pair<ForwardIterator, ForwardIterator>
27998 minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
28002 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
28003 <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
28004 comp)</tt></del> <ins>the first iterator in <tt>[first,
28005 last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
28006 <ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
28007 <tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
28008 in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
28011 <i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
28012 <ins><tt>max(⌊(3/2) (N-1)⌋, 0)</tt></ins> applications of the
28013 corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
28024 <h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
28025 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28026 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
28027 <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>
28028 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28029 <p><b>Discussion:</b></p>
28031 In the listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss
28032 the following C99 functions (from 7.12.11.2):
28035 <blockquote><pre>float nanf(const char *tagp);
28036 long double nanl(const char *tagp);
28037 </pre></blockquote>
28040 (Note: These functions cannot be overloaded and they are also not
28041 listed anywhere else)
28045 <p><b>Proposed resolution:</b></p>
28047 In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
28048 just after the existing entry <tt>nan</tt>.
28056 <h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3>
28057 <p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28058 <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
28059 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28060 <p><b>Discussion:</b></p>
28062 Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful
28063 bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
28064 <tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></tt>, but that promising path
28065 immediately falters on <tt>op--</tt> which can't reliably dereference because we
28066 don't know the lower bound). Also, most buffers you'd want to point to
28067 don't have a compile-time known size.
28071 To enable any bounds-checking would require run-time information, with
28072 the usual triplet: base (lower bound), current offset, and max offset
28073 (upper bound). And I can sympathize with the point of view that you
28074 wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
28075 follow the <tt><T[N]></tt> path, especially not with additional functions to
28076 query the bounds etc., because this sets wrong user expectations by
28077 embarking on a path that doesn't go all the way to bounds checking as it
28082 If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
28083 <tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
28084 user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
28085 debug builds and not doing so on release builds (for example).
28089 Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
28090 pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
28091 don't agree, but if that were true that would be another reason to
28092 remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like
28093 <tt>std::array.</tt> :-)
28102 <p>Suggestion that fixed-size array instantiations are going to fail at
28103 compile time anyway (if we remove specialization) due to pointer decay,
28104 at least that appears to be result from available compilers.
28107 So concerns about about requiring static_assert seem unfounded.
28109 <p>After a little more experimentation with compiler, it appears that
28110 fixed size arrays would only work at all if we supply these explicit
28111 specialization. So removing them appears less breaking than originally
28115 straw poll unanimous move to Ready.
28121 <p><b>Proposed resolution:</b></p>
28123 Change the synopsis under 20.7.11 [unique.ptr] p2:
28126 <blockquote><pre>...
28127 template<class T> struct default_delete;
28128 template<class T> struct default_delete<T[]>;
28129 <del>template<class T, size_t N> struct default_delete<T[N]>;</del>
28131 template<class T, class D = default_delete<T>> class unique_ptr;
28132 template<class T, class D> class unique_ptr<T[], D>;
28133 <del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del>
28135 </pre></blockquote>
28138 Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>.
28142 Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
28143 and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
28144 20.7.11.4.3 [unique.ptr.compiletime.modifiers].
28153 <h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
28154 <p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28155 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
28156 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28157 <p><b>Discussion:</b></p>
28159 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:
28163 We may need to open an issue to deal with the question of
28164 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
28168 This issue was opened in response to that note.
28172 I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
28173 appropriate, and consistent with how other library components are currently specified.
28183 Concern that the three signatures for swap is needlessly complicated,
28184 but this issue merely brings shared_ptr into equal complexity with the
28185 rest of the library. Will open a new issue for concern about triplicate
28189 Adopt issue as written.
28194 <p><b>Proposed resolution:</b></p>
28196 Change the synopsis in 20.7.12.2 [util.smartptr.shared]:
28199 <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
28201 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
28202 <ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
28203 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
28204 </pre></blockquote>
28207 Change 20.7.12.2.4 [util.smartptr.shared.mod]:
28210 <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
28211 </pre></blockquote>
28214 Change 20.7.12.2.9 [util.smartptr.shared.spec]:
28217 <blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
28218 <ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
28219 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
28220 </pre></blockquote>
28227 <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
28228 <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28229 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
28230 <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>
28231 <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>
28232 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28233 <p><b>Discussion:</b></p>
28235 Without some lifetime guarantee, it is hard to know how this type can be
28236 used. Very specifically, I don't see how the current wording would
28237 guarantee and exception_ptr caught at the end of one thread could be safely
28238 stored and rethrown in another thread - the original motivation for this
28242 (Peter Dimov agreed it should be clearer, maybe a non-normative note to
28253 Agree the issue is real.
28256 Intent is lifetime is similar to a shared_ptr (and we might even want to
28257 consider explicitly saying that it is a shared_ptr< unspecified type >).
28260 We expect that most implementations will use shared_ptr, and the
28261 standard should be clear that the exception_ptr type is intended to be
28262 something whose semantics are smart-pointer-like so that the user does
28263 not need to worry about lifetime management. We still need someone to
28264 draught those words - suggest emailing Peter Dimov.
28272 <p><b>Proposed resolution:</b></p>
28274 Change 18.7.5 [propagation]/7:
28278 -7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
28279 handled exception or a copy of the currently handled exception, or a
28280 null <tt>exception_ptr</tt> object if no exception is being handled.
28281 <ins>The referenced object remains valid at least as long as there is an
28282 <tt>exception_ptr</tt> that refers to it.</ins>
28283 If the function needs to allocate memory and the attempt
28284 fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
28285 <tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
28286 calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
28287 that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
28288 each time it is called. <i>--end note</i>]
28296 <h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
28297 <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28298 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
28299 <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>
28300 <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>
28301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28302 <p><b>Discussion:</b></p>
28304 I understand that the attempt to copy an exception may run out of memory,
28305 but I believe this is the only part of the standard that mandates failure
28306 with specifically <tt>bad_alloc</tt>, as opposed to allowing an
28307 implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core
28308 language for a failed new expression is:
28312 Any other allocation function that fails to allocate storage shall indicate
28313 failure only by throwing an exception of a type that would match a handler
28314 (15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
28318 I think we should allow similar freedom here (or add a blanket
28319 compatible-exception freedom paragraph in 17)
28322 I prefer the clause 17 approach myself, and maybe clean up any outstanding
28323 wording that could also rely on it.
28326 Although filed against a specific case, this issue is a problem throughout
28337 Is issue bigger than library?
28340 No - Core are already very clear about their wording, which is inspiration for the issue.
28343 While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
28346 Accept the broad view and move to ready
28351 <p><b>Proposed resolution:</b></p>
28353 Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
28357 A function may throw a type not listed in its <i>Throws</i> clause so long as it is
28358 derived from a class named in the <i>Throws</i> clause, and would be caught by an
28359 exception handler for the base type.
28367 <h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor<T>::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
28368 <p><b>Section:</b> 20.5.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>
28369 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
28370 <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>
28371 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28372 <p><b>Discussion:</b></p>
28374 Unfortunately a class can have multiple copy constructors, and I believe to
28375 be useful this trait should only return true is ALL copy constructors are
28382 <pre>struct awkward {
28383 awkward( const awkward & ) throw() {}
28384 awkward( awkward & ) { throw "oops"; } };
28389 <p><b>Proposed resolution:</b></p>
28391 Change 20.5.4.3 [meta.unary.prop]:
28395 <pre>has_trivial_copy_constructor</pre>
28397 <tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
28398 <ins>where all copy constructors are trivial</ins> (12.8).
28403 <pre>has_trivial_assign</pre>
28405 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
28406 or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
28411 <pre>has_nothrow_copy_constructor</pre>
28413 <tt>has_trivial_copy_constructor<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
28414 a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins>
28415 known not to throw any exceptions or <tt>T</tt> is an
28416 array of such a class type
28421 <pre>has_nothrow_assign</pre>
28423 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and
28424 <tt>has_trivial_assign<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
28425 <ins>where all</ins> copy
28426 assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
28427 throw any exceptions or <tt>T</tt> is an array of such a class type.
28437 <h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
28438 <p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28439 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p>
28440 <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>
28441 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28442 <p><b>Discussion:</b></p>
28444 A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
28447 <blockquote><pre>vector<int> v;
28449 v.swap(vector<int>(v)); // shrink to fit
28454 <pre>vector<int>(v).swap(v); // shrink to fit
28459 <pre>swap(v, vector<int>(v)); // shrink to fit
28464 A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
28467 <blockquote><pre>string s;
28470 </pre></blockquote>
28473 Neither of these is at all obvious to beginners, and even some
28474 experienced C++ programmers are not aware that shrink-to-fit is
28475 trivially available.
28478 Lack of explicit functions to perform these commonly requested
28479 operations makes vector and string less usable for non-experts. Because
28480 the idioms are somewhat obscure, code readability is impaired. It is
28481 also unfortunate that two similar vector-like containers use different
28482 syntax for the same operation.
28485 The proposed resolution addresses these concerns. The proposed function
28486 takes no arguments to keep the solution simple and focused.
28490 <p><b>Proposed resolution:</b></p>
28492 To Class template basic_string 21.3 [basic.string] synopsis,
28493 Class template vector 23.2.6 [vector] synopsis, and Class
28494 vector<bool> 23.2.7 [vector.bool] synopsis, add:
28498 void shrink_to_fit();
28499 </pre></blockquote>
28502 To basic_string capacity 21.3.4 [string.capacity] and vector
28503 capacity 23.2.6.2 [vector.capacity], add:
28507 <pre>void shrink_to_fit();
28510 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
28511 <tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
28512 allow latitude for implementation-specific optimizations.
28513 <i>-- end note</i>]
28518 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
28527 <h3><a name="759"></a>759. A reference is not an object</h3>
28528 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28529 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</p>
28530 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
28531 <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>
28532 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28533 <p><b>Discussion:</b></p>
28535 23.1 [container.requirements] says:
28539 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
28540 diagnostic required.
28544 A reference is not an object, but this sentence appears to claim so.
28548 What is probably meant here:
28551 An object bound to an rvalue
28552 reference parameter of a member function of a container shall not be
28553 an element of that container; no diagnostic required.
28558 <p><b>Proposed resolution:</b></p>
28560 Change 23.1 [container.requirements]:
28564 -12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
28565 <ins>An object bound to an rvalue
28566 reference parameter of a member function of a container shall not be
28568 of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o
28569 diagnostic required.
28578 <h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
28579 <p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28580 <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
28581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28582 <p><b>Discussion:</b></p>
28584 The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts
28585 like <tt>operator[]()</tt>, except it throws an exception when the input key is
28586 not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
28587 key doesn't have a default constructor, it is an error if the key is
28588 not found, or the user wants to avoid accidentally adding an element to
28589 the map. For exactly these same reasons, <tt>at()</tt> would be equally useful
28590 in <tt>std::unordered_map</tt>.
28594 <p><b>Proposed resolution:</b></p>
28596 Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
28599 <blockquote><pre>mapped_type& at(const key_type& k);
28600 const mapped_type &at(const key_type &k) const;
28601 </pre></blockquote>
28604 Add the following definitions to 23.4.1.2 [unord.map.elem]:
28608 <pre>mapped_type& at(const key_type& k);
28609 const mapped_type &at(const key_type &k) const;
28613 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
28614 whose key is equivalent to <tt>k</tt>.
28617 <i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
28624 Bellevue: Editorial note: the "(unique)" differs from map.
28634 <h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
28635 <p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28636 <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</p>
28637 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
28638 <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>
28639 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28640 <p><b>Discussion:</b></p>
28642 23.1 [container.requirements]p10 states:
28647 Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
28648 additional requirements:
28654 <li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
28660 23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
28661 additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
28662 <tt>erase()</tt> members. However, 23.1 [container.requirements]p10
28663 does not mention 23.1.5.1 [unord.req.except] that specifies exception
28665 for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
28666 offers the following guaratee for
28671 No <tt>erase()</tt> function throws an exception unless that exception
28672 is thrown by the container's Hash or Pred object (if any).
28680 According to 23.1 [container.requirements]p10 no
28681 <tt>erase()</tt> function should throw an exception unless otherwise
28682 specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
28683 for unordered containers, allowing <tt>erase()</tt> to throw if
28684 predicate or hash function throws.
28688 In contrast, associative containers have no exception safety guarantees
28689 section so no <tt>erase()</tt> function should throw, <em>including
28690 <tt>erase(k)</tt></em> that needs to use the predicate function to
28691 perform its work. This means that the predicate of an associative
28692 container is not allowed to throw.
28701 <tt>erase(k)</tt> for associative containers is not allowed to throw. On
28702 the other hand, <tt>erase(k)</tt> for unordered associative containers
28703 is allowed to throw.
28706 <tt>erase(q)</tt> for associative containers is not allowed to throw. On
28707 the other hand, <tt>erase(q)</tt> for unordered associative containers
28708 is allowed to throw if it uses the hash or predicate.
28711 To fulfill 1), predicates of associative containers are not allowed to throw.
28712 Predicates of unordered associative containers are allowed to throw.
28715 2) breaks a widely used programming pattern (flyweight pattern) for
28716 unordered containers, where objects are registered in a global map in
28717 their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
28718 allowed to throw, the destructor of the object would need to rethrow the
28719 exception or swallow it, leaving the object registered.
28724 <p><b>Proposed resolution:</b></p>
28726 Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
28727 safety guarantees".
28732 1 For associative containers, no <tt>clear()</tt> function throws an exception.
28733 <tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
28734 the container's Pred object (if any).
28738 2 For associative containers, if an exception is thrown by any operation
28739 from within an <tt>insert()</tt> function inserting a single element, the
28740 <tt>insert()</tt> function has no effect.
28744 3 For associative containers, no <tt>swap</tt> function throws an exception
28745 unless that exception is thrown by the copy constructor or copy
28746 assignment operator of the container's Pred object (if any).
28751 Change 23.1.5.1 [unord.req.except]p1:
28755 For unordered associative containers, no <tt>clear()</tt> function
28756 throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
28757 <del>function</del> <ins>does not</ins> throw<del>s</del> an exception
28758 unless that exception is thrown by the container's Hash or Pred object
28763 Change 23.1 [container.requirements]p10 to add references to new sections:
28767 Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
28768 <del>and</del> [vector.modifiers]<ins>, [associative.req.except],
28769 [unord.req.except]</ins>) all container types defined in this clause meet
28770 the following additional requirements:
28774 Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
28780 no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
28781 by the copy constructor or assignment operator of the container's
28782 Compare object (if any; see [associative.reqmts])</del>.
28793 <h3><a name="768"></a>768. Typos in [atomics]?</h3>
28794 <p><b>Section:</b> 29.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28795 <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
28796 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28797 <p><b>Discussion:</b></p>
28799 in the latest publicly available draft, paper
28800 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
28801 in section 29.3.3 [atomics.types.generic], the following specialization of the template
28802 <tt>atomic<></tt> is provided for pointers:
28805 <blockquote><pre>template <class T> struct atomic<T*> : atomic_address {
28806 T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
28807 T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
28809 atomic() = default;
28810 constexpr explicit atomic(T);
28811 atomic(const atomic&) = delete;
28812 atomic& operator=(const atomic&) = delete;
28814 T* operator=(T*) volatile;
28815 T* operator++(int) volatile;
28816 T* operator--(int) volatile;
28817 T* operator++() volatile;
28818 T* operator--() volatile;
28819 T* operator+=(ptrdiff_t) volatile;
28820 T* operator-=(ptrdiff_t) volatile;
28822 </pre></blockquote>
28825 First of all, there is a typo in the non-default constructor which
28826 should take a <tt>T*</tt> rather than a <tt>T</tt>.
28830 As you can see, the specialization redefine and therefore hide a few
28831 methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
28832 <tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
28833 to the other methods, in particular these ones:
28836 <blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
28837 T* load( memory_order = memory_order_seq_cst ) volatile;
28838 T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
28839 bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
28840 bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
28841 </pre></blockquote>
28845 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
28847 definition of the specialization <tt>atomic<T*></tt> matches the one in the
28848 draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
28849 and <tt>compare_swap()</tt> are indeed present.
28853 Strangely, the example implementation does not redefine the method
28854 <tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
28855 hiding the <tt>void*</tt> signature from the base class makes the class
28856 error-prone to say the least: it lets you assign pointers of any type to
28857 a <tt>T*</tt>, without any hint from the compiler.
28861 Is there a true intent to remove them from the specialization or are
28862 they just missing from the definition because of a mistake?
28872 The proposed revisions are accepted.
28875 Further discussion: why is the ctor labeled "constexpr"? Lawrence said
28876 this permits the object to be statically initialized, and that's
28877 important because otherwise there would be a race condition on
28883 <p><b>Proposed resolution:</b></p>
28885 Change the synopsis in 29.3.3 [atomics.types.generic]:
28888 <blockquote><pre>template <class T> struct atomic<T*> : atomic_address {
28889 <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
28890 <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
28891 <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
28892 <ins>bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;</ins>
28893 <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
28895 T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
28896 T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
28898 atomic() = default;
28899 constexpr explicit atomic(T<ins>*</ins>);
28900 atomic(const atomic&) = delete;
28901 atomic& operator=(const atomic&) = delete;
28903 T* operator=(T*) volatile;
28904 T* operator++(int) volatile;
28905 T* operator--(int) volatile;
28906 T* operator++() volatile;
28907 T* operator--() volatile;
28908 T* operator+=(ptrdiff_t) volatile;
28909 T* operator-=(ptrdiff_t) volatile;
28911 </pre></blockquote>
28919 <h3><a name="770"></a>770. std::function should use rvalue swap</h3>
28920 <p><b>Section:</b> 20.6.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28921 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
28922 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28923 <p><b>Discussion:</b></p>
28925 It is expected that typical implementations of <tt>std::function</tt> will
28926 use dynamic memory allocations at least under given conditions,
28927 so it seems appropriate to change the current lvalue swappabilty of
28928 this class to rvalue swappability.
28932 <p><b>Proposed resolution:</b></p>
28934 In 20.6 [function.objects], header <tt><functional></tt> synopsis, just below of
28937 <blockquote><pre>template<class R, class... ArgTypes>
28938 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
28939 <ins>template<class R, class... ArgTypes>
28940 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
28941 template<class R, class... ArgTypes>
28942 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
28943 </pre></blockquote>
28946 In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change
28949 <blockquote><pre>void swap(function&<ins>&</ins>);
28950 </pre></blockquote>
28953 In 20.6.15.2 [func.wrap.func], just below of
28956 <blockquote><pre>template <class R, class... ArgTypes>
28957 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
28958 <ins>template <class R, class... ArgTypes>
28959 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
28960 template <class R, class... ArgTypes>
28961 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
28962 </pre></blockquote>
28965 In 20.6.15.2.2 [func.wrap.func.mod] change
28968 <blockquote><pre>void swap(function&<ins>&</ins> other);
28969 </pre></blockquote>
28972 In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
28975 <blockquote><pre><ins>template<class R, class... ArgTypes>
28976 void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
28977 template<class R, class... ArgTypes>
28978 void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins>
28979 </pre></blockquote>
28987 <h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
28988 <p><b>Section:</b> 20.4.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
28989 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
28990 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
28991 <p><b>Discussion:</b></p>
28993 The tuple element access API identifies the element in the sequence
28994 using signed integers, and then goes on to enforce the requirement that
28995 I be >= 0. There is a much easier way to do this - declare I as
28999 In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
29002 A second suggestion is that it is hard to imagine an API that deduces
29003 and index at compile time and returns a reference throwing an exception.
29004 Add a specific <em>Throws:</em> Nothing paragraph to each element
29008 In addition to <code>tuple</code>, update the API applies to
29009 <code>pair</code> and <code>array</code>, and should be updated
29014 A third observation is that the return type of the <code>get</code>
29015 functions for <code>std::pair</code> is pseudo-code, but it is not
29016 clearly marked as such. There is actually no need for pseudo-code as
29017 the return type can be specified precisely with a call to
29018 <code>tuple_element</code>. This is already done for
29019 <code>std::tuple</code>, and <code>std::array</code> does not have a
29020 problem as all elements are of type <code>T</code>.
29024 <p><b>Proposed resolution:</b></p>
29026 Update header <utility> synopsis in 20.2 [utility]
29028 <pre><em>// 20.2.3, tuple-like access to pair:</em>
29029 template <class T> class tuple_size;
29030 template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element;
29032 template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
29033 template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
29034 template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
29036 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
29037 <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&);
29038 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
29039 const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&);
29042 Update <strong>20.2.3 [pairs] Pairs</strong>
29044 <pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
29045 <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&);
29046 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
29047 const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&);
29050 <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>
29053 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>.
29056 <ins><em>Throws:</em> Nothing.</ins>
29061 Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below:
29063 <pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em>
29064 template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >;
29066 <em>// 20.3.1.4, element access:</em>
29067 template <<del>int</del><ins>size_t</ins> I, class... Types>
29068 typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
29069 template <<del>int</del><ins>size_t</ins> I, class ... types>
29070 typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
29074 Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong>
29076 <pre>template <<del>int</del><ins>size_t</ins> I, class... Types>
29077 class tuple_element<I, tuple<Types...> > {
29082 1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
29085 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.
29088 Update <strong>20.4.1.5 [tuple.elem] Element access</strong>
29090 <pre>template <<del>int</del><ins>size_t</ins> I, class... types >
29091 typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
29093 1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
29095 2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
29097 <ins><em>Throws:</em> Nothing.</ins>
29098 <pre>template <<del>int</del><ins>size_t</ins> I, class... types>
29099 typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
29102 3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
29105 4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
29108 <ins><em>Throws:</em> Nothing.</ins>
29113 Update header <array> synopsis in 20.2 [utility]
29115 <pre>template <class T> class tuple_size; <em>// forward declaration</em>
29116 template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em>
29117 template <class T, size_t N>
29118 struct tuple_size<array<T, N> >;
29119 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
29120 struct tuple_element<I, array<T, N> >;
29121 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
29122 T& get(array<T, N>&);
29123 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
29124 const T& get(const array<T, N>&);
29128 Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
29130 <pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type
29133 3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds.
29136 4 <em>Value:</em> The type <code>T</code>.
29138 <pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a);
29141 5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
29144 <em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
29147 <ins><em>Throws:</em> Nothing.</ins>
29149 <pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a);
29152 6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
29155 7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
29158 <ins><em>Throws:</em> Nothing.</ins>
29163 Bellevue: Note also that the phrase "The program is ill-formed if I is
29164 out of bounds" in the requires clauses are probably unnecessary, and
29165 could be removed at the editor's discretion. Also std:: qualification
29166 for pair is also unnecessary.
29173 <h3><a name="777"></a>777. Atomics Library Issue</h3>
29174 <p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29175 <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p>
29176 <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>
29177 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29178 <p><b>Discussion:</b></p>
29180 The load functions are defined as
29183 <blockquote><pre>C atomic_load(volatile A* object);
29184 C atomic_load_explicit(volatile A* object, memory_order);
29185 C A::load(memory_order order = memory_order_seq_cst) volatile;
29186 </pre></blockquote>
29189 which prevents their use in <tt>const</tt> contexts.
29193 post Bellevue Peter adds:
29199 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
29200 subtle point here. Atomic loads do not generally write to the object, except
29201 potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
29202 architecture, a dummy write with the same value may be required to be issued
29203 by the atomic load to maintain sequential consistency. This, in turn, may
29204 make the following code:
29207 <blockquote><pre>const atomic_int x{};
29213 </pre></blockquote>
29216 dump core under a straightforward implementation that puts const objects in
29217 a read-only section.
29220 There are ways to sidestep the problem, but it needs to be considered.
29223 The tradeoff is between making the data member of the atomic types
29224 mutable and requiring the user to explicitly mark atomic members as
29225 mutable, as is already the case with mutexes.
29231 <p><b>Proposed resolution:</b></p>
29233 Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
29236 <blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
29237 C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
29238 C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
29239 </pre></blockquote>
29247 <h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
29248 <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29249 <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
29250 <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>
29251 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29252 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
29253 <p><b>Discussion:</b></p>
29255 A small issue with <tt>std::bitset</tt>: it does not have any constructor
29256 taking a string literal, which is clumsy and looks like an oversigt when
29257 we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
29264 <blockquote><pre>explicit bitset( const char* str );
29265 </pre></blockquote>
29272 <p><b>Proposed resolution:</b></p>
29274 Add to synopsis in 23.3.5 [template.bitset]
29277 <blockquote><pre>explicit bitset( const char* str );
29278 </pre></blockquote>
29281 Add to synopsis in 23.3.5.1 [bitset.cons]
29284 <blockquote><pre>explicit bitset( const char* str );
29287 <i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
29297 <h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
29298 <p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29299 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p>
29300 <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>
29301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29302 <p><b>Discussion:</b></p>
29304 A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis])
29305 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
29306 some complex functions that are missing in C++. These are:
29311 7.3.9.4: (required elements of the C99 library)<br>
29312 The <tt>cproj</tt> functions
29315 7.26.1: (optional elements of the C99 library)<br>
29316 <pre>cerf cerfc cexp2
29317 cexpm1 clog10 clog1p
29318 clog2 clgamma ctgamma
29324 I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
29325 C++ functions. This addition is easy to do in one sentence (delegation to C99
29330 Please note also that the current entry <tt>polar</tt>
29331 in 26.3.9 [cmplx.over]/1
29332 should be removed from the mentioned overload list. It does not make sense to require that a
29333 function already expecting <em>scalar</em> arguments
29334 should cast these arguments into corresponding
29335 <tt>complex<T></tt> arguments, which are not accepted by
29340 <p><b>Proposed resolution:</b></p>
29342 In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
29345 <blockquote><pre>template<class T> complex<T> conj(const complex<T>&);
29346 <ins>template<class T> complex<T> proj(const complex<T>&);</ins>
29347 template<class T> complex<T> fabs(const complex<T>&);
29348 </pre></blockquote>
29351 In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
29355 <pre>template<class T> complex<T> proj(const complex<T>& x);
29359 <i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
29360 subclause 7.3.9.4."
29365 In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
29371 The following function templates shall have additional overloads:
29373 <blockquote><pre>arg norm
29374 conj <del>polar</del> <ins>proj</ins>
29376 </pre></blockquote>
29385 <h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
29386 <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29387 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</p>
29388 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
29389 <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>
29390 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29391 <p><b>Discussion:</b></p>
29393 Part of the resolution of n2423, issue 8 was the proposal to
29394 extend the <tt>seed_seq</tt> constructor accepting an input range
29395 as follows (which is now part of N2461):
29398 <blockquote><pre>template<class InputIterator,
29399 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
29400 seed_seq(InputIterator begin, InputIterator end);
29401 </pre></blockquote>
29404 First, the expression <tt>iterator_traits<InputIterator>::value_type</tt>
29405 is invalid due to missing <tt>typename</tt> keyword, which is easy to
29410 Second (and worse), while the language now supports default
29411 template arguments of function templates, this customization
29412 point via the second <tt>size_t</tt> template parameter is of no advantage,
29413 because <tt>u</tt> can never be deduced, and worse - because it is a
29414 constructor function template - it can also never be explicitly
29415 provided (14.8.1 [temp.arg.explicit]/7).
29419 The question arises, which advantages result from a compile-time
29420 knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
29421 suffices, this parameter should be provided as normal function
29422 default argument [Resolution marked (A)], if compile-time knowledge
29423 is important, this could be done via a tagging template or more
29424 user-friendly via a standardized helper generator function
29425 (<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
29435 Fermilab does not have a strong opinion. Would prefer to go with
29436 solution A. Bill agrees that solution A is a lot simpler and does the
29440 Proposed Resolution: Accept Solution A.
29445 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
29450 <p><b>Proposed resolution:</b></p>
29454 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
29457 <blockquote><pre>class seed_seq
29461 template<class InputIterator<del>,
29462 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
29463 seed_seq(InputIterator begin, InputIterator end<ins>,
29464 size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>);
29467 </pre></blockquote>
29470 and do a similar replacement in the member description between
29477 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
29478 member description between p.3 and p.4 replace:
29481 <blockquote><pre>template<class InputIterator<del>,
29482 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
29483 seed_seq(InputIterator begin, InputIterator end);
29484 <ins>template<class InputIterator, size_t u>
29485 seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
29486 </pre></blockquote>
29489 In 26.4.2 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the
29490 class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
29491 after the class <tt>seed_seq</tt> definition add:
29494 <blockquote><pre>template<size_t u, class InputIterator>
29495 seed_seq make_seed_seq(InputIterator begin, InputIterator end);
29496 </pre></blockquote>
29499 In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
29504 The first constructor behaves as if it would provide an
29505 integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
29506 <tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>.
29509 The second constructor uses an implementation-defined mechanism
29510 to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
29511 is called by the function <tt>make_seed_seq</tt>.
29516 In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
29520 <pre>template<size_t u, class InputIterator>
29521 seed_seq make_seed_seq(InputIterator begin, InputIterator end);
29525 where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
29528 <i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
29542 <h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
29543 <p><b>Section:</b> 30.2.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>
29544 <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
29545 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29546 <p><b>Discussion:</b></p>
29548 The current working paper
29549 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
29550 integrated just before Bellevue) is
29551 not completely clear whether a given <tt>thread::id</tt> value may be reused once
29552 a thread has exited and has been joined or detached. Posix allows
29553 thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is
29554 not completely clear whether this originally was the right decision, it
29555 is clearly the established practice, and we believe it was always the
29556 intent of the C++ threads API to follow Posix and allow this. Howard
29557 Hinnant's example implementation implicitly relies on allowing reuse
29558 of ids, since it uses Posix thread ids directly.
29562 It is important to be clear on this point, since it the reuse of thread
29563 ids often requires extra care in client code, which would not be
29564 necessary if thread ids were unique across all time. For example, a
29565 hash table indexed by thread id may have to be careful not to associate
29566 data values from an old thread with a new one that happens to reuse the
29567 id. Simply removing the old entry after joining a thread may not be
29568 sufficient, if it creates a visible window between the join and removal
29569 during which a new thread with the same id could have been created and
29570 added to the table.
29574 post Bellevue Peter adds:
29580 There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
29581 reconsider fixing this by disallowing reuse, rather than explicitly allowing
29582 it. Dealing with thread id reuse is an incredibly painful exercise that
29583 would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
29587 In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
29588 atomically in a lock-free manner, as motivated by the recursive lock
29593 <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>
29599 <p><b>Proposed resolution:</b></p>
29601 Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
29606 An object of type <code>thread::id</code> provides
29607 a unique identifier for each thread of execution
29608 and a single distinct value for all thread objects
29609 that do not represent a thread of execution ([thread.threads.class]).
29610 Each thread of execution has a <code>thread::id</code>
29611 that is not equal to the <code>thread::id</code>
29612 of other threads of execution
29613 and that is not equal to
29614 the <code>thread::id</code> of <code>std::thread</code> objects
29615 that do not represent threads of execution.
29616 <ins>The library may reuse the value of a <code>thread::id</code> of a
29617 terminated thread that can no longer be joined.</ins>
29626 <h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
29627 <p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29628 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
29629 <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>
29630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29631 <p><b>Discussion:</b></p>
29633 <tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
29642 Non-controversial. Bill is right, but Fermilab believes that this is
29643 easy to use badly and hard to use right, and so it should be removed
29644 entirely. Got into TR1 by well defined route, do we have permission to
29645 remove stuff? Should probably check with Jens, as it is believed he is
29646 the originator. Broad consensus that this is not a robust engine
29651 <p><b>Proposed resolution:</b></p>
29653 Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
29656 Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
29664 <h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
29665 <p><b>Section:</b> 26.4.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>
29666 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
29667 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
29668 <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>
29669 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29670 <p><b>Discussion:</b></p>
29672 <tt>piecewise_constant_distribution</tt> is undefined for a range with just one
29673 endpoint. (Probably should be the same as an empty range.)
29677 <p><b>Proposed resolution:</b></p>
29679 Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
29683 b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
29691 <h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
29692 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
29693 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
29694 <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>
29695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29696 <p><b>Discussion:</b></p>
29698 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
29699 and its earlier predecessors have moved the old binders from
29700 [lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
29701 of the template parameter names (<tt>Operation -> Fn</tt>). During this
29702 renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
29703 <tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
29704 this user access point is probably rarely used.
29708 <p><b>Proposed resolution:</b></p>
29710 Change D.8.1 [depr.lib.binder.1st]:
29714 <pre>template <class Fn>
29716 : public unary_function<typename Fn::second_argument_type,
29717 typename Fn::result_type> {
29719 Fn <del>fn</del> <ins>op</ins>;
29720 typename Fn::first_argument_type value;
29722 binder1st(const Fn& x,
29723 const typename Fn::first_argument_type& y);
29724 typename Fn::result_type
29725 operator()(const typename Fn::second_argument_type& x) const;
29726 typename Fn::result_type
29727 operator()(typename Fn::second_argument_type& x) const;
29733 -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>.
29736 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
29742 Change D.8.3 [depr.lib.binder.2nd]:
29746 <pre>template <class Fn>
29748 : public unary_function<typename Fn::first_argument_type,
29749 typename Fn::result_type> {
29751 Fn <del>fn</del> <ins>op</ins>;
29752 typename Fn::second_argument_type value;
29754 binder2nd(const Fn& x,
29755 const typename Fn::second_argument_type& y);
29756 typename Fn::result_type
29757 operator()(const typename Fn::first_argument_type& x) const;
29758 typename Fn::result_type
29759 operator()(typename Fn::first_argument_type& x) const;
29765 -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>.
29768 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
projects / l4.git / blob