1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2 <html><head><title>C++ Standard Library Active Issues List</title>
6 <style type="text/css">
8 li {text-align:justify}
9 ins {background-color:#A0FFA0}
10 del {background-color:#FFA0A0}
14 <td align="left">Doc. no.</td>
15 <td align="left">N2612=08-0122</td>
18 <td align="left">Date:</td>
19 <td align="left">2008-05-18</td>
22 <td align="left">Project:</td>
23 <td align="left">Programming Language C++</td>
26 <td align="left">Reply to:</td>
27 <td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
30 <h1>C++ Standard Library Active Issues List (Revision R56)</h1>
32 <p>Reference ISO/IEC IS 14882:1998(E)</p>
35 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
36 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
37 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
38 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
39 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
41 <p>The purpose of this document is to record the status of issues
42 which have come before the Library Working Group (LWG) of the ANSI
43 (J16) and ISO (WG21) C++ Standards Committee. Issues represent
44 potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
45 are not to be used to request new features. </p>
47 <p>This document contains only library issues which are actively being
48 considered by the Library Working Group. That is, issues which have a
49 status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
50 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
51 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
52 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
54 <p>The issues in these lists are not necessarily formal ISO Defect
55 Reports (DR's). While some issues will eventually be elevated to
56 official Defect Report status, other issues will be disposed of in
57 other ways. See <a href="#Status">Issue Status</a>.</p>
59 <p>This document is in an experimental format designed for both
60 viewing via a world-wide web browser and hard-copy printing. It
61 is available as an HTML file for browsing or PDF file for
64 <p>Prior to Revision 14, library issues lists existed in two slightly
65 different versions; a Committee Version and a Public
66 Version. Beginning with Revision 14 the two versions were combined
67 into a single version.</p>
69 <p>This document includes <i>[bracketed italicized notes]</i> as a
70 reminder to the LWG of current progress on issues. Such notes are
71 strictly unofficial and should be read with caution as they may be
72 incomplete or incorrect. Be aware that LWG support for a particular
73 resolution can quickly change if new viewpoints or killer examples are
74 presented in subsequent discussions.</p>
76 <p>For the most current official version of this document see
77 <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
78 Requests for further information about this document should include
79 the document number above, reference ISO/IEC 14882:1998(E), and be
80 submitted to Information Technology Industry Council (ITI), 1250 Eye
81 Street NW, Washington, DC 20005.</p>
83 <p>Public information as to how to obtain a copy of the C++ Standard,
84 join the standards committee, submit an issue, or comment on an issue
85 can be found in the comp.std.c++ FAQ.
86 Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
89 <p>For committee members, files available on the committee's private
90 web site include the HTML version of the Standard itself. HTML
91 hyperlinks from this issues list to those files will only work for
92 committee members who have downloaded them into the same disk
93 directory as the issues list files. </p>
95 <h2>Revision History</h2>
98 2008-05-16 pre-Sophia Antipolis mailing.
100 <li><b>Summary:</b><ul>
101 <li>191 open issues, up by 24.</li>
102 <li>647 closed issues, up by 1.</li>
103 <li>838 issues total, up by 25.</li>
105 <li><b>Details:</b><ul>
106 <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-active.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-active.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>
107 <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>
112 2008-03-14 post-Bellevue mailing.
114 <li><b>Summary:</b><ul>
115 <li>167 open issues, down by 39.</li>
116 <li>646 closed issues, up by 65.</li>
117 <li>813 issues total, up by 26.</li>
119 <li><b>Details:</b><ul>
120 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
121 <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>
122 <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>
123 <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>
124 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</a>.</li>
125 <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>
126 <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>
127 <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>
128 <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>
129 <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>
130 <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>
131 <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>
132 <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>
133 <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-active.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-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
134 <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>
135 <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#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>
136 <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>
137 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>.</li>
138 <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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#673">673</a>.</li>
139 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>.</li>
140 <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>
141 <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>
142 <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>
143 <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>
148 2008-02-01 pre-Bellevue mailing.
150 <li><b>Summary:</b><ul>
151 <li>206 open issues, up by 23.</li>
152 <li>581 closed issues, up by 0.</li>
153 <li>787 issues total, up by 23.</li>
155 <li><b>Details:</b><ul>
156 <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-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
157 <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>
158 <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>
159 <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>
160 <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>
161 <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>
166 2007-12-09 mid-term mailing.
168 <li><b>Summary:</b><ul>
169 <li>183 open issues, up by 11.</li>
170 <li>581 closed issues, down by 1.</li>
171 <li>764 issues total, up by 10.</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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>
175 <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>
176 <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>
181 2007-10-19 post-Kona mailing.
183 <li><b>Summary:</b><ul>
184 <li>172 open issues, up by 4.</li>
185 <li>582 closed issues, up by 27.</li>
186 <li>754 issues total, up by 31.</li>
188 <li><b>Details:</b><ul>
189 <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-active.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-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.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>
190 <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>
191 <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>
192 <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>
193 <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-active.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-active.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>
194 <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>
195 <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>
196 <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-active.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>
197 <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>
198 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
199 <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>
200 <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>
201 <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>
206 2007-09-09 pre-Kona mailing.
208 <li><b>Summary:</b><ul>
209 <li>168 open issues, up by 15.</li>
210 <li>555 closed issues, up by 0.</li>
211 <li>723 issues total, up by 15.</li>
213 <li><b>Details:</b><ul>
214 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
219 2007-08-05 post-Toronto mailing.
221 <li><b>Summary:</b><ul>
222 <li>153 open issues, down by 5.</li>
223 <li>555 closed issues, up by 17.</li>
224 <li>708 issues total, up by 12.</li>
226 <li><b>Details:</b><ul>
227 <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>
228 <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>
229 <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>
230 <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>
231 <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>
232 <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>
233 <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>
234 <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>
235 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li>
236 <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>
237 <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>
238 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>.</li>
239 <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>
240 <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>
241 <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>
246 2007-06-23 pre-Toronto mailing.
248 <li><b>Summary:</b><ul>
249 <li>158 open issues, up by 13.</li>
250 <li>538 closed issues, up by 7.</li>
251 <li>696 issues total, up by 20.</li>
253 <li><b>Details:</b><ul>
254 <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-active.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>
255 <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>
256 <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>
257 <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>
258 <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>
263 2007-05-06 post-Oxford mailing.
265 <li><b>Summary:</b><ul>
266 <li>145 open issues, down by 33.</li>
267 <li>531 closed issues, up by 53.</li>
268 <li>676 issues total, up by 20.</li>
270 <li><b>Details:</b><ul>
271 <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-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
272 <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>
273 <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>
274 <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>
275 <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>
276 <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>
277 <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>
278 <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>
279 <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>
280 <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>
281 <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-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
282 <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>
283 <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>
284 <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>
285 <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>
290 2007-03-09 pre-Oxford mailing.
292 <li><b>Summary:</b><ul>
293 <li>178 open issues, up by 37.</li>
294 <li>478 closed issues, up by 0.</li>
295 <li>656 issues total, up by 37.</li>
297 <li><b>Details:</b><ul>
298 <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-active.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-defects.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>
299 <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>
300 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
301 <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>
302 <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>
303 <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>
308 2007-01-12 mid-term mailing.
310 <li><b>Summary:</b><ul>
311 <li>141 open issues, up by 11.</li>
312 <li>478 closed issues, down by 1.</li>
313 <li>619 issues total, up by 10.</li>
315 <li><b>Details:</b><ul>
316 <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>
321 2006-11-03 post-Portland mailing.
323 <li><b>Summary:</b><ul>
324 <li>130 open issues, up by 0.</li>
325 <li>479 closed issues, up by 17.</li>
326 <li>609 issues total, up by 17.</li>
328 <li><b>Details:</b><ul>
329 <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>
330 <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>
331 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
332 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>
333 <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>
334 <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>
335 <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>
340 2006-09-08 pre-Portland mailing.
342 <li><b>Summary:</b><ul>
343 <li>130 open issues, up by 6.</li>
344 <li>462 closed issues, down by 1.</li>
345 <li>592 issues total, up by 5.</li>
347 <li><b>Details:</b><ul>
348 <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>
353 2006-06-23 mid-term mailing.
355 <li><b>Summary:</b><ul>
356 <li>124 open issues, up by 14.</li>
357 <li>463 closed issues, down by 1.</li>
358 <li>587 issues total, up by 13.</li>
360 <li><b>Details:</b><ul>
361 <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>
362 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
363 <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>
368 2006-04-21 post-Berlin mailing.
370 <li><b>Summary:</b><ul>
371 <li>110 open issues, down by 16.</li>
372 <li>464 closed issues, up by 24.</li>
373 <li>574 issues total, up by 8.</li>
375 <li><b>Details:</b><ul>
376 <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>
377 <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>
378 <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>
379 <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>
380 <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>
381 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
386 2006-02-24 pre-Berlin mailing.
388 <li><b>Summary:</b><ul>
389 <li>126 open issues, up by 31.</li>
390 <li>440 closed issues, up by 0.</li>
391 <li>566 issues total, up by 31.</li>
393 <li><b>Details:</b><ul>
394 <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>
395 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
396 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
401 2005-12-16 mid-term mailing.
403 <li><b>Summary:</b><ul>
404 <li>95 open issues.</li>
405 <li>440 closed issues.</li>
406 <li>535 issues total.</li>
408 <li><b>Details:</b><ul>
409 <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>
414 2005-10-14 post-Mont Tremblant mailing.
415 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>.
416 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.
417 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.
418 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.
419 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.
420 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
421 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
424 2005-07-03 pre-Mont Tremblant mailing.
425 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>.
426 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>
429 2005-06 mid-term mailing.
430 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>.
433 2005-04 post-Lillehammer mailing. All issues in "ready" status except
434 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
435 previously in "DR" status were moved to "WP".
438 2005-03 pre-Lillehammer mailing.
441 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>.
444 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
447 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
448 new issues received after the 2004-07 mailing. Added
449 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>.
452 2004-07 mid-term mailing: reflects new proposed resolutions and
453 new issues received after the post-Sydney mailing. Added
454 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>.
457 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
458 Voted all "Ready" issues from R29 into the working paper.
459 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>.
462 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>.
465 Post-Kona mailing: reflects decisions made at the Kona meeting.
466 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>.
469 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>.
472 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
473 All issues in Ready status were voted into DR status. All issues in
474 DR status were voted into WP status.
477 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>.
480 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
481 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
482 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
483 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
484 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
487 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>.
488 Moved issues in the TC to TC status.
491 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>.
494 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>.
497 Post-Redmond mailing; reflects actions taken in Redmond. Added
498 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
499 <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
500 not discussed at the meeting.
502 All Ready issues were moved to DR status, with the exception of issues
503 <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>.
505 Noteworthy issues discussed at Redmond include
506 <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>,
507 <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>.
510 Pre-Redmond mailing. Added new issues
511 <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>.
514 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
515 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
516 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>.
518 Changed status of issues
519 <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>
520 <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>
521 <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>
522 <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>
523 <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>
524 <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>
525 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
528 Changed status of issues
529 <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>
530 <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>
531 <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>
532 <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>
533 <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>
534 <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>
535 <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>
536 <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>
537 <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>
541 <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>
542 <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>
543 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
548 Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
549 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>.
550 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>.
553 post-Toronto mailing; reflects actions taken in Toronto. Added new
554 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
555 <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>,
556 <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>,
557 <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>,
558 <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>,
559 <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>,
560 <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>,
561 <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>,
562 <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>,
563 <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>,
564 <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>,
565 <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>,
566 <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>,
567 <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
568 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
569 <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
570 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
571 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
572 the bug in enough places.
575 pre-Toronto mailing. Added issues
576 <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
577 changes so that we pass Weblint tests.
580 post-Tokyo II mailing; reflects committee actions taken in
581 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)
584 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>.
587 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
588 <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
589 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
590 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
593 post-Kona mailing: Updated to reflect LWG and full committee actions
594 in Kona (99-0048/N1224). Note changed resolution of issues
595 <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>
596 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
597 "closed" documents. Changed the proposed resolution of issue
598 <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
599 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
602 pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
603 <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>,
604 <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
605 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
608 pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
609 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
610 "closed" documents. (99-0030/N1206, 25 Aug 99)
613 post-Dublin mailing. Updated to reflect LWG and full committee actions
614 in Dublin. (99-0016/N1193, 21 Apr 99)
617 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>,
618 <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>,
619 <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>,
620 <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)
623 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>,
624 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
627 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
628 <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
629 for making list public. (30 Dec 98)
632 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
633 <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
634 issues corrected. (22 Oct 98)
637 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>
638 added, many issues updated to reflect LWG consensus (12 Oct 98)
641 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,
642 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
645 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
646 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
650 <h2><a name="Status"></a>Issue Status</h2>
652 <p><b><a name="New">New</a></b> - The issue has not yet been
653 reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
654 suggestion from the issue submitter, and should not be construed as
657 <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
658 but is not yet ready to move the issue forward. There are several
659 possible reasons for open status:</p>
661 <li>Consensus may have not yet have been reached as to how to deal
663 <li>Informal consensus may have been reached, but the LWG awaits
664 exact <b>Proposed Resolution</b> wording for review.</li>
665 <li>The LWG wishes to consult additional technical experts before
667 <li>The issue may require further study.</li>
670 <p>A <b>Proposed Resolution</b> for an open issue is still not be
671 construed as the view of LWG. Comments on the current state of
672 discussions are often given at the end of open issues in an italic
673 font. Such comments are for information only and should not be given
674 undue importance.</p>
676 <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
677 the issue is a duplicate of another issue, and will not be further
678 dealt with. A <b>Rationale</b> identifies the duplicated issue's
681 <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
682 the issue is not a defect in the Standard.</p>
684 <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
685 the issue can either be handled editorially, or is handled by a paper (usually
686 linked to in the rationale).</p>
688 <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
689 status, the LWG believes that this issue should be revisited at the
690 next revision of the standard.</p>
692 <p><b><a name="Review">Review</a></b> - Exact wording of a
693 <b>Proposed Resolution</b> is now available for review on an issue
694 for which the LWG previously reached informal consensus.</p>
696 <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
697 been reviewed online, but not in a meeting, and some support has been formed
698 for the proposed resolution. Tentatively Ready issues may be moved to Ready
699 and forwarded to full committee within the same meeting. Unlike Ready issues
700 they will be reviewed in subcommittee prior to forwarding to full committee.</p>
702 <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
703 that the issue is a defect in the Standard, the <b>Proposed
704 Resolution</b> is correct, and the issue is ready to forward to the
705 full committee for further action as a Defect Report (DR).</p>
707 <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
708 committee has voted to forward the issue to the Project Editor to be
709 processed as a Potential Defect Report. The Project Editor reviews
710 the issue, and then forwards it to the WG21 Convenor, who returns it
711 to the full committee for final disposition. This issues list
712 accords the status of DR to all these Defect Reports regardless of
713 where they are in that process.</p>
715 <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
716 WG21 committee has voted to accept the Defect Report's Proposed
717 Resolution as a Technical Corrigenda. Action on this issue is thus
718 complete and no further action is possible under ISO rules.</p>
720 <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
721 LWG has voted to accept the Defect Report's Proposed
722 Resolution into the Decimal TR. Action on this issue is thus
723 complete and no further action is expected.</p>
725 <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
726 resolution has not been accepted as a Technical Corrigendum, but
727 the full WG21 committee has voted to apply the Defect Report's Proposed
728 Resolution to the working paper.</p>
730 <p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to
731 a status this indicates the issue has been
732 processed by the committee, and a decision has been made to move the issue to
733 the associated unqualified status. However for logistical reasons the indicated
734 outcome of the issue has not yet appeared in the latest working paper.
736 </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
737 they first appear on the issues list. They may progress to
738 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
739 is actively working on them. When the LWG has reached consensus on
740 the disposition of an issue, the status will then change to
741 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or
742 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to
743 forward Ready issues to the Project Editor, they are given the
744 status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
745 become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
746 or are closed without action other than a Record of Response
747 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
748 only issues which are truly defects in the Standard move to the
749 formal ISO DR status.
753 <h2>Active Issues</h2>
755 <h3><a name="23"></a>23. Num_get overflow result</h3>
756 <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#Open">Open</a>
757 <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
758 <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>
759 <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>
760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
761 <p><b>Discussion:</b></p>
762 <p>The current description of numeric input does not account for the
763 possibility of overflow. This is an implicit result of changing the
764 description to rely on the definition of scanf() (which fails to
765 report overflow), and conflicts with the documented behavior of
766 traditional and current implementations. </p>
768 <p>Users expect, when reading a character sequence that results in a
769 value unrepresentable in the specified type, to have an error
770 reported. The standard as written does not permit this. </p>
772 <p><b>Further comments from Dietmar:</b></p>
775 I don't feel comfortable with the proposed resolution to issue 23: It
776 kind of simplifies the issue to much. Here is what is going on:
780 Currently, the behavior of numeric overflow is rather counter intuitive
781 and hard to trace, so I will describe it briefly:
786 According to 22.2.2.1.2 [facet.num.get.virtuals]
787 paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
788 return an input error; otherwise a value is converted to the rules
792 <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
795 <tt>fscanf()</tt> returns an input failure if during conversion no
796 character matching the conversion specification could be extracted
797 before reaching EOF. This is the only reason for <tt>fscanf()</tt>
798 to fail due to an input error and clearly does not apply to the case
802 Thus, the conversion is performed according to the rules of
803 <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
804 <tt>strtol()</tt>, etc. are to be used for the conversion.
807 The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
808 many matching characters as there are and on overflow continue to
809 consume matching characters but also return a value identical to
810 the maximum (or minimum for signed types if there was a leading minus)
811 value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
814 Thus, according to the current wording in the standard, overflows
815 can be detected! All what is to be done is to check <tt>errno</tt>
816 after reading an element and, of course, clearing <tt>errno</tt>
817 before trying a conversion. With the current wording, it can be
818 detected whether the overflow was due to a positive or negative
819 number for signed types.
823 <p><b>Further discussion from Redmond:</b></p>
825 <p>The basic problem is that we've defined our behavior,
826 including our error-reporting behavior, in terms of C90. However,
827 C90's method of reporting overflow in scanf is not technically an
828 "input error". The <tt>strto_*</tt> functions are more precise.</p>
830 <p>There was general consensus that <tt>failbit</tt> should be set
831 upon overflow. We considered three options based on this:</p>
833 <li>Set failbit upon conversion error (including overflow), and
834 don't store any value.</li>
835 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
836 indicated the precise nature of the error.</li>
837 <li>Set failbit upon conversion error. If the error was due to
838 overflow, store +-numeric_limits<T>::max() as an
839 overflow indication.</li>
842 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
845 <p>Discussed at Lillehammer. General outline of what we want the
846 solution to look like: we want to say that overflow is an error, and
847 provide a way to distinguish overflow from other kinds of errors.
848 Choose candidate field the same way scanf does, but don't describe
849 the rest of the process in terms of format. If a finite input field
850 is too large (positive or negative) to be represented as a finite
851 value, then set failbit and assign the nearest representable value.
852 Bill will provide wording.</p>
855 Discussed at Toronto:
856 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
857 is in alignment with the direction we wanted to go with in Lillehammer. Bill
863 <p><b>Proposed resolution:</b></p>
866 Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
871 <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
872 <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
873 converted to a numeric value by the rules of one of the functions declared
874 in the header <tt><cstdlib></tt>:</ins>
878 <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
879 converted (according to the rules of <tt>scanf</tt>) to a value of the
880 type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
881 stored in <i>err</i>.</del>
882 <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
885 <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
886 <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
887 assigned to <i>err</i>.</del>
888 <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
891 <ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
895 <ins>The numeric value to be stored can be one of:</ins>
898 <li><ins>zero, if the conversion function fails to convert the entire field.
899 <tt>ios_base::failbit</tt> is assigned to err.</ins></li>
900 <li><ins>the most positive representable value, if the field represents a value
901 too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
902 to <i>err</i>.</ins></li>
903 <li><ins>the most negative representable value (zero for unsigned integer), if
904 the field represents a value too large negative to be represented in <i>val</i>.
905 <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
906 <li><ins>the converted value, otherwise.</ins></li>
910 The resultant numeric value is stored in <i>val</i>.
915 Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
919 <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>,
920 ios_base::iostate& <i>err</i>, bool& <i>val</i>) const;
924 -6- <i>Effects:</i> If
925 <tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input
926 proceeds as it would for a <tt>long</tt> except that if a value is being
927 stored into <i>val</i>, the value is determined according to the
928 following: If the value to be stored is 0 then <tt>false</tt> is stored.
929 If the value is 1 then <tt>true</tt> is stored. Otherwise
930 <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
931 stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
934 -7- Otherwise target sequences are determined "as if" by calling the
935 members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
936 obtained by <tt>use_facet<numpunct<charT>
937 >(<i>str</i>.getloc())</tt>. Successive characters in the range
938 <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
939 against corresponding positions in the target sequences only as
940 necessary to identify a unique match. The input iterator <i>in</i> is
941 compared to <i>end</i> only when necessary to obtain a character. If <del>and
942 only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
943 corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
944 is assigned to <i>err</i>.</ins>
954 <h3><a name="96"></a>96. Vector<bool> is not a container</h3>
955 <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#Open">Open</a>
956 <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
957 <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>
958 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
959 <p><b>Discussion:</b></p>
960 <p><tt>vector<bool></tt> is not a container as its reference and
961 pointer types are not references and pointers. </p>
963 <p>Also it forces everyone to have a space optimization instead of a
966 <p><b>See also:</b> 99-0008 == N1185 Vector<bool> is
967 Nonconforming, Forces Optimization Choice.</p>
969 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
972 <p><i>[In Dublin many present felt that failure to meet Container
973 requirements was a defect. There was disagreement as to whether
974 or not the optimization requirements constituted a defect.]</i></p>
977 <p><i>[The LWG looked at the following resolutions in some detail:
979 * Not A Defect.<br>
980 * Add a note explaining that vector<bool> does not meet
981 Container requirements.<br>
982 * Remove vector<bool>.<br>
983 * Add a new category of container requirements which
984 vector<bool> would meet.<br>
985 * Rename vector<bool>.<br>
987 No alternative had strong, wide-spread, support and every alternative
988 had at least one "over my dead body" response.<br>
990 There was also mention of a transition scheme something like (1) add
991 vector_bool and deprecate vector<bool> in the next standard. (2)
992 Remove vector<bool> in the following standard.]</i></p>
995 <p><i>[Modifying container requirements to permit returning proxies
996 (thus allowing container requirements conforming vector<bool>)
997 was also discussed.]</i></p>
1000 <p><i>[It was also noted that there is a partial but ugly workaround in
1001 that vector<bool> may be further specialized with a customer
1005 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1006 vector<bool>: More Problems, Better Solutions. Much discussion
1007 of a two step approach: a) deprecate, b) provide replacement under a
1008 new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
1009 my dead body. This resolution was mentioned in the LWG report to the
1010 full committee, where several additional committee members indicated
1011 over-my-dead-body positions.]</i></p>
1014 <p>Discussed at Lillehammer. General agreement that we should
1015 deprecate vector<bool> and introduce this functionality under
1016 a different name, e.g. bit_vector. This might make it possible to
1017 remove the vector<bool> specialization in the standard that comes
1018 after C++0x. There was also a suggestion that
1019 in C++0x we could additional say that it's implementation defined
1020 whether vector<bool> refers to the specialization or to the
1021 primary template, but there wasn't general agreement that this was a
1024 <p>We need a paper for the new bit_vector class.</p>
1029 <p><b>Proposed resolution:</b></p>
1032 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1034 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1038 Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1039 from <tt>vector<bool></tt>. Although some of the funcitonality from
1040 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1041 could well be used in such a template. The concern is easing the API migration for those
1042 users who want to continue using a bit-packed container. Alan and Beman to work.
1051 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3>
1052 <p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1053 <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
1054 <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>
1055 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1056 <p><b>Discussion:</b></p>
1057 <p>The following question came from Thorsten Herlemann:</p>
1060 <p>You can set a mode when constructing or opening a file-stream or
1061 filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
1062 that mode later on, e.g. in my own operator << or operator
1063 >> or when I want to check whether a file-stream or
1064 file-buffer object passed as parameter is opened for input or output
1065 or binary? Is there no possibility? Is this a design-error in the
1066 standard C++ library? </p>
1069 <p>It is indeed impossible to find out what a stream's or stream
1070 buffer's open mode is, and without that knowledge you don't know
1071 how certain operations behave. Just think of the append mode. </p>
1073 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1074 current open mode setting. </p>
1077 post Bellevue: Alisdair requested to re-Open.
1083 <p><b>Proposed resolution:</b></p>
1084 <p>For stream buffers, add a function to the base class as a non-virtual function
1085 qualified as const to 27.5.2 [streambuf]:</p>
1087 <p> <tt>openmode mode() const</tt>;</p>
1089 <p><b> Returns</b> the current open mode.</p>
1091 <p>With streams, I'm not sure what to suggest. In principle, the mode
1092 could already be returned by <tt>ios_base</tt>, but the mode is only
1093 initialized for file and string stream objects, unless I'm overlooking
1094 anything. For this reason it should be added to the most derived
1095 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1096 and would be default initialized in <tt>basic_ios<>::init()</tt>.</p>
1099 <p><b>Rationale:</b></p>
1100 <p>This might be an interesting extension for some future, but it is
1101 not a defect in the current standard. The Proposed Resolution is
1102 retained for future reference.</p>
1109 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
1110 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1111 <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
1112 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
1113 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
1114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1115 <p><b>Discussion:</b></p>
1116 <p>It is the constness of the container which should control whether
1117 it can be modified through a member function such as erase(), not the
1118 constness of the iterators. The iterators only serve to give
1119 positioning information.</p>
1121 <p>Here's a simple and typical example problem which is currently very
1122 difficult or impossible to solve without the change proposed
1125 <p>Wrap a standard container C in a class W which allows clients to
1126 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
1127 only modification clients are allowed to make to elements in this
1128 subrange is to erase them from C through the use of a member function
1132 post Bellevue, Alisdair adds:
1138 This issue was implemented by
1139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
1140 for everything but <tt>basic_string</tt>.
1144 Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
1145 we forgot to amend in
1146 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
1147 so we might open this issue for that
1154 <p><b>Proposed resolution:</b></p>
1155 <p>Change all non-const iterator parameters of standard library
1156 container member functions to accept const_iterator parameters.
1157 Note that this change applies to all library clauses, including
1160 <p>For example, in 21.3.5.5 change:<br>
1162 <tt>iterator erase(iterator p);</tt><br>
1165 <tt>iterator erase(const_iterator p);</tt>
1169 <p><b>Rationale:</b></p>
1170 <p>The issue was discussed at length. It was generally agreed that 1)
1171 There is no major technical argument against the change (although
1172 there is a minor argument that some obscure programs may break), and
1173 2) Such a change would not break const correctness. The concerns about
1174 making the change were 1) it is user detectable (although only in
1175 boundary cases), 2) it changes a large number of signatures, and 3) it
1176 seems more of a design issue that an out-and-out defect.</p>
1178 <p>The LWG believes that this issue should be considered as part of a
1179 general review of const issues for the next revision of the
1180 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
1186 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
1187 <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#Open">Open</a>
1188 <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
1189 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
1190 <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>
1191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1192 <p><b>Discussion:</b></p>
1193 <p>Both std::min and std::max are defined as template functions. This
1194 is very different than the definition of std::plus (and similar
1195 structs) which are defined as function objects which inherit
1196 std::binary_function.<br>
1198 This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
1199 a function object that inherits std::binary_function.</p>
1202 post Bellevue: Alisdair requested to re-Open.
1208 <p><b>Rationale:</b></p>
1209 <p>Although perhaps an unfortunate design decision, the omission is not a defect
1210 in the current standard. A future standard may wish to consider additional
1211 function objects.</p>
1217 <h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
1218 <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#Open">Open</a>
1219 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
1220 <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>
1221 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1222 <p><b>Discussion:</b></p>
1224 The basic_streambuf members gbump() and pbump() are specified to take an
1225 int argument. This requirement prevents the functions from effectively
1226 manipulating buffers larger than std::numeric_limits<int>::max()
1227 characters. It also makes the common use case for these functions
1228 somewhat difficult as many compilers will issue a warning when an
1229 argument of type larger than int (such as ptrdiff_t on LLP64
1230 architectures) is passed to either of the function. Since it's often the
1231 result of the subtraction of two pointers that is passed to the
1232 functions, a cast is necessary to silence such warnings. Finally, the
1233 usage of a native type in the functions signatures is inconsistent with
1234 other member functions (such as sgetn() and sputn()) that manipulate the
1235 underlying character buffer. Those functions take a streamsize argument.
1239 <p><b>Proposed resolution:</b></p>
1241 Change the signatures of these functions in the synopsis of template
1242 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
1243 and 27.5.2.3.2, p4) to take a streamsize argument.
1247 Although this change has the potential of changing the ABI of the
1248 library, the change will affect only platforms where int is different
1249 than the definition of streamsize. However, since both functions are
1250 typically inline (they are on all known implementations), even on such
1251 platforms the change will not affect any user code unless it explicitly
1252 relies on the existing type of the functions (e.g., by taking their
1253 address). Such a possibility is IMO quite remote.
1257 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
1261 This is something of a nit, but I'm wondering if streamoff wouldn't be a
1262 better choice than streamsize. The argument to pbump and gbump MUST be
1263 signed. But the standard has this to say about streamsize
1264 (27.4.1/2/Footnote):
1268 [Footnote: streamsize is used in most places where ISO C would use
1269 size_t. Most of the uses of streamsize could use size_t, except for
1270 the strstreambuf constructors, which require negative values. It
1271 should probably be the signed type corresponding to size_t (which is
1272 what Posix.2 calls ssize_t). --- end footnote]
1276 This seems a little weak for the argument to pbump and gbump. Should we
1277 ever really get rid of strstream, this footnote might go with it, along
1278 with the reason to make streamsize signed.
1282 <p><b>Rationale:</b></p>
1283 <p>The LWG believes this change is too big for now. We may wish to
1284 reconsider this for a future revision of the standard. One
1285 possibility is overloading pbump, rather than changing the
1288 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
1296 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
1297 <p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1298 <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
1299 <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>
1300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1301 <p><b>Discussion:</b></p>
1302 <p>The specification of the for_each algorithm does not have a
1303 "Requires" section, which means that there are no
1304 restrictions imposed on the function object whatsoever. In essence it
1305 means that I can provide any function object with arbitrary side
1306 effects and I can still expect a predictable result. In particular I
1307 can expect that the function object is applied exactly last - first
1308 times, which is promised in the "Complexity" section.
1311 <p>I don't see how any implementation can give such a guarantee
1312 without imposing requirements on the function object.
1315 <p>Just as an example: consider a function object that removes
1316 elements from the input sequence. In that case, what does the
1317 complexity guarantee (applies f exactly last - first times) mean?
1320 <p>One can argue that this is obviously a nonsensical application and
1321 a theoretical case, which unfortunately it isn't. I have seen
1322 programmers shooting themselves in the foot this way, and they did not
1323 understand that there are restrictions even if the description of the
1324 algorithm does not say so.
1326 <p><i>[Lillehammer: This is more general than for_each. We don't want
1327 the function object in transform invalidiating iterators
1328 either. There should be a note somewhere in clause 17 (17, not 25)
1329 saying that user code operating on a range may not invalidate
1330 iterators unless otherwise specified. Bill will provide wording.]</i></p>
1334 <p><b>Proposed resolution:</b></p>
1342 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
1343 <p><b>Section:</b> 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1344 <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
1345 <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>
1346 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1347 <p><b>Discussion:</b></p>
1349 In section 24.1.4 [bidirectional.iterators],
1350 Table 75 gives the return type of *r-- as convertible to T. This is
1351 not consistent with Table 74 which gives the return type of *r++ as
1352 T&. *r++ = t is valid while *r-- = t is invalid.
1356 In section 24.1.5 [random.access.iterators],
1357 Table 76 gives the return type of a[n] as convertible to T. This is
1358 not consistent with the semantics of *(a + n) which returns T& by
1359 Table 74. *(a + n) = t is valid while a[n] = t is invalid.
1363 Discussion from the Copenhagen meeting: the first part is
1364 uncontroversial. The second part, operator[] for Random Access
1365 Iterators, requires more thought. There are reasonable arguments on
1366 both sides. Return by value from operator[] enables some potentially
1367 useful iterators, e.g. a random access "iota iterator" (a.k.a
1368 "counting iterator" or "int iterator"). There isn't any obvious way
1369 to do this with return-by-reference, since the reference would be to a
1370 temporary. On the other hand, <tt>reverse_iterator</tt> takes an
1371 arbitrary Random Access Iterator as template argument, and its
1372 operator[] returns by reference. If we decided that the return type
1373 in Table 76 was correct, we would have to change
1374 <tt>reverse_iterator</tt>. This change would probably affect user
1379 History: the contradiction between <tt>reverse_iterator</tt> and the
1380 Random Access Iterator requirements has been present from an early
1381 stage. In both the STL proposal adopted by the committee
1382 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1383 Stepanov and Lee), the Random Access Iterator requirements say that
1384 operator[]'s return value is "convertible to T". In N0527
1385 reverse_iterator's operator[] returns by value, but in HPL-95-11
1386 (R.1), and in the STL implementation that HP released to the public,
1387 reverse_iterator's operator[] returns by reference. In 1995, the
1388 standard was amended to reflect the contents of HPL-95-11 (R.1). The
1389 original intent for operator[] is unclear.
1393 In the long term it may be desirable to add more fine-grained
1394 iterator requirements, so that access method and traversal strategy
1395 can be decoupled. (See "Improved Iterator Categories and
1396 Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
1397 about issue 299 should keep this possibility in mind.
1400 <p>Further discussion: I propose a compromise between John Potter's
1401 resolution, which requires <tt>T&</tt> as the return type of
1402 <tt>a[n]</tt>, and the current wording, which requires convertible to
1403 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1404 for the return type of the expression <tt>a[n]</tt>, but to also add
1405 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1406 common case uses of random access iterators, while at the same time
1407 allowing iterators such as counting iterator and caching file
1408 iterators to remain random access iterators (iterators where the
1409 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1410 lifetime of the iterator).
1414 Note that the compromise resolution necessitates a change to
1415 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1420 Note also there is one kind of mutable random access iterator that
1421 will no longer meet the new requirements. Currently, iterators that
1422 return an r-value from <tt>operator[]</tt> meet the requirements for a
1423 mutable random access iterartor, even though the expression <tt>a[n] =
1424 t</tt> will only modify a temporary that goes away. With this proposed
1425 resolution, <tt>a[n] = t</tt> will be required to have the same
1426 operational semantics as <tt>*(a + n) = t</tt>.
1431 <p><b>Proposed resolution:</b></p>
1434 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1435 type in table 75 from "convertible to <tt>T</tt>" to
1440 In section 24.1.5 [lib.random.access.iterators], change the
1441 operational semantics for <tt>a[n]</tt> to " the r-value of
1442 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1443 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1444 with a return type of convertible to <tt>T</tt> and operational semantics of
1445 <tt>*(a + n) = t</tt>.
1448 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1449 iterator redesign]</i></p>
1459 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
1460 <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#Open">Open</a>
1461 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
1462 <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>
1463 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1464 <p><b>Discussion:</b></p>
1466 The descriptions of the constructors of basic_istream<>::sentry
1467 (27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
1468 (27.6.2.4 [ostream::sentry]) do not explain what the functions do in
1469 case an exception is thrown while they execute. Some current
1470 implementations allow all exceptions to propagate, others catch them
1471 and set ios_base::badbit instead, still others catch some but let
1476 The text also mentions that the functions may call setstate(failbit)
1477 (without actually saying on what object, but presumably the stream
1478 argument is meant). That may have been fine for
1479 basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
1480 the function performs an input operation which may fail. However,
1481 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.3 [istream::sentry], p2 to
1482 clarify that the function should actually call setstate(failbit |
1483 eofbit), so the sentence in p3 is redundant or even somewhat
1488 The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
1489 doesn't seem to be very meaningful for basic_istream<>::sentry
1490 which performs no input. It is actually rather misleading since it
1491 would appear to guide library implementers to calling
1492 setstate(failbit) when os.tie()->flush(), the only called function,
1493 throws an exception (typically, it's badbit that's set in response to
1497 <p><b>Additional comments from Martin, who isn't comfortable with the
1498 current proposed resolution</b> (see c++std-lib-11530)</p>
1501 The istream::sentry ctor says nothing about how the function
1502 deals with exemptions (27.6.1.1.2, p1 says that the class is
1503 responsible for doing "exception safe"(*) prefix and suffix
1504 operations but it doesn't explain what level of exception
1505 safety the class promises to provide). The mockup example
1506 of a "typical implementation of the sentry ctor" given in
1507 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
1508 exception handling, either. Since the ctor is not classified
1509 as a formatted or unformatted input function, the text in
1510 27.6.1.1, p1 through p4 does not apply. All this would seem
1511 to suggest that the sentry ctor should not catch or in any
1512 way handle exceptions thrown from any functions it may call.
1513 Thus, the typical implementation of an istream extractor may
1514 look something like [1].
1518 The problem with [1] is that while it correctly sets ios::badbit
1519 if an exception is thrown from one of the functions called from
1520 the sentry ctor, if the sentry ctor reaches EOF while extracting
1521 whitespace from a stream that has eofbit or failbit set in
1522 exceptions(), it will cause an ios::failure to be thrown, which
1523 will in turn cause the extractor to set ios::badbit.
1527 The only straightforward way to prevent this behavior is to
1528 move the definition of the sentry object in the extractor
1529 above the try block (as suggested by the example in 22.2.8,
1530 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
1531 But such an implementation will allow exceptions thrown from
1532 functions called from the ctor to freely propagate to the
1533 caller regardless of the setting of ios::badbit in the stream
1534 object's exceptions().
1538 So since neither [1] nor [2] behaves as expected, the only
1539 possible solution is to have the sentry ctor catch exceptions
1540 thrown from called functions, set badbit, and propagate those
1541 exceptions if badbit is also set in exceptions(). (Another
1542 solution exists that deals with both kinds of sentries, but
1543 the code is non-obvious and cumbersome -- see [3].)
1547 Please note that, as the issue points out, current libraries
1548 do not behave consistently, suggesting that implementors are
1549 not quite clear on the exception handling in istream::sentry,
1550 despite the fact that some LWG members might feel otherwise.
1551 (As documented by the parenthetical comment here:
1552 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
1556 Also please note that those LWG members who in Copenhagen
1557 felt that "a sentry's constructor should not catch exceptions,
1558 because sentries should only be used within (un)formatted input
1559 functions and that exception handling is the responsibility of
1560 those functions, not of the sentries," as noted here
1561 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
1562 would in effect be either arguing for the behavior described
1563 in [1] or for extractors implemented along the lines of [3].
1567 The original proposed resolution (Revision 25 of the issues
1568 list) clarifies the role of the sentry ctor WRT exception
1569 handling by making it clear that extractors (both library
1570 or user-defined) should be implemented along the lines of
1571 [2] (as opposed to [1]) and that no exception thrown from
1572 the callees should propagate out of either function unless
1573 badbit is also set in exceptions().
1577 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
1580 <pre>struct S { long i; };
1582 istream& operator>> (istream &strm, S &s)
1584 ios::iostate err = ios::goodbit;
1586 const istream::sentry guard (strm, false);
1588 use_facet<num_get<char> >(strm.getloc ())
1589 .get (istreambuf_iterator<char>(strm),
1590 istreambuf_iterator<char>(),
1597 strm.setstate (ios::badbit);
1607 strm.setstate (err);
1613 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
1616 <pre>istream& operator>> (istream &strm, S &s)
1618 istream::sentry guard (strm, false);
1620 ios::iostate err = ios::goodbit;
1622 use_facet<num_get<char> >(strm.getloc ())
1623 .get (istreambuf_iterator<char>(strm),
1624 istreambuf_iterator<char>(),
1630 strm.setstate (ios::badbit);
1640 strm.setstate (err);
1648 [3] Extractor that catches exceptions thrown from sentry
1649 but doesn't set badbit if the exception was thrown as a
1650 result of a call to strm.clear().
1654 <pre>istream& operator>> (istream &strm, S &s)
1656 const ios::iostate state = strm.rdstate ();
1657 const ios::iostate except = strm.exceptions ();
1658 ios::iostate err = std::ios::goodbit;
1661 const istream::sentry guard (strm, false);
1664 use_facet<num_get<char> >(strm.getloc ())
1665 .get (istreambuf_iterator<char>(strm),
1666 istreambuf_iterator<char>(),
1671 if (thrown && state & except)
1674 strm.setstate (ios::badbit);
1684 strm.setstate (err);
1692 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
1696 [Pre-Portland] A relevant newsgroup post:
1700 The current proposed resolution of issue #309
1701 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
1702 unacceptable. I write commerical software and coding around this
1703 makes my code ugly, non-intuitive, and requires comments referring
1704 people to this very issue. Following is the full explanation of my
1708 In the course of writing software for commercial use, I constructed
1709 std::ifstream's based on user-supplied pathnames on typical POSIX
1713 It was expected that some files that opened successfully might not read
1714 successfully -- such as a pathname which actually refered to a
1715 directory. Intuitively, I expected the streambuffer underflow() code
1716 to throw an exception in this situation, and recent implementations of
1717 libstdc++'s basic_filebuf do just that (as well as many of my own
1721 I also intuitively expected that the istream code would convert these
1722 exceptions to the "badbit' set on the stream object, because I had not
1723 requested exceptions. I refer to 27.6.1.1. P4.
1726 However, this was not the case on at least two implementations -- if
1727 the first thing I did with an istream was call operator>>( T& ) for T
1728 among the basic arithmetic types and std::string. Looking further I
1729 found that the sentry's constructor was invoking the exception when it
1730 pre-scanned for whitespace, and the extractor function (operator>>())
1731 was not catching exceptions in this situation.
1734 So, I was in a situation where setting 'noskipws' would change the
1735 istream's behavior even though no characters (whitespace or not) could
1736 ever be successfully read.
1739 Also, calling .peek() on the istream before calling the extractor()
1740 changed the behavior (.peek() had the effect of setting the badbit
1744 I found this all to be so inconsistent and inconvenient for me and my
1745 code design, that I filed a bugzilla entry for libstdc++. I was then
1746 told that the bug cannot be fixed until issue #309 is resolved by the
1752 <p><b>Proposed resolution:</b></p>
1755 <p><b>Rationale:</b></p>
1756 <p>The LWG agrees there is minor variation between implementations,
1757 but believes that it doesn't matter. This is a rarely used corner
1758 case. There is no evidence that this has any commercial importance
1759 or that it causes actual portability problems for customers trying
1760 to write code that runs on multiple implementations.</p>
1767 <h3><a name="342"></a>342. seek and eofbit</h3>
1768 <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#Open">Open</a>
1769 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
1770 <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>
1771 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1772 <p><b>Discussion:</b></p>
1773 <p>I think we have a defect.</p>
1775 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
1776 description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
1780 Behaves as an unformatted input function (as described in 27.6.1.3,
1781 paragraph 1), except that it does not count the number of characters
1782 extracted and does not affect the value returned by subsequent calls to
1783 gcount(). After constructing a sentry object, if fail() != true,
1784 executes rdbuf()->pubseekpos( pos).
1787 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
1788 27.6.1.3, paragraph 1 looks like:</p>
1791 Each unformatted input function begins execution by constructing an
1792 object of class sentry with the default argument noskipws (second)
1793 argument true. If the sentry object returns true, when converted to a
1794 value of type bool, the function endeavors to obtain the requested
1795 input. Otherwise, if the sentry constructor exits by throwing an
1796 exception or if the sentry object returns false, when converted to a
1797 value of type bool, the function returns without attempting to obtain
1798 any input. In either case the number of extracted characters is set to
1799 0; unformatted input functions taking a character array of non-zero
1800 size as an argument shall also store a null character (using charT())
1801 in the first location of the array. If an exception is thrown during
1802 input then ios::badbit is turned on in *this'ss error state. If
1803 (exception()&badbit)!= 0 then the exception is rethrown. It also counts
1804 the number of characters extracted. If no exception has been thrown it
1805 ends by storing the count in a member object and returning the value
1806 specified. In any event the sentry object is destroyed before leaving
1807 the unformatted input function.
1810 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1813 If, after any preparation is completed, is.good() is true, ok_ != false
1814 otherwise, ok_ == false.
1818 So although the seekg paragraph says that the operation proceeds if
1819 !fail(), the behavior of unformatted functions says the operation
1820 proceeds only if good(). The two statements are contradictory when only
1821 eofbit is set. I don't think the current text is clear which condition
1822 should be respected.
1825 <p><b>Further discussion from Redmond:</b></p>
1827 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1828 "unformatted". That makes specific claims about sentry that
1829 aren't quite appropriate for seeking, which has less fragile failure
1830 modes than actual input. If we do really mean that it's unformatted
1831 input, it should behave the same way as other unformatted input. On
1832 the other hand, "principle of least surprise" is that seeking from EOF
1836 Pre-Berlin: Paolo points out several problems with the proposed resolution in
1841 <li>It should apply to both overloads of seekg.</li>
1842 <li>tellg has similar issues, except that it should not call clear().</li>
1843 <li>The point about clear() seems to apply to seekp().</li>
1844 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
1846 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
1847 you can never seek away from the end of stream.</li>
1852 <p><b>Proposed resolution:</b></p>
1854 <p>Change 27.6.1.3 [istream.unformatted] to:</p>
1856 Behaves as an unformatted input function (as described in 27.6.1.3,
1857 paragraph 1), except that it does not count the number of characters
1858 extracted, does not affect the value returned by subsequent calls to
1859 gcount(), and does not examine the value returned by the sentry
1860 object. After constructing a sentry object, if <tt>fail() !=
1861 true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In
1862 case of success, the function calls clear().
1863 In case of failure, the function calls <tt>setstate(failbit)</tt>
1864 (which may throw <tt>ios_base::failure</tt>).
1867 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1872 <p><b>Rationale:</b></p>
1873 <p>In C, fseek does clear EOF. This is probably what most users would
1874 expect. We agree that having eofbit set should not deter a seek,
1875 and that a successful seek should clear eofbit. Note
1876 that <tt>fail()</tt> is true only if <tt>failbit</tt>
1877 or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
1878 than <tt>good()</tt>, satisfies this goal.</p>
1885 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
1886 <p><b>Section:</b> 21 [strings], 23 [containers], 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1887 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
1888 <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>
1889 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1890 <p><b>Discussion:</b></p>
1892 The synopses of the C++ library headers clearly show which names are
1893 required to be defined in each header. Since in order to implement the
1894 classes and templates defined in these headers declarations of other
1895 templates (but not necessarily their definitions) are typically
1896 necessary the standard in 17.4.4, p1 permits library implementers to
1897 include any headers needed to implement the definitions in each header.
1901 For instance, although it is not explicitly specified in the synopsis of
1902 <string>, at the point of definition of the std::basic_string template
1903 the declaration of the std::allocator template must be in scope. All
1904 current implementations simply include <memory> from within <string>,
1905 either directly or indirectly, to bring the declaration of
1906 std::allocator into scope.
1910 Additionally, however, some implementation also include <istream> and
1911 <ostream> at the top of <string> to bring the declarations of
1912 std::basic_istream and std::basic_ostream into scope (which are needed
1913 in order to implement the string inserter and extractor operators
1914 (21.3.7.9 [lib.string.io])). Other implementations only include
1915 <iosfwd>, since strictly speaking, only the declarations and not the
1916 full definitions are necessary.
1920 Obviously, it is possible to implement <string> without actually
1921 providing the full definitions of all the templates std::basic_string
1922 uses (std::allocator, std::basic_istream, and std::basic_ostream).
1923 Furthermore, not only is it possible, doing so is likely to have a
1924 positive effect on compile-time efficiency.
1928 But while it may seem perfectly reasonable to expect a program that uses
1929 the std::basic_string insertion and extraction operators to also
1930 explicitly include <istream> or <ostream>, respectively, it doesn't seem
1931 reasonable to also expect it to explicitly include <memory>. Since
1932 what's reasonable and what isn't is highly subjective one would expect
1933 the standard to specify what can and what cannot be assumed.
1934 Unfortunately, that isn't the case.
1937 <p>The examples below demonstrate the issue.</p>
1941 <p>It is not clear whether the following program is complete:</p>
1943 <pre>#include <string>
1945 extern std::basic_ostream<char> &strm;
1948 strm << std::string ("Hello, World!\n");
1952 <p>or whether one must explicitly include <memory> or
1953 <ostream> (or both) in addition to <string> in order for
1954 the program to compile.</p>
1959 <p>Similarly, it is unclear whether the following program is complete:</p>
1961 <pre>#include <istream>
1963 extern std::basic_iostream<char> &strm;
1966 strm << "Hello, World!\n";
1971 or whether one needs to explicitly include <ostream>, and
1972 perhaps even other headers containing the definitions of other
1973 required templates:</p>
1975 <pre>#include <ios>
1976 #include <istream>
1977 #include <ostream>
1978 #include <streambuf>
1980 extern std::basic_iostream<char> &strm;
1983 strm << "Hello, World!\n";
1989 <p>Likewise, it seems unclear whether the program below is complete:</p>
1990 <pre>#include <iterator>
1992 bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b)
2000 <p>or whether one should be required to include <istream>.</p>
2002 <p>There are many more examples that demonstrate this lack of a
2003 requirement. I believe that in a good number of cases it would be
2004 unreasonable to require that a program explicitly include all the
2005 headers necessary for a particular template to be specialized, but I
2006 think that there are cases such as some of those above where it would
2007 be desirable to allow implementations to include only as much as
2008 necessary and not more.</p>
2016 Position taken in prior reviews is that the idea of a table of header
2017 dependencies is a good one. Our view is that a full paper is needed to
2018 do justice to this, and we've made that recommendation to the issue
2024 <p><b>Proposed resolution:</b></p>
2026 For every C++ library header, supply a minimum set of other C++ library
2027 headers that are required to be included by that header. The proposed
2028 list is below (C++ headers for C Library Facilities, table 12 in
2029 17.4.1.2, p3, are omitted):
2032 <pre>+------------+--------------------+
2033 | C++ header |required to include |
2034 +============+====================+
2035 |<algorithm> | |
2036 +------------+--------------------+
2038 +------------+--------------------+
2039 |<complex> | |
2040 +------------+--------------------+
2041 |<deque> |<memory> |
2042 +------------+--------------------+
2043 |<exception> | |
2044 +------------+--------------------+
2045 |<fstream> |<ios> |
2046 +------------+--------------------+
2047 |<functional>| |
2048 +------------+--------------------+
2049 |<iomanip> |<ios> |
2050 +------------+--------------------+
2051 |<ios> |<streambuf> |
2052 +------------+--------------------+
2054 +------------+--------------------+
2055 |<iostream> |<istream>, <ostream>|
2056 +------------+--------------------+
2057 |<istream> |<ios> |
2058 +------------+--------------------+
2059 |<iterator> | |
2060 +------------+--------------------+
2062 +------------+--------------------+
2063 |<list> |<memory> |
2064 +------------+--------------------+
2066 +------------+--------------------+
2067 |<map> |<memory> |
2068 +------------+--------------------+
2070 +------------+--------------------+
2071 |<new> |<exception> |
2072 +------------+--------------------+
2073 |<numeric> | |
2074 +------------+--------------------+
2075 |<ostream> |<ios> |
2076 +------------+--------------------+
2077 |<queue> |<deque> |
2078 +------------+--------------------+
2079 |<set> |<memory> |
2080 +------------+--------------------+
2081 |<sstream> |<ios>, <string> |
2082 +------------+--------------------+
2083 |<stack> |<deque> |
2084 +------------+--------------------+
2085 |<stdexcept> | |
2086 +------------+--------------------+
2087 |<streambuf> |<ios> |
2088 +------------+--------------------+
2089 |<string> |<memory> |
2090 +------------+--------------------+
2091 |<strstream> | |
2092 +------------+--------------------+
2093 |<typeinfo> |<exception> |
2094 +------------+--------------------+
2095 |<utility> | |
2096 +------------+--------------------+
2097 |<valarray> | |
2098 +------------+--------------------+
2099 |<vector> |<memory> |
2100 +------------+--------------------+
2104 <p><b>Rationale:</b></p>
2105 <p>The portability problem is real. A program that works correctly on
2106 one implementation might fail on another, because of different header
2107 dependencies. This problem was understood before the standard was
2108 completed, and it was a conscious design choice.</p>
2109 <p>One possible way to deal with this, as a library extension, would
2110 be an <all> header.</p>
2113 Hinnant: It's time we dealt with this issue for C++0X. Reopened.
2123 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
2124 <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#Open">Open</a>
2125 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
2126 <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>
2127 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2128 <p><b>Discussion:</b></p>
2130 It seems that the descriptions of codecvt do_in() and do_out() leave
2131 sufficient room for interpretation so that two implementations of
2132 codecvt may not work correctly with the same filebuf. Specifically,
2133 the following seems less than adequately specified:
2138 the conditions under which the functions terminate
2141 precisely when the functions return ok
2144 precisely when the functions return partial
2147 the full set of conditions when the functions return error
2153 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
2154 function: ...Stops if it encounters a character it cannot
2155 convert... This assumes that there *is* a character to
2156 convert. What happens when there is a sequence that doesn't form a
2157 valid source character, such as an unassigned or invalid UNICODE
2158 character, or a sequence that cannot possibly form a character
2159 (e.g., the sequence "\xc0\xff" in UTF-8)?
2162 Table 53 says that the function returns codecvt_base::ok
2163 to indicate that the function(s) "completed the conversion."
2164 Suppose that the source sequence is "\xc0\x80" in UTF-8,
2165 with from pointing to '\xc0' and (from_end==from + 1).
2166 It is not clear whether the return value should be ok
2167 or partial (see below).
2170 Table 53 says that the function returns codecvt_base::partial
2171 if "not all source characters converted." With the from pointers
2172 set up the same way as above, it is not clear whether the return
2173 value should be partial or ok (see above).
2176 Table 53, in the row describing the meaning of error mistakenly
2177 refers to a "from_type" character, without the symbol from_type
2178 having been defined. Most likely, the word "source" character
2179 is intended, although that is not sufficient. The functions
2180 may also fail when they encounter an invalid source sequence
2181 that cannot possibly form a valid source character (e.g., as
2182 explained in bullet 1 above).
2186 Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
2189 "A return value of partial, if (from_next == from_end),
2190 indicates that either the destination sequence has not
2191 absorbed all the available destination elements, or that
2192 additional source elements are needed before another
2193 destination element can be produced."
2196 If the value is partial, it's not clear to me that (from_next
2197 ==from_end) could ever hold if there isn't enough room
2198 in the destination buffer. In order for (from_next==from_end) to
2199 hold, all characters in that range must have been successfully
2200 converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
2201 further source characters to convert, no more room in the
2202 destination buffer can be needed.
2205 It's also not clear to me that (from_next==from_end) could ever
2206 hold if additional source elements are needed to produce another
2207 destination character (not element as incorrectly stated in the
2208 text). partial is returned if "not all source characters have
2209 been converted" according to Table 53, which also implies that
2210 (from_next==from) does NOT hold.
2213 Could it be that the intended qualifying condition was actually
2214 (from_next != from_end), i.e., that the sentence was supposed
2218 "A return value of partial, if (from_next != from_end),..."
2221 which would make perfect sense, since, as far as I understand it,
2222 partial can only occur if (from_next != from_end)?
2224 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
2225 fixed. Right now, the description of codecvt is too vague for it to
2226 be a useful contract between providers and clients of codecvt
2227 facets. (Note that both vendors and users can be both providers and
2228 clients of codecvt facets.) The major philosophical issue is whether
2229 the standard should only describe mappings that take a single wide
2230 character to multiple narrow characters (and vice versa), or whether
2231 it should describe fully general N-to-M conversions. When the
2232 original standard was written only the former was contemplated, but
2233 today, in light of the popularity of utf8 and utf16, that doesn't
2234 seem sufficient for C++0x. Bill supports general N-to-M conversions;
2235 we need to make sure Martin and Howard agree.]</i></p>
2239 <p><b>Proposed resolution:</b></p>
2245 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
2246 <p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
2247 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
2248 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
2249 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
2250 <p><b>Discussion:</b></p>
2252 The absence of explicit description of std::complex<T> layout
2253 makes it imposible to reuse existing software developed in traditional
2254 languages like Fortran or C with unambigous and commonly accepted
2255 layout assumptions. There ought to be a way for practitioners to
2256 predict with confidence the layout of std::complex<T> whenever T
2257 is a numerical datatype. The absence of ways to access individual
2258 parts of a std::complex<T> object as lvalues unduly promotes
2259 severe pessimizations. For example, the only way to change,
2260 independently, the real and imaginary parts is to write something like
2263 <pre>complex<T> z;
2265 // set the real part to r
2266 z = complex<T>(r, z.imag());
2268 // set the imaginary part to i
2269 z = complex<T>(z.real(), i);
2273 At this point, it seems appropriate to recall that a complex number
2274 is, in effect, just a pair of numbers with no particular invariant to
2275 maintain. Existing practice in numerical computations has it that a
2276 complex number datatype is usually represented by Cartesian
2277 coordinates. Therefore the over-encapsulation put in the specification
2278 of std::complex<> is not justified.
2283 <p><b>Proposed resolution:</b></p>
2284 <p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
2286 <p>If z is an lvalue expression of type cv std::complex<T> then</p>
2289 <li>the expression reinterpret_cast<cv T(&)[2]>(z)
2290 is well-formed; and</li>
2291 <li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the
2292 real part of z; and</li>
2293 <li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the
2294 imaginary part of z.</li>
2298 Moreover, if a is an expression of pointer type cv complex<T>*
2299 and the expression a[i] is well-defined for an integer expression
2304 <li>reinterpret_cast<cv T*>(a)[2*i] designates the real
2305 part of a[i]; and</li>
2306 <li>reinterpret_cast<cv T*>(a)[2*i+1] designates the
2307 imaginary part of a[i].</li>
2312 In 26.3.2 [complex] Add the member functions
2315 <blockquote><pre>void real(T);
2320 Add to 26.3.4 [complex.members]
2324 <pre>T real() const;
2327 <i>Returns:</i> the value of the real component
2329 <pre>void real(T val);
2332 Assigns val to the real component.
2334 <pre>T imag() const;
2337 <i>Returns:</i> the value of the imaginary component
2339 <pre>void imag(T val);
2342 Assigns val to the imaginary component.
2346 <p><i>[Kona: The layout guarantee is absolutely necessary for C
2347 compatibility. However, there was disagreement about the other part
2348 of this proposal: retrieving elements of the complex number as
2349 lvalues. An alternative: continue to have real() and imag() return
2350 rvalues, but add set_real() and set_imag(). Straw poll: return
2351 lvalues - 2, add setter functions - 5. Related issue: do we want
2352 reinterpret_cast as the interface for converting a complex to an
2353 array of two reals, or do we want to provide a more explicit way of
2354 doing it? Howard will try to resolve this issue for the next
2358 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
2367 Second half of proposed wording replaced and moved to Ready.
2371 <p><b>Rationale:</b></p>
2372 <p>The LWG believes that C99 compatibility would be enough
2373 justification for this change even without other considerations. All
2374 existing implementations already have the layout proposed here.</p>
2381 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
2382 <p><b>Section:</b> 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#Open">Open</a>
2383 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
2384 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2385 <p><b>Discussion:</b></p>
2387 There is a contradiction in Formatted output about what bit is
2388 supposed to be set if the formatting fails. On sentence says it's
2389 badbit and another that it's failbit.
2392 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2395 <pre> ... If the generation fails, then the formatted output function
2396 does setstate(ios::failbit), which might throw an exception.
2399 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2402 ... The formatting conversion occurs as if it performed the
2403 following code fragment:
2406 use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
2408 (getloc()).put(*this, *this, fill(), val). failed();
2410 ... If failed is true then does setstate(badbit) ...
2413 The original intent of the text, according to Jerry Schwarz (see
2414 c++std-lib-10500), is captured in the following paragraph:
2417 In general "badbit" should mean that the stream is unusable because
2418 of some underlying failure, such as disk full or socket closure;
2419 "failbit" should mean that the requested formatting wasn't possible
2420 because of some inconsistency such as negative widths. So typically
2421 if you clear badbit and try to output something else you'll fail
2422 again, but if you clear failbit and try to output something else
2426 In the case of the arithmetic inserters, since num_put cannot
2427 report failure by any means other than exceptions (in response
2428 to which the stream must set badbit, which prevents the kind of
2429 recoverable error reporting mentioned above), the only other
2430 detectable failure is if the iterator returned from num_put
2431 returns true from failed().
2434 Since that can only happen (at least with the required iostream
2435 specializations) under such conditions as the underlying failure
2436 referred to above (e.g., disk full), setting badbit would seem
2437 to be the appropriate response (indeed, it is required in
2438 27.6.2.5.2, p1). It follows that failbit can never be directly
2439 set by the arithmetic (it can only be set by the sentry object
2440 under some unspecified conditions).
2443 The situation is different for other formatted output functions
2444 which can fail as a result of the streambuf functions failing
2445 (they may do so by means other than exceptions), and which are
2446 then required to set failbit.
2449 The contradiction, then, is that ostream::operator<<(int) will
2450 set badbit if the disk is full, while operator<<(ostream&,
2451 char) will set failbit under the same conditions. To make the behavior
2452 consistent, the Common requirements sections for the Formatted output
2453 functions should be changed as proposed below.
2455 <p><i>[Kona: There's agreement that this is a real issue. What we
2456 decided at Kona: 1. An error from the buffer (which can be detected
2457 either directly from streambuf's member functions or by examining a
2458 streambuf_iterator) should always result in badbit getting set.
2459 2. There should never be a circumstance where failbit gets set.
2460 That represents a formatting error, and there are no circumstances
2461 under which the output facets are specified as signaling a
2462 formatting error. (Even more so for string output that for numeric
2463 because there's nothing to format.) If we ever decide to make it
2464 possible for formatting errors to exist then the facets can signal
2465 the error directly, and that should go in clause 22, not clause 27.
2466 3. The phrase "if generation fails" is unclear and should be
2467 eliminated. It's not clear whether it's intended to mean a buffer
2468 error (e.g. a full disk), a formatting error, or something else.
2469 Most people thought it was supposed to refer to buffer errors; if
2470 so, we should say so. Martin will provide wording.]</i></p>
2475 <p><b>Proposed resolution:</b></p>
2478 <p><b>Rationale:</b></p>
2486 <h3><a name="396"></a>396. what are characters zero and one</h3>
2487 <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#Open">Open</a>
2488 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2489 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
2490 <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>
2491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2492 <p><b>Discussion:</b></p>
2494 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
2495 having the value of 0 or 1 but there is no definition of what
2496 that means for charT other than char and wchar_t. And even for
2497 those two types, the values 0 and 1 are not actually what is
2498 intended -- the values '0' and '1' are. This, along with the
2499 converse problem in the description of to_string() in 23.3.5.2,
2500 p33, looks like a defect remotely related to DR 303.
2503 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
2506 -6- An element of the constructed string has value zero if the
2507 corresponding character in str, beginning at position pos,
2508 is 0. Otherwise, the element has the value one.
2511 -33- Effects: Constructs a string object of the appropriate
2512 type and initializes it to a string of length N characters.
2513 Each character is determined by the value of its
2514 corresponding bit position in *this. Character position N
2515 ?- 1 corresponds to bit position zero. Subsequent decreasing
2516 character positions correspond to increasing bit positions.
2517 Bit value zero becomes the character 0, bit value one becomes
2521 Also note the typo in 23.3.5.1, p6: the object under construction
2522 is a bitset, not a string.
2526 <p><b>Proposed resolution:</b></p>
2527 <p>Change the constructor's function declaration immediately before
2528 23.3.5.1 [bitset.cons] p3 to:</p>
2529 <pre> template <class charT, class traits, class Allocator>
2531 bitset(const basic_string<charT, traits, Allocator>& str,
2532 typename basic_string<charT, traits, Allocator>::size_type pos = 0,
2533 typename basic_string<charT, traits, Allocator>::size_type n =
2534 basic_string<charT, traits, Allocator>::npos,
2535 charT zero = charT('0'), charT one = charT('1'))
2537 <p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
2538 element of the constructed string has value 0 if the corresponding
2539 character in <i>str</i>, beginning at position <i>pos</i>,
2540 is <i>zero</i>. Otherwise, the element has the value 1.</p>
2542 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
2543 "The function then throws invalid_argument if any of the rlen
2544 characters in str beginning at position pos is other than <i>zero</i>
2545 or <i>one</i>. The function uses traits::eq() to compare the character
2549 <p>Change the declaration of the <tt>to_string</tt> member function
2550 immediately before 23.3.5.2 [bitset.members] p33 to:</p>
2551 <pre> template <class charT, class traits, class Allocator>
2552 basic_string<charT, traits, Allocator>
2553 to_string(charT zero = charT('0'), charT one = charT('1')) const;
2555 <p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
2556 value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
2557 character <tt><i>one</i></tt>.</p>
2558 <p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
2559 <p><b>Returns</b>:</p>
2560 <pre> os << x.template to_string<charT,traits,allocator<charT> >(
2561 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'),
2562 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1'));
2566 <p><b>Rationale:</b></p>
2567 <p>There is a real problem here: we need the character values of '0'
2568 and '1', and we have no way to get them since strings don't have
2569 imbued locales. In principle the "right" solution would be to
2570 provide an extra object, either a ctype facet or a full locale,
2571 which would be used to widen '0' and '1'. However, there was some
2572 discomfort about using such a heavyweight mechanism. The proposed
2573 resolution allows those users who care about this issue to get it
2575 <p>We fix the inserter to use the new arguments. Note that we already
2576 fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
2586 We are happy with the resolution as proposed, and we move this to Ready.
2593 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
2594 <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#Open">Open</a>
2595 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2596 <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>
2597 <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>
2598 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2599 <p><b>Discussion:</b></p>
2601 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2604 27.6.2.3, p4 says this about the ostream::sentry dtor:
2606 <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
2607 is true, calls os.flush().
2610 27.6.2.6, p7 that describes ostream::flush() says:
2612 <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
2613 If that function returns ?-1 calls setstate(badbit) (which
2614 may throw ios_base::failure (27.4.4.3)).
2617 That seems like a defect, since both pubsync() and setstate() can
2621 The contradiction is real. Clause 17 says destructors may never
2622 throw exceptions, and clause 27 specifies a destructor that does
2623 throw. In principle we might change either one. We're leaning
2624 toward changing clause 17: putting in an "unless otherwise specified"
2625 clause, and then putting in a footnote saying the sentry destructor
2626 is the only one that can throw. PJP suggests specifying that
2627 sentry::~sentry() should internally catch any exceptions it might cause.
2632 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
2638 <p><b>Proposed resolution:</b></p>
2645 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
2646 <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#Open">Open</a>
2647 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2648 <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>
2649 <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>
2650 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2651 <p><b>Discussion:</b></p>
2653 While reviewing unformatted input member functions of istream
2654 for their behavior when they encounter end-of-file during input
2655 I found that the requirements vary, sometimes unexpectedly, and
2656 in more than one case even contradict established practice (GNU
2657 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2658 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2661 The following unformatted input member functions set eofbit if they
2662 encounter an end-of-file (this is the expected behavior, and also
2663 the behavior of all major implementations):
2665 <pre> basic_istream<charT, traits>&
2666 get (char_type*, streamsize, char_type);
2669 Also sets failbit if it fails to extract any characters.
2671 <pre> basic_istream<charT, traits>&
2672 get (char_type*, streamsize);
2675 Also sets failbit if it fails to extract any characters.
2677 <pre> basic_istream<charT, traits>&
2678 getline (char_type*, streamsize, char_type);
2681 Also sets failbit if it fails to extract any characters.
2683 <pre> basic_istream<charT, traits>&
2684 getline (char_type*, streamsize);
2687 Also sets failbit if it fails to extract any characters.
2689 <pre> basic_istream<charT, traits>&
2690 ignore (int, int_type);
2692 <pre> basic_istream<charT, traits>&
2693 read (char_type*, streamsize);
2696 Also sets failbit if it encounters end-of-file.
2698 <pre> streamsize readsome (char_type*, streamsize);
2702 The following unformated input member functions set failbit but
2703 not eofbit if they encounter an end-of-file (I find this odd
2704 since the functions make it impossible to distinguish a general
2705 failure from a failure due to end-of-file; the requirement is
2706 also in conflict with all major implementation which set both
2707 eofbit and failbit):
2709 <pre> int_type get();
2711 <pre> basic_istream<charT, traits>&
2712 get (char_type&);
2715 These functions only set failbit of they extract no characters,
2716 otherwise they don't set any bits, even on failure (I find this
2717 inconsistency quite unexpected; the requirement is also in
2718 conflict with all major implementations which set eofbit
2719 whenever they encounter end-of-file):
2721 <pre> basic_istream<charT, traits>&
2722 get (basic_streambuf<charT, traits>&, char_type);
2724 <pre> basic_istream<charT, traits>&
2725 get (basic_streambuf<charT, traits>&);
2728 This function sets no bits (all implementations except for
2729 STLport and Classic Iostreams set eofbit when they encounter
2732 <pre> int_type peek ();
2734 <p>Informally, what we want is a global statement of intent saying
2735 that eofbit gets set if we trip across EOF, and then we can take
2736 away the specific wording for individual functions. A full review
2737 is necessary. The wording currently in the standard is a mishmash,
2738 and changing it on an individual basis wouldn't make things better.
2739 Dietmar will do this work.</p>
2742 <p><b>Proposed resolution:</b></p>
2748 <h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</h3>
2749 <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#Open">Open</a>
2750 <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
2751 <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>
2752 <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>
2753 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2754 <p><b>Discussion:</b></p>
2756 I've been discussing iterator semantics with Dave Abrahams, and a
2757 surprise has popped up. I don't think this has been discussed before.
2761 24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
2762 iterator values is to assign a non-singular value to them. (It
2763 doesn't say they can be destroyed, and that's probably a defect.)
2764 Some implementations have taken this to imply that there is no need
2765 to initialize the data member of a reverse_iterator<> in the default
2766 constructor. As a result, code like
2768 <blockquote><pre> std::vector<std::reverse_iterator<char*> > v(7);
2772 invokes undefined behavior, because it must default-initialize the
2773 vector elements, and then copy them to other storage. Of course many
2774 other vector operations on these adapters are also left undefined,
2775 and which those are is not reliably deducible from the standard.
2779 I don't think that 24.1 was meant to make standard-library iterator
2780 types unsafe. Rather, it was meant to restrict what operations may
2781 be performed by functions which take general user- and standard
2782 iterators as arguments, so that raw pointers would qualify as
2783 iterators. However, this is not clear in the text, others have come
2784 to the opposite conclusion.
2788 One question is whether the standard iterator adaptors have defined
2789 copy semantics. Another is whether they have defined destructor
2792 <blockquote><pre> { std::vector<std::reverse_iterator<char*> > v(7); }
2799 Note this is not a question of whether algorithms are allowed to
2800 rely on copy semantics for arbitrary iterators, just whether the
2801 types we actually supply support those operations. I believe the
2802 resolution must be expressed in terms of the semantics of the
2803 adapter's argument type. It should make clear that, e.g., the
2804 reverse_iterator<T> constructor is actually required to execute
2805 T(), and so copying is defined if the result of T() is copyable.
2809 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2810 constructor more precisely, has some relevance to this issue.
2811 However, it is not the whole story.
2815 The issue was whether
2817 <blockquote><pre> reverse_iterator() { }
2822 <blockquote><pre> reverse_iterator() : current() { }
2826 The difference is when T is char*, where the first leaves the member
2827 uninitialized, and possibly equal to an existing pointer value, or
2828 (on some targets) may result in a hardware trap when copied.
2832 8.5 paragraph 5 seems to make clear that the second is required to
2833 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
2838 But that only takes care of reverse_iterator, and doesn't establish
2839 a policy for all iterators. (The reverse iterator adapter was just
2840 an example.) In particular, does my function
2842 <blockquote><pre> template <typename Iterator>
2843 void f() { std::vector<Iterator> v(7); }
2846 evoke undefined behavior for some conforming iterator definitions?
2847 I think it does, now, because vector<> will destroy those singular
2848 iterator values, and that's explicitly disallowed.
2852 24.1 shouldn't give blanket permission to copy all singular iterators,
2853 because then pointers wouldn't qualify as iterators. However, it
2854 should allow copying of that subset of singular iterator values that
2855 are default-initialized, and it should explicitly allow destroying any
2856 iterator value, singular or not, default-initialized or not.
2859 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
2861 We don't want to require all singular iterators to be copyable,
2862 because that is not the case for pointers. However, default
2863 construction may be a special case. Issue: is it really default
2864 construction we want to talk about, or is it something like value
2865 initialization? We need to check with core to see whether default
2866 constructed pointers are required to be copyable; if not, it would be
2867 wrong to impose so strict a requirement for iterators.
2873 <p><b>Proposed resolution:</b></p>
2880 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
2881 <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#Open">Open</a>
2882 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2883 <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>
2884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2885 <p><b>Discussion:</b></p>
2887 The Effects and Returns clauses of the do_widen() member function of
2888 the ctype facet fail to specify the behavior of the function on failure.
2889 That the function may not be able to simply cast the narrow character
2890 argument to the type of the result since doing so may yield the wrong value
2891 for some wchar_t encodings. Popular implementations of ctype<wchar_t> that
2892 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
2893 when the argument's MSB is set. There is no way for the the rest of locale
2894 and iostream to reliably detect this failure.
2896 <p><i>[Kona: This is a real problem. Widening can fail. It's unclear
2897 what the solution should be. Returning WEOF works for the wchar_t
2898 specialization, but not in general. One option might be to add a
2899 default, like <i>narrow</i>. But that's an incompatible change.
2900 Using <i>traits::eof</i> might seem like a good idea, but facets
2901 don't have access to traits (a recurring problem). We could
2902 have <i>widen</i> throw an exception, but that's a scary option;
2903 existing library components aren't written with the assumption
2904 that <i>widen</i> can throw.]</i></p>
2908 <p><b>Proposed resolution:</b></p>
2914 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
2915 <p><b>Section:</b> 27.4.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2916 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2917 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2918 <p><b>Discussion:</b></p>
2920 The dtor of the ios_base::Init object is supposed to call flush() on the
2921 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
2922 This call may cause an exception to be thrown.
2926 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
2930 The question is: What should this dtor do if one or more of these calls
2931 to flush() ends up throwing an exception? This can happen quite easily
2932 if one of the facets installed in the locale imbued in the iostream
2935 <p><i>[Kona: We probably can't do much better than what we've got, so
2936 the LWG is leaning toward NAD. At the point where the standard
2937 stream objects are being cleaned up, the usual error reporting
2938 mechanism are all unavailable. And exception from flush at this
2939 point will definitely cause problems. A quality implementation
2940 might reasonably swallow the exception, or call abort, or do
2941 something even more drastic.]</i></p>
2945 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-defects.html#622">622</a> for related issues.
2951 <p><b>Proposed resolution:</b></p>
2957 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
2958 <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#Open">Open</a>
2959 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2960 <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>
2961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2962 <p><b>Discussion:</b></p>
2965 27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
2966 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2967 true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
2968 says that a formatted input function endeavors to obtain the requested input
2969 if the sentry's operator bool() returns true.
2971 Given these requirements, no formatted extractor should ever set failbit if
2972 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2973 all implementations I tested. The program below prints out
2981 #include <sstream>
2982 #include <cstdio>
2986 std::istringstream strm ("1");
2992 std::printf ("eof = %d, fail = %d\n",
2993 !!strm.eof (), !!strm.fail ());
2997 std::printf ("eof = %d, fail = %d\n",
2998 !!strm.eof (), !!strm.fail ());
3005 Comments from Jerry Schwarz (c++std-lib-11373):
3008 Jerry Schwarz wrote:
3011 I don't know where (if anywhere) it says it in the standard, but the
3012 formatted extractors are supposed to set failbit if they don't extract
3013 any characters. If they didn't then simple loops like
3016 while (cin >> x);
3022 Further comments from Martin Sebor:
3025 The question is which part of the extraction should prevent this from happening
3026 by setting failbit when eofbit is already set. It could either be the sentry
3027 object or the extractor. It seems that most implementations have chosen to
3028 set failbit in the sentry [...] so that's the text that will need to be
3033 Pre Berlin: This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>. If the sentry
3034 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
3035 you can never seek away from the end of stream.
3037 <p>Kona: Possibly NAD. If eofbit is set then good() will return false. We
3038 then set <i>ok</i> to false. We believe that the sentry's
3039 constructor should always set failbit when <i>ok</i> is false, and
3040 we also think the standard already says that. Possibly it could be
3045 <p><b>Proposed resolution:</b></p>
3047 Change 27.6.1.1.3 [istream::sentry], p2 to:
3051 <pre>explicit sentry(basic_istream<charT,traits>& <i>is</i> , bool <i>noskipws</i> = false);</pre>
3053 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
3054 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
3055 Otherwise</ins> prepares for formatted or unformatted input. ...
3065 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
3066 <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#Open">Open</a>
3067 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3068 <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>
3069 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3070 <p><b>Discussion:</b></p>
3072 The reflector thread starting with c++std-lib-11346 notes that the class
3073 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
3074 is copy-constructible but that the semantics of the copy constructors
3075 are not defined anywhere. Further, different implementations behave
3076 differently in this respect: some prevent copy construction of objects
3077 of these types by declaring their copy ctors and assignment operators
3078 private, others exhibit undefined behavior, while others still give
3079 these operations well-defined semantics.
3083 Note that this problem doesn't seem to be isolated to just the three
3084 types mentioned above. A number of other types in the library section
3085 of the standard provide a compiler-generated copy ctor and assignment
3086 operator yet fail to specify their semantics. It's believed that the
3087 only types for which this is actually a problem (i.e. types where the
3088 compiler-generated default may be inappropriate and may not have been
3089 intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
3093 <p><b>Proposed resolution:</b></p>
3095 27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
3099 <pre>basic_streambuf(const basic_streambuf& sb);
3100 basic_streambuf& operator=(const basic_streambuf& sb);
3104 <p>Insert after 27.5.2.1, paragraph 2:</p>
3106 <pre>basic_streambuf(const basic_streambuf& sb);
3109 <p>Constructs a copy of sb.</p>
3110 <p>Postcondtions:</p>
3111 <pre> eback() == sb.eback()
3113 egptr() == sb.egptr()
3114 pbase() == sb.pbase()
3116 epptr() == sb.epptr()
3117 getloc() == sb.getloc()
3120 <pre>basic_streambuf& operator=(const basic_streambuf& sb);
3123 <p>Assigns the data members of sb to this.</p>
3125 <p>Postcondtions:</p>
3126 <pre> eback() == sb.eback()
3128 egptr() == sb.egptr()
3129 pbase() == sb.pbase()
3131 epptr() == sb.epptr()
3132 getloc() == sb.getloc()
3135 <p>Returns: *this.</p>
3138 <p>27.7.1 [lib.stringbuf]:</p>
3140 <p><b>Option A:</b></p>
3143 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
3145 <pre>basic_stringbuf(const basic_stringbuf&); // not defined
3146 basic_stringbuf& operator=(const basic_stringbuf&); // not defined
3150 <p><b>Option B:</b></p>
3153 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
3155 <pre>basic_stringbuf(const basic_stringbuf& sb);
3156 basic_stringbuf& operator=(const basic_stringbuf& sb);
3159 <p>27.7.1.1, insert after paragraph 4:</p>
3161 <pre>basic_stringbuf(const basic_stringbuf& sb);</pre>
3164 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
3167 <p>Postcondtions: </p>
3168 <pre> str() == sb.str()
3169 gptr() - eback() == sb.gptr() - sb.eback()
3170 egptr() - eback() == sb.egptr() - sb.eback()
3171 pptr() - pbase() == sb.pptr() - sb.pbase()
3172 getloc() == sb.getloc()
3176 Note: The only requirement on epptr() is that it point beyond the
3177 initialized range if an output sequence exists. There is no requirement
3178 that epptr() - pbase() == sb.epptr() - sb.pbase().
3181 <pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre>
3182 <p>After assignment the basic_stringbuf has the same state as if it
3183 were initially copy constructed from sb, except that the
3184 basic_stringbuf is allowed to retain any excess capacity it might have,
3185 which may in turn effect the value of epptr().
3189 <p>27.8.1.1 [lib.filebuf]</p>
3191 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
3195 basic_filebuf(const basic_filebuf&); // not defined
3196 basic_filebuf& operator=(const basic_filebuf&); // not defined
3199 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
3200 derived classes. We are leaning toward allowing basic_streambuf to
3201 be copyable, and specifying its precise semantics. (Probably the
3202 obvious: copying the buffer pointers.) We are less sure whether
3203 the streambuf derived classes should be copyable. Howard will
3204 write up a proposal.]</i></p>
3207 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
3208 being copyable: it can lead to an encapsulation violation. Filebuf
3209 inherits from streambuf. Now suppose you inhert a my_hijacking_buf
3210 from streambuf. You can copy the streambuf portion of a filebuf to a
3211 my_hijacking_buf, giving you access to the pointers into the
3212 filebuf's internal buffer. Perhaps not a very strong argument, but
3213 it was strong enough to make people nervous. There was weak
3214 preference for having streambuf not be copyable. There was weak
3215 preference for having stringbuf not be copyable even if streambuf
3216 is. Move this issue to open for now.
3222 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
3223 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
3224 as would be generated by the compiler. These members aid in derived classes implementing move semantics.
3225 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
3226 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
3227 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather
3228 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
3229 move semantics less tedious and error prone.
3235 <p><b>Rationale:</b></p>
3237 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
3238 and assignment operator are the same as currently implied by the lack
3239 of declarations: public and simply copies the data members. This
3240 resolution is not a change but a clarification of the current
3245 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
3246 basic_stringbuf not copyable. This is likely the status-quo of
3247 current implementations. B) Reasonable copy semantics of
3248 basic_stringbuf can be defined and implemented. A copyable
3249 basic_streambuf is arguably more useful than a non-copyable one. This
3250 should be considered as new functionality and not the fixing of a
3251 defect. If option B is chosen, ramifications from issue 432 are taken
3256 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
3266 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
3267 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3268 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3269 <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>
3270 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3271 <p><b>Discussion:</b></p>
3274 A third party test suite tries to exercise istream::ignore(N) with
3275 a negative value of N and expects that the implementation will treat
3276 N as if it were 0. Our implementation asserts that (N >= 0) holds and
3281 I can't find anything in section 27 that prohibits such values but I don't
3282 see what the effects of such calls should be, either (this applies to
3283 a number of unformatted input functions as well as some member functions
3284 of the basic_streambuf template).
3288 <p><b>Proposed resolution:</b></p>
3290 I propose that we add to each function in clause 27 that takes an argument,
3291 say N, of type streamsize a Requires clause saying that "N >= 0." The intent
3292 is to allow negative streamsize values in calls to precision() and width()
3293 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3297 <p><i>[Kona: The LWG agreed that this is probably what we want. However, we
3298 need a review to find all places where functions in clause 27 take
3299 arguments of type streamsize that shouldn't be allowed to go
3300 negative. Martin will do that review.]</i></p>
3308 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
3309 <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#Open">Open</a>
3310 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3311 <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>
3312 <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>
3313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3314 <p><b>Discussion:</b></p>
3316 The requirements specified in Stage 2 and reiterated in the rationale
3317 of DR 221 (and echoed again in DR 303) specify that num_get<charT>::
3318 do_get() compares characters on the stream against the widened elements
3319 of "012...abc...ABCX+-"
3323 An implementation is required to allow programs to instantiate the num_get
3324 template on any charT that satisfies the requirements on a user-defined
3325 character type. These requirements do not include the ability of the
3326 character type to be equality comparable (the char_traits template must
3327 be used to perform tests for equality). Hence, the num_get template cannot
3328 be implemented to support any arbitrary character type. The num_get template
3329 must either make the assumption that the character type is equality-comparable
3330 (as some popular implementations do), or it may use char_traits<charT> to do
3331 the comparisons (some other popular implementations do that). This diversity
3332 of approaches makes it difficult to write portable programs that attempt to
3333 instantiate the num_get template on user-defined types.
3336 <p><i>[Kona: the heart of the problem is that we're theoretically
3337 supposed to use traits classes for all fundamental character
3338 operations like assignment and comparison, but facets don't have
3339 traits parameters. This is a fundamental design flaw and it
3340 appears all over the place, not just in this one place. It's not
3341 clear what the correct solution is, but a thorough review of facets
3342 and traits is in order. The LWG considered and rejected the
3343 possibility of changing numeric facets to use narrowing instead of
3344 widening. This may be a good idea for other reasons (see issue
3345 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
3346 issue. Whether we use widen or narrow the <tt>num_get</tt> facet
3347 still has no idea which traits class the user wants to use for
3348 the comparison, because only streams, not facets, are passed traits
3349 classes. The standard does not require that two different
3350 traits classes with the same <tt>char_type</tt> must necessarily
3351 have the same behavior.]</i></p>
3354 <p>Informally, one possibility: require that some of the basic
3355 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3356 and <tt>assign</tt>, must behave the same way for all traits classes
3357 with the same <tt>char_type</tt>. If we accept that limitation on
3358 traits classes, then the facet could reasonably be required to
3359 use <tt>char_traits<charT></tt>.</p>
3362 <p><b>Proposed resolution:</b></p>
3368 <h3><a name="430"></a>430. valarray subset operations</h3>
3369 <p><b>Section:</b> 26.5.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3370 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3371 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3372 <p><b>Discussion:</b></p>
3374 The standard fails to specify the behavior of valarray::operator[](slice)
3375 and other valarray subset operations when they are passed an "invalid"
3376 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3377 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3378 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3380 <p><i>[Kona: the LWG believes that invalid slices should invoke
3381 undefined behavior. Valarrays are supposed to be designed for high
3382 performance, so we don't want to require specific checking. We
3383 need wording to express this decision.]</i></p>
3392 Please note that the standard also fails to specify the behavior of
3393 slice_array and gslice_array in the valid case. Bill Plauger will
3394 endeavor to provide revised wording for slice_array and gslice_array.
3398 post-Bellevue: Bill provided wording.
3403 <p><b>Proposed resolution:</b></p>
3405 Insert after 26.5.2.4 [valarray.sub], paragraph 1:
3410 The member operator is overloaded to provide several ways to select
3412 of elements from among those controlled by <tt>*this</tt>. The first group of five
3413 member operators work in conjunction with various overloads of <tt>operator=</tt>
3414 (and other assigning operators) to allow selective replacement (slicing) of
3415 the controlled sequence. The selected elements must exist.
3418 The first member operator selects element off. For example:
3421 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3423 // v0 == valarray<char>("abcAefghijklmnop", 16)
3427 The second member operator selects those elements of the controlled sequence
3428 designated by <tt>slicearr</tt>. For example:
3431 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3432 valarray<char> v1("ABCDE", 5);
3433 v0[slice(2, 5, 3)] = v1;
3434 // v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
3438 The third member operator selects those elements of the controlled sequence
3439 designated by <tt>gslicearr</tt>. For example:
3442 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3443 valarray<char> v1("ABCDEF", 6);
3444 const size_t lv[] = {2, 3};
3445 const size_t dv[] = {7, 2};
3446 const valarray<size_t> len(lv, 2), str(dv, 2);
3447 v0[gslice(3, len, str)] = v1;
3448 // v0 == valarray<char>("abcAeBgCijDlEnFp", 16)
3452 The fourth member operator selects those elements of the controlled sequence
3453 designated by <tt>boolarr</tt>. For example:
3456 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3457 valarray<char> v1("ABC", 3);
3458 const bool vb[] = {false, false, true, true, false, true};
3459 v0[valarray<bool>(vb, 6)] = v1;
3460 // v0 == valarray<char>("abABeCghijklmnop", 16)
3464 The fifth member operator selects those elements of the controlled sequence
3465 designated by indarr. For example:
3468 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3469 valarray<char> v1("ABCDE", 5);
3470 const size_t vi[] = {7, 5, 2, 3, 8};
3471 v0[valarray<size_t>(vi, 5)] = v1;
3472 // v0 == valarray<char>("abCDeBgAEjklmnop", 16)
3476 The second group of five member operators each construct an object that
3477 represents the value(s) selected. The selected elements must exist.
3481 The sixth member operator returns the value of element off. For example:
3484 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3485 // v0[3] returns 'd'
3489 The seventh member operator returns an object of class <tt>valarray<Ty></tt>
3490 containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
3494 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3495 // v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)
3499 The eighth member operator selects those elements of the controlled sequence
3500 designated by <tt>gslicearr</tt>. For example:
3503 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3504 const size_t lv[] = {2, 3};
3505 const size_t dv[] = {7, 2};
3506 const valarray<size_t> len(lv, 2), str(dv, 2);
3507 // v0[gslice(3, len, str)] returns
3508 // valarray<char>("dfhkmo", 6)
3512 The ninth member operator selects those elements of the controlled sequence
3513 designated by <tt>boolarr</tt>. For example:
3516 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3517 const bool vb[] = {false, false, true, true, false, true};
3518 // v0[valarray<bool>(vb, 6)] returns
3519 // valarray<char>("cdf", 3)
3523 The last member operator selects those elements of the controlled sequence
3524 designated by <tt>indarr</tt>. For example:
3527 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3528 const size_t vi[] = {7, 5, 2, 3, 8};
3529 // v0[valarray<size_t>(vi, 5)] returns
3530 // valarray<char>("hfcdi", 5)
3540 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
3541 <p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3542 <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
3543 <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>
3544 <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>
3545 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3546 <p><b>Discussion:</b></p>
3547 <p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
3548 are permitted to supply containers that are unable to cope with
3549 allocator instances and that container implementations may assume
3550 that all instances of an allocator type compare equal. We gave
3551 implementers this latitude as a temporary hack, and eventually we
3552 want to get rid of it. What happens when we're dealing with
3553 allocators that <i>don't</i> compare equal?
3556 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3557 objects of type <tt>vector<int, my_alloc></tt> and that
3558 <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if
3559 we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p>
3561 <p>1. This operation is illegal. Perhaps we could say that an
3562 implementation is required to check and to throw an exception, or
3563 perhaps we could say it's undefined behavior.</p>
3564 <p>2. The operation performs a slow swap (i.e. using three
3565 invocations of <tt>operator=</tt>, leaving each allocator with its
3566 original container. This would be an O(N) operation.</p>
3567 <p>3. The operation swaps both the vectors' contents and their
3568 allocators. This would be an O(1) operation. That is:</p>
3570 <pre> my_alloc a1(...);
3574 vector<int, my_alloc> v1(a1);
3575 vector<int, my_alloc> v2(a2);
3576 assert(a1 == v1.get_allocator());
3577 assert(a2 == v2.get_allocator());
3580 assert(a1 == v2.get_allocator());
3581 assert(a2 == v1.get_allocator());
3585 <p><i>[Kona: This is part of a general problem. We need a paper
3586 saying how to deal with unequal allocators in general.]</i></p>
3589 <p><i>[pre-Sydney: Howard argues for option 3 in
3590 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
3595 2007-01-12, Howard: This issue will now tend to come up more often with move constructors
3596 and move assignment operators. For containers, these members transfer resources (i.e.
3597 the allocated memory) just like swap.
3602 Batavia: There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
3603 requirement using concepts. If the allocator supports Swappable, then container's swap will
3604 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
3610 <p><b>Proposed resolution:</b></p>
3617 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
3618 <p><b>Section:</b> 24.1 [iterator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3619 <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
3620 <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>
3621 <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>
3622 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3623 <p><b>Discussion:</b></p>
3625 What requirements does the standard place on equality comparisons between
3626 iterators that refer to elements of different containers. For example, if
3627 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
3628 Is it allowed to throw an exception?
3632 The standard appears to be silent on both questions.
3634 <p><i>[Sydney: The intention is that comparing two iterators from
3635 different containers is undefined, but it's not clear if we say that,
3636 or even whether it's something we should be saying in clause 23 or in
3637 clause 24. Intuitively we might want to say that equality is defined
3638 only if one iterator is reachable from another, but figuring out how
3639 to say it in any sensible way is a bit tricky: reachability is defined
3640 in terms of equality, so we can't also define equality in terms of
3647 <p><b>Proposed resolution:</b></p>
3655 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
3656 <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#Open">Open</a>
3657 <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
3658 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
3659 <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>
3660 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3661 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
3662 <p><b>Discussion:</b></p>
3663 <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
3666 <p>should be supplemented with the overload:</p>
3668 <pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
3672 Depending on the operating system, one of these forms is fundamental and
3673 the other requires an implementation-defined mapping to determine the
3677 <p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
3678 provide wording.]</i></p>
3682 In Toronto we noted that this is issue 5 from
3683 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
3687 How does this interact with the newly-defined character types, and how
3688 do we avoid interface explosion considering <tt>std::string</tt> overloads that
3689 were added? Propose another solution that is different than the
3690 suggestion proposed by PJP.
3693 Suggestion is to make a member template function for <tt>basic_string</tt> (for
3694 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
3695 <tt>const char*</tt> member.
3698 Goal is to do implicit conversion between character string literals to
3699 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
3702 Implementors are free to add specific overloads for non-char character
3708 <p><b>Proposed resolution:</b></p>
3712 <pre>basic_filebuf<charT,traits>* open(
3714 ios_base::openmode mode );
3718 Effects: If is_open() != false, returns a null pointer.
3719 Otherwise, initializes the filebuf as required. It then
3720 opens a file, if possible, whose name is the NTBS s ("as if"
3721 by calling std::fopen(s,modstr)).</p>
3727 <pre>basic_filebuf<charT,traits>* open(
3729 ios_base::openmode mode );
3731 basic_filebuf<charT,traits>* open(
3733 ios_base::openmode mode );
3737 Effects: If is_open() != false, returns a null pointer.
3738 Otherwise, initializes the filebuf as required. It then
3739 opens a file, if possible, whose name is the NTBS s ("as if"
3740 by calling std::fopen(s,modstr)).
3741 For the second signature, the NTBS s is determined from the
3742 WCBS ws in an implementation-defined manner.
3746 (NOTE: For a system that "naturally" represents a filename
3747 as a WCBS, the NTBS s in the first signature may instead
3748 be mapped to a WCBS; if so, it follows the same mapping
3749 rules as the first argument to open.)
3755 <p><b>Rationale:</b></p>
3757 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
3758 this to Ready. The controversy was because the mapping between wide
3759 names and files in a filesystem is implementation defined. The
3760 counterargument, which most but not all LWG members accepted, is that
3761 the mapping between narrow files names and files is also
3762 implemenation defined.</p>
3764 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
3765 (1) Why just basic_filebuf, instead of also basic_fstream (and
3766 possibly other things too). (2) Why not also constructors that take
3767 std::basic_string? (3) We might want to wait until we see Beman's
3768 filesystem library; we might decide that it obviates this.]</i></p>
3778 Move again to Ready.
3781 There is a timing issue here. Since the filesystem library will not be
3782 in C++0x, this should be brought forward. This solution would remain
3783 valid in the context of the proposed filesystem.
3786 This issue has been kicking around for a while, and the wchar_t addition
3787 alone would help many users. Thus, we suggest putting this on the
3788 reflector list with an invitation for someone to produce proposed
3789 wording that covers basic_fstream. In the meantime, we suggest that the
3790 proposed wording be adopted as-is.
3793 If more of the Lillehammer questions come back, they should be
3794 introduced as separate issues.
3806 <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
3807 <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#Open">Open</a>
3808 <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
3809 <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>
3810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3811 <p><b>Discussion:</b></p>
3813 In 24.1.5 [lib.random.access.iterators], table 76 the operational
3814 semantics for the expression "r -= n" are defined as "return r += -n".
3815 This means, that the expression -n must be valid, which is not the case
3820 Sydney: Possibly not a real problem, since difference type is required
3821 to be a signed integer type. However, the wording in the standard may
3822 be less clear than we would like.
3828 <p><b>Proposed resolution:</b></p>
3830 To remove this limitation, I suggest to change the
3831 operational semantics for this column to:
3833 <blockquote><pre> { Distance m = n;
3847 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
3848 <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#Open">Open</a>
3849 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
3850 <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>
3851 <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>
3852 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3853 <p><b>Discussion:</b></p>
3854 <p>When parsing strings of wide-character digits, the standard
3855 requires the library to widen narrow-character "atoms" and compare
3856 the widened atoms against the characters that are being parsed.
3857 Simply narrowing the wide characters would be far simpler, and
3858 probably more efficient. The two choices are equivalent except in
3859 convoluted test cases, and many implementations already ignore the
3860 standard and use narrow instead of widen.</p>
3863 First, I disagree that using narrow() instead of widen() would
3864 necessarily have unfortunate performance implications. A possible
3865 implementation of narrow() that allows num_get to be implemented
3866 in a much simpler and arguably comparably efficient way as calling
3867 widen() allows, i.e. without making a virtual call to do_narrow every
3868 time, is as follows:
3871 <pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
3873 const unsigned wi = unsigned (wc);
3875 if (wi > UCHAR_MAX)
3876 return typeid (*this) == typeid (ctype<wchar_t>) ?
3877 dflt : do_narrow (wc, dflt);
3879 if (narrow_ [wi] < 0) {
3880 const char nc = do_narrow (wc, dflt);
3886 return char (narrow_ [wi]);
3891 Second, I don't think the change proposed in the issue (i.e., to use
3892 narrow() instead of widen() during Stage 2) would be at all
3893 drastic. Existing implementations with the exception of libstdc++
3894 currently already use narrow() so the impact of the change on programs
3895 would presumably be isolated to just a single implementation. Further,
3896 since narrow() is not required to translate alternate wide digit
3897 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
3899 their narrow equivalents (i.e., the portable source characters '0'
3900 through '9'), the change does not necessarily imply that these
3901 alternate digits would be treated as ordinary digits and accepted as
3902 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
3903 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
3904 digit character, wc, to an ordinary digit in the basic source
3905 character set unless the expression
3906 (ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in
3907 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
3908 5.2.1, respectively) for charT of either char or wchar_t.
3911 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
3912 you're only trafficking in char and wchar_t we're only dealing with a
3913 stable character set, so you don't really need either 'widen' or
3914 'narrow': can just use literals. Finally, it's not even clear whether
3915 widen-vs-narrow is the right question; arguably we should be using
3916 codecvt instead.]</i></p>
3921 <p><b>Proposed resolution:</b></p>
3922 <p>Change stage 2 so that implementations are permitted to use either
3923 technique to perform the comparison:</p>
3925 <li> call widen on the atoms and compare (either by using
3926 operator== or char_traits<charT>::eq) the input with
3927 the widened atoms, or</li>
3928 <li> call narrow on the input and compare the narrow input
3930 <li> do (1) or (2) only if charT is not char or wchar_t,
3931 respectively; i.e., avoid calling widen or narrow
3932 if it the source and destination types are the same</li>
3940 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
3941 <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#Open">Open</a>
3942 <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
3943 <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>
3944 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3945 <p><b>Discussion:</b></p>
3948 TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
3949 member of auto_ptr (20.4.5.3/4) obsolete.
3953 The sole purpose of this obsolete conversion member is to enable copy
3954 initialization base from r-value derived (or any convertible types like
3957 <pre>#include <memory>
3958 using std::auto_ptr;
3963 auto_ptr<D> source();
3964 int sink(auto_ptr<B>);
3965 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
3969 The excellent analysis of conversion operations that was given in the final
3971 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
3972 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
3973 wrong and actually comes to forbid the loophole that was exploited by the
3978 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
3979 ever allowed this case. This is probably because it requires 3 user defined
3980 conversions and in fact current compilers conform to DR #84.
3984 I was surprised to discover that the obsolete conversion member actually has
3985 negative impact of the copy initialization base from l-value derived
3987 <pre>auto_ptr<D> dp;
3988 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
3992 I'm sure that the original intention was allowing this initialization using
3993 the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
3994 since in this copy initialization it's merely user defined conversion (UDC)
3995 and the obsolete conversion member is UDC with the same rank (for the early
3996 overloading stage) there is an ambiguity between them.
4000 Removing the obsolete member will have impact on code that explicitly
4003 <pre>int y = sink(source().operator auto_ptr<B>());
4007 IMHO no one ever wrote such awkward code and the reasonable workaround for
4010 <pre>int y = sink( auto_ptr<B>(source()) );
4014 I was even more surprised to find out that after removing the obsolete
4015 conversion member the initialization was still ill-formed:
4016 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
4020 This copy initialization semantically requires copy constructor which means
4021 that both template conversion constructor and the auto_ptr_ref conversion
4022 member (20.4.5.3/3) are required which is what was explicitly forbidden in
4023 DR #84. This is a bit amusing case in which removing ambiguity results with
4028 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
4030 <pre>int f(auto_ptr<B>, std::string);
4031 auto_ptr<B> source2();
4033 // string constructor throws while auto_ptr_ref
4034 // "holds" the pointer
4035 int x4 = f(source2(), "xyz"); // #4
4039 The theoretic execution sequence that will cause a leak:
4042 <li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li>
4043 <li>call string::string(char const*) and throw</li>
4047 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
4048 returns auto_ptr_ref<Y> that holds *this and this is another defect since
4049 the type of *this is auto_ptr<X> where X might be different from Y. Several
4050 library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
4051 is much more reasonable. Other vendor implemented auto_ptr_ref as
4052 defectively required and it results with awkward and catastrophic code:
4053 int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
4058 Dave Abrahams noticed that there is no specification saying that
4059 auto_ptr_ref copy constructor can't throw.
4063 My proposal comes to solve all the above issues and significantly simplify
4064 auto_ptr implementation. One of the fundamental requirements from auto_ptr
4065 is that it can be constructed in an intuitive manner (i.e. like ordinary
4066 pointers) but with strict ownership semantics which yield that source
4067 auto_ptr in initialization must be non-const. My idea is to add additional
4068 constructor template with sole propose to generate ill-formed, diagnostic
4069 required, instance for const auto_ptr arguments during instantiation of
4070 declaration. This special constructor will not be instantiated for other
4071 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
4072 in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
4073 legitimate since the actual argument can't be const yet non const r-value
4078 This implementation technique makes the "private auxiliary class"
4079 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
4080 GCC and VC) consume the new implementation as expected and allow all
4081 intuitive initialization and assignment cases while rejecting illegal cases
4082 that involve const auto_ptr arguments.
4085 <p>The proposed auto_ptr interface:</p>
4087 <pre>namespace std {
4088 template<class X> class auto_ptr {
4090 typedef X element_type;
4092 // 20.4.5.1 construct/copy/destroy:
4093 explicit auto_ptr(X* p=0) throw();
4094 auto_ptr(auto_ptr&) throw();
4095 template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
4096 auto_ptr& operator=(auto_ptr&) throw();
4097 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
4098 ~auto_ptr() throw();
4100 // 20.4.5.2 members:
4101 X& operator*() const throw();
4102 X* operator->() const throw();
4103 X* get() const throw();
4104 X* release() throw();
4105 void reset(X* p=0) throw();
4108 template<class U>
4109 auto_ptr(U& rhs, typename
4110 unspecified_error_on_const_auto_ptr<U>::type = 0);
4116 One compliant technique to implement the unspecified_error_on_const_auto_ptr
4117 helper class is using additional private auto_ptr member class template like
4120 <pre>template<typename T> struct unspecified_error_on_const_auto_ptr;
4122 template<typename T>
4123 struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
4124 { typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
4128 There are other techniques to implement this helper class that might work
4129 better for different compliers (i.e. better diagnostics) and therefore I
4130 suggest defining its semantic behavior without mandating any specific
4131 implementation. IMO, and I didn't found any compiler that thinks otherwise,
4132 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
4133 verifying this with core language experts.
4136 <p><b>Further changes in standard text:</b></p>
4137 <p>Remove section 20.4.5.3</p>
4139 <p>Change 20.4.5/2 to read something like:
4140 Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
4141 ill-formed declaration that will require unspecified diagnostic.</p>
4143 <p>Change 20.4.5.1/4,5,6 to read:</p>
4145 <pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre>
4146 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
4147 <p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p>
4148 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
4150 <p>Change 20.4.5.1/10</p>
4151 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
4154 10 Requires: Y* can be implicitly converted to X*. The expression delete
4155 get() is well formed.
4158 <p>LWG TC DR #127 is obsolete.</p>
4161 Notice that the copy constructor and copy assignment operator should remain
4162 as before and accept non-const auto_ptr& since they have effect on the form
4163 of the implicitly declared copy constructor and copy assignment operator of
4164 class that contains auto_ptr as member per 12.8/5,10:
4167 // implicit X(X&)
4168 // implicit X& operator=(X&)
4169 auto_ptr<D> aptr_;
4174 In most cases this indicates about sloppy programming but preserves the
4175 current auto_ptr behavior.
4179 Dave Abrahams encouraged me to suggest fallback implementation in case that
4180 my suggestion that involves removing of auto_ptr_ref will not be accepted.
4181 In this case removing the obsolete conversion member to auto_ptr<Y> and
4182 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
4183 cases. The two constructors that I suggested will co exist with the current
4184 members but will make auto_ptr_ref obsolete in initialization contexts.
4185 auto_ptr_ref will be effective in assignment contexts as suggested in DR
4186 #127 and I can't see any serious exception safety issues in those cases
4187 (although it's possible to synthesize such). auto_ptr_ref<X> semantics will
4188 have to be revised to say that it strictly holds pointer of type X and not
4189 reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
4190 constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
4191 from r-value derived to base).
4194 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
4195 want to fix auto_ptr for C++-0x, or remove it and replace it with
4196 move_ptr and unique_ptr.]</i></p>
4200 Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases
4201 and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended
4207 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
4213 <p><b>Proposed resolution:</b></p>
4215 Change the synopsis in D.9.1 [auto.ptr]:
4218 <blockquote><pre>namespace std {
4219 <del>template <class Y> struct auto_ptr_ref {};</del>
4221 <ins>// exposition only</ins>
4222 <ins>template <class T> struct constant_object;</ins>
4224 <ins>// exposition only</ins>
4225 <ins>template <class T></ins>
4226 <ins>struct cannot_transfer_ownership_from</ins>
4227 <ins>: constant_object<T> {};</ins>
4229 template <class X> class auto_ptr {
4231 typedef X element_type;
4233 // D.9.1.1 construct/copy/destroy:
4234 explicit auto_ptr(X* p =0) throw();
4235 auto_ptr(auto_ptr&) throw();
4236 template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw();
4237 auto_ptr& operator=(auto_ptr&) throw();
4238 template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw();
4239 <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del>
4240 ~auto_ptr() throw();
4243 X& operator*() const throw();
4244 X* operator->() const throw();
4245 X* get() const throw();
4246 X* release() throw();
4247 void reset(X* p =0) throw();
4249 <del>// D.9.1.3 conversions:</del>
4250 <del>auto_ptr(auto_ptr_ref<X>) throw();</del>
4251 <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del>
4252 <del>template<class Y> operator auto_ptr<Y>() throw();</del>
4254 <ins>// exposition only</ins>
4255 <ins>template<class U></ins>
4256 <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins>
4259 template <> class auto_ptr<void>
4262 typedef void element_type;
4269 Remove D.9.1.3 [auto.ptr.conv].
4273 Change D.9.1 [auto.ptr], p3:
4277 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
4278 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
4279 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
4280 destination. If more than one <tt>auto_ptr</tt> owns the same object at
4281 the same time the behavior of the program is undefined. <ins>Templates
4282 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
4283 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
4284 For any types <tt>X</tt> and <tt>Y</tt>, initializing
4285 <tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is
4286 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
4287 <tt>auto_ptr</tt> include providing temporary exception-safety for
4288 dynamically allocated memory, passing ownership of dynamically allocated
4289 memory to a function, and returning dynamically allocated memory from a
4290 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
4291 and <tt>Assignable</tt> requirements for Standard Library container
4292 elements and thus instantiating a Standard Library container with an
4293 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
4297 Change D.9.1.1 [auto.ptr.cons], p5:
4301 <pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw();
4305 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4308 <i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
4311 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
4317 Change D.9.1.1 [auto.ptr.cons], p10:
4321 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw();
4325 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4326 The expression <tt>delete get()</tt> is well formed.
4329 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
4332 <i>Returns:</i> <tt>*this</tt>.
4343 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
4344 <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#Ready">Ready</a>
4345 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
4346 <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>
4347 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
4348 <p><b>Discussion:</b></p>
4350 <p>[lib.exception] specifies the following:</p>
4351 <pre> exception (const exception&) throw();
4352 exception& operator= (const exception&) throw();
4354 -4- Effects: Copies an exception object.
4355 -5- Notes: The effects of calling what() after assignment
4356 are implementation-defined.
4360 First, does the Note only apply to the assignment operator? If so,
4361 what are the effects of calling what() on a copy of an object? Is
4362 the returned pointer supposed to point to an identical copy of
4363 the NTBS returned by what() called on the original object or not?
4367 Second, is this Note intended to extend to all the derived classes
4368 in section 19? I.e., does the standard provide any guarantee for
4369 the effects of what() called on a copy of any of the derived class
4370 described in section 19?
4374 Finally, if the answer to the first question is no, I believe it
4375 constitutes a defect since throwing an exception object typically
4376 implies invoking the copy ctor on the object. If the answer is yes,
4377 then I believe the standard ought to be clarified to spell out
4378 exactly what the effects are on the copy (i.e., after the copy
4382 <p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is
4387 Batavia: Howard provided wording.
4398 Eric concerned this is unimplementable, due to nothrow guarantees.
4399 Suggested implementation would involve reference counting.
4402 Is the implied reference counting subtle enough to call out a note on
4403 implementation? Probably not.
4406 If reference counting required, could we tighten specification further
4407 to require same pointer value? Probably an overspecification, especially
4408 if exception classes defer evalutation of final string to calls to
4412 Remember issue moved open and not resolved at Batavia, but cannot
4413 remember who objected to canvas a disenting opinion - please speak up if
4414 you disagree while reading these minutes!
4417 Move to Ready as we are accepting words unmodified.
4423 <p><b>Proposed resolution:</b></p>
4426 Change 18.7.1 [exception] to:
4430 <pre>exception(const exception& <ins><i>e</i></ins>) throw();
4431 exception& operator=(const exception& <ins><i>e</i></ins>) throw();</pre>
4434 -4- <i>Effects:</i> Copies an exception object.
4437 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
4440 <ins>-5- <i>Throws:</i> Nothing. This also applies
4441 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4444 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>. This also applies
4445 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4455 <h3><a name="473"></a>473. underspecified ctype calls</h3>
4456 <p><b>Section:</b> 22.2.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4457 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
4458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4459 <p><b>Discussion:</b></p>
4461 Most ctype member functions come in two forms: one that operates
4462 on a single character at a time and another form that operates
4463 on a range of characters. Both forms are typically described by
4464 a single Effects and/or Returns clause.
4467 The Returns clause of each of the single-character non-virtual forms
4468 suggests that the function calls the corresponding single character
4469 virtual function, and that the array form calls the corresponding
4470 virtual array form. Neither of the two forms of each virtual member
4471 function is required to be implemented in terms of the other.
4474 There are three problems:
4477 1. One is that while the standard does suggest that each non-virtual
4478 member function calls the corresponding form of the virtual function,
4479 it doesn't actually explicitly require it.
4482 Implementations that cache results from some of the virtual member
4483 functions for some or all values of their arguments might want to
4484 call the array form from the non-array form the first time to fill
4485 the cache and avoid any or most subsequent virtual calls. Programs
4486 that rely on each form of the virtual function being called from
4487 the corresponding non-virtual function will see unexpected behavior
4488 when using such implementations.
4491 2. The second problem is that either form of each of the virtual
4492 functions can be overridden by a user-defined function in a derived
4493 class to return a value that is different from the one produced by
4494 the virtual function of the alternate form that has not been
4498 Thus, it might be possible for, say, ctype::widen(c) to return one
4499 value, while for ctype::widen(&c, &c + 1, &wc) to set
4500 wc to another value. This is almost certainly not intended. Both
4501 forms of every function should be required to return the same result
4502 for the same character, otherwise the same program using an
4503 implementation that calls one form of the functions will behave
4504 differently than when using another implementation that calls the
4505 other form of the function "under the hood."
4508 3. The last problem is that the standard text fails to specify whether
4509 one form of any of the virtual functions is permitted to be implemented
4510 in terms of the other form or not, and if so, whether it is required
4511 or permitted to call the overridden virtual function or not.
4514 Thus, a program that overrides one of the virtual functions so that
4515 it calls the other form which then calls the base member might end
4516 up in an infinite loop if the called form of the base implementation
4517 of the function in turn calls the other form.
4520 Lillehammer: Part of this isn't a real problem. We already talk about
4521 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
4522 each other, so users don't know which ones to override to avoid avoid
4525 <p>This is a problem for all facet virtuals, not just ctype virtuals,
4526 so we probably want a blanket statement in clause 22 for all
4527 facets. The LWG is leaning toward a blanket prohibition, that a
4528 facet's virtuals may never call each other. We might want to do that
4529 in clause 27 too, for that matter. A review is necessary. Bill will
4530 provide wording.</p>
4533 <p><b>Proposed resolution:</b></p>
4539 <h3><a name="484"></a>484. Convertible to T</h3>
4540 <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#Open">Open</a>
4541 <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
4542 <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>
4543 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4544 <p><b>Discussion:</b></p>
4545 <p>From comp.std.c++:</p>
4548 I note that given an input iterator a for type T,
4549 then *a only has to be "convertable to T", not actually of type T.
4552 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
4553 While I assume it is the obvious definition (an implicit conversion), I
4554 can't find an exact definition. Is there one?</p>
4556 <p>Slightly more worryingly, there doesn't seem to be any restriction on
4557 the this type, other than it is "convertable to T". Consider two input
4558 iterators a and b. I would personally assume that most people would
4559 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
4560 the standard requires that, and that whatever type *a is (call it U)
4561 could have == defined on it with totally different symantics and still
4562 be a valid inputer iterator.</p>
4564 <p>Is this a correct reading? When using input iterators should I write
4565 T(*a) all over the place to be sure that the object i'm using is the
4568 <p>This is especially a nuisance for operations that are defined to be
4569 "convertible to bool". (This is probably allowed so that
4570 implementations could return say an int and avoid an unnessary
4571 conversion. However all implementations I have seen simply return a
4572 bool anyway. Typical implemtations of STL algorithms just write
4573 things like <tt>while(a!=b && *a!=0)</tt>. But strictly
4574 speaking, there are lots of types that are convertible to T but
4575 that also overload the appropriate operators so this doesn't behave
4578 <p>If we want to make code like this legal (which most people seem to
4579 expect), then we'll need to tighten up what we mean by "convertible
4582 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
4583 well-defined in core. The second part is basically about pathological
4584 overloads. It's a minor problem but a real one. So leave open for
4585 now, hope we solve it as part of iterator redesign.]</i></p>
4589 <p><b>Proposed resolution:</b></p>
4596 <h3><a name="485"></a>485. output iterator insufficently constrained</h3>
4597 <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#Open">Open</a>
4598 <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
4599 <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>
4600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4601 <p><b>Discussion:</b></p>
4603 The note on 24.1.2 Output iterators insufficently limits what can be
4604 performed on output iterators. While it requires that each iterator is
4605 progressed through only once and that each iterator is written to only
4606 once, it does not require the following things:</p>
4608 <p>Note: Here it is assumed that x is an output iterator of type X which
4609 has not yet been assigned to.</p>
4611 <p>a) That each value of the output iterator is written to:
4612 The standard allows:
4617 b) That assignments to the output iterator are made in order
4618 X a(x); ++a; *a=1; *x=2; is allowed
4622 c) Chains of output iterators cannot be constructed:
4623 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
4624 wording (I believe) x,a,b,c could be written to in any order.
4627 <p>I do not believe this was the intension of the standard?</p>
4628 <p><i>[Lillehammer: Real issue. There are lots of constraints we
4629 intended but didn't specify. Should be solved as part of iterator
4634 <p><b>Proposed resolution:</b></p>
4641 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
4642 <p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4643 <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
4644 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
4645 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
4646 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4647 <p><b>Discussion:</b></p>
4648 <p>Various clauses other than clause 25 make use of iterator arithmetic not
4649 supported by the iterator category in question.
4650 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
4651 paragraph 9, but this paragraph does not provide semantics to the
4652 expression "iterator - n", where n denotes a value of a distance type
4653 between iterators.</p>
4655 <p>1) Examples of current wording:</p>
4657 <p>Current wording outside clause 25:</p>
4660 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
4662 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
4663 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
4664 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
4665 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
4666 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
4670 [Important note: The list is not complete, just an illustration. The
4671 same issue might well apply to other paragraphs not listed here.]</p>
4673 <p>None of these expressions is valid for the corresponding iterator
4676 <p>Current wording in clause 25:</p>
4679 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
4680 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4682 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
4683 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
4687 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4688 neither of these four cases:</p>
4690 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4693 "In the description of the algorithms operator + and - are used for some
4694 of the iterator categories for which they do not have to be defined. In
4695 these cases the semantics of a+n is the same as that of</p>
4701 <p>and that of b-a is the same as of return distance(a, b)"</p>
4704 This paragrpah does not take the expression "iterator - n" into account,
4705 where n denotes a value of a distance type between two iterators [Note:
4706 According to current wording, the expression "iterator - n" would be
4707 resolved as equivalent to "return distance(n, iterator)"]. Even if the
4708 expression "iterator - n" were to be reinterpreted as equivalent to
4709 "iterator + -n" [Note: This would imply that "a" and "b" were
4710 interpreted implicitly as values of iterator types, and "n" as value of
4711 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4712 may be negative only for random access and bidirectional iterators.",
4713 and none of the paragraphs quoted above requires the iterators on which
4714 the algorithms operate to be of random access or bidirectional category.
4717 <p>2) Description of intended behavior:</p>
4720 For the rest of this Defect Report, it is assumed that the expression
4721 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
4722 described in current 25 [lib.algorithms], paragraph 9, but applying to
4723 all clauses. The expression "iterator1 - n" is equivalent to an
4724 result-iterator for which the expression "result-iterator + n" yields an
4725 iterator denoting the same position as iterator1 does. The terms
4726 "iterator1", "iterator2" and "result-iterator" shall denote the value of
4727 an iterator type, and the term "n" shall denote a value of a distance
4728 type between two iterators.</p>
4731 All implementations known to the author of this Defect Report comply
4732 with these assumptions.
4733 No impact on current code is expected.</p>
4735 <p>3) Proposed fixes:</p>
4738 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4741 "In the description of the algorithms operator + and - are used for some
4742 of the iterator categories for which they do not have to be defined. In
4743 this paragraph, a and b denote values of an iterator type, and n denotes
4744 a value of a distance type between two iterators. In these cases the
4745 semantics of a+n is the same as that of</p>
4751 <p>,the semantics of a-n denotes the value of an iterator i for which the
4752 following condition holds:
4754 and that of b-a is the same as of
4755 return distance(a, b)".
4758 <p>Comments to the new wording:</p>
4761 a) The wording " In this paragraph, a and b denote values of an iterator
4762 type, and n denotes a value of a distance type between two iterators."
4763 was added so the expressions "b-a" and "a-n" are distinguished regarding
4764 the types of the values on which they operate.
4765 b) The wording ",the semantics of a-n denotes the value of an iterator i
4766 for which the following condition holds: advance(i, n) == a" was added
4767 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
4768 was used to avoid a dependency on the semantics of a+n, as the wording
4769 "i + n == a" would have implied. However, such a dependency might well
4771 c) DR 225 is not considered in the new wording.
4775 Proposed fixes regarding invalid iterator arithmetic expressions outside
4780 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4781 before any current invalid iterator arithmetic expression. In that case,
4782 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4783 modified and could read: "For the rest of this International Standard,
4784 ...." / "In the description of the following clauses including this
4785 ...." / "In the description of the text below ..." etc. - anyways
4786 substituting the wording "algorithms", which is a straight reference to
4788 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
4791 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
4792 paragraph 9, to the beginning of each clause containing invalid iterator
4793 arithmetic expressions.
4795 c) Fix each paragraph (both current wording and possible resolutions of
4796 DRs) containing invalid iterator arithmetic expressions separately.
4799 <p>5) References to other DRs:</p>
4803 See DR 237. The resolution could then also read "Linear in last -
4813 Keep open and ask Bill to provide wording.
4817 <p><b>Proposed resolution:</b></p>
4819 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
4820 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
4821 not quite broad enough, because there are some arithmetic expressions
4822 it doesn't cover. Bill will provide wording.]</i></p>
4831 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
4832 <p><b>Section:</b> 25.2.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4833 <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
4834 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4835 <p><b>Discussion:</b></p>
4838 The iterator requirements for partition() and stable_partition() [25.2.12]
4839 are listed as BidirectionalIterator, however, there are efficient algorithms
4840 for these functions that only require ForwardIterator that have been known
4841 since before the standard existed. The SGI implementation includes these (see
4842 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
4844 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
4848 <p><b>Proposed resolution:</b></p>
4850 Change 25.2.12 from </p>
4851 <blockquote><pre>template<class BidirectionalIterator, class Predicate>
4852 BidirectionalIterator partition(BidirectionalIterato r first,
4853 BidirectionalIterator last,
4857 <blockquote><pre>template<class ForwardIterator, class Predicate>
4858 ForwardIterator partition(ForwardIterator first,
4859 ForwardIterator last,
4862 <p>Change the complexity from </p>
4865 At most (last - first)/2 swaps are done. Exactly (last - first)
4866 applications of the predicate are done.
4872 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
4873 swaps are done; otherwise at most (last - first) swaps are done. Exactly
4874 (last - first) applications of the predicate are done.
4879 <p><b>Rationale:</b></p>
4881 Partition is a "foundation" algorithm useful in many contexts (like sorting
4882 as just one example) - my motivation for extending it to include forward
4883 iterators is slist - without this extension you can't partition an slist
4884 (without writing your own partition). Holes like this in the standard
4885 library weaken the argument for generic programming (ideally I'd be able
4886 to provide a library that would refine std::partition() to other concepts
4887 without fear of conflicting with other libraries doing the same - but
4888 that is a digression). I consider the fact that partition isn't defined
4889 to work for ForwardIterator a minor embarrassment.
4892 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
4893 by next meeting. Sean provided further rationale by post-meeting
4903 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
4904 <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#Open">Open</a>
4905 <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
4906 <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>
4907 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4908 <p><b>Discussion:</b></p>
4914 This requirement seems obvious to me, it is the essence of code modularity.
4915 I have complained to Mr. Plauger that the Dinkumware library does not
4916 observe this principle but he objected that this behaviour is not covered in
4921 <p><b>Proposed resolution:</b></p>
4923 Append the following point to 22.1.1.1.1:
4927 6. The implementation of a facet of Table 52 parametrized with an
4928 InputIterator/OutputIterator should use that iterator only as character
4929 source/sink respectively.
4930 For a *_get facet, it means that the value received depends only on the
4931 sequence of input characters and not on how they are accessed.
4932 For a *_put facet, it means that the sequence of characters output depends
4933 only on the value to be formatted and not of how the characters are stored.
4937 Berlin: Moved to Open, Need to clean up this area to make it clear
4938 locales don't have to contain open ended sets of facets. Jack, Howard,
4949 <h3><a name="503"></a>503. more on locales</h3>
4950 <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#Open">Open</a>
4951 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
4952 <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>
4953 <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>
4954 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4955 <p><b>Discussion:</b></p>
4957 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
4958 51" to refer to the facet *objects* associated with a locale. And we
4959 almost certainly mean just those associated with the default or "C"
4960 locale. Otherwise, you can't switch to a locale that enforces a different
4961 mapping between narrow and wide characters, or that defines additional
4962 uppercase characters.
4966 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
4970 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
4971 a homing sequence for the basic character set, which might very well need
4976 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
4977 between wide and narrow characters be taken as one-for-one.
4981 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
4982 I can tell. The muddle is, as before, calling Table 51 a list of
4983 instantiations. But the constraint it applies seems to me to cover
4984 *all* defined uses of num_get/put, so why bother to say so?
4988 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
4989 return '.' or L'.'.) Presumably this means "as appropriate for the
4990 character type. But given the vague definition of "required" earlier,
4991 this overrules *any* change of decimal point for non "C" locales.
4992 Surely we don't want to do that.
4996 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
4997 return ',' or L','.) As above, this probably means "as appropriate for the
4998 character type. But this overrules the "C" locale, which requires *no*
4999 character ('\0') for the thousands separator. Even if we agree that we
5000 don't mean to block changes in decimal point or thousands separator,
5001 we should also eliminate this clear incompatibility with C.
5005 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
5006 return the empty string, indicating no grouping." Same considerations
5007 as for do_decimal_point.
5011 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
5012 51". Same bad jargon.
5016 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
5017 in Table 51". Same bad jargon.
5021 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
5026 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
5031 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
5032 in Table 51 ... return an object of type pattern initialized to
5033 {symbol, sign, none, value}." This once again *overrides* the "C"
5034 locale, as well as any other locale."
5038 3) We constrain the use_facet calls that can be made by num_get/put,
5039 so why don't we do the same for money_get/put? Or for any of the
5040 other facets, for that matter?
5044 4) As an almost aside, we spell out when a facet needs to use the ctype
5045 facet, but several also need to use a codecvt facet and we don't say so.
5048 Berlin: Bill to provide wording.
5053 <p><b>Proposed resolution:</b></p>
5062 <h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
5063 <p><b>Section:</b> 23.1.3 [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#Ready">Ready</a>
5064 <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
5065 <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>
5066 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5067 <p><b>Discussion:</b></p>
5069 Issue 371 deals with stability of multiset/multimap under insert and erase
5070 (i.e. do they preserve the relative order in ranges of equal elements).
5071 The same issue applies to unordered_multiset and unordered_multimap.
5074 Moved to open (from review): There is no resolution.
5079 Toronto: We have a resolution now. Moved to Review. Some concern was noted
5080 as to whether this conflicted with existing practice or not. An additional
5081 concern was in specifying (partial) ordering for an unordered container.
5087 <p><b>Proposed resolution:</b></p>
5089 Wording for the proposed resolution is taken from the equivalent text for associative containers.
5093 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to:
5097 An unordered associative container supports <i>unique</i> keys if it may
5098 contain at most one element for each key. Otherwise, it supports <i>equivalent
5099 keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support
5100 unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt>
5101 support equivalent keys. In containers that support equivalent keys, elements
5102 with equivalent keys are adjacent to each other. <ins>For
5103 <tt>unordered_multiset</tt>
5104 and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt>
5105 preserve the relative ordering of equivalent elements.</ins>
5109 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to:
5113 <p>The elements of an unordered associative container are organized into <i>
5114 buckets</i>. Keys with the same hash code appear in the same bucket. The number
5115 of buckets is automatically increased as elements are added to an unordered
5116 associative container, so that the average number of elements per bucket is kept
5117 below a bound. Rehashing invalidates iterators, changes ordering between
5118 elements, and changes which buckets elements appear in, but does not invalidate
5119 pointers or references to elements. <ins>For <tt>unordered_multiset</tt>
5120 and <tt>unordered_multimap</tt>, rehashing
5121 preserves the relative ordering of equivalent elements.</ins></p>
5130 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
5131 <p><b>Section:</b> 20.3 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5132 <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
5133 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
5134 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
5135 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5136 <p><b>Discussion:</b></p>
5138 Tuple doesn't define swap(). It should.
5141 Berlin: Doug to provide wording.
5145 Batavia: Howard to provide wording.
5149 Toronto: Howard to provide wording (really this time).
5154 Bellevue: Alisdair provided wording.
5160 <p><b>Proposed resolution:</b></p>
5163 Add these signatures to 20.3 [tuple]
5166 <blockquote><pre>template <class... Types>
5167 void swap(tuple<Types...>& x, tuple<Types...>& y);
5168 template <class... Types>
5169 void swap(tuple<Types...>&& x, tuple<Types...>& y);
5170 template <class... Types>
5171 void swap(tuple<Types...>& x, tuple<Types...>&& y);
5175 Add this signature to 20.3.1 [tuple.tuple]
5178 <blockquote><pre>void swap(tuple&&);
5182 Add the following two sections to the end of the tuple clauses
5187 20.3.1.7 tuple swap [tuple.swap]
5190 <pre>void swap(tuple&& rhs);
5195 <i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
5198 <i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
5202 <i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
5208 20.3.1.8 tuple specialized algorithms [tuple.special]
5211 <pre>template <class... Types>
5212 void swap(tuple<Types...>& x, tuple<Types...>& y);
5213 template <class... Types>
5214 void swap(tuple<Types...>&& x, tuple<Types...>& y);
5215 template <class... Types>
5216 void swap(tuple<Types...>& x, tuple<Types...>&& y);
5221 <i>Effects:</i> x.swap(y)
5232 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
5233 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5234 <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
5235 <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>
5236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5237 <p><b>Discussion:</b></p>
5239 A problem with TR1 regex is currently being discussed on the Boost
5240 developers list. It involves the handling of case-insensitive matching
5241 of character ranges such as [Z-a]. The proper behavior (according to the
5242 ECMAScript standard) is unimplementable given the current specification
5243 of the TR1 regex_traits<> class template. John Maddock, the author of
5244 the TR1 regex proposal, agrees there is a problem. The full discussion
5245 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
5246 message copied below). We don't have any recommendations as yet.
5249 -- Begin original message --
5252 The situation of interest is described in the ECMAScript specification
5253 (ECMA-262), section 15.10.2.15:
5256 "Even if the pattern ignores case, the case of the two ends of a range
5257 is significant in determining which characters belong to the range.
5258 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5259 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5260 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5263 A more interesting case is what should happen when doing a
5264 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5265 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5266 Boost.Regex (it throws an exception from the regex constructor).
5269 The tough pill to swallow is that, given the specification in TR1, I
5270 don't think there is any effective way to handle this situation.
5271 According to the spec, case-insensitivity is handled with
5272 regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
5273 if they compare equal after both are sent through the translate_nocase
5274 function. But I don't see any way of using this translation function to
5275 make character ranges case-insensitive. Consider the difficulty of
5276 detecting whether "z" is in the range [Z-a]. Applying the transformation
5277 to "z" has no effect (it is essentially std::tolower). And we're not
5278 allowed to apply the transformation to the ends of the range, because as
5279 ECMA-262 says, "the case of the two ends of a range is significant."
5282 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5283 is to redefine translate_nocase to return a string_type containing all
5284 the characters that should compare equal to the specified character. But
5285 this function is hard to implement for Unicode, and it doesn't play nice
5286 with the existing ctype facet. What a mess!
5289 -- End original message --
5298 One small correction, I have since found that ICU's regex package does
5299 implement this correctly, using a similar mechanism to the current
5303 Given an expression [c1-c2] that is compiled as case insensitive it:
5306 Enumerates every character in the range c1 to c2 and converts it to it's
5307 case folded equivalent. That case folded character is then used a key to a
5308 table of equivalence classes, and each member of the class is added to the
5309 list of possible matches supported by the character-class. This second step
5310 isn't possible with our current traits class design, but isn't necessary if
5311 the input text is also converted to a case-folded equivalent on the fly.
5314 ICU applies similar brute force mechanisms to character classes such as
5315 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5316 is less noticeable in this case.
5319 Quick and dirty performance comparisons show that expressions such as
5320 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
5321 slower than a "normal" expression). For an application that uses a lot of
5322 regexes this could have a noticeable performance impact. ICU also has an
5323 advantage in that it knows the range of valid characters codes: code points
5324 outside that range are assumed not to require enumeration, as they can not
5325 be part of any equivalence class. I presume that if we want the TR1.Regex
5326 to work with arbitrarily large character sets enumeration really does become
5330 Finally note that Unicode has:
5333 Three cases (upper, lower and title).
5334 One to many, and many to one case transformations.
5335 Character that have context sensitive case translations - for example an
5336 uppercase sigma has two different lowercase forms - the form chosen depends
5337 on context(is it end of a word or not), a caseless match for an upper case
5338 sigma should match either of the lower case forms, which is why case folding
5339 is often approximated by tolower(toupper(c)).
5342 Probably we need some way to enumerate character equivalence classes,
5343 including digraphs (either as a result or an input), and some way to tell
5344 whether the next character pair is a valid digraph in the current locale.
5347 Hoping this doesn't make this even more complex that it was already,
5351 Portland: Alisdair: Detect as invalid, throw an exception.
5352 Pete: Possible general problem with case insensitive ranges.
5358 <p><b>Proposed resolution:</b></p>
5365 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
5366 <p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
5367 <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
5368 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
5369 <p><b>Discussion:</b></p>
5371 There are some problems in the definition of partial_sum and
5372 adjacent_difference in 26.4 [lib.numeric.ops]
5376 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
5377 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
5378 specifies the effects clause as;
5382 Assigns to every element referred to by iterator <tt>i</tt> in the range
5383 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
5385 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
5390 And similarly for BinaryOperation. Using just this definition, it seems
5391 logical to expect that:
5395 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
5398 std::partial_sum(i_array, i_array+4, o_array);
5405 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
5409 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
5414 Yet all implementations I have tested produce 100, -56, 44, -112,
5415 because they are using an accumulator of the <tt>InputIterator</tt>'s
5416 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
5420 The issue becomes more noticeable when the result of the expression <tt>*i +
5421 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
5422 <tt>value_type</tt>. In a contrived example:
5425 <blockquote><pre>enum not_int { x = 1, y = 2 };
5427 not_int e_array[4] = { x, x, y, y };
5428 std::partial_sum(e_array, e_array+4, o_array);
5432 Is it the intent that the operations happen in the <tt>input type</tt>, or in
5433 the <tt>result type</tt>?
5437 If the intent is that operations happen in the <tt>result type</tt>, something
5438 like this should be added to the "Requires" clause of 26.4.3/4
5443 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
5444 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
5449 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
5450 [lib.inner.product].)
5454 The "auto initializer" feature proposed in
5455 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
5457 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
5458 obtained by using the <tt>std::plus<></tt> function object.
5462 If the intent is that operations happen in the <tt>input type</tt>, then
5463 something like this should be added instead;
5467 The type of *first shall meet the requirements of
5468 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
5469 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
5470 convertible to this type.
5474 The 'widening' behaviour can then be obtained by writing a custom proxy
5475 iterator, which is somewhat involved.
5479 In both cases, the semantics should probably be clarified.
5483 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
5484 all implementations seem to perform operations in the 'result' type:
5487 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
5490 std::adjacent_difference(i_array, i_array+4, o_array);
5494 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
5498 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
5499 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
5500 [lib.numeric.ops] by adding the following to 26.4.4/2
5501 [lib.adjacent.difference]:
5505 The type of <tt>*first</tt> shall meet the requirements of
5506 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
5509 Berlin: Giving output iterator's value_types very controversial. Suggestion of
5510 adding signatures to allow user to specify "accumulator".
5520 The intent of the algorithms is to perform their calculations using the type of the input iterator.
5521 Proposed wording provided.
5525 <p><b>Proposed resolution:</b></p>
5527 Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
5531 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5532 (20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
5533 <tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
5537 Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
5541 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5542 (20.1.3) and <tt>Assignable</tt> (23.1) types.
5551 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
5552 <p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5553 <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
5554 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5555 <p><b>Discussion:</b></p>
5557 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
5558 The rest of the TR should use that type. I believe this affects two places.
5559 First, the random number requirements, 5.1.1/10-11, lists all of the types with
5560 which template parameters named IntType and UIntType may be instantiated.
5561 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
5562 IntType list, and UIntType (again, or "unsigned long long") should be added to
5563 the UIntType list. Second, 6.3.2 lists the types for which hash<> is
5564 required to be instantiable. _Longlong and _Ulonglong should be added to that
5565 list, so that people may use long long as a hash key.
5569 <p><b>Proposed resolution:</b></p>
5578 <h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
5579 <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#Ready">Ready</a>
5580 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
5581 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
5582 <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>
5583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5584 <p><b>Discussion:</b></p>
5586 Assuming we adopt the
5587 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
5588 compatibility package from C99</a> what should be the return type of the
5589 following signature be:
5591 <blockquote><pre>? pow(float, int);
5594 C++03 says that the return type should be <tt>float</tt>.
5595 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
5596 TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put
5597 clients into a situation where C++03 provides answers that are not as high
5598 quality as C90/C99/TR1. For example:
5600 <blockquote><pre>#include <math.h>
5604 float x = 2080703.375F;
5605 double y = pow(x, 2);
5609 Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
5612 <blockquote><pre>y = 4329326534736.390625
5616 which is exactly right. While C++98/C++03 demands:
5619 <blockquote><pre>y = 4329326510080.
5623 which is only approximately right.
5627 I recommend that C++0X adopt the mixed mode arithmetic already adopted by
5628 Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
5633 Kona (2007): Other functions that are affected by this issue include
5634 <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
5635 26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
5636 nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
5637 resolution appears above, rather than below, the heading "Proposed
5648 Unfortunately I strongly disagree with a part of the resolution
5649 from Kona. I am moving from New to Open instead of to Review because I do not believe
5650 we have consensus on the intent of the resolution.
5653 This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
5654 the second integral parameter in each of these signatures (from C99) is <b>not</b> a
5655 <i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are
5656 intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
5659 For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
5660 <tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the
5661 correct signature is:
5664 <pre>float nexttoward(float, long double);
5668 which is what both the C++0X working paper and C99 state (as far as I currently understand).
5671 This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one
5672 route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt><tgmath.h></tt>.
5673 The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
5685 This signature was not picked up from C99. Instead, if one types
5686 pow(2.0f,2), the promotion rules will invoke "double pow(double,
5687 double)", which generally gives special treatment for integral
5688 exponents, preserving full accuracy of the result. New proposed
5693 <p><b>Proposed resolution:</b></p>
5695 Change 26.7 [c.math] p10:
5700 The added signatures are:
5702 <blockquote><pre>...
5703 <del>float pow(float, int);</del>
5705 <del>double pow(double, int);</del>
5707 <del>long double pow(long double, int);</del>
5717 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
5718 <p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5719 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
5720 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
5721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5722 <p><b>Discussion:</b></p>
5724 In 25, p8 we allow BinaryPredicates to return a type that's convertible
5725 to bool but need not actually be bool. That allows predicates to return
5726 things like proxies and requires that implementations be careful about
5727 what kinds of expressions they use the result of the predicate in (e.g.,
5728 the expression in if (!pred(a, b)) need not be well-formed since the
5729 negation operator may be inaccessible or return a type that's not
5730 convertible to bool).
5733 Here's the text for reference:
5736 ...if an algorithm takes BinaryPredicate binary_pred as its argument
5737 and first1 and first2 as its iterator arguments, it should work
5738 correctly in the construct if (binary_pred(*first1, first2)){...}.
5742 In 25.3, p2 we require that the Compare function object return true
5743 of false, which would seem to preclude such proxies. The relevant text
5747 Compare is used as a function object which returns true if the first
5748 argument is less than the second, and false otherwise...
5752 <p><b>Proposed resolution:</b></p>
5754 I think we could fix this by rewording 25.3, p2 to read somthing like:
5757 -2- <tt>Compare</tt> is <del>used as a function object which returns
5758 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
5759 return value of the function call operator applied to an object of type
5760 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
5761 if the first argument of the call</ins> is less than the second, and
5762 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
5763 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
5764 will not apply any non-constant function through the dereferenced iterator.
5769 Portland: Jack to define "convertible to bool" such that short circuiting isn't
5778 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
5779 <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#Open">Open</a>
5780 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5781 <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>
5782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5783 <p><b>Discussion:</b></p>
5785 The effects of the <code>seekpos()</code> member function of
5786 <code>basic_stringbuf</code> simply say that the function positions
5787 the input and/or output sequences but fail to spell out exactly
5788 how. This is in contrast to the detail in which <code>seekoff()</code>
5793 <p><b>Proposed resolution:</b></p>
5796 Change 27.7.1.3, p13 to read:
5801 -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
5802 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
5803 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
5804 (as described below).</del>
5807 <li><del>If <tt>(<i>which</i> & ios_base::in) != 0</tt>, positions the input sequence.</del></li>
5808 <li><del>If <tt>(<i>which</i> & ios_base::out) != 0</tt>, positions the output sequence.</del></li>
5809 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
5810 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
5811 has not been obtained by a previous successful call to one of the positioning
5812 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
5813 the effect is undefined.</del></li>
5819 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
5820 definition, so there is no ambiguity as to what it means. Proposed
5826 Post-Kona Martin adds:
5827 I'm afraid I disagree
5828 with the Kona '07 rationale for marking it NAD. The only text
5829 that describes precisely what it means to position the input
5830 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
5831 clause is inadequate in comparison and the proposed resolution
5832 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
5840 <h3><a name="565"></a>565. xsputn inefficient</h3>
5841 <p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5842 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5844 <p><b>Discussion:</b></p>
5847 <tt>streambuf::xsputn()</tt> is specified to have the effect of
5848 "writing up to <tt>n</tt> characters to the output sequence as if by
5849 repeated calls to <tt>sputc(c)</tt>."
5854 Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when
5855 <tt>(pptr() == epptr())</tt> is true, strictly speaking
5856 <tt>xsputn()</tt> should do the same. However, doing so would be
5857 suboptimal in some interesting cases, such as in unbuffered mode or
5858 when the buffer is <tt>basic_stringbuf</tt>.
5863 Assuming calling <tt>overflow()</tt> is not really intended to be
5864 required and the wording is simply meant to describe the general
5865 effect of appending to the end of the sequence it would be worthwhile
5866 to mention in <tt>xsputn()</tt> that the function is not actually
5867 required to cause a call to <tt>overflow()</tt>.
5872 <p><b>Proposed resolution:</b></p>
5875 Add the following sentence to the <tt>xsputn()</tt> Effects clause in
5876 27.5.2.4.5, p1 (N1804):
5881 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
5882 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
5883 written are obtained from successive elements of the array whose first element
5884 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
5885 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
5886 <tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls
5887 <tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether
5888 it achieves the same effects by other means.</ins>
5893 In addition, I suggest to add a footnote to this function with the
5894 same text as Footnote 292 to make it extra clear that derived classes
5895 are permitted to override <tt>xsputn()</tt> for efficiency.
5901 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
5902 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
5903 has always been the intention of the committee. We believe that the
5904 proposed wording doesn't accomplish that. Proposed Disposition: Open
5912 <h3><a name="568"></a>568. log2 overloads missing</h3>
5913 <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
5914 <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
5915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
5916 <p><b>Discussion:</b></p>
5918 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
5922 Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
5926 <p><b>Proposed resolution:</b></p>
5928 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
5936 <h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
5937 <p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5938 <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
5939 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
5940 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
5941 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5942 <p><b>Discussion:</b></p>
5944 Currently, the Standard Library specifies only a declaration for template class
5945 char_traits<> and requires the implementation provide two explicit
5946 specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard
5947 should require explicit specializations for all built-in character types, i.e.
5948 char, wchar_t, unsigned char, and signed char.
5951 I have put together a paper
5952 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
5953 that describes this in more detail and
5954 includes all the necessary wording.
5957 Portland: Jack will rewrite
5958 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
5959 to propose a primary template that will work with other integral types.
5963 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
5974 We suggest that Jack be asked about the status of his paper, and if it
5975 is not forthcoming, the work-item be assigned to someone else. If no one
5976 steps forward to do the paper before the next meeting, we propose to
5977 make this NAD without further discussion. We leave this Open for now,
5978 but our recommendation is NAD.
5981 Note: the issue statement should be updated, as the Toronto comment has
5982 already been resolved. E.g., char_traits specializations for char16_t
5983 and char32_t are now in the working paper.
5989 <p><b>Proposed resolution:</b></p>
5996 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
5997 <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#Open">Open</a>
5998 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
5999 <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>
6000 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6001 <p><b>Discussion:</b></p>
6003 There are two deficiencies related to file sizes:
6006 <li>It doesn't appear that the Standard Library is specified in
6007 a way that handles modern file sizes, which are often too
6008 large to be represented by an unsigned long.</li>
6010 <li>The std::fpos class does not currently have the ability to
6011 set/get file positions.</li>
6014 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
6017 <li>Defining fpos_t be long long, which is large enough to
6018 represent any file position likely in the foreseeable future.</li>
6020 <li>Adding member functions to class fpos. For example,
6021 <blockquote><pre>fpos_t seekpos() const;
6026 Because there are so many types relating to file positions and offsets (fpos_t,
6027 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
6028 perhaps more), it is difficult to know if the Dinkumware extensions are
6029 sufficient. But they seem a useful starting place for discussions, and they do
6030 represent existing practice.
6034 Kona (2007): We need a paper. It would be nice if someone proposed
6035 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
6036 these definitions are horrible. Proposed Disposition: Open
6041 <p><b>Proposed resolution:</b></p>
6050 <h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
6051 <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#Ready">Ready</a>
6052 <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
6053 <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>
6054 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6055 <p><b>Discussion:</b></p>
6057 lib.iostream.objects requires that the standard stream objects are never
6058 destroyed, and it requires that they be destroyed.
6061 DR 369 adds words to say that we really mean for ios_base::Init objects to force
6062 construction of standard stream objects. It ends, though, with the phrase "these
6063 stream objects shall be destroyed after the destruction of dynamically ...".
6064 However, the rule for destruction is stated in the standard: "The objects are
6065 not destroyed during program execution."
6069 <p><b>Proposed resolution:</b></p>
6071 Change 27.3 [iostream.objects]/1:
6076 -2- The objects are constructed and the associations are established at
6077 some time prior to or during the first time an object of class
6078 <tt>ios_base::Init</tt> is constructed, and in any case before the body of main
6079 begins execution.<sup>290)</sup> The objects are not destroyed during program
6080 execution.<sup>291)</sup> If a translation unit includes <tt><iostream&t;</tt> or explicitly
6081 constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
6082 constructed before dynamic initialization of non-local objects defined
6083 later in that translation unit<del>, and these stream objects shall be
6084 destroyed after the destruction of dynamically initialized non-local
6085 objects defined later in that translation unit</del>.
6091 Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
6092 shall be destroyed after the destruction of dynamically initialized
6093 non-local objects defined later in that translation unit." Proposed
6102 <h3><a name="580"></a>580. unused allocator members</h3>
6103 <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#Open">Open</a>
6104 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6105 <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>
6106 <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>
6107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6108 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
6109 <p><b>Discussion:</b></p>
6112 C++ Standard Library templates that take an allocator as an argument
6113 are required to call the <code>allocate()</code> and
6114 <code>deallocate()</code> members of the allocator object to obtain
6115 storage. However, they do not appear to be required to call any other
6116 allocator members such as <code>construct()</code>,
6117 <code>destroy()</code>, <code>address()</code>, and
6118 <code>max_size()</code>. This makes these allocator members less than
6119 useful in portable programs.
6124 It's unclear to me whether the absence of the requirement to use these
6125 allocator members is an unintentional omission or a deliberate
6126 choice. However, since the functions exist in the standard allocator
6127 and since they are required to be provided by any user-defined
6128 allocator I believe the standard ought to be clarified to explictly
6129 specify whether programs should or should not be able to rely on
6130 standard containers calling the functions.
6135 I propose that all containers be required to make use of these
6140 Batavia: We support this resolution. Martin to provide wording.
6144 pre-Oxford: Martin provided wording.
6149 <p><b>Proposed resolution:</b></p>
6152 Specifically, I propose to change 23.1 [container.requirements],
6158 -9- Copy constructors for all container types defined in this clause
6159 <ins>that are parametrized on <code>Allocator</code></ins> copy
6160 <del>an</del><ins>the</ins> allocator argument from their respective
6163 All other constructors for these container types take a<del>n</del>
6164 <ins>const</ins> <code>Allocator&</code> argument (20.1.6), an
6165 allocator whose <code>value_type</code> is the same as the container's
6166 <code>value_type</code>.
6168 A copy of this argument <del>is</del><ins>shall be</ins> used for any
6169 memory allocation <ins> and deallocation</ins> performed<del>,</del>
6170 by these constructors and by all member functions<del>,</del> during
6171 the lifetime of each container object. <ins>Allocation shall be
6172 performed "as if" by calling the <code>allocate()</code> member
6173 function on a copy of the allocator object of the appropriate type
6174 <sup>New Footnote)</sup>, and deallocation "as if" by calling
6175 <code>deallocate()</code> on a copy of the same allocator object of
6176 the corresponding type.</ins>
6178 <ins>A copy of this argument shall also be used to construct and
6179 destroy objects whose lifetime is managed by the container, including
6180 but not limited to those of the container's <code>value_type</code>,
6181 and to obtain their address. All objects residing in storage
6182 allocated by a container's allocator shall be constructed "as if" by
6183 calling the <code>construct()</code> member function on a copy of the
6184 allocator object of the appropriate type. The same objects shall be
6185 destroyed "as if" by calling <code>destroy()</code> on a copy of the
6186 same allocator object of the same type. The address of such objects
6187 shall be obtained "as if" by calling the <code>address()</code> member
6188 function on a copy of the allocator object of the appropriate
6191 <ins>Finally, a copy of this argument shall be used by its container
6192 object to determine the maximum number of objects of the container's
6193 <code>value_type</code> the container may store at the same time. The
6194 container member function <code>max_size()</code> obtains this number
6195 from the value returned by a call to
6196 <code>get_allocator().max_size()</code>.</ins>
6198 In all container types defined in this clause <ins>that are
6199 parametrized on <code>Allocator</code></ins>, the member
6200 <code>get_allocator()</code> returns a copy of the
6201 <code>Allocator</code> object used to construct the
6202 container.<sup>258)</sup>
6205 New Footnote: This type may be different from <code>Allocator</code>:
6206 it may be derived from <code>Allocator</code> via
6207 <code>Allocator::rebind<U>::other</code> for the appropriate
6208 type <code>U</code>.
6213 The proposed wording seems cumbersome but I couldn't think of a better
6214 way to describe the requirement that containers use their
6215 <code>Allocator</code> to manage only objects (regardless of their
6216 type) that persist over their lifetimes and not, for example,
6217 temporaries created on the stack. That is, containers shouldn't be
6218 required to call <code>Allocator::construct(Allocator::allocate(1),
6219 elem)</code> just to construct a temporary copy of an element, or
6220 <code>Allocator::destroy(Allocator::address(temp), 1)</code> to
6221 destroy temporaries.
6227 Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
6232 post Oxford: This would be rendered NAD Editorial by acceptance of
6233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
6241 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
6242 <p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6243 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
6245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6246 <p><b>Discussion:</b></p>
6249 The specialized algorithms [lib.specialized.algorithms] are specified
6250 as having the general effect of invoking the following expression:
6254 new (static_cast<void*>(&*i))
6255 typename iterator_traits<ForwardIterator>::value_type (x)
6260 This expression is ill-formed when the type of the subexpression
6261 <code>&*i</code> is some volatile-qualified <code>T</code>.
6266 Batavia: Lack of support for proposed resolution but agree there is a
6267 defect. Howard to look at wording. Concern that move semantics
6268 properly expressed if iterator returns rvalue.
6274 <p><b>Proposed resolution:</b></p>
6277 In order to allow these algorithms to operate on volatile storage I
6278 propose to change the expression so as to make it well-formed even for
6279 pointers to volatile types. Specifically, I propose the following
6280 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
6286 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6287 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6289 for (; first != last; ++result, ++first)
6290 new (static_cast<void*>(const_cast<pointer>(&*result))
6291 value_type (*first);
6296 change 20.6.4.2, p1 to read
6302 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6303 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6305 for (; first != last; ++result, ++first)
6306 new (static_cast<void*>(const_cast<pointer>(&*first))
6312 and change 20.6.4.3, p1 to read
6318 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6319 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6321 for (; n--; ++first)
6322 new (static_cast<void*>(const_cast<pointer>(&*first))
6328 In addition, since there is no partial specialization for
6329 <code>iterator_traits<volatile T*></code> I propose to add one
6330 to parallel such specialization for <const T*>. Specifically, I
6331 propose to add the following text to the end of 24.3.1, p3:
6336 and for pointers to volatile as
6341 template<class T> struct iterator_traits<volatile T*> {
6342 typedef ptrdiff_t difference_type;
6343 typedef T value_type;
6344 typedef volatile T* pointer;
6345 typedef volatile T& reference;
6346 typedef random_access_iterator_tag iterator_category;
6353 Note that the change to <code>iterator_traits</code> isn't necessary
6354 in order to implement the specialized algorithms in a way that allows
6355 them to operate on volatile strorage. It is only necesassary in order
6356 to specify their effects in terms of <code>iterator_traits</code> as
6357 is done here. Implementations can (and some do) achieve the same
6358 effect by means of function template overloading.
6366 <h3><a name="585"></a>585. facet error reporting</h3>
6367 <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#Open">Open</a>
6368 <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
6369 <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>
6370 <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>
6371 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6372 <p><b>Discussion:</b></p>
6375 Section 22.2, paragraph 2 requires facet <code>get()</code> members
6376 that take an <code>ios_base::iostate&</code> argument,
6377 <code><i>err</i></code>, to ignore the (initial) value of the
6378 argument, but to set it to <code>ios_base::failbit</code> in case of a
6384 We believe there are a few minor problems with this blanket
6385 requirement in conjunction with the wording specific to each
6386 <code>get()</code> member function.
6391 First, besides <code>get()</code> there are other member functions
6392 with a slightly different name (for example,
6393 <code>get_date()</code>). It's not completely clear that the intent of
6394 the paragraph is to include those as well, and at least one
6395 implementation has interpreted the requirement literally.
6400 Second, the requirement to "set the argument to
6401 <code>ios_base::failbit</code> suggests that the functions are not
6402 permitted to set it to any other value (such as
6403 <code>ios_base::eofbit</code>, or even <code>ios_base::eofbit |
6404 ios_base::failbit</code>).
6409 However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and
6410 p6 (<code>bool</code> parsing) specifies that the <code>do_get</code>
6411 functions perform <code><i>err</i> |= ios_base::eofbit</code>, which
6412 contradicts the earlier requirement to ignore <i>err</i>'s initial
6418 22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code>
6419 facet's <code>do_get</code> member functions) also specifies that
6420 <code><i>err</i></code>'s initial value be used to compute the final
6421 value by ORing it with either <code>ios_base::failbit</code> or
6422 with<code>ios_base::eofbit | ios_base::failbit</code>.
6427 <p><b>Proposed resolution:</b></p>
6430 We believe the intent is for all facet member functions that take an
6431 <code>ios_base::iostate&</code> argument to:
6437 ignore the initial value of the <code><i>err</i></code> argument,
6442 reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior
6443 to any further processing,
6448 and set either <code>ios_base::eofbit</code>, or
6449 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
6450 appropriate, in response to reaching the end-of-file or on parse
6457 To that effect we propose to change 22.2, p2 as follows:
6462 The <i>put</i><del>()</del> members make no provision for error
6463 reporting. (Any failures of the OutputIterator argument must be
6464 extracted from the returned iterator.) <ins>Unless otherwise
6465 specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins>
6466 take an <code>ios_base::iostate&</code> argument <del>whose value
6467 they ignore, but set to ios_base::failbit in case of a parse
6468 error.</del><ins>, <code><i>err</i></code>, start by evaluating
6469 <code>err = ios_base::goodbit</code>, and may subsequently set
6470 <i>err</i> to either <code>ios_base::eofbit</code>, or
6471 <code>ios_base::failbit</code>, or <code>ios_base::eofbit |
6472 ios_base::failbit</code> in response to reaching the end-of-file or in
6473 case of a parse error, or both, respectively.</ins>
6479 Kona (2007): We need to change the proposed wording to clarify that the
6480 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
6481 Proposed Disposition: Open
6488 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
6489 <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6490 <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
6491 <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>
6492 <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>
6493 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6494 <p><b>Discussion:</b></p>
6496 The wording used for section 23.2.1 [lib.array] seems to be subtly
6497 ambiguous about zero sized arrays (N==0). Specifically:
6500 * "An instance of array<T, N> stores N elements of type T, so that
6504 Does this imply that a zero sized array object stores 0 elements, i.e.
6505 that it cannot store any element of type T? The next point clarifies
6506 the rationale behind this question, basically how to implement begin()
6510 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
6511 end() == unique value."
6514 What does "unique" mean in this context? Let's consider the following
6515 possible implementations, all relying on a partial specialization:
6518 template< typename T >
6519 class array< T, 0 > {
6524 { return iterator( reinterpret_cast< T * >( this ) ); }
6530 This has been used in boost, probably intending that the return value
6531 had to be unique to the specific array object and that array couldn't
6532 store any T. Note that, besides relying on a reinterpret_cast, has
6533 (more than potential) alignment problems.
6536 template< typename T >
6537 class array< T, 0 > {
6542 { return iterator( &t ); }
6548 This provides a value which is unique to the object and to the type of
6549 the array, but requires storing a T. Also, it would allow the user to
6550 mistakenly provide an initializer list with one element.
6553 A slight variant could be returning *the* null pointer of type T
6555 <blockquote><pre> return static_cast<T*>(0);
6558 In this case the value would be unique to the type array<T, 0> but not
6559 to the objects (all objects of type array<T, 0> with the same value
6560 for T would yield the same pointer value).
6563 Furthermore this is inconsistent with what the standard requires from
6564 allocation functions (see library issue 9).
6567 c) same as above but with t being a static data member; again, the
6568 value would be unique to the type, not to the object.
6571 d) to avoid storing a T *directly* while disallowing the possibility
6572 to use a one-element initializer list a non-aggregate nested class
6575 <blockquote><pre> struct holder { holder() {} T t; } h;
6578 and then begin be defined as
6580 <blockquote><pre> iterator begin() { return &h.t; }
6583 But then, it's arguable whether the array stores a T or not.
6587 -----------------------------------------------------
6590 Now, on different issues:
6593 * what's the effect of calling assign(T&) on a zero-sized array? There
6594 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
6595 p4 (I would also suggest to move that bullet to section 23.2.1.5
6596 [lib.array.zero], for locality of reference)
6599 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
6600 inconsistent with that of other sequences: that's not a problem in
6601 itself, but compare it for instance with "A vector is a kind of
6602 sequence that supports random access iterators"; though the intent is
6603 obvious one might argue that the wording used for arrays doesn't tell
6604 what an array is, and relies on the reader to infer that it is what
6605 the <array> header defines.
6608 * it would be desiderable to have a static const data member of type
6609 std::size_t, with value N, for usage as integral constant expression
6612 * section 23.1 [lib.container.requirements] seem not to consider
6613 fixed-size containers at all, as it says: "[containers] control
6614 allocation and deallocation of these objects [the contained objects]
6615 through constructors, destructors, *insert and erase* operations"
6618 * max_size() isn't specified: the result is obvious but, technically,
6619 it relies on table 80: "size() of the largest possible container"
6620 which, again, doesn't seem to consider fixed size containers
6624 <p><b>Proposed resolution:</b></p>
6630 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
6631 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
6632 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
6640 <h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3>
6641 <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#Ready">Ready</a>
6642 <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
6643 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
6644 <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>
6645 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6646 <p><b>Discussion:</b></p>
6648 TR1 introduced, in the C compatibility chapter, the function
6649 fabs(complex<T>):
6651 <blockquote><pre>----- SNIP -----
6652 8.1.1 Synopsis [tr.c99.cmplx.syn]
6657 template<class T> complex<T> fabs(const complex<T>& x);
6663 8.1.8 Function fabs [tr.c99.cmplx.fabs]
6665 1 Effects: Behaves the same as C99 function cabs, defined in
6671 The current C++0X draft document (n2009.pdf) adopted this
6672 definition in chapter 26.3.1 (under the comment // 26.3.7 values)
6676 But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
6677 n1124), the referenced subclause reads
6680 <blockquote><pre>----- SNIP -----
6681 7.3.8.1 The cabs functions
6685 1 #include <complex.h>
6686 double cabs(double complex z);
6687 float cabsf(float complex z);
6688 long double cabsl(long double z);
6692 2 The cabs functions compute the complex absolute value (also called
6693 norm, modulus, or magnitude) of z.
6697 3 The cabs functions return the complex absolute value.
6702 Note that the return type of the cabs*() functions is not a complex
6703 type. Thus, they are equivalent to the already well established
6704 template<class T> T abs(const complex<T>& x);
6705 (26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
6706 document n2009.pdf).
6709 So either the return value of fabs() is specified wrongly, or fabs()
6710 does not behave the same as C99's cabs*().
6713 <b>Possible Resolutions</b>
6716 This depends on the intention behind the introduction of fabs().
6719 If the intention was to provide a /complex/ valued function that
6720 calculates the magnitude of its argument, this should be
6721 explicitly specified. In TR1, the categorization under "C
6722 compatibility" is definitely wrong, since C99 does not provide
6723 such a complex valued function.
6726 Also, it remains questionable if such a complex valued function
6727 is really needed, since complex<T> supports construction and
6728 assignment from real valued arguments. There is no difference
6729 in observable behaviour between
6731 <blockquote><pre> complex<double> x, y;
6733 complex<double> z(fabs(x));
6738 <blockquote><pre> complex<double> x, y;
6740 complex<double> z(abs(x));
6743 If on the other hand the intention was to provide the intended
6744 functionality of C99, fabs() should be either declared deprecated
6745 or (for C++0X) removed from the standard, since the functionality
6746 is already provided by the corresponding overloads of abs().
6755 Bill believes that abs() is a suitable overload. We should remove fabs().
6759 <p><b>Proposed resolution:</b></p>
6762 Change the synopsis in 26.3.1 [complex.synopsis]:
6765 <blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del>
6769 Remove 26.3.7 [complex.value.ops], p7:
6773 <pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del>
6777 <del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
6785 Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
6786 Proposed Disposition: Ready
6794 <h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
6795 <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#Ready">Ready</a>
6796 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
6797 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
6798 <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>
6799 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6800 <p><b>Discussion:</b></p>
6802 In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
6804 <blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
6807 and we expect the open to fail, because out|in|app is not listed in
6808 Table 92, and just before the table we see very specific words:
6811 If mode is not some combination of flags shown in the table
6812 then the open fails.
6815 But the corresponding table in the C standard, 7.19.5.3, provides two
6816 modes "a+" and "a+b", to which the C++ modes out|in|app and
6817 out|in|app|binary would presumably apply.
6820 We would like to argue that the intent of Table 112 was to match the
6821 semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
6822 unintentional. (Otherwise there would be valid and useful behaviors
6823 available in C file I/O which are unavailable using C++, for no
6824 valid functional reason.)
6827 We further request that the missing modes be explicitly restored to
6828 the WP, for inclusion in C++0x.
6837 ...besides "a+" and "a+b" the C++ table is also missing a row
6838 for a lone app bit which in at least two current implementation
6839 as well as in Classic Iostreams corresponds to the C stdio "a"
6840 mode and has been traditionally documented as implying ios::out.
6841 Which means the table should also have a row for in|app meaning
6842 the same thing as "a+" already proposed in the issue.
6846 <p><b>Proposed resolution:</b></p>
6848 Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
6853 <caption> File open modes</caption>
6855 <th colspan="5"><tt>ios_base</tt> Flag combination</th>
6856 <th><tt>stdio</tt> equivalent</th>
6859 <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>
6863 <td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"w"</tt></td>
6866 <td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
6869 <td> </td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
6872 <td> </td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w"</tt></td>
6875 <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"r"</tt></td>
6878 <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+"</tt></td>
6881 <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+"</tt></td>
6884 <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>
6887 <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>
6891 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"wb"</tt></td>
6894 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
6897 <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>
6900 <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"wb"</tt></td>
6903 <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"rb"</tt></td>
6906 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+b"</tt></td>
6909 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+b"</tt></td>
6911 <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>
6914 <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>
6924 Kona (2007) Added proposed wording and moved to Review.
6932 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
6933 <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#Open">Open</a>
6934 <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
6935 <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>
6936 <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>
6937 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6938 <p><b>Discussion:</b></p>
6940 In a private email, Daveed writes:
6944 I am not familiar with the C TR, but my guess is that the
6945 class type approach still won't match a built-in type
6946 approach because the notion of "promotion" cannot be
6947 emulated by user-defined types.
6955 S(_Decimal32 const&); // Converting constructor
6961 void g(_Decimal32 d) {
6968 If _Decimal32 is a built-in type, the call f(d) will likely
6969 resolve to f(_Decimal64) because that requires only a
6970 promotion, whereas f(S) requires a user-defined conversion.
6973 If _Decimal32 is a class type, I think the call f(d) will be
6974 ambiguous because both the conversion to _Decimal64 and the
6975 conversion to S will be user-defined conversions with neither
6976 better than the other.
6983 In general, a library of arithmetic types cannot exactly emulate the
6984 behavior of the intrinsic numeric types. There are several ways to tell
6985 whether an implementation of the decimal types uses compiler
6986 intrinisics or a library. For example:
6988 <pre> _Decimal32 d1;
6989 d1.operator+=(5); // If d1 is a builtin type, this won't compile.
6992 In preparing the decimal TR, we have three options:
6995 <li>require that the decimal types be class types</li>
6996 <li>require that the decimal types be builtin types, like float and double</li>
6997 <li>specify a library of class types, but allow enough implementor
6998 latitude that a conforming implementation could instead provide builtin
7002 We decided as a group to pursue option #3, but that approach implies
7003 that implementations may not agree on the semantics of certain use
7004 cases (first example, above), or on whether certain other cases are
7005 well-formed (second example). Another potentially important problem is
7006 that, under the present definition of POD, the decimal classes are not
7007 POD types, but builtins will be.
7009 <p>Note that neither example above implies any problems with respect to
7010 C-to-C++ compatibility, since neither example can be expressed in C.
7014 <p><b>Proposed resolution:</b></p>
7021 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
7022 <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#Open">Open</a>
7023 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
7024 <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>
7025 <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>
7026 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7027 <p><b>Discussion:</b></p>
7029 In c++std-lib-17205, Martin writes:
7031 <blockquote><p>...was it a deliberate design choice to make narrowing
7032 assignments ill-formed while permitting narrowing compound assignments?
7035 <pre> decimal32 d32;
7042 In c++std-lib-17229, Robert responds:
7044 <blockquote><p>It is a vestige of an old idea that I forgot to remove
7045 from the paper. Narrowing assignments should be permitted. The bug is
7046 that the converting constructors that cause narrowing should not be
7047 explicit. Thanks for pointing this out.
7050 <p><b>Proposed resolution:</b></p>
7052 1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
7054 <pre> // <i>3.2.2.2 conversion from floating-point type:</i>
7055 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
7056 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
7059 2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
7062 3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
7064 <pre> // <i>3.2.3.2 conversion from floating-point type:</i>
7065 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
7068 4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
7072 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
7081 <h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
7082 <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#Ready">Ready</a>
7083 <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
7084 <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>
7085 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7086 <p><b>Discussion:</b></p>
7088 18.2.1.2 55 states that "A type is modulo if it is possible to add two
7089 positive numbers together and have a result that wraps around to a
7090 third number that is less".
7091 This seems insufficient for the following reasons:
7095 <li>Doesn't define what that value received is.</li>
7096 <li>Doesn't state the result is repeatable</li>
7097 <li> Doesn't require that doing addition, subtraction and other
7098 operations on all values is defined behaviour.</li>
7103 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
7104 Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined.
7109 Bellevue: accept resolution, move to ready status.
7110 Does this mandate that is_modulo be true on platforms for which int
7111 happens to b modulo? A: the standard already seems to require that.
7116 <p><b>Proposed resolution:</b></p>
7118 Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to:
7122 A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
7123 and have a result that wraps around to a third number that is less.</del>
7124 <ins>given any operation involving +,- or * on values of that type whose value
7125 would fall outside the range <tt>[min(), max()]</tt>, then the value returned
7126 differs from the true value by an integer multiple of <tt>(max() - min() +
7136 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
7137 <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#Open">Open</a>
7138 <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
7139 <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>
7140 <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>
7141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7142 <p><b>Discussion:</b></p>
7144 This is based on N2134, where 21.3.1/2 states:
7145 "... The Allocator object used shall be a copy of the Allocator object
7146 passed to the basic_string object's constructor or, if the constructor does
7147 not take an Allocator argument, a copy of a default-constructed Allocator
7151 Section 21.3.2/1 lists two constructors:
7153 <blockquote><pre>basic_string(const basic_string<charT,traits,Allocator>& str );
7155 basic_string(const basic_string<charT,traits,Allocator>& str ,
7156 size_type pos , size_type n = npos,
7157 const Allocator& a = Allocator());
7160 and then says "In the first form, the Allocator value used is copied from
7161 str.get_allocator().", which isn't an option according to 21.3.1.
7164 Batavia: We need blanket statement to the effect of:
7169 <li>If an allocator is passed in, use it, or,</li>
7170 <li>If a string is passed in, use its allocator.</li>
7173 Review constructors and functions that return a string; make sure we follow these
7174 rules (substr, operator+, etc.). Howard to supply wording.
7179 Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not
7180 consistent with 23.1 [container.requirements], p9 which says in part:
7183 All other constructors for these container types take an
7184 <tt>Allocator&</tt> argument (20.1.2), an allocator whose value type
7185 is the same as the container's value type. A copy of this argument is
7186 used for any memory allocation performed, by these constructors and by
7187 all member functions, during the lifetime of each container object.
7193 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
7199 <p><b>Proposed resolution:</b></p>
7208 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
7209 <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7210 <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
7211 <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>
7212 <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>
7213 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7214 <p><b>Discussion:</b></p>
7216 The <tt><array></tt> header is given under 23.2 [sequences].
7217 23.2.1 [array]/paragraph 3 says:
7220 "Unless otherwise specified, all array operations are as described in
7221 23.1 [container.requirements]".
7224 However, array isn't mentioned at all in section 23.1 [container.requirements].
7225 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
7226 that std::array does not have in 23.2.1 [array].
7229 Also, Table 83 "Optional sequence operations" lists several operations that
7230 std::array does have, but array isn't mentioned.
7234 <p><b>Proposed resolution:</b></p>
7243 <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
7244 <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#Ready">Ready</a>
7245 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
7246 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7247 <p><b>Discussion:</b></p>
7249 I would respectfully request an issue be opened with the intention to
7250 clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
7254 <p><b>Proposed resolution:</b></p>
7256 Change 26.5.2.7 [valarray.members], paragraph 10:
7261 <pre>valarray<T> cshift(int <i>n</i>) const;
7266 This function returns an object of class <tt>valarray<T></tt>, of
7267 length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
7268 <tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
7269 the leftmost element, a positive value of <i>n</i> shifts the elements
7270 circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
7271 element zero is taken as the leftmost element, a non-negative value of
7272 <i>n</i> shifts the elements circularly left <i>n</i> places and a
7273 negative value of <i>n</i> shifts the elements circularly right
7274 -<i>n</i> places.</ins>
7281 <p><b>Rationale:</b></p>
7283 We do not believe that there is any real ambiguity about what happens
7284 when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
7285 expression causes more trouble that it solves. The expression is
7286 certainly wrong when <tt>n < 0</tt>, since the sign of % with negative arguments
7287 is implementation defined.
7292 Kona (2007) Changed proposed wording, added rationale and set to Review.
7300 <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
7301 <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#Ready">Ready</a>
7302 <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
7303 <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>
7304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7305 <p><b>Discussion:</b></p>
7307 is there an issue opened for (0,3) as complex number with
7308 the French local? With the English local, the above parses as an
7309 imaginery complex number. With the French locale it parses as a
7310 real complex number.
7314 Further notes/ideas from the lib-reflector, messages 17982-17984:
7319 Add additional entries in num_punct to cover the complex separator (French would be ';').
7322 Insert a space before the comma, which should eliminate the ambiguity.
7325 Solve the problem for ordered sequences in general, perhaps with a
7326 dedicated facet. Then complex should use that solution.
7337 After much discussion, we agreed on the following: Add a footnote:
7340 [In a locale in which comma is being used as a decimal point character,
7341 inserting "showbase" into the output stream forces all outputs to show
7342 an explicit decimal point character; then all inserted complex sequences
7343 will extract unambiguously.]
7346 And move this to READY status.
7351 <p><b>Proposed resolution:</b></p>
7353 Add a footnote to 26.3.6 [complex.ops] p16:
7357 [In a locale in which comma is being used as a decimal point character,
7358 inserting "showbase" into the output stream forces all outputs to show
7359 an explicit decimal point character; then all inserted complex sequences
7360 will extract unambiguously.]
7368 <h3><a name="630"></a>630. arrays of valarray</h3>
7369 <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#Open">Open</a>
7370 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
7371 <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>
7372 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7373 <p><b>Discussion:</b></p>
7376 Section 26.1 [numeric.requirements], p1 suggests that a
7377 <code>valarray</code> specialization on a type <code>T</code> that
7378 satisfies the requirements enumerated in the paragraph is itself a
7379 valid type on which <code>valarray</code> may be instantiated
7380 (Footnote 269 makes this clear). I.e.,
7381 <code>valarray<valarray<T> ></code> is valid as long as
7382 <code>T</code> is valid. However, since implementations of
7383 <code>valarray</code> are permitted to initialize storage allocated by
7384 the class by invoking the default ctor of <code>T</code> followed by
7385 the copy assignment operator, such implementations of
7386 <code>valarray</code> wouldn't work with (perhaps user-defined)
7387 specializations of <code>valarray</code> whose assignment operator had
7388 undefined behavior when the size of its argument didn't match the size
7389 of <code>*this</code>. By <i>"wouldn't work"</i> I mean that it would
7390 be impossible to resize such an array of arrays by calling the
7391 <code>resize()</code> member function on it if the function used the
7392 copy assignment operator after constructing all elements using the
7393 default ctor (e.g., by invoking <code>new value_type[N]</code>) to
7394 obtain default-initialized storage) as it's permitted to do.
7399 Stated more generally, the problem is that
7400 <code>valarray<valarray<T> >::resize(size_t)</code> isn't
7401 required or guaranteed to have well-defined semantics for every type
7402 <code>T</code> that satisfies all requirements in
7403 26.1 [numeric.requirements].
7408 I believe this problem was introduced by the adoption of the
7409 resolution outlined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
7410 <i>Assignment of valarrays</i>, from 1996. The copy assignment
7411 operator of the original numerical array classes proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
7412 as well as the one proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
7413 (both from 1993), had well-defined semantics for arrays of unequal
7414 size (the latter explicitly only when <code>*this</code> was empty;
7415 assignment of non empty arrays of unequal size was a runtime error).
7420 The justification for the change given in N0857 was the "loss of
7421 performance [deemed] only significant for very simple operations on
7422 small arrays or for architectures with very few registers."
7427 Since tiny arrays on a limited subset of hardware architectures are
7428 likely to be an exceedingly rare case (despite the continued
7429 popularity of x86) I propose to revert the resolution and make the
7430 behavior of all <code>valarray</code> assignment operators
7431 well-defined even for non-conformal arrays (i.e., arrays of unequal
7432 size). I have implemented this change and measured no significant
7433 degradation in performance in the common case (non-empty arrays of
7434 equal size). I have measured a 50% (and in some cases even greater)
7435 speedup in the case of assignments to empty arrays versus calling
7436 <code>resize()</code> first followed by an invocation of the copy
7437 assignment operator.
7447 If no proposed wording by June meeting, this issue should be closed NAD.
7452 <p><b>Proposed resolution:</b></p>
7455 Change 26.5.2.2 [valarray.assign], p1 as follows:
7462 valarray<T>& operator=(const valarray<T>&<ins> x</ins>);
7468 -1- Each element of the <code>*this</code> array is assigned the value
7469 of the corresponding element of the argument array. <del>The
7470 resulting behavior is undefined if </del><ins>When </ins>the length of
7471 the argument array is not equal to the length of the *this
7472 array<del>.</del><ins> resizes <code>*this</code> to make the two
7473 arrays the same length, as if by calling
7474 <code>resize(x.size())</code>, before performing the assignment.</ins>
7480 And add a new paragraph just below paragraph 1 with the following
7487 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
7493 Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
7499 <ins>-?- When the length, <i><code>N</code></i> of the array referred
7500 to by the argument is not equal to the length of <code>*this</code>,
7501 the operator resizes <code>*this</code> to make the two arrays the
7502 same length, as if by calling <code>resize(<i>N</i>)</code>, before
7503 performing the assignment.</ins>
7510 Kona (2007): Gaby to propose wording for an alternative resolution in
7511 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
7512 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
7520 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
7521 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7522 <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
7523 <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>
7524 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7525 <p><b>Discussion:</b></p>
7527 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
7528 some functions. In particular, it says that:
7532 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
7533 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
7534 iterator arguments, it should work correctly in the construct <tt>if
7535 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
7536 <tt>BinaryPredicate</tt> always takes the first iterator type as its
7537 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
7538 part of the signature, it should work correctly in the context of <tt>if
7539 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
7543 In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
7544 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
7545 element of the sequence (a result of dereferencing
7546 <tt>*<i>first</i></tt>).
7550 In the description of <tt>lexicographical_compare</tt>, we have both
7551 "<tt>*<i>first1</i> < *<i>first2</i></tt>" and "<tt>*<i>first2</i>
7552 < *<i>first1</i></tt>" (which presumably implies "<tt>comp(
7553 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
7554 *<i>first1</i> )</tt>".
7558 Toronto: Moved to Open. ConceptGCC seems to get <tt>lower_bound</tt>
7559 and <tt>upper_bound</tt> to work withoutt these changes.
7565 <p><b>Proposed resolution:</b></p>
7567 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
7568 relationship, with the semantics of "less than". Depending on the
7569 function, it may be used to determine equality, or any of the inequality
7570 relationships; doing this requires being able to use it with either
7571 parameter first. I would thus suggest that the requirement be:
7575 [...] <tt>BinaryPredicate</tt> always takes the first iterator
7576 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
7577 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
7578 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
7579 iterator arguments, it should work correctly both in the construct
7580 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
7581 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>. In
7582 those cases when <tt>T <i>value</i></tt> is part of the signature, it
7583 should work correctly in the context of <tt>if (binary_pred
7584 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
7585 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
7586 types are not identical, and neither is convertable to the other, this
7587 may require that the <tt>BinaryPredicate</tt> be a functional object
7588 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
7592 Alternatively, one could specify an order for each function. IMHO, this
7593 would be more work for the committee, more work for the implementors,
7594 and of no real advantage for the user: some functions, such as
7595 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
7596 functions, and it seems like a much easier rule to teach that both
7597 functions are always required, rather than to have a complicated list of
7598 when you only need one, and which one.
7606 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
7607 <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#Open">Open</a>
7608 <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
7609 <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>
7610 <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>
7611 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7612 <p><b>Discussion:</b></p>
7614 A recent news group discussion:
7618 Anyone know if the Standard has anything to say about the time complexity
7619 of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily
7620 during an algorithm and was thus wondering whether I'd be better off
7621 tracking the size "manually" or whether that'd be pointless.
7624 That would be pointless. size() is O(1).
7627 Nit: the standard says "should" have constant time. Implementations may take
7628 license to do worse. I know that some do this for <tt>std::list<></tt> as a part of
7629 some trade-off with other operation.
7633 I was aware of that, hence my reluctance to use size() for std::set.
7636 However, this reason would not apply to <tt>std::set<></tt> as far as I can see.
7639 Ok, I guess the only option is to try it and see...
7644 If I have any recommendation to the C++ Standards Committee it is that
7645 implementations must (not "should"!) document clearly[1], where known, the
7646 time complexity of *all* container access operations.
7649 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
7650 for std::set is not documented... but if it is it's certainly well hidden
7656 <p><b>Proposed resolution:</b></p>
7662 Kona (2007): This issue affects all the containers. We'd love to see a
7663 paper dealing with the broad issue. We think that the complexity of the
7664 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
7665 O(1). Alan has volunteered to provide wording.
7675 Mandating O(1) size will not fly, too many implementations would be
7676 invalidated. Alan to provide wording that toughens wording, but that
7677 does not absolutely mandate O(1).
7684 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
7685 <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#Open">Open</a>
7686 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
7687 <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>
7688 <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>
7689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7690 <p><b>Discussion:</b></p>
7692 The table of allocator requirements in 20.1.2 [allocator.requirements] describes
7693 <tt>allocator::address</tt> as:
7695 <blockquote><pre>a.address(r)
7699 where <tt>r</tt> and <tt>s</tt> are described as:
7702 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
7710 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
7711 where <tt>a1 == a</tt>
7715 This all implies that to get the address of some value of type <tt>T</tt> that
7716 value must have been allocated by this allocator or a copy of it.
7720 However sometimes container code needs to compare the address of an external value of
7721 type <tt>T</tt> with an internal value. For example <tt>list::remove(const T& t)</tt>
7722 may want to compare the address of the external value <tt>t</tt> with that of a value
7723 stored within the list. Similarly <tt>vector</tt> or <tt>deque insert</tt> may
7724 want to make similar comparisons (to check for self-referencing calls).
7728 Mandating that <tt>allocator::address</tt> can only be called for values which the
7729 allocator allocated seems overly restrictive.
7734 <p><b>Proposed resolution:</b></p>
7736 Change 20.1.2 [allocator.requirements]:
7741 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
7744 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
7745 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
7750 post Oxford: This would be rendered NAD Editorial by acceptance of
7751 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
7756 Kona (2007): This issue is section 8 of N2387. There was some discussion of it but
7757 no resolution to this issue was recorded. Moved to Open.
7767 <h3><a name="638"></a>638. deque end invalidation during erase</h3>
7768 <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#Ready">Ready</a>
7769 <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
7770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7771 <p><b>Discussion:</b></p>
7773 The standard states at 23.2.2.3 [deque.modifiers]/4:
7775 <blockquote><pre>deque erase(...)
7778 <i>Effects:</i> ... An erase at either end of the deque invalidates only
7779 the iterators and the references to the erased elements.
7783 This does not state that iterators to end will be invalidated.
7784 It needs to be amended in such a way as to account for end invalidation.
7790 Any time the last element is erased, iterators to end are invalidated.
7794 This would handle situations like:
7796 <blockquote><pre>erase(begin(), end())
7799 resize(n, ...) where n < size()
7800 pop_front() with size() == 1
7805 Post Kona, Steve LoBasso notes:
7810 My only issue with the proposed resolution is that it might not be clear
7811 that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
7817 <p><b>Proposed resolution:</b></p>
7819 Change 23.2.2.3 [deque.modifiers], p4:
7823 <pre>iterator erase(const_iterator position);
7824 iterator erase(const_iterator first, const_iterator last);
7829 -4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
7830 invalidates all the iterators and references to elements of the
7831 <tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
7832 either end of the <tt>deque</tt> invalidates only the iterators and the
7833 references to the erased elements<ins>, except that erasing at the end
7834 also invalidates the past-the-end iterator</ins>.
7842 Kona (2007): Proposed wording added and moved to Review.
7852 Note that there is existing code that relies on iterators not being
7853 invalidated, but there are also existing implementations that do
7854 invalidate iterators. Thus, such code is not portable in any case. There
7855 is a pop_front() note, which should possibly be a separate issue. Mike
7856 Spertus to evaluate and, if need be, file an issue.
7863 <h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3>
7864 <p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7865 <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
7866 <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>
7867 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7868 <p><b>Discussion:</b></p>
7870 Greg Herlihy has clearly demonstrated that a user defined input
7871 iterator should have an operator->(), even if its
7872 value type is a built-in type (comp.std.c++, "Re: Should any iterator
7873 have an operator->() in C++0x?", March 2007). And as Howard
7874 Hinnant remarked in the same thread that the input iterator
7875 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
7879 Based on Greg's example, the following code demonstrates the issue:
7880 </p><pre> #include <iostream>
7881 #include <fstream>
7882 #include <streambuf>
7887 std::ifstream s("filename", std::ios::in);
7888 std::istreambuf_iterator<char> i(s);
7890 (*i).~C(); // This is well-formed...
7891 i->~C(); // ... so this should be supported!
7896 Of course, operator-> is also needed when the value_type of
7897 istreambuf_iterator is a class.
7900 The operator-> could be implemented in various ways. For instance,
7901 by storing the current value inside the iterator, and returning its
7902 address. Or by returning a proxy, like operator_arrow_proxy, from
7903 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
7906 I hope that the resolution of this issue will contribute to getting a
7907 clear and consistent definition of iterator concepts.
7911 <p><b>Proposed resolution:</b></p>
7913 Add to the synopsis in 24.5.3 [istreambuf.iterator]:
7916 <blockquote><pre>charT operator*() const;
7917 <ins>pointer operator->() const;</ins>
7918 istreambuf_iterator<charT,traits>& operator++();
7922 Change 24.5.3 [istreambuf.iterator], p1:
7926 The class template <tt>istreambuf_iterator</tt> reads successive
7927 characters from the <tt>streambuf</tt> for which it was constructed.
7928 <tt>operator*</tt> provides access to the current input character, if
7929 any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time
7930 <tt>operator++</tt> is evaluated, the iterator advances to the next
7931 input character. If the end of stream is reached
7932 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
7933 iterator becomes equal to the end of stream iterator value. The default
7934 constructor <tt>istreambuf_iterator()</tt> and the constructor
7935 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
7936 object suitable for use as an end-of-range.
7942 Kona (2007): The proposed resolution is inconsistent because the return
7943 type of <tt>istreambuf_iterator::operator->()</tt> is specified to be <tt>pointer</tt>,
7944 but the proposed text also states that "<tt>operator-></tt> may return a proxy."
7949 Niels Dekker (mailed to Howard Hinnant):
7954 The proposed resolution does
7955 not seem inconsistent to me. <tt>istreambuf_iterator::operator->()</tt> should
7956 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
7957 may in fact be a proxy.
7960 AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
7961 unspecified for some iterator categories") implies that for any iterator
7962 class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by
7963 definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
7966 Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would
7967 be removed from the resolution. I think it's up to the library
7968 implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As
7969 longs as it behaves as expected: <tt>i->m</tt> should have the same effect as
7970 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue
7971 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>!
7979 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
7980 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7981 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7982 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
7983 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
7984 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7985 <p><b>Discussion:</b></p>
7987 22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
7991 The result is returned as an integral value
7992 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
7993 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
7994 from '0' through '9', inclusive) stored in <tt>digits</tt>.
7999 objection has been raised:
8003 Some implementations interpret this to mean that a facet derived from
8004 <tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
8005 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
8006 <tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
8007 implementations have assumed that one or more places in the standard permit the
8008 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
8009 both interpretations permissible, or only one?
8013 [Plum ref _222612Y14]
8017 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
8018 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
8022 Kona (2007): Bill and Dietmar to provide proposed wording.
8027 post Bellevue: Bill adds:
8032 The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
8033 The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
8034 which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
8035 the widened characters are not relevant to the parsing of the subject string.
8039 <p><b>Proposed resolution:</b></p>
8048 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
8049 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8050 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8051 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
8052 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
8053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8054 <p><b>Discussion:</b></p>
8056 22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
8060 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
8061 optional, and if no sign is detected, the result is given the sign
8062 that corresponds to the source of the empty string.
8067 objection has been raised:
8071 A <tt>negative_sign</tt> of "" means "there is no
8072 way to write a negative sign" not "any null sequence is a negative
8073 sign, so it's always there when you look for it".
8077 [Plum ref _222612Y32]
8081 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
8087 <p><b>Proposed resolution:</b></p>
8096 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
8097 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8098 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8099 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
8100 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
8101 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8102 <p><b>Discussion:</b></p>
8104 22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
8108 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
8109 or if both strings are empty, the result is given a positive sign.
8113 One interpretation is that an input sequence must match either the
8114 positive pattern or the negative pattern, and then in either event it
8115 is interpreted as positive. The following objections has been raised:
8119 The input can successfully match only a positive sign, so the negative
8120 pattern is an unsuccessful match.
8124 [Plum ref _222612Y34, 222612Y51b]
8128 Bill to provide proposed wording and interpretation of existing wording.
8134 <p><b>Proposed resolution:</b></p>
8143 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
8144 <p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8145 <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8146 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8147 <p><b>Discussion:</b></p>
8149 22.2.6.3 [locale.moneypunct], para 2 says:
8153 The value <tt>space</tt> indicates that at least one space is required at
8158 The following objection has been raised:
8162 Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
8166 [Plum ref _22263Y22]
8170 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
8171 ambiguous, and that we want C++0X to say "space" means 0 or more
8172 whitespace characters on input.
8178 <p><b>Proposed resolution:</b></p>
8187 <h3><a name="671"></a>671. precision of hexfloat</h3>
8188 <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#Open">Open</a>
8189 <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
8190 <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>
8191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8192 <p><b>Discussion:</b></p>
8194 I am trying to understand how TR1 supports hex float (%a) output.
8197 As far as I can tell, it does so via the following:
8200 8.15 Additions to header <locale> [tr.c99.locale]
8203 In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
8205 floatfield == ios_base::scientific %E
8210 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
8211 floatfield == ios_base::fixed | ios_base::scientific %A 2
8214 [Note: The additional requirements on print and scan functions, later
8215 in this clause, ensure that the print functions generate hexadecimal
8216 floating-point fields with a %a or %A conversion specifier, and that
8217 the scan functions match hexadecimal floating-point fields with a %g
8218 conversion specifier. end note]
8221 Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
8224 For conversion from a floating-point type, if (flags & fixed) != 0 or
8225 if str.precision() > 0, then str.precision() is specified in the
8226 conversion specification.
8229 This would seem to imply that when floatfield == fixed|scientific, the
8230 precision of the conversion specifier is to be taken from
8231 str.precision(). Is this really what's intended? I sincerely hope
8232 that I'm either missing something or this is an oversight. Please
8233 tell me that the committee did not intend to mandate that hex floats
8234 (and doubles) should by default be printed as if by %.6a.
8238 Howard: I think the fundamental issue we overlooked was that with %f,
8239 %e, %g, the default precision was always 6. With %a the default
8240 precision is not 6, it is infinity. So for the first time, we need to
8241 distinguish between the default value of precision, and the precision
8248 <p><b>Proposed resolution:</b></p>
8254 Kona (2007): Robert volunteers to propose wording.
8262 <h3><a name="672"></a>672. Swappable requirements need updating</h3>
8263 <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#Ready">Ready</a>
8264 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
8265 <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>
8266 <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>
8267 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8268 <p><b>Discussion:</b></p>
8270 The current <tt>Swappable</tt> is:
8275 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
8276 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
8277 <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
8278 held by <tt>t</tt></td></tr>
8279 <tr><td colspan="3">
8281 The Swappable requirement is met by satisfying one or more of the following conditions:
8285 <tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
8286 and the <tt>CopyAssignable</tt> requirements (Table 36);
8289 <tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
8290 namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
8291 and has the semantics described in this table.
8299 With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
8300 require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum.
8304 Additionally we may want to support proxy references such that the following code is acceptable:
8307 <blockquote><pre>namespace Mine {
8309 template <class T>
8312 template <class T>
8313 struct proxied_iterator
8315 typedef T value_type;
8316 typedef proxy<T> reference;
8317 reference operator*() const;
8323 // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
8328 void swap(A&, A&);
8329 void swap(proxy<A>, A&);
8330 void swap(A&, proxy<A>);
8331 void swap(proxy<A>, proxy<A>);
8337 Mine::proxied_iterator<Mine::A> i(...)
8343 I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
8344 itself. We do not need to anything in terms of implementation except not block their way with overly
8345 constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
8346 between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
8351 <p><b>Proposed resolution:</b></p>
8354 Change 20.1.1 [utility.arg.requirements]:
8360 -1- The template definitions in the C++ Standard Library refer to various
8361 named requirements whose details are set out in tables 31-38. In these
8362 tables, <tt>T</tt> is a type to be supplied by a C++ program
8363 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8364 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
8365 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
8366 <tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
8367 rvalue of type <tt>T</tt>.
8371 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
8372 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
8373 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
8374 <td><tt>t</tt> has the value originally
8375 held by <tt>u</tt>, and
8376 <tt>u</tt> has the value originally held
8377 by <tt>t</tt></td></tr>
8378 <tr><td colspan="3">
8380 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
8384 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
8385 <del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
8386 requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
8387 requirements (Table <del>36</del> <ins>35</ins>);
8390 <tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
8391 <tt>swap</tt> exists in the same namespace as the definition of
8392 <tt>T</tt>, such that the expression
8393 <tt>swap(t,u)</tt> is valid and has the
8394 semantics described in this table.
8404 Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
8405 move semantics. The issue relating to the support of proxies is
8406 separable from the one relating to move semantics, and it's bigger than
8407 just swap. We'd like to address only the move semantics changes under
8408 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
8409 may be a third issue, in that the current definition of <tt>Swappable</tt> does
8410 not permit rvalues to be operands to a swap operation, and Howard's
8411 proposed resolution would allow the right-most operand to be an rvalue,
8412 but it would not allow the left-most operand to be an rvalue (some swap
8413 functions in the library have been overloaded to permit left operands to
8414 swap to be rvalues).
8422 <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
8423 <p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
8424 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
8425 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
8426 <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>
8427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
8428 <p><b>Discussion:</b></p>
8430 Since the publication of
8431 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
8432 there have been a few small but significant advances which should be included into
8433 <tt>unique_ptr</tt>. There exists a
8434 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
8435 for all of these changes.
8442 Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>),
8443 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt>
8444 even if it is never used. For example see
8445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
8446 happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
8447 type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with
8448 <tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt>
8449 the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
8450 This is simpler than creating a <tt>unique_ptr<void></tt> specialization which isn't robust in the
8451 face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
8455 This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt>
8456 which could be very useful to the client.
8463 Efforts have been made to better support containers and smart pointers in shared
8464 memory contexts. One of the key hurdles in such support is not assuming that a
8465 pointer type is actually a <tt>T*</tt>. This can easily be accomplished
8466 for <tt>unique_ptr</tt> by having the deleter define the pointer type:
8467 <tt>D::pointer</tt>. Furthermore this type can easily be defaulted to
8468 <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
8469 type (example implementation
8470 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
8471 This change has no run time overhead. It has no interface overhead on
8472 authors of custom delter types. It simply allows (but not requires)
8473 authors of custom deleter types to define a smart pointer for the
8474 storage type of <tt>unique_ptr</tt> if they find such functionality
8475 useful. <tt>std::default_delete</tt> is an example of a deleter which
8476 defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
8477 and not including a <tt>pointer typedef</tt>.
8483 When the deleter type is a function pointer then it is unsafe to construct
8484 a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
8485 This case is easy to check for with a <tt>static_assert</tt> assuring that the
8486 deleter is not a pointer type in those constructors which do not accept deleters.
8489 <blockquote><pre>unique_ptr<A, void(*)(void*)> p(new A); // error, no function given to delete the pointer!
8497 Kona (2007): We don't like the solution given to the first bullet in
8498 light of concepts. The second bullet solves the problem of supporting
8499 fancy pointers for one library component only. The full LWG needs to
8500 decide whether to solve the problem of supporting fancy pointers
8501 piecemeal, or whether a paper addressing the whole library is needed. We
8502 think that the third bullet is correct.
8507 Post Kona: Howard adds example user code related to the first bullet:
8512 <pre>void legacy_code(void*, std::size_t);
8514 void foo(std::size_t N)
8516 std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
8517 legacy_code(ptr.get(), N);
8518 } // unique_ptr used for exception safety purposes
8523 I.e. <tt>unique_ptr<void></tt> <i>is</i> a useful tool that we don't want
8524 to disable with concepts. The only part of <tt>unique_ptr<void></tt> we
8525 want to disable (with concepts or by other means) are the two member functions:
8528 <blockquote><pre>T& operator*() const;
8529 T* operator->() const;
8534 <p><b>Proposed resolution:</b></p>
8537 I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
8538 the proposed resolutions below.
8546 Change 20.6.11.2 [unique.ptr.single]:
8549 <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
8551 <del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
8557 Change 20.6.11.2.4 [unique.ptr.single.observers]:
8560 <blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
8567 Change 20.6.11.2 [unique.ptr.single]:
8570 <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
8572 <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
8574 explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8576 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
8577 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
8579 <del>T*</del> <ins>pointer</ins> operator->() const;
8580 <del>T*</del> <ins>pointer</ins> get() const;
8582 <del>T*</del> <ins>pointer</ins> release();
8583 void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8589 -3- If the type <tt>remove_reference<D>::type::pointer</tt>
8590 exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to
8591 <tt>remove_reference<D>::type::pointer</tt>. Otherwise
8592 <tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>.
8593 The type <tt>unique_ptr<T, D>::pointer</tt> shall be <tt>CopyConstructible</tt>
8594 and <tt>CopyAssignable</tt>.
8599 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8602 <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8604 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8605 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8607 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
8608 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
8610 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A& d);
8611 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
8613 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
8614 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d);
8619 -23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
8620 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
8621 <del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
8622 reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
8623 (diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins>
8624 <del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
8629 -25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
8630 the construction, modulo any required offset adjustments resulting from
8631 the cast from <del><tt>U*</tt></del>
8632 <ins><tt>unique_ptr<U,E>::pointer</tt></ins> to <del><tt>T*</tt></del>
8633 <ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
8634 internally stored deleter which was constructed from
8635 <tt>u.get_deleter()</tt>.
8639 Change 20.6.11.2.3 [unique.ptr.single.asgn]:
8644 -8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
8645 <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
8646 <ins><tt>unique_ptr<U,E>::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
8647 convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
8652 Change 20.6.11.2.4 [unique.ptr.single.observers]:
8656 <pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre>
8658 <pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
8662 Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
8666 <pre><del>T*</del> <ins>pointer</ins> release();</pre>
8668 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
8672 Change 20.6.11.3 [unique.ptr.runtime]:
8675 <blockquote><pre>template <class T, class D> class unique_ptr<T[], D> {
8677 <ins>typedef <i>implementation</i> pointer;</ins>
8679 explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8681 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8682 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8684 <del>T*</del> <ins>pointer</ins> get() const;
8686 <del>T*</del> <ins>pointer</ins> release();
8687 void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8692 Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
8696 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8697 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8698 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8702 These constructors behave the same as in the primary template except
8703 that they do not accept pointer types which are convertible to
8704 <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
8705 implementation technique is to create private templated overloads of
8706 these members. <i>-- end note</i>]
8711 Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
8715 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8719 -1- <i>Requires:</i> Does not accept pointer types which are convertible
8720 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
8721 required). [<i>Note:</i> One implementation technique is to create a private
8722 templated overload. <i>-- end note</i>]
8731 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8735 <pre>unique_ptr();</pre>
8738 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
8739 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
8740 reference type <ins>or pointer type (diagnostic required)</ins>.
8743 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
8746 <i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
8747 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
8748 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
8755 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8759 <pre>unique_ptr();</pre>
8762 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
8763 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
8764 reference type <ins>or pointer type (diagnostic required)</ins>.
8767 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
8770 <i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
8771 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
8772 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
8788 <h3><a name="675"></a>675. Move assignment of containers</h3>
8789 <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#Open">Open</a>
8790 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
8791 <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>
8792 <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>
8793 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8794 <p><b>Discussion:</b></p>
8796 James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
8797 (just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></tt> might have
8798 the wrong semantics under move assignment when the source is not truly an rvalue, but a
8799 moved-from lvalue (destructors could run late).
8802 <blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1;
8803 <tt>vector<shared_ptr<ostream>></tt> v2;
8806 v1 = std::move(v2); // #2
8810 Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
8811 It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example
8812 both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s
8813 <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
8814 copy assignment or move assignment.
8818 This implies that the semantics of move assignment of a generic container should be
8819 <tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same
8820 effect would be to move assign each element. In either case, the complexity of move
8821 assignment needs to be relaxed to <tt>O(v1.size())</tt>.
8825 The performance hit of this change is not nearly as drastic as it sounds.
8826 In practice, the target of a move assignment has always just been move constructed
8827 or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in
8828 this common use case) we are still achieving O(1) complexity.
8833 <p><b>Proposed resolution:</b></p>
8835 Change 23.1 [container.requirements]:
8840 <caption>Table 86: Container requirements</caption>
8842 <th>expression</th><th>return type</th><th>operational semantics</th>
8843 <th>assertion/note pre/post-condition</th><th>complexity</th>
8846 <td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
8847 <td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
8848 <td><tt>a</tt> shall be equal to the
8849 value that <tt>rv</tt> had
8850 before this construction
8852 <td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
8860 post Bellevute Howard adds:
8866 This issue was voted to WP in Bellevue, but accidently got stepped on by
8867 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
8868 which was voted to WP simulataneously. Moving back to Open for the purpose of getting
8869 the wording right. The intent of this issue and N2525 are not in conflict.
8877 <h3><a name="676"></a>676. Moving the unordered containers</h3>
8878 <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8879 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
8880 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
8881 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
8882 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8883 <p><b>Discussion:</b></p>
8885 Move semantics are missing from the <tt>unordered</tt> containers. The proposed
8886 resolution below adds move-support consistent with
8887 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
8888 and the current working draft.
8892 The current proposed resolution simply lists the requirements for each function.
8893 These might better be hoisted into the requirements table for unordered associative containers.
8894 Futhermore a mild reorganization of the container requirements could well be in order.
8895 This defect report is purposefully ignoring these larger issues and just focusing
8896 on getting the unordered containers "moved".
8901 <p><b>Proposed resolution:</b></p>
8904 Add to 23.4 [unord]:
8907 <blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
8908 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
8909 unordered_map<Key, T, Hash, Pred, Alloc>& y);
8911 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8912 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
8913 unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
8915 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8916 void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
8917 unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
8919 template <class Key, class T, class Hash, class Pred, class Alloc>
8920 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
8921 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
8923 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8924 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
8925 unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
8927 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8928 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
8929 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
8933 template <class Value, class Hash, class Pred, class Alloc>
8934 void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
8935 unordered_set<Value, Hash, Pred, Alloc>& y);
8937 <ins>template <class Value, class Hash, class Pred, class Alloc>
8938 void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
8939 unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
8941 <ins>template <class Value, class Hash, class Pred, class Alloc>
8942 void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
8943 unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
8945 template <class Value, class Hash, class Pred, class Alloc>
8946 void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
8947 unordered_multiset<Value, Hash, Pred, Alloc>& y);
8949 <ins>template <class Value, class Hash, class Pred, class Alloc>
8950 void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
8951 unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
8953 <ins>template <class Value, class Hash, class Pred, class Alloc>
8954 void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
8955 unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
8958 <p><b><tt>unordered_map</tt></b></p>
8961 Change 23.4.1 [unord.map]:
8964 <blockquote><pre>class unordered_map
8967 unordered_map(const unordered_map&);
8968 <ins>unordered_map(unordered_map&&);</ins>
8970 unordered_map& operator=(const unordered_map&);
8971 <ins>unordered_map& operator=(unordered_map&&);</ins>
8974 <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
8975 <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
8976 iterator insert(iterator hint, const value_type& obj);
8977 <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
8978 const_iterator insert(const_iterator hint, const value_type& obj);
8979 <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
8981 void swap(unordered_map&<ins>&</ins>);
8983 mapped_type& operator[](const key_type& k);
8984 <ins>mapped_type& operator[](key_type&& k);</ins>
8988 template <class Key, class T, class Hash, class Pred, class Alloc>
8989 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
8990 unordered_map<Key, T, Hash, Pred, Alloc>& y);
8992 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8993 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
8994 unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
8996 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
8997 void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
8998 unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
9002 Add to 23.4.1.1 [unord.map.cnstr]:
9006 <pre>template <class InputIterator>
9007 unordered_map(InputIterator f, InputIterator l,
9008 size_type n = <i>implementation-defined</i>,
9009 const hasher& hf = hasher(),
9010 const key_equal& eql = key_equal(),
9011 const allocator_type& a = allocator_type());
9016 <i>Requires:</i> If the iterator's dereference operator returns an
9017 lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
9018 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
9019 <tt>CopyConstructible</tt>.
9025 Add to 23.4.1.2 [unord.map.elem]:
9030 <pre>mapped_type& operator[](const key_type& k);</pre>
9035 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
9036 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
9040 <pre><ins>mapped_type& operator[](key_type&& k);</ins></pre>
9044 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
9045 element whose key is equivalent to <tt>k</tt> , inserts the value
9046 <tt>std::pair<const key_type, mapped_type>(std::move(k), mapped_type())</tt>.
9050 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
9054 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
9055 (unique) element whose key is equivalent to <tt>k</tt>.
9063 Add new section [unord.map.modifiers]:
9067 <pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
9068 <ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
9069 <ins>iterator insert(iterator hint, const value_type& x);</ins>
9070 <ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
9071 <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
9072 <ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
9073 <ins>template <class InputIterator>
9074 void insert(InputIterator first, InputIterator last);</ins>
9079 <i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
9080 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
9081 <tt>CopyConstructible</tt>.
9085 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
9086 If <tt>P</tt> is instantiated as a reference
9087 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
9088 is considered to be an rvalue as it is converted to <tt>value_type</tt>
9089 and inserted into the <tt>unordered_map</tt>. Specifically, in such
9090 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
9091 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
9092 requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
9093 mapped_type></tt>, then <tt>key_type</tt> must be
9094 <tt>CopyConstructible</tt>).
9098 The signature taking <tt>InputIterator</tt>
9099 parameters requires <tt>CopyConstructible</tt> of both
9100 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
9101 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9102 <tt>value_type</tt>.
9110 Add to 23.4.1.3 [unord.map.swap]:
9114 <pre>template <class Key, class T, class Hash, class Pred, class Alloc>
9115 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
9116 unordered_map<Key, T, Hash, Pred, Alloc>& y);
9117 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9118 void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
9119 unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
9120 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9121 void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
9122 unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
9126 <p><b><tt>unordered_multimap</tt></b></p>
9129 Change 23.4.2 [unord.multimap]:
9132 <blockquote><pre>class unordered_multimap
9135 unordered_multimap(const unordered_multimap&);
9136 <ins>unordered_multimap(unordered_multimap&&);</ins>
9137 ~unordered_multimap();
9138 unordered_multimap& operator=(const unordered_multimap&);
9139 <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
9142 iterator insert(const value_type& obj);
9143 <ins>template <class P> iterator insert(P&& obj);</ins>
9144 iterator insert(iterator hint, const value_type& obj);
9145 <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
9146 const_iterator insert(const_iterator hint, const value_type& obj);
9147 <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
9149 void swap(unordered_multimap&<ins>&</ins>);
9153 template <class Key, class T, class Hash, class Pred, class Alloc>
9154 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
9155 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
9157 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9158 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
9159 unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
9161 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9162 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
9163 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
9167 Add to 23.4.2.1 [unord.multimap.cnstr]:
9171 <pre>template <class InputIterator>
9172 unordered_multimap(InputIterator f, InputIterator l,
9173 size_type n = <i>implementation-defined</i>,
9174 const hasher& hf = hasher(),
9175 const key_equal& eql = key_equal(),
9176 const allocator_type& a = allocator_type());
9181 <i>Requires:</i> If the iterator's dereference operator returns an
9182 lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
9183 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
9184 <tt>CopyConstructible</tt>.
9190 Add new section [unord.multimap.modifiers]:
9194 <pre><ins>iterator insert(const value_type& x);</ins>
9195 <ins>template <class P> iterator insert(P&& x);</ins>
9196 <ins>iterator insert(iterator hint, const value_type& x);</ins>
9197 <ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
9198 <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
9199 <ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
9200 <ins>template <class InputIterator>
9201 void insert(InputIterator first, InputIterator last);</ins>
9206 <i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
9207 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
9208 <tt>CopyConstructible</tt>.
9212 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
9213 If <tt>P</tt> is instantiated as a reference
9214 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
9215 is considered to be an rvalue as it is converted to <tt>value_type</tt>
9216 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
9217 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
9218 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
9219 requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
9220 mapped_type></tt>, then <tt>key_type</tt> must be
9221 <tt>CopyConstructible</tt>).
9225 The signature taking <tt>InputIterator</tt>
9226 parameters requires <tt>CopyConstructible</tt> of both
9227 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
9228 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9229 <tt>value_type</tt>.
9236 Add to 23.4.2.2 [unord.multimap.swap]:
9240 <pre>template <class Key, class T, class Hash, class Pred, class Alloc>
9241 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
9242 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
9243 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9244 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
9245 unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
9246 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9247 void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
9248 unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
9252 <p><b><tt>unordered_set</tt></b></p>
9255 Change 23.4.3 [unord.set]:
9258 <blockquote><pre>class unordered_set
9261 unordered_set(const unordered_set&);
9262 <ins>unordered_set(unordered_set&&);</ins>
9264 unordered_set& operator=(const unordered_set&);
9265 <ins>unordered_set& operator=(unordered_set&&);</ins>
9268 <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
9269 <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
9270 iterator insert(iterator hint, const value_type& obj);
9271 <ins>iterator insert(iterator hint, value_type&& obj);</ins>
9272 const_iterator insert(const_iterator hint, const value_type& obj);
9273 <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
9275 void swap(unordered_set&<ins>&</ins>);
9279 template <class Key, class T, class Hash, class Pred, class Alloc>
9280 void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
9281 unordered_set<Key, T, Hash, Pred, Alloc>& y);
9283 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9284 void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
9285 unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
9287 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9288 void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
9289 unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
9293 Add to 23.4.3.1 [unord.set.cnstr]:
9297 <pre>template <class InputIterator>
9298 unordered_set(InputIterator f, InputIterator l,
9299 size_type n = <i>implementation-defined</i>,
9300 const hasher& hf = hasher(),
9301 const key_equal& eql = key_equal(),
9302 const allocator_type& a = allocator_type());
9307 <i>Requires:</i> If the iterator's dereference operator returns an
9308 lvalue or a const rvalue <tt>value_type</tt>, then the
9309 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
9315 Add new section [unord.set.modifiers]:
9319 <pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
9320 <ins>pair<iterator, bool> insert(value_type&& x);</ins>
9321 <ins>iterator insert(iterator hint, const value_type& x);</ins>
9322 <ins>iterator insert(iterator hint, value_type&& x);</ins>
9323 <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
9324 <ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
9325 <ins>template <class InputIterator>
9326 void insert(InputIterator first, InputIterator last);</ins>
9332 <i>Requires:</i> Those signatures taking a <tt>const
9333 value_type&</tt> parameter requires the <tt>value_type</tt> to
9334 be <tt>CopyConstructible</tt>.
9338 The signature taking <tt>InputIterator</tt> parameters requires
9339 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
9340 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9341 <tt>value_type</tt>.
9349 Add to 23.4.3.2 [unord.set.swap]:
9353 <pre>template <class Key, class T, class Hash, class Pred, class Alloc>
9354 void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
9355 unordered_set<Key, T, Hash, Pred, Alloc>& y);
9356 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9357 void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
9358 unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
9359 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9360 void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
9361 unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
9365 <p><b><tt>unordered_multiset</tt></b></p>
9368 Change 23.4.4 [unord.multiset]:
9371 <blockquote><pre>class unordered_multiset
9374 unordered_multiset(const unordered_multiset&);
9375 <ins>unordered_multiset(unordered_multiset&&);</ins>
9376 ~unordered_multiset();
9377 unordered_multiset& operator=(const unordered_multiset&);
9378 <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
9381 iterator insert(const value_type& obj);
9382 <ins>iterator insert(value_type&& obj);</ins>
9383 iterator insert(iterator hint, const value_type& obj);
9384 <ins>iterator insert(iterator hint, value_type&& obj);</ins>
9385 const_iterator insert(const_iterator hint, const value_type& obj);
9386 <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
9388 void swap(unordered_multiset&<ins>&</ins>);
9392 template <class Key, class T, class Hash, class Pred, class Alloc>
9393 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
9394 unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
9396 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9397 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
9398 unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
9400 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9401 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
9402 unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
9406 Add to 23.4.4.1 [unord.multiset.cnstr]:
9410 <pre>template <class InputIterator>
9411 unordered_multiset(InputIterator f, InputIterator l,
9412 size_type n = <i>implementation-defined</i>,
9413 const hasher& hf = hasher(),
9414 const key_equal& eql = key_equal(),
9415 const allocator_type& a = allocator_type());
9420 <i>Requires:</i> If the iterator's dereference operator returns an
9421 lvalue or a const rvalue <tt>value_type</tt>, then the
9422 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
9428 Add new section [unord.multiset.modifiers]:
9432 <pre><ins>iterator insert(const value_type& x);</ins>
9433 <ins>iterator insert(value_type&& x);</ins>
9434 <ins>iterator insert(iterator hint, const value_type& x);</ins>
9435 <ins>iterator insert(iterator hint, value_type&& x);</ins>
9436 <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
9437 <ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
9438 <ins>template <class InputIterator>
9439 void insert(InputIterator first, InputIterator last);</ins>
9445 <i>Requires:</i> Those signatures taking a <tt>const
9446 value_type&</tt> parameter requires the <tt>value_type</tt> to
9447 be <tt>CopyConstructible</tt>.
9451 The signature taking <tt>InputIterator</tt> parameters requires
9452 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
9453 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9454 <tt>value_type</tt>.
9462 Add to 23.4.4.2 [unord.multiset.swap]:
9466 <pre>template <class Key, class T, class Hash, class Pred, class Alloc>
9467 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
9468 unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
9469 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9470 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
9471 unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
9472 <ins>template <class Key, class T, class Hash, class Pred, class Alloc>
9473 void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
9474 unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
9481 Voted to WP in Bellevue.
9486 post Bellevue, Pete notes:
9492 Please remind people who are reviewing issues to check that the text
9493 modifications match the current draft. Issue 676, for example, adds two
9494 overloads for unordered_map::insert taking a hint. One takes a
9495 const_iterator and returns a const_iterator, and the other takes an
9496 iterator and returns an iterator. This was correct at the time the issue
9497 was written, but was changed in Toronto so there is only one hint
9498 overload, taking a const_iterator and returning an iterator.
9501 This issue is not ready. In addition to the relatively minor signature
9502 problem I mentioned earlier, it puts requirements in the wrong places.
9503 Instead of duplicating requirements throughout the template
9504 specifications, it should put them in the front matter that talks about
9505 requirements for unordered containers in general. This presentation
9506 problem is editorial, but I'm not willing to do the extensive rewrite
9507 that it requires. Please put it back into Open status.
9515 <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
9516 <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#Ready">Ready</a>
9517 <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
9518 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9519 <p><b>Discussion:</b></p>
9521 In C++03 the difference between two <tt>reverse_iterators</tt>
9523 <blockquote><pre>ri1 - ri2
9526 is possible to compute only if both iterators have the same base
9527 iterator. The result type is the <tt>difference_type</tt> of the base iterator.
9530 In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
9532 <blockquote><pre>template<class Iterator1, class Iterator2>
9533 typename reverse_iterator<Iterator>::difference_type
9534 operator-(const reverse_iterator<Iterator1>& x,
9535 const reverse_iterator<Iterator2>& y);
9538 The return type is the same as the C++03 one, based on the no longer
9539 present <tt>Iterator</tt> template parameter.
9542 Besides being slightly invalid, should this operator work only when
9543 <tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
9544 implementation choose one of them? Which one?
9547 The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
9548 24.4.3.3.14 [move.iter.nonmember].
9552 <p><b>Proposed resolution:</b></p>
9554 Change the synopsis in 24.4.1.1 [reverse.iterator]:
9558 <pre>template <class Iterator1, class Iterator2>
9559 <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
9560 const reverse_iterator<Iterator1>& x,
9561 const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>;
9566 Change 24.4.1.3.19 [reverse.iter.opdiff]:
9570 <pre>template <class Iterator1, class Iterator2>
9571 <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
9572 const reverse_iterator<Iterator1>& x,
9573 const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>;
9577 <i>Returns:</i> <tt>y.current - x.current</tt>.
9584 Change the synopsis in 24.4.3.1 [move.iterator]:
9588 <pre>template <class Iterator1, class Iterator2>
9589 <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
9590 const move_iterator<Iterator1>& x,
9591 const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>;
9596 Change 24.4.3.3.14 [move.iter.nonmember]:
9600 <pre>template <class Iterator1, class Iterator2>
9601 <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
9602 const move_iterator<Iterator1>& x,
9603 const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>;
9607 <i>Returns:</i> <tt>x.base() - y.base()</tt>.
9613 Pre Bellevue: This issue needs to wait until the <tt>auto -> return</tt> language feature
9624 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
9625 <p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9626 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
9627 <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>
9628 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9629 <p><b>Discussion:</b></p>
9631 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
9632 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
9633 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
9634 Now that we have a mechanism to detect an rvalue, we can fix them to
9635 disallow this source of undefined behavior.
9639 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
9644 <p><b>Proposed resolution:</b></p>
9646 In 20.5 [function.objects], add the following two signatures to the synopsis:
9649 <blockquote><pre>template <class T> void ref(const T&& t) = delete;
9650 template <class T> void cref(const T&& t) = delete;
9656 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
9657 addresses the first part of the resolution but not the second.
9662 Bellevue: Doug noticed problems with the current wording.
9667 post Bellevue: Howard and Peter provided revised wording.
9672 This resolution depends on a "favorable" resolution of CWG 606: that is,
9673 the "special deduction rule" is disabled with the const T&& pattern.
9681 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
9682 <p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
9683 <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
9684 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
9685 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
9686 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
9687 <p><b>Discussion:</b></p>
9689 The last version of TR1 does not include the following member
9691 for unordered containers:
9694 <blockquote><pre>const_local_iterator cbegin(size_type n) const;
9695 const_local_iterator cend(size_type n) const;
9699 which looks like an oversight to me. I've checked th TR1 issues lists
9700 and the latest working draft of the C++0x std (N2284) and haven't
9701 found any mention to these menfuns or to their absence.
9704 Is this really an oversight, or am I missing something?
9709 <p><b>Proposed resolution:</b></p>
9711 Add the following two rows to table 93 (unordered associative container
9712 requirements) in section 23.1.3 [unord.req]:
9717 <caption>Unordered associative container requirements (in addition to container)</caption>
9719 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
9722 <td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td>
9725 <td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td>
9731 Add to the synopsis in 23.4.1 [unord.map]:
9734 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9735 const_local_iterator cend(size_type n) const;</ins>
9739 Add to the synopsis in 23.4.2 [unord.multimap]:
9742 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9743 const_local_iterator cend(size_type n) const;</ins>
9747 Add to the synopsis in 23.4.3 [unord.set]:
9750 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9751 const_local_iterator cend(size_type n) const;</ins>
9755 Add to the synopsis in 23.4.4 [unord.multiset]:
9758 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9759 const_local_iterator cend(size_type n) const;</ins>
9768 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
9769 <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
9770 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
9771 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
9772 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
9773 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
9774 <p><b>Discussion:</b></p>
9776 In a private email Bill Plauger notes:
9779 I believe that the function that implements <code>get_money</code>
9780 [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
9781 should behave as a formatted input function, and the function that
9782 implements <code>put_money</code> should behave as a formatted output
9783 function. This has implications regarding the skipping of whitespace
9784 and the handling of errors, among other things.
9787 The words don't say that right now and I'm far from convinced that
9788 such a change is editorial.
9794 I agree that the manipulators should handle exceptions the same way as
9795 formatted I/O functions do. The text in N2072 assumes so but the
9796 <i>Returns</i> clause explicitly omits exception handling for the sake
9797 of brevity. The spec should be clarified to that effect.
9800 As for dealing with whitespace, I also agree it would make sense for
9801 the extractors and inserters involving the new manipulators to treat
9802 it the same way as formatted I/O.
9806 <p><b>Proposed resolution:</b></p>
9808 Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the
9812 <i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code>
9813 described below behaves as a formatted input function (as
9814 described in 27.6.1.2.1 [istream.formatted.reqmts]).
9817 Also change p4 of 27.6.4 [ext.manip] as follows:
9820 <i>Returns</i>: An object <code>s</code> of unspecified type such that
9821 if <code>in</code> is an object of type <code>basic_istream<charT,
9822 traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function
9823 that calls </ins><code>f(in, mon, intl)</code><del> were
9824 called</del>. The function <code>f</code> can be defined as...
9834 We recommend moving immediately to Review. We've looked at the issue and
9835 have a consensus that the proposed resolution is correct, but want an
9836 iostream expert to sign off. Alisdair has taken the action item to putt
9837 this up on the reflector for possible movement by Howard to Tenatively
9845 <h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
9846 <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#New">New</a>
9847 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
9848 <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>
9849 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
9850 <p><b>Discussion:</b></p>
9852 From message c++std-lib-17897:
9855 The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if"
9856 implementation of the two arithmetic extractors that don't have a
9857 corresponding <code>num_get</code> interface (i.e., the
9858 <code>short</code> and <code>int</code> overloads) is subtly buggy in
9859 how it deals with <code>EOF</code>, overflow, and other similar
9860 conditions (in addition to containing a few typos).
9863 One problem is that if <code>num_get::get()</code> reaches the EOF
9864 after reading in an otherwise valid value that exceeds the limits of
9865 the narrower type (but not <code>LONG_MIN</code> or
9866 <code>LONG_MAX</code>), it will set <code><i>err</i></code> to
9867 <code>eofbit</code>. Because of the if condition testing for
9868 <code>(<i>err</i> == 0)</code>, the extractor won't set
9869 <code>failbit</code> (and presumably, return a bogus value to the
9873 Another problem with the code is that it never actually sets the
9874 argument to the extracted value. It can't happen after the call to
9875 <code>setstate()</code> since the function may throw, so we need to
9876 show when and how it's done (we can't just punt as say: "it happens
9877 afterwards"). However, it turns out that showing how it's done isn't
9878 quite so easy since the argument is normally left unchanged by the
9879 facet on error except when the error is due to a misplaced thousands
9880 separator, which causes <code>failbit</code> to be set but doesn't
9881 prevent the facet from storing the value.
9885 <p><b>Proposed resolution:</b></p>
9894 <h3><a name="698"></a>698. Some system_error issues</h3>
9895 <p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
9896 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
9897 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
9898 <p><b>Discussion:</b></p>
9900 In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
9901 <tt>std::system_error</tt>. In contrast to all exception classes, which
9902 are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
9903 or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
9904 <tt>const string&</tt> are possible. For consistency with the re-designed
9905 remaining exception classes this class should also provide
9906 c'tors which accept a const <tt>char* what_arg</tt> string.
9909 Please note that this proposed addition makes sense even
9910 considering the given implementation hint for <tt>what()</tt>, because
9911 <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
9912 <tt>runtime_error</tt>, which now has the additional c'tor overload
9913 accepting a <tt>const char*</tt>.
9917 <p><b>Proposed resolution:</b></p>
9926 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
9927 <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
9928 <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
9929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
9930 <p><b>Discussion:</b></p>
9932 I see that the definition the associated Laguerre
9933 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
9934 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
9935 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
9936 while the associated Laguerre polynomials are actually valid for real
9937 values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the
9938 definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
9939 must be used, which also holds for integer values of <tt>m</tt>. See
9940 Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
9941 the integer case. In fact fractional values are most commonly used in
9942 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
9943 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
9947 If I am correct, the calculation of the more general case is no
9948 more difficult, and is in fact the function implemented in the GNU
9949 Scientific Library. I would urge you to consider upgrading the
9950 standard, either adding extra functions for real <tt>m</tt> or switching the
9951 current ones to <tt>double</tt>.
9955 <p><b>Proposed resolution:</b></p>
9964 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
9965 <p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
9966 <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
9967 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
9968 <p><b>Discussion:</b></p>
9970 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
9971 <tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p>
9974 <p><b>Proposed resolution:</b></p>
9983 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
9984 <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#Open">Open</a>
9985 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
9986 <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>
9987 <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>
9988 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9989 <p><b>Discussion:</b></p>
9991 The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
9992 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
9993 most of the member functions of node-based containers. But the move-related changes
9994 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
9995 require <tt>CopyAssignable</tt>.
9999 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
10000 from some of the sequence requirements. Additionally the <i>in-place</i> construction
10001 work may further reduce requirements. For purposes of an easy reference, here are the
10002 minimum sequence requirements as I currently understand them. Those items in requirements
10003 table in the working draft which do not appear below have been purposefully omitted for
10004 brevity as they do not have any requirements of this nature. Some items which do not
10005 have any requirements of this nature are included below just to confirm that they were
10006 not omitted by mistake.
10010 <caption>Container Requirements</caption>
10011 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
10012 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
10013 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
10014 Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
10015 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
10016 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
10017 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10018 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>Swappable</tt>.
10019 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>, <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
10020 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10027 <caption>Sequence Requirements</caption>
10028 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
10029 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
10030 <tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10031 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10032 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10033 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
10034 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
10035 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
10036 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10037 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
10038 <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10039 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
10040 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
10041 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
10042 <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
10043 <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
10044 <tr><td><tt>a.clear()</tt></td><td></td></tr>
10045 <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
10046 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
10047 <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
10048 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
10049 The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10050 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10057 <caption>Optional Sequence Requirements</caption>
10058 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
10059 <tr><td><tt>a.back()</tt></td><td></td></tr>
10060 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10061 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10062 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10063 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10064 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
10065 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
10066 <tr><td><tt>a[n]</tt></td><td></td></tr>
10067 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
10074 <caption>Associative Container Requirements</caption>
10075 <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10076 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10077 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10078 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10079 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10080 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10081 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10082 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10083 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10084 If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
10091 <caption>Unordered Associative Container Requirements</caption>
10092 <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10093 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10094 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10095 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10096 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10097 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10098 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10099 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
10100 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10101 If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
10108 <caption>Miscellaneous Requirements</caption>
10109 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
10110 The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
10111 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
10112 The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
10116 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
10121 Bellevue: This should be handled as part of the concepts work.
10127 <p><b>Proposed resolution:</b></p>
10135 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
10136 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10137 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
10138 <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>
10139 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10140 <p><b>Discussion:</b></p>
10142 The POSIX "Extended API Set Part 4,"
10145 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
10148 introduces extensions to the C locale mechanism that
10149 allow multiple concurrent locales to be used in the same application
10150 by introducing a type <tt>locale_t</tt> that is very similar to
10151 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
10154 The global locale (set by setlocale) is now specified to be per-
10155 process. If a thread does not call <tt>uselocale</tt>, the global locale is
10156 in effect for that thread. It can install a per-thread locale by
10157 using <tt>uselocale</tt>.
10160 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
10161 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
10162 locales, with no <tt>std::locale</tt> equivalent.
10165 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
10166 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
10170 Kona (2007): Bill and Nick to provide wording.
10176 <p><b>Proposed resolution:</b></p>
10185 <h3><a name="710"></a>710. Missing postconditions</h3>
10186 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10187 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
10188 <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>
10189 <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>
10190 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10191 <p><b>Discussion:</b></p>
10194 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
10195 has identified a contradiction in the <tt>shared_ptr</tt> specification.
10196 The <tt>shared_ptr</tt> move constructor and the cast functions are
10197 missing postconditions for the <tt>get()</tt> accessor.
10207 Move to "ready", adopting the first (Peter's) proposed resolution.
10210 Note to the project editor: there is an editorial issue here. The
10211 wording for the postconditions of the casts is slightly awkward, and the
10212 editor should consider rewording "If w is the return value...", e. g. as
10213 "For a return value w...".
10218 <p><b>Proposed resolution:</b></p>
10220 Add to 20.6.12.2.1 [util.smartptr.shared.const]:
10224 <pre>shared_ptr(shared_ptr&& r);
10225 template<class Y> shared_ptr(shared_ptr<Y>&& r);
10229 <i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
10230 shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
10236 Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
10240 <pre>template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
10244 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
10245 <tt>w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
10251 <pre>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
10255 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins>
10261 <pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
10265 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
10266 <tt>w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
10272 Alberto Ganesh Barbati has written an
10273 <a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
10274 where he suggests (among other things) that the casts be respecified in terms of
10275 the aliasing constructor as follows:
10279 Change 20.6.12.2.10 [util.smartptr.shared.cast]:
10284 -2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
10285 shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
10286 object that stores <tt>static_cast<T*>(r.get())</tt> and shares ownership with
10287 <tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, static_cast<T*>(r.get())</tt>.</ins>
10293 -6- <i>Returns:</i>
10296 <li><del>When <tt>dynamic_cast<T*>(r.get())</tt> returns a nonzero value,
10297 a <tt>shared_ptr<T></tt> object that stores a copy
10298 of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
10299 <li><del>Otherwise, an <i>empty</i> <tt>shared_ptr<T></tt> object.</del></li>
10300 <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>
10301 <li><ins>Otherwise, <tt>shared_ptr<T>()</tt>.</ins></li>
10307 -10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
10308 shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
10309 object that stores <tt>const_cast<T*>(r.get())</tt> and shares ownership with
10310 <tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, const_cast<T*>(r.get())</tt>.</ins>
10315 This takes care of the missing postconditions for the casts by bringing
10316 in the aliasing constructor postcondition "by reference".
10325 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
10326 <p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10327 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
10328 <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>
10329 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
10330 <p><b>Discussion:</b></p>
10333 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
10334 has identified a contradiction in the <tt>shared_ptr</tt> specification.
10339 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
10344 after the aliasing constructor
10347 <blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
10348 </pre></blockquote>
10351 reflects the intent of
10352 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
10353 to, well, allow the creation of an empty <tt>shared_ptr</tt>
10354 with a non-NULL stored pointer.
10358 This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
10362 <pre>T* get() const;
10365 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
10376 Adopt option 1 and move to review, not ready.
10379 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
10380 isn't defined anywhere), and whether we have a good mental model for how
10381 one behaves. We think it might be possible to deduce what the definition
10382 should be, but the words just aren't there. We need to open an issue on
10383 the use of this undefined term. (The resolution of that issue might
10384 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
10387 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
10388 now that we realize some of its implications, and we need to keep an eye
10389 on it, but there isn't support for removing this feature at this time.
10394 <p><b>Proposed resolution:</b></p>
10396 In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
10400 <pre>T* get() const;
10403 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
10408 Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
10412 Change 20.6.12.2.1 [util.smartptr.shared.const]:
10416 <pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
10420 <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
10423 <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
10424 instance with a non-NULL stored pointer.
10425 -- <i>end note</i> ]</del>
10436 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
10437 <p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
10438 <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10439 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
10440 <p><b>Discussion:</b></p>
10442 The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
10443 log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
10444 average", with no worst case complicity specified. The intention was to
10445 allow a median-of-three quicksort implementation, which is usually <tt>O(N
10446 log N)</tt> but can be quadratic for pathological inputs. However, there is
10447 no longer any reason to allow implementers the freedom to have a
10448 worst-cast-quadratic sort algorithm. Implementers who want to use
10449 quicksort can use a variant like David Musser's "Introsort" (Software
10450 Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
10451 log N)</tt> in the worst case without incurring additional overhead in the
10452 average case. Most C++ library implementers already do this, and there
10453 is no reason not to guarantee it in the standard.
10457 <p><b>Proposed resolution:</b></p>
10459 In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
10464 <i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> <del>(where <i>N</i> == <i>last</i> - <i>first</i> )
10465 </del>comparisons<del> on the average</del>.<del><sup>266)</sup></del>
10468 <del><sup>266)</sup>
10469 If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
10470 (25.3.1.3) should be used.</del>
10480 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
10481 <p><b>Section:</b> 25.1.9 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
10482 <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10483 <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>
10484 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
10485 <p><b>Discussion:</b></p>
10487 The complexity for <tt>search_n</tt> (25.1.9 [alg.search] par 7) is specified as "At most
10488 (last - first ) * count applications of the corresponding predicate if
10489 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
10490 Regardless of the value of count, there is no reason to examine any
10491 element in the range more than once.
10495 <p><b>Proposed resolution:</b></p>
10497 Change the complexity to "At most (last - first) applications of the corresponding predicate".
10501 <pre>template<class ForwardIterator, class Size, class T>
10503 search_n(ForwardIterator first , ForwardIterator last , Size count ,
10504 const T& value );
10506 template<class ForwardIterator, class Size, class T,
10507 class BinaryPredicate>
10509 search_n(ForwardIterator first , ForwardIterator last , Size count ,
10510 const T& value , BinaryPredicate pred );
10514 <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
10515 <del>if <tt>count</tt> is positive, or 0 otherwise</del>.
10526 <h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
10527 <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#Ready">Ready</a>
10528 <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10529 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
10530 <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>
10531 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10532 <p><b>Discussion:</b></p>
10534 The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
10535 (last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
10536 i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
10537 <tt>max_element</tt> separately. This is gratuitously inefficient. There is a
10538 well known technique that does better: see section 9.1 of CLRS
10539 (Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
10543 <p><b>Proposed resolution:</b></p>
10545 Change 25.3.7 [alg.min.max] to:
10549 <pre>template<class ForwardIterator>
10550 pair<ForwardIterator, ForwardIterator>
10551 minmax_element(ForwardIterator first , ForwardIterator last);
10552 template<class ForwardIterator, class Compare>
10553 pair<ForwardIterator, ForwardIterator>
10554 minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
10558 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
10559 <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
10560 comp)</tt></del> <ins>the first iterator in <tt>[first,
10561 last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
10562 <ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
10563 <tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
10564 in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
10567 <i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
10568 <ins><tt>max(⌊(3/2) (N-1)⌋, 0)</tt></ins> applications of the
10569 corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
10580 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
10581 <p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
10582 <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
10583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
10584 <p><b>Discussion:</b></p>
10586 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
10591 The following productions within the ECMAScript grammar are modified as follows:
10594 <blockquote><pre>CharacterClass ::
10595 [ [lookahead ∉ {^}] ClassRanges ]
10597 </pre></blockquote>
10602 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
10606 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
10610 <p><b>Proposed resolution:</b></p>
10612 Remove this mention of the CharacterClass production.
10615 <blockquote><pre><del>CharacterClass ::
10616 [ [lookahead ∉ {^}] ClassRanges ]
10617 [ ^ ClassRanges ]</del>
10618 </pre></blockquote>
10626 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
10627 <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#Open">Open</a>
10628 <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
10629 <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>
10630 <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>
10631 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10632 <p><b>Discussion:</b></p>
10634 Paragraph 21.3 [basic.string]/3 states:
10639 The class template <tt>basic_string</tt> conforms to the requirements for a
10640 Sequence (23.1.1) and for a Reversible Container (23.1).
10645 First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
10646 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
10647 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
10648 even close to conform to the current requirements.
10658 <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
10659 <li>with concepts do we need to maintain string as sequence container?</li>
10660 <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
10663 <li>basic_string already has push_back</li>
10664 <li>const_iterator parameters to insert and erase should be added to basic_string</li>
10665 <li>this leaves emplace to handle -- we have the following options:
10667 <li>option 1: add it to string even though it's optional</li>
10668 <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
10669 <li>option 3: say string not sequence (the proposal),</li>
10670 <li>option 4: add an exception to basic string wording.</li>
10674 General consensus is to suggest option 2.
10679 <p><b>Proposed resolution:</b></p>
10681 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
10682 not just a <tt>vector</tt>-light for literal types, but something quite
10683 different, a string abstraction in its own right.
10691 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
10692 <p><b>Section:</b> 20.4 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10693 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
10694 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
10695 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10696 <p><b>Discussion:</b></p>
10698 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
10699 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
10704 -11- A type is a <i>literal</i> type if it is:
10707 <li>a scalar type; or</li>
10708 <li><p>a class type (clause 9) with</p>
10710 <li>a trivial copy constructor,</li>
10711 <li>a trivial destructor,</li>
10712 <li>at least one constexpr constructor other than the copy constructor,</li>
10713 <li>no virtual base classes, and</li>
10714 <li>all non-static data members and base classes of literal types; or</li>
10717 <li>an array of literal type.</li>
10722 I strongly suggest that the standard provides a type traits for
10723 literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
10727 <li>To keep the traits in sync with existing types.</li>
10728 <li>I see many reasons for programmers to use this trait in template
10729 code to provide optimized template definitions for these types,
10731 <li>A user-provided definition of this trait is practically impossible
10732 to write portably.</li>
10736 The special problem of reason (c) is that I don't see currently a
10737 way to portably test the condition for literal class types:
10742 <li>at least one constexpr constructor other than the copy constructor,</li>
10747 Here follows a simply example to demonstrate it's usefulness:
10750 <blockquote><pre>template <typename T>
10751 constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
10753 return x < T() ? -x : x;
10756 template <typename T>
10757 typename std::enable_if<!std::is_literal<T>::value, T>::type
10758 abs(const T& x) {
10759 return x < T() ? -x : x;
10761 </pre></blockquote>
10764 Here we have the possibility to provide a general <tt>abs</tt> function
10765 template that can be used in ICE's if it's argument is a literal
10766 type which's value is a constant expression, otherwise we
10767 have an optimized version for arguments which are expensive
10768 to copy and therefore need the usage of arguments of
10769 reference type (instead of <tt>const T&</tt> we could decide to
10770 use <tt>T&&</tt>, but that is another issue).
10774 Alisdair is considering preparing a paper listing a number of missing
10775 type traits, and feels that it might be useful to handle them all
10776 together rather than piecemeal. This would affect issue 719 and 750.
10777 These two issues should move to OPEN pending AM paper on type traits.
10783 <p><b>Proposed resolution:</b></p>
10785 In 20.4.2 [meta.type.synop] in the group "type properties",
10786 just below the line
10789 <blockquote><pre>template <class T> struct is_pod;
10790 </pre></blockquote>
10796 <blockquote><pre>template <class T> struct is_literal;
10797 </pre></blockquote>
10800 In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
10801 below the line for the <tt>is_pod</tt> property add a new line:
10806 <th>Template</th><th>Condition</th><th>Preconditions</th>
10809 <td><tt>template <class T> struct is_literal;</tt></td>
10810 <td><tt>T</tt> is a literal type (3.9)</td>
10811 <td><tt>T</tt> shall be a complete type, an
10812 array of unknown bound, or
10813 (possibly cv-qualified) <tt>void</tt>.</td>
10823 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
10824 <p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10825 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
10826 <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>
10827 <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>
10828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10829 <p><b>Discussion:</b></p>
10832 The member function <tt>bool array<T,N>::empty() const</tt> should be a
10833 <tt>constexpr</tt> because this is easily to proof and to implement following it's operational
10834 semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
10837 The member function <tt>bool bitset<N>::test() const</tt> must be a
10838 <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
10839 bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
10842 I wonder how the constructor <tt>bitset<N>::bitset(unsigned long)</tt> can
10843 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
10844 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
10845 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
10846 initialisation. What have I overlooked here?
10851 <p><b>Proposed resolution:</b></p>
10854 <p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
10855 <blockquote><pre><ins>constexpr</ins> bool empty() const;
10856 </pre></blockquote>
10860 <p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
10861 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
10862 </pre></blockquote>
10865 and in 23.3.5.2 [bitset.members] change
10868 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
10869 </pre></blockquote>
10879 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
10880 <p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
10881 <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
10882 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
10883 <p><b>Discussion:</b></p>
10885 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
10886 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
10887 be used (because of a protected destructor).
10891 How are we going to explain this code to beginning programmers?
10894 <blockquote><pre>template<class I, class E, class S>
10895 struct codecvt : std::codecvt<I, E, S>
10903 std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
10905 std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
10907 </pre></blockquote>
10911 <p><b>Proposed resolution:</b></p>
10920 <h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
10921 <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#Ready">Ready</a>
10922 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
10923 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
10924 <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>
10925 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10926 <p><b>Discussion:</b></p>
10928 In the listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss
10929 the following C99 functions (from 7.12.11.2):
10932 <blockquote><pre>float nanf(const char *tagp);
10933 long double nanl(const char *tagp);
10934 </pre></blockquote>
10937 (Note: These functions cannot be overloaded and they are also not
10938 listed anywhere else)
10942 <p><b>Proposed resolution:</b></p>
10944 In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
10945 just after the existing entry <tt>nan</tt>.
10953 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
10954 <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#New">New</a>
10955 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
10956 <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>
10957 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
10958 <p><b>Discussion:</b></p>
10960 According to the current state of the standard draft, the class
10961 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
10962 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
10963 IMO it should be, because typical regex state machines tend
10964 to have a rather large data quantum and I have seen several
10965 use cases, where a factory function returns regex values,
10966 which would take advantage of moveabilities.
10970 <p><b>Proposed resolution:</b></p>
10974 In the header <tt><regex></tt> synopsis 28.4 [re.syn], just below the function
10975 template <tt>swap</tt> add two further overloads:
10977 <blockquote><pre>template <class charT, class traits>
10978 void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2);
10979 <ins>template <class charT, class traits>
10980 void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
10981 template <class charT, class traits>
10982 void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);</ins>
10983 </pre></blockquote>
10985 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
10986 perform the following changes:
10991 <p>Just after the copy c'tor:</p>
10992 <blockquote><pre>basic_regex(basic_regex&&);
10993 </pre></blockquote>
10997 <p>Just after the copy-assignment op.:</p>
10998 <blockquote><pre>basic_regex& operator=(basic_regex&&);
10999 </pre></blockquote>
11003 <p>Just after the first <tt>assign</tt> overload insert:</p>
11004 <blockquote><pre>basic_regex& assign(basic_regex&& that);
11005 </pre></blockquote>
11009 <p>Change the current <tt>swap</tt> function to read:</p>
11010 <blockquote><pre>void swap(basic_regex&&);
11011 </pre></blockquote>
11015 <p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
11016 corresponding member definition of:</p>
11017 <blockquote><pre>basic_regex(basic_regex&&);
11018 </pre></blockquote>
11022 <p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
11023 c'tor add a corresponding member definition of:</p>
11024 <blockquote><pre>basic_regex& operator=(basic_regex&&);
11025 </pre></blockquote>
11029 <p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
11030 a corresponding member definition of:</p>
11031 <blockquote><pre>basic_regex& assign(basic_regex&& that);
11032 </pre></blockquote>
11036 <p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
11038 <blockquote><pre>void swap(basic_regex&& e);
11039 </pre></blockquote>
11043 <p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
11044 function, add the two missing overloads:</p>
11045 <blockquote><pre>template <class charT, class traits>
11046 void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
11047 template <class charT, class traits>
11048 void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
11049 </pre></blockquote>
11054 Of course there would be need of corresponding proper standardese
11055 to describe these additions.
11064 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
11065 <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#Open">Open</a>
11066 <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
11067 <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>
11068 <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>
11069 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11070 <p><b>Discussion:</b></p>
11072 The <tt>DefaultConstructible</tt> requirement is referenced in
11073 several places in the August 2007 working draft
11074 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
11075 but is not defined anywhere.
11085 Walking into the default/value-initialization mess...
11088 Why two lines? Because we need both expressions to be valid.
11091 AJM not sure what the phrase "default constructed" means. This is
11092 unfortunate, as the phrase is already used 24 times in the library!
11095 Example: const int would not accept first line, but will accept the second.
11098 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
11101 It seems that the requirements are the syntax in the proposed first
11102 column is valid, but not clear what semantics we need.
11105 A table where there is no post-condition seems odd, but appears to sum up our position best.
11108 At a minimum an object is declared and is destuctible.
11111 Move to open, as no-one happy to produce wording on the fly.
11116 <p><b>Proposed resolution:</b></p>
11118 In section 20.1.1 [utility.arg.requirements], before table 33, add the
11122 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
11124 <div align="center">
11126 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
11128 <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
11129 <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
11131 <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
11132 <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
11136 <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
11137 <p style="margin: 0in 0in 0.0001pt;"><tt>T
11141 <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
11142 <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
11143 is <i>default constructed.</i></p>
11156 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
11157 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11158 <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
11159 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
11160 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
11161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11162 <p><b>Discussion:</b></p>
11164 Two overloads of <tt>regex_replace()</tt> are currently provided:
11167 <blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
11168 class traits, class charT>
11170 regex_replace(OutputIterator out,
11171 BidirectionalIterator first, BidirectionalIterator last,
11172 const basic_regex<charT, traits>& e,
11173 const basic_string<charT>& fmt,
11174 regex_constants::match_flag_type flags =
11175 regex_constants::match_default);
11177 template <class traits, class charT>
11178 basic_string<charT>
11179 regex_replace(const basic_string<charT>& s,
11180 const basic_regex<charT, traits>& e,
11181 const basic_string<charT>& fmt,
11182 regex_constants::match_flag_type flags =
11183 regex_constants::match_default);
11184 </pre></blockquote>
11187 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
11188 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
11190 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
11192 <blockquote><pre>const string s("kitten");
11193 const regex r("en");
11194 cout << regex_replace(s, r, "y") << endl;
11195 </pre></blockquote>
11198 The compiler error message will be something like "could not deduce
11199 template argument for 'const std::basic_string<_Elem> &' from 'const
11204 Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
11205 <tt>const charT *</tt>. In their own code, when they write a function taking
11206 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
11207 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
11208 regex algorithms are templated on <tt>charT</tt>, they can't rely on
11209 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
11210 indicates, template argument deduction fails first).
11214 If a user figures out what the compiler error message means, workarounds
11215 are available - but they are all verbose. Explicit template arguments
11216 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
11217 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
11218 the first, so this would be extremely verbose. Therefore, constructing
11219 a <tt>basic_string</tt> from each C string is the simplest workaround.
11224 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
11225 impose performance costs that could be avoided by a library
11226 implementation taking C strings and dealing with them directly.
11227 (Currently, for replacement sources, C strings can be converted into
11228 iterator pairs at the cost of verbosity, but for format strings, there
11229 is no way to avoid constructing a <tt>basic_string</tt>.)
11235 <p><b>Proposed resolution:</b></p>
11237 Provide additional overloads for <tt>regex_replace()</tt>: one additional
11238 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
11239 additional overloads of the convenience form (one taking <tt>const charT*
11240 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
11241 charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]:
11245 <pre>template <class OutputIterator, class BidirectionalIterator,
11246 class traits, class charT>
11248 regex_replace(OutputIterator out,
11249 BidirectionalIterator first, BidirectionalIterator last,
11250 const basic_regex<charT, traits>& e,
11251 const basic_string<charT>& fmt,
11252 regex_constants::match_flag_type flags =
11253 regex_constants::match_default);
11255 <ins>template <class OutputIterator, class BidirectionalIterator,
11256 class traits, class charT>
11258 regex_replace(OutputIterator out,
11259 BidirectionalIterator first, BidirectionalIterator last,
11260 const basic_regex<charT, traits>& e,
11262 regex_constants::match_flag_type flags =
11263 regex_constants::match_default);</ins>
11266 <pre>template <class traits, class charT>
11267 basic_string<charT>
11268 regex_replace(const basic_string<charT>& s,
11269 const basic_regex<charT, traits>& e,
11270 const basic_string<charT>& fmt,
11271 regex_constants::match_flag_type flags =
11272 regex_constants::match_default);
11274 <ins>template <class traits, class charT>
11275 basic_string<charT>
11276 regex_replace(const basic_string<charT>& s,
11277 const basic_regex<charT, traits>& e,
11279 regex_constants::match_flag_type flags =
11280 regex_constants::match_default);</ins>
11282 <ins>template <class traits, class charT>
11283 basic_string<charT>
11284 regex_replace(const charT* s,
11285 const basic_regex<charT, traits>& e,
11286 const basic_string<charT>& fmt,
11287 regex_constants::match_flag_type flags =
11288 regex_constants::match_default);</ins>
11290 <ins>template <class traits, class charT>
11291 basic_string<charT>
11292 regex_replace(const charT* s,
11293 const basic_regex<charT, traits>& e,
11295 regex_constants::match_flag_type flags =
11296 regex_constants::match_default);</ins>
11306 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
11307 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
11308 <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
11309 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
11310 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
11311 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
11312 <p><b>Discussion:</b></p>
11314 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST,
11315 SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
11316 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
11321 <p><b>Proposed resolution:</b></p>
11323 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
11324 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST,
11325 SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
11326 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
11327 existing code using TR1 and giving explicit template arguments to
11328 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
11337 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
11338 <p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11339 <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11340 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
11341 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11342 <p><b>Discussion:</b></p>
11344 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
11345 as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
11346 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
11347 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
11348 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
11349 Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
11350 [<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
11354 I see two possible resolutions:
11358 <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
11359 multiplier from [the above reference] for the 64-bit case (my preference)</li>
11360 <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
11361 order) and always employ the 32-bit algorithm for seeding
11366 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11367 for further discussion.
11377 Stephan Tolksdorf has additional comments on N2424. He comments: "there
11378 is a typo in the required behaviour for mt19937_64: It should be the
11379 10000th (not 100000th) invocation whose value is given, and the value
11380 should be 9981545732273789042 (not 14002232017267485025)." These values
11384 Take the proposed recommendation in N2424 and move to REVIEW.
11391 <p><b>Proposed resolution:</b></p>
11394 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11395 for the proposed resolution.
11399 Stephan Tolksdorf adds pre-Bellevue:
11404 I support the proposed resolution in
11405 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
11406 but there is a typo in the
11407 required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
11408 100000<sup>th</sup>) invocation whose value is given, and the value should be
11409 9981545732273789042 (not 14002232017267485025). The change to para. 8
11410 proposed by Charles Karney should also be included in the proposed
11420 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
11421 <p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11422 <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11423 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
11424 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11425 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
11426 <p><b>Discussion:</b></p>
11428 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
11429 meant to simulate random numbers from any general distribution given only the density and the
11430 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
11431 of correctly and efficiently implementing the described functionality. From what I know, this is
11432 essentially an unsolved research problem. Existing algorithms either require more knowledge
11433 about the distribution and the problem domain or work only under very limited circumstances.
11434 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
11435 generality, and in any case, testing and customer support for such a library feature would be a
11440 <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
11450 Disagreement persists.
11453 Objection to this issue is that this function takes a general functor.
11454 The general approach would be to normalize this function, integrate it,
11455 and take the inverse of the integral, which is not possible in general.
11456 An example function is sin(1+n*x) -- for any spatial frequency that the
11457 implementor chooses, there is a value of n that renders that choice
11458 arbitrarily erroneous.
11461 Correction: The formula above should instead read 1+sin(n*x).
11464 Objector proposes the following possible compromise positions:
11468 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
11470 <li>replace rand.disk.samp.genpdf with an extension to either or both
11471 of the discrete functions to take arguments that take a functor and
11472 number of points in place of the list of probabilities. Reference
11473 issues 793 and 794.
11480 <p><b>Proposed resolution:</b></p>
11482 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11483 for the proposed resolution.
11491 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
11492 <p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11493 <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11495 <p><b>Discussion:</b></p>
11497 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
11498 have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
11499 following two reasons this is an unnecessary restriction: First, in many applications such as
11500 Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
11501 eters as continuous variables. Second, the standard non-naive algorithms (i.e.
11503 for simulating from these distributions work with floating-point parameters anyway (all three
11504 distributions could be easily implemented using the Gamma distribution, for instance).
11508 Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
11509 <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
11510 parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
11511 the implementation would be significantly complicated by a non-discrete parameter (in most
11512 implementations one would need an approximation of the log-gamma function instead of just the
11513 log-factorial function).
11517 <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
11527 In N2424. Not wildly enthusiastic, not really felt necessary. Less
11528 frequently used in practice. Not terribly bad either. Move to OPEN.
11532 <p><b>Proposed resolution:</b></p>
11534 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11535 for the proposed resolution.
11539 Stephan Tolksdorf adds pre-Bellevue:
11545 In 26.4.8.4.3 [rand.dist.norm.chisq]:
11550 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
11554 Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
11555 with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
11559 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
11565 In 26.4.8.4.5 [rand.dist.norm.f]:
11569 Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
11573 Replace both occurrences of
11575 <blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
11576 </pre></blockquote>
11580 <blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
11581 </pre></blockquote>
11584 Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
11588 Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
11593 In 26.4.8.4.6 [rand.dist.norm.t]:
11598 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
11602 Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
11603 with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
11607 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
11618 <h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3>
11619 <p><b>Section:</b> 20.6.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11620 <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
11621 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11622 <p><b>Discussion:</b></p>
11624 Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful
11625 bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
11626 <tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></tt>, but that promising path
11627 immediately falters on <tt>op--</tt> which can't reliably dereference because we
11628 don't know the lower bound). Also, most buffers you'd want to point to
11629 don't have a compile-time known size.
11633 To enable any bounds-checking would require run-time information, with
11634 the usual triplet: base (lower bound), current offset, and max offset
11635 (upper bound). And I can sympathize with the point of view that you
11636 wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
11637 follow the <tt><T[N]></tt> path, especially not with additional functions to
11638 query the bounds etc., because this sets wrong user expectations by
11639 embarking on a path that doesn't go all the way to bounds checking as it
11644 If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
11645 <tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
11646 user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
11647 debug builds and not doing so on release builds (for example).
11651 Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
11652 pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
11653 don't agree, but if that were true that would be another reason to
11654 remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like
11655 <tt>std::array.</tt> :-)
11664 <p>Suggestion that fixed-size array instantiations are going to fail at
11665 compile time anyway (if we remove specialization) due to pointer decay,
11666 at least that appears to be result from available compilers.
11669 So concerns about about requiring static_assert seem unfounded.
11671 <p>After a little more experimentation with compiler, it appears that
11672 fixed size arrays would only work at all if we supply these explicit
11673 specialization. So removing them appears less breaking than originally
11677 straw poll unanimous move to Ready.
11683 <p><b>Proposed resolution:</b></p>
11685 Change the synopsis under 20.6.11 [unique.ptr] p2:
11688 <blockquote><pre>...
11689 template<class T> struct default_delete;
11690 template<class T> struct default_delete<T[]>;
11691 <del>template<class T, size_t N> struct default_delete<T[N]>;</del>
11693 template<class T, class D = default_delete<T>> class unique_ptr;
11694 template<class T, class D> class unique_ptr<T[], D>;
11695 <del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del>
11697 </pre></blockquote>
11700 Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>.
11704 Remove the entire section 20.6.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
11705 and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers],
11706 20.6.11.4.3 [unique.ptr.compiletime.modifiers].
11715 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
11716 <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#Open">Open</a>
11717 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
11718 <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>
11719 <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>
11720 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11721 <p><b>Discussion:</b></p>
11723 This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a> now just
11724 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
11725 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
11726 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
11730 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here
11734 <blockquote><pre>namespace Mine {
11736 template <class T>
11737 struct proxy {...};
11739 template <class T>
11740 struct proxied_iterator
11742 typedef T value_type;
11743 typedef proxy<T> reference;
11744 reference operator*() const;
11750 // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
11755 void swap(A&, A&);
11756 void swap(proxy<A>, A&);
11757 void swap(A&, proxy<A>);
11758 void swap(proxy<A>, proxy<A>);
11764 Mine::proxied_iterator<Mine::A> i(...)
11766 <b>swap(*i1, a);</b>
11767 </pre></blockquote>
11770 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
11771 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
11772 same type). A secondary point is that to support proxies, one must be able to pass rvalues
11773 to <tt>swap</tt>. But note that I am not stating that the general purpose <tt>std::swap</tt>
11774 should accept rvalues! Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
11779 That is, no standard library code needs to change. We simply need to have a more flexible
11780 definition of <tt>Swappable</tt>.
11790 While we believe Concepts work will define a swappable concept, we
11791 should still resolve this issue if possible to give guidance to the
11795 Would an ambiguous swap function in two namespaces found by ADL break
11796 this wording? Suggest that the phrase "valid expression" means such a
11797 pair of types would still not be swappable.
11800 Motivation is proxy-iterators, but facility is considerably more
11801 general. Are we happy going so far?
11804 We think this wording is probably correct and probably an improvement on
11805 what's there in the WP. On the other hand, what's already there in the
11806 WP is awfully complicated. Why do we need the two bullet points? They're
11807 too implementation-centric. They don't add anything to the semantics of
11808 what swap() means, which is there in the post-condition. What's wrong
11809 with saying that types are swappable if you can call swap() and it
11810 satisfies the semantics of swapping?
11816 <p><b>Proposed resolution:</b></p>
11818 Change 20.1.1 [utility.arg.requirements]:
11824 -1- The template definitions in the C++ Standard Library refer to various
11825 named requirements whose details are set out in tables 31-38. In these
11826 tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
11827 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
11828 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
11829 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
11830 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
11831 rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
11835 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
11836 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
11837 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
11838 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
11839 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
11840 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
11841 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
11842 <tr><td colspan="3">
11844 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
11848 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
11849 the same type and </ins> <tt>T</tt> satisfies the
11850 <del><tt>CopyConstructible</tt></del>
11851 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
11852 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
11853 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
11857 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
11858 <tt>swap</tt> exists in the same namespace as the definition of
11859 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
11860 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
11861 semantics described in this table.
11874 <h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
11875 <p><b>Section:</b> 20.6.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11876 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
11877 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11878 <p><b>Discussion:</b></p>
11880 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:
11884 We may need to open an issue to deal with the question of
11885 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
11889 This issue was opened in response to that note.
11893 I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
11894 appropriate, and consistent with how other library components are currently specified.
11904 Concern that the three signatures for swap is needlessly complicated,
11905 but this issue merely brings shared_ptr into equal complexity with the
11906 rest of the library. Will open a new issue for concern about triplicate
11910 Adopt issue as written.
11915 <p><b>Proposed resolution:</b></p>
11917 Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
11920 <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
11922 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
11923 <ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
11924 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
11925 </pre></blockquote>
11928 Change 20.6.12.2.4 [util.smartptr.shared.mod]:
11931 <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
11932 </pre></blockquote>
11935 Change 20.6.12.2.9 [util.smartptr.shared.spec]:
11938 <blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
11939 <ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
11940 template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
11941 </pre></blockquote>
11948 <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
11949 <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#Ready">Ready</a>
11950 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
11951 <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>
11952 <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>
11953 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11954 <p><b>Discussion:</b></p>
11956 Without some lifetime guarantee, it is hard to know how this type can be
11957 used. Very specifically, I don't see how the current wording would
11958 guarantee and exception_ptr caught at the end of one thread could be safely
11959 stored and rethrown in another thread - the original motivation for this
11963 (Peter Dimov agreed it should be clearer, maybe a non-normative note to
11974 Agree the issue is real.
11977 Intent is lifetime is similar to a shared_ptr (and we might even want to
11978 consider explicitly saying that it is a shared_ptr< unspecified type >).
11981 We expect that most implementations will use shared_ptr, and the
11982 standard should be clear that the exception_ptr type is intended to be
11983 something whose semantics are smart-pointer-like so that the user does
11984 not need to worry about lifetime management. We still need someone to
11985 draught those words - suggest emailing Peter Dimov.
11993 <p><b>Proposed resolution:</b></p>
11995 Change 18.7.5 [propagation]/7:
11999 -7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
12000 handled exception or a copy of the currently handled exception, or a
12001 null <tt>exception_ptr</tt> object if no exception is being handled.
12002 <ins>The referenced object remains valid at least as long as there is an
12003 <tt>exception_ptr</tt> that refers to it.</ins>
12004 If the function needs to allocate memory and the attempt
12005 fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
12006 <tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
12007 calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
12008 that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
12009 each time it is called. <i>--end note</i>]
12017 <h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
12018 <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#Ready">Ready</a>
12019 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12020 <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>
12021 <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>
12022 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12023 <p><b>Discussion:</b></p>
12025 I understand that the attempt to copy an exception may run out of memory,
12026 but I believe this is the only part of the standard that mandates failure
12027 with specifically <tt>bad_alloc</tt>, as opposed to allowing an
12028 implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core
12029 language for a failed new expression is:
12033 Any other allocation function that fails to allocate storage shall indicate
12034 failure only by throwing an exception of a type that would match a handler
12035 (15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
12039 I think we should allow similar freedom here (or add a blanket
12040 compatible-exception freedom paragraph in 17)
12043 I prefer the clause 17 approach myself, and maybe clean up any outstanding
12044 wording that could also rely on it.
12047 Although filed against a specific case, this issue is a problem throughout
12058 Is issue bigger than library?
12061 No - Core are already very clear about their wording, which is inspiration for the issue.
12064 While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
12067 Accept the broad view and move to ready
12072 <p><b>Proposed resolution:</b></p>
12074 Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
12078 A function may throw a type not listed in its <i>Throws</i> clause so long as it is
12079 derived from a class named in the <i>Throws</i> clause, and would be caught by an
12080 exception handler for the base type.
12088 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
12089 <p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12090 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12091 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
12092 <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>
12093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12094 <p><b>Discussion:</b></p>
12096 We have 3 separate type traits to identify classes supporting no-throw
12097 operations, which are very useful when trying to provide exception safety
12098 guarantees. However, I'm not entirely clear on what the current wording
12099 requires of a conforming implementation. To quote from
12100 <tt>has_nothrow_default_constructor</tt>:
12103 or <tt>T</tt> is a class type with a default constructor that is known not to throw
12107 What level of magic do we expect to deduce if this is known?
12113 <blockquote><pre>struct test{
12117 </pre></blockquote>
12119 Should I expect a conforming compiler to
12120 <tt>assert( has_nothrow_constructor<test>::value )</tt>
12123 Is this a QoI issue?
12126 Should I expect to 'know' only if-and-only-if there is an inline definition
12130 Should I never expect that to be true, and insist that the user supplies an
12131 empty throw spec if they want to assert the no-throw guarantee?
12134 It would be helpful to maybe have a footnote explaining what is required,
12135 but right now I don't know what to suggest putting in the footnote.
12138 (agreement since is that trivial ops and explicit no-throws are required.
12139 Open if QoI should be allowed to detect further)
12148 This looks like a QoI issue.
12149 In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
12150 Move to OPEN. Need to talk to Core about this.
12154 <p><b>Proposed resolution:</b></p>
12163 <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>
12164 <p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
12165 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12166 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
12167 <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>
12168 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12169 <p><b>Discussion:</b></p>
12171 Unfortunately a class can have multiple copy constructors, and I believe to
12172 be useful this trait should only return true is ALL copy constructors are
12179 <pre>struct awkward {
12180 awkward( const awkward & ) throw() {}
12181 awkward( awkward & ) { throw "oops"; } };
12186 <p><b>Proposed resolution:</b></p>
12188 Change 20.4.4.3 [meta.unary.prop]:
12192 <pre>has_trivial_copy_constructor</pre>
12194 <tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
12195 <ins>where all copy constructors are trivial</ins> (12.8).
12200 <pre>has_trivial_assign</pre>
12202 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
12203 or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
12208 <pre>has_nothrow_copy_constructor</pre>
12210 <tt>has_trivial_copy_constructor<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
12211 a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins>
12212 known not to throw any exceptions or <tt>T</tt> is an
12213 array of such a class type
12218 <pre>has_nothrow_assign</pre>
12220 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and
12221 <tt>has_trivial_assign<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
12222 <ins>where all</ins> copy
12223 assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
12224 throw any exceptions or <tt>T</tt> is an array of such a class type.
12234 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
12235 implicitly convertible, so explicit constructors are ignored.</h3>
12236 <p><b>Section:</b> 20.4.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12237 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12239 <p><b>Discussion:</b></p>
12241 With the pending arrival of explicit conversion functions though, I'm
12242 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
12251 Alisdair is considering preparing a paper listing a number of missing
12252 type traits, and feels that it might be useful to handle them all
12253 together rather than piecemeal. This would affect issue 719 and 750.
12254 These two issues should move to OPEN pending AM paper on type traits.
12258 <p><b>Proposed resolution:</b></p>
12267 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
12268 <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12269 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12270 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
12271 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
12272 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12273 <p><b>Discussion:</b></p>
12275 A number of vector<bool> members take const bool& as arguments.
12276 Is there any chance we could change them to pass-by-value or would I
12277 be wasting everyone's time if wrote up an issue?
12287 As we understand it, the original requester (Martin Sebor) would like
12288 for implementations to be permitted to pass-by-value. Alisdair suggests
12289 that if this is to be resolved, it should be resolved more generally,
12290 e.g. in other containers as well.
12293 We note that this would break ABI. However, we also suspect that this
12294 might be covered under the "as-if" rule in section 1.9.
12297 Many in the group feel that for vector<bool>, this is a "don't care",
12298 and that at this point in the process it's not worth the bandwidth.
12301 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
12302 now in the working paper -- is related to this, though not a duplicate.
12305 Moving to Open with a task for Alisdair to craft a informative note to
12306 be put whereever appropriate in the WP. This note would clarify places
12307 where pass-by-const-ref can be transformed to pass-by-value under the
12314 <p><b>Proposed resolution:</b></p>
12323 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
12324 <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#New">New</a>
12325 <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
12326 <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>
12327 <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>
12328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
12329 <p><b>Discussion:</b></p>
12331 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
12332 on the allocators are expected to be amortized constant time."?
12335 As I think I pointed out earlier, this is currently fiction for
12336 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
12337 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
12338 large objects. Would it be controversial to officially let these take
12339 time linear in the size of the object, as they already do in real life?
12342 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
12343 object if you mix in GC. But it's not really a new problem, and I think
12344 we'd be confusing things by leaving the bogus requirements there. The
12345 current requirement on <tt>allocate()</tt> is generally not important anyway,
12346 since it takes O(size) to construct objects in the resulting space.
12347 There are real performance issues here, but they're all concerned with
12348 the constants, not the asymptotic complexity.
12352 <p><b>Proposed resolution:</b></p>
12354 Change 20.1.2 [allocator.requirements]/2:
12359 -2- Table 39 describes the requirements on types manipulated through
12360 allocators. All the operations on the allocators are expected to be
12361 amortized constant time<ins>, except that <tt>allocate</tt> and
12362 <tt>construct</tt> may require time proportional to the size of the
12363 object allocated or constructed</ins>. Table 40 describes the
12364 requirements on allocator types.
12373 <h3><a name="753"></a>753. Move constructor in draft</h3>
12374 <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#Open">Open</a>
12375 <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
12376 <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>
12377 <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>
12378 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12379 <p><b>Discussion:</b></p>
12381 The draft standard n2369 uses the term <i>move constructor</i> in a few
12382 places, but doesn't seem to define it.
12386 <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
12392 <caption><tt>MoveConstructible</tt> requirements</caption>
12394 <th>expression</th> <th>post-condition</th>
12397 <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
12400 <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
12401 construction. <i>-- end note</i>]</td>
12407 (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
12411 So I assume the move constructor is the constructor that would be used
12412 in filling the above requirement.
12416 For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
12417 23.2.6.4 [vector.modifiers] we have
12421 <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
12422 not throw any exceptions.
12426 Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
12427 type which can be put into a <tt>vector</tt> has a move constructor (a copy
12428 constructor is also a move constructor). Secondly it means that for
12429 any <tt>value_type</tt> which has a throwing copy constructor and no other move
12430 constructor these functions cannot be used -- which I think will come
12431 as a shock to people who have been using such types in <tt>vector</tt> until
12436 I can see two ways to correct this. The simpler, which is presumably
12437 what was intended, is to say "If <tt>value_type</tt> has a move constructor and
12438 no copy constructor, the move constructor shall not throw any
12439 exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
12440 value of its parameter,".
12444 The other alternative is add to <tt>MoveConstructible</tt> the requirement that
12445 the expression does not throw. This would mean that not every type
12446 that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
12447 <tt>MoveConstructible</tt> requirements. It would mean changing requirements in
12448 various places in the draft to allow either <tt>MoveConstructible</tt> or
12449 <tt>CopyConstructible</tt>, but I think the result would be clearer and
12450 possibly more concise too.
12454 <p><b>Proposed resolution:</b></p>
12456 Add new defintions to 17.1 [definitions]:
12461 <b>move constructor</b>
12464 a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
12465 side effect during the construction.
12468 <b>move assignment operator</b>
12471 an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
12472 side effect during the assignment.
12475 <b>move assignment</b>
12478 use of the move assignment operator.
12483 Howard adds post-Bellevue:
12489 Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. <tt>reserve</tt> et. al. will use a move constructor
12490 if one is available, else it will use a copy constructor. A type may have both. If the move constructor is
12491 used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording
12492 is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am
12493 unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-)
12503 <h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
12504 <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#Ready">Ready</a>
12505 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p>
12506 <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>
12507 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12508 <p><b>Discussion:</b></p>
12510 A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
12513 <blockquote><pre>vector<int> v;
12515 v.swap(vector<int>(v)); // shrink to fit
12520 <pre>vector<int>(v).swap(v); // shrink to fit
12525 <pre>swap(v, vector<int>(v)); // shrink to fit
12530 A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
12533 <blockquote><pre>string s;
12536 </pre></blockquote>
12539 Neither of these is at all obvious to beginners, and even some
12540 experienced C++ programmers are not aware that shrink-to-fit is
12541 trivially available.
12544 Lack of explicit functions to perform these commonly requested
12545 operations makes vector and string less usable for non-experts. Because
12546 the idioms are somewhat obscure, code readability is impaired. It is
12547 also unfortunate that two similar vector-like containers use different
12548 syntax for the same operation.
12551 The proposed resolution addresses these concerns. The proposed function
12552 takes no arguments to keep the solution simple and focused.
12556 <p><b>Proposed resolution:</b></p>
12558 To Class template basic_string 21.3 [basic.string] synopsis,
12559 Class template vector 23.2.6 [vector] synopsis, and Class
12560 vector<bool> 23.2.7 [vector.bool] synopsis, add:
12564 void shrink_to_fit();
12565 </pre></blockquote>
12568 To basic_string capacity 21.3.4 [string.capacity] and vector
12569 capacity 23.2.6.2 [vector.capacity], add:
12573 <pre>void shrink_to_fit();
12576 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
12577 <tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
12578 allow latitude for implementation-specific optimizations.
12579 <i>-- end note</i>]
12588 <h3><a name="756"></a>756. Container adaptors push</h3>
12589 <p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12590 <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p>
12591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12592 <p><b>Discussion:</b></p>
12594 After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
12595 of the "emplace" type. At variance with that, still in n2461, we have
12596 two separate overloads, the C++03 one + one taking an rvalue reference
12597 in the container adaptors. Therefore, simply from a consistency point of
12598 view, I was wondering whether the container adaptors should be aligned
12599 with the specifications of the sequence container themselves: thus have
12600 a single <tt>push</tt> along the lines:
12603 <blockquote><pre>template<typename... _Args>
12605 push(_Args&&... __args)
12606 { c.push_back(std::forward<_Args>(__args)...); }
12607 </pre></blockquote>
12610 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
12615 <p><b>Proposed resolution:</b></p>
12617 Change 23.2.5.1.1 [queue.defn]:
12620 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
12621 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
12622 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
12623 </pre></blockquote>
12626 Change 23.2.5.2 [priority.queue]:
12629 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
12630 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
12631 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
12632 </pre></blockquote>
12635 Change 23.2.5.2.2 [priqueue.members]:
12639 <pre><del>void push(const value_type& x);</del>
12643 <del><i>Effects:</i></del>
12645 <blockquote><pre><del>c.push_back(x);</del>
12646 <del>push_heap(c.begin(), c.end(), comp);</del>
12647 </pre></blockquote>
12650 <pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>);
12656 <blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
12657 push_heap(c.begin(), c.end(), comp);
12658 </pre></blockquote>
12663 Change 23.2.5.3.1 [stack.defn]:
12666 <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del>
12667 <del>void push(value_type&& x) { c.push_back(std::move(x)); }</del>
12668 <ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins>
12669 </pre></blockquote>
12677 <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
12678 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
12679 <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
12680 <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>
12681 <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>
12682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12683 <p><b>Discussion:</b></p>
12685 Consider the following program:
12688 <blockquote><pre>int main() {
12689 shared_ptr<int> p(nullptr);
12692 </pre></blockquote>
12695 This program will fail to compile because <tt>shared_ptr</tt> uses the following
12696 template constructor to construct itself from pointers:
12699 <blockquote><pre>template <class Y> shared_ptr(Y *);
12700 </pre></blockquote>
12704 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
12705 the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
12706 deducible, so the above constructor will not be found. There are similar problems with the
12707 constructors that take a pointer and a <tt>deleter</tt> or a
12708 pointer, a <tt>deleter</tt> and an allocator, as well as the
12709 corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
12710 will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
12711 <tt>deleters</tt> or allocators or for <tt>reset()</tt>.
12715 In the case of the functions that take deleters, there is the additional
12716 question of what argument should be passed to the deleter when it is
12717 eventually called. There are two reasonable possibilities: <tt>nullptr</tt> or
12718 <tt>static_cast<T *>(0)</tt>, where <tt>T</tt> is the template argument of the
12719 <tt>shared_ptr</tt>. It is not immediately clear which of these is better. If
12720 <tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
12721 constructor, then <tt>d(static_cast<T*>(0))</tt> will compile and <tt>d(nullptr)</tt>
12722 will not. On the other hand, if <tt>D::operator()()</tt> takes a parameter that
12723 is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
12724 from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast<T *>(0))</tt> may not.
12734 The general idea is right, we need to be able to pass a nullptr to a
12735 shared_ptr, but there are a few borderline editorial issues here. (For
12736 example, the single-argument nullptr_t constructor in the class synopsis
12737 isn't marked explicit, but it is marked explicit in the proposed wording
12738 for 20.6.6.2.1. There is a missing empty parenthesis in the form that
12739 takes a nullptr_t, a deleter, and an allocator.)
12742 More seriously: this issue says that a shared_ptr constructed from a
12743 nullptr is empty. Since "empty" is undefined, it's hard to know whether
12744 that's right. This issue is pending on handling that term better.
12747 Peter suggests definition of empty should be "does not own anything"
12750 Is there an editorial issue that post-conditions should refer to get() =
12751 nullptr, rather than get() = 0?
12754 No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
12757 Seems there are no technical merits between NAD and Ready, comes down to
12758 "Do we intentially want to allow/disallow null pointers with these
12759 functions". Staw Poll - support null pointers 5 - No null pointers 0
12762 Move to Ready, modulo editorial comments
12767 post Bellevue Peter adds:
12773 The following wording changes are less intrusive:
12777 In 20.6.12.2.1 [util.smartptr.shared.const], add:
12780 <blockquote><pre>shared_ptr(nullptr_t);
12781 </pre></blockquote>
12787 <blockquote><pre>shared_ptr();
12788 </pre></blockquote>
12791 (Absence of explicit intentional.)
12795 <tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
12796 I'm not convinced of its utility.
12799 It's similarly not clear to me whether the deleter constructors need to be
12800 extended to take <tt>nullptr</tt>, but if they need to:
12806 <blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d);
12807 template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
12808 </pre></blockquote>
12814 <blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
12815 template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
12816 </pre></blockquote>
12819 Note that this changes the semantics of the new constructors such that they
12820 consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
12823 The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
12824 has repeatedly been requested by users, but the other additions that the
12825 proposed resolution makes are not supported by real world demand or
12826 motivating examples.
12829 It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
12830 constructor into a separate issue. Waiting for "empty" to be clarified is
12831 unnecessary; this is effectively an alias for the default constructor.
12837 <p><b>Proposed resolution:</b></p>
12839 Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
12842 <blockquote><pre>shared_ptr(nullptr_t);
12843 template <class D> shared_ptr(nullptr_t, D d);
12844 template <class D, class A> shared_ptr(nullptr_t, D d, A a);
12845 </pre></blockquote>
12848 Add the following methods to 20.6.12.2 [util.smartptr.shared]:
12851 <blockquote><pre>void reset(nullptr_t);
12852 template <class D> void reset(nullptr_t, D d);
12853 template <class D, class A> void reset(nullptr_t, D d, A a);
12854 </pre></blockquote>
12857 Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]:
12861 <pre> explicit shared_ptr(nullptr_t);
12865 <i>Effects:</i> Constructs an empty shared_ptr object.
12868 <i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>.
12871 <i>Throws:</i> nothing.
12877 <pre>template <class D> shared_ptr(nullptr_t, D d);
12878 template <class D, class A> shared_ptr<nullptr_t, D d, A a);
12882 <i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
12883 destructor of <tt>D</tt> shall not throw exceptions. The expression
12884 <tt>d(static_cast<T *>(0))</tt> shall be well-formed, shall have well defined behavior,
12885 and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
12886 The copy constructor and destructor of <tt>A</tt> shall not throw
12890 <i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
12891 and deleter <tt>d</tt>. The
12892 second constructor shall use a copy of <tt>a</tt> to allocate memory for
12896 <i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
12899 <i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
12900 resource other than memory could not be obtained.
12903 <i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called.
12909 Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
12913 <pre>void reset(nullptr_t);
12917 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr).swap(*this)</tt>.
12923 <pre>template <class D> void reset(nullptr_t, const D d)
12927 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d).swap(*this)</tt>.
12933 <pre>template <class D, class A> void reset(nullptr_t, D d, A a);
12937 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d, a).swap(*this)</tt>.
12948 <h3><a name="759"></a>759. A reference is not an object</h3>
12949 <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#Ready">Ready</a>
12950 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</p>
12951 <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>
12952 <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>
12953 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12954 <p><b>Discussion:</b></p>
12956 23.1 [container.requirements] says:
12960 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
12961 diagnostic required.
12965 A reference is not an object, but this sentence appears to claim so.
12969 What is probably meant here:
12972 An object bound to an rvalue
12973 reference parameter of a member function of a container shall not be
12974 an element of that container; no diagnostic required.
12979 <p><b>Proposed resolution:</b></p>
12981 Change 23.1 [container.requirements]:
12985 -12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
12986 <ins>An object bound to an rvalue
12987 reference parameter of a member function of a container shall not be
12989 of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o
12990 diagnostic required.
12999 <h3><a name="760"></a>760. The emplace issue</h3>
13000 <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#Open">Open</a>
13001 <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p>
13002 <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>
13003 <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>
13004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13005 <p><b>Discussion:</b></p>
13007 In an emplace member function the function parameter pack may be bound
13008 to a priori unlimited number of objects: some or all of them can be
13009 elements of the container itself. Apparently, in order to conform to the
13010 blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
13011 that possibility. A possible solution can involve extending the
13012 exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
13013 <tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
13014 this problem, can be efficiently implemented anyway
13018 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
13029 The proposed addition (13) is partially redundant with the existing
13030 paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
13031 does it not cover subelements and pointers?
13034 Resolution: Alan Talbot to rework language, then set state to Review.
13040 <p><b>Proposed resolution:</b></p>
13042 Add after 23.1 [container.requirements]/12:
13047 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
13048 diagnostic required.
13052 -13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
13053 sub-objects of elements of the container. No diagnostic required.
13065 <h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
13066 <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#Ready">Ready</a>
13067 <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
13068 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
13069 <p><b>Discussion:</b></p>
13071 The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts
13072 like <tt>operator[]()</tt>, except it throws an exception when the input key is
13073 not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
13074 key doesn't have a default constructor, it is an error if the key is
13075 not found, or the user wants to avoid accidentally adding an element to
13076 the map. For exactly these same reasons, <tt>at()</tt> would be equally useful
13077 in <tt>std::unordered_map</tt>.
13081 <p><b>Proposed resolution:</b></p>
13083 Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
13086 <blockquote><pre>mapped_type& at(const key_type& k);
13087 const mapped_type &at(const key_type &k) const;
13088 </pre></blockquote>
13091 Add the following definitions to 23.4.1.2 [unord.map.elem]:
13095 <pre>mapped_type& at(const key_type& k);
13096 const mapped_type &at(const key_type &k) const;
13100 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
13101 whose key is equivalent to <tt>k</tt>.
13104 <i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
13111 Bellevue: Editorial note: the "(unique)" differs from map.
13121 <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
13122 <p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13123 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p>
13124 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
13125 <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>
13126 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13127 <p><b>Discussion:</b></p>
13129 In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
13130 does currently not support incomplete types, because it
13131 gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
13132 an incomplete pointee type <tt>T</tt> automatically belongs to
13133 undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
13134 bullet. This is an unnecessary restriction and prevents
13135 many well-established patterns - like the bridge pattern -
13136 for <tt>std::unique_ptr</tt>.
13145 Move to open. The LWG is comfortable with the intent of allowing
13146 incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
13147 not comfortable with the wording. The specification for <tt>unique_ptr</tt>
13148 should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
13149 member functions, which ones require their types to be complete. The
13150 <tt>shared_ptr</tt> specification is careful to say that for each function, and
13151 we need the same level of care here. We also aren't comfortable with the
13152 "part of the operational semantic" language; it's not used elsewhere in
13153 the standard, and it's not clear what it means. We need a volunteer to
13154 produce new wording.
13158 <p><b>Proposed resolution:</b></p>
13160 The proposed changes in the following revision refers to the current state of
13161 N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed
13162 according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>.
13165 The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on
13166 type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings
13167 try to cope with that. If the committee sees less usefulness on relaxed
13168 constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation
13169 e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1:
13170 "<tt>T</tt> shall be a complete type, if used as template argument of
13171 <tt>unique_ptr<T[], D></tt>
13174 This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, but it seems not to cause any
13175 problems with this one,
13176 because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
13177 with the here discussed
13178 ones, provided that <tt>D::pointer</tt>'s operations (including default
13179 construction, copy construction/assignment,
13180 and pointer conversion) are specified <em>not</em> to throw, otherwise this
13181 would have impact on the
13182 current specification of <tt>unique_ptr</tt>.
13188 In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
13192 The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
13193 <tt>unique_ptr</tt> owns the object it holds a pointer to. A
13194 <tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
13195 <tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
13196 <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
13197 <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
13198 uses of <tt>unique_ptr</tt> include providing exception safety for
13199 dynamically allcoated memory, passing ownership of dynamically allocated
13200 memory to a function, and returning dynamically allocated memory from a
13201 function. -- <i>end note</i> ]
13207 20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
13212 N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
13213 The current wording says just this.
13221 In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
13226 <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
13227 of <tt>D</tt> shall not throw an exception.</del>
13228 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type.
13230 <tt>D</tt> shall be default constructible, and that construction
13231 shall not throw an exception.
13235 N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
13236 this point. I assume that the current wording is based on the
13237 corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
13238 requirement is necessary, because the corresponding c'tor *can* fail
13239 and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
13240 this regard. The *only* functions that must insist on well-formedness
13241 and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
13242 the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
13243 explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
13245 <tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
13246 we do *not* need the
13247 requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
13248 <tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
13249 potentially requires <tt>Convertible<Y*, X*></tt>, which
13250 again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt>
13258 Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
13259 of 12, but transferring the "requires" to 13:
13264 <i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
13267 N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
13268 well-formed/well-defined at this point. The current wording guarantees
13269 all what we need, namely that the initialization of both the <tt>T*</tt>
13270 pointer and the <tt>D</tt> deleter are well-formed and well-defined.
13277 20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
13280 <p>20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.</p>
13283 N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
13284 is completely defined, because it requires that <tt>Convertible<U*, T*></tt> is
13285 true. If the committee wishes this explicit requirement can be added,
13286 e.g. "<tt>U</tt> shall be a complete type."
13293 20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
13297 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
13298 shall have well-defined behavior, and shall not throw exceptions.
13301 N.B.: This requirement ensures that the whole responsibility on
13302 type-completeness of <tt>T</tt> is delegated to this expression.
13310 20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
13311 current editorial issue, that "must shall" has to be changed to
13312 "shall", but this change is not a special part of this resolution.
13316 N.B. The current wording is sufficient, because we can delegate all
13317 further requirements on the requirements of the effects clause
13324 20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
13327 N.B.: The current wording of p. 6 already implicitly guarantees that
13328 <tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt>
13329 is true, see (6)+(8).
13336 20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
13339 N.B.: Delegation to requirements of effects clause is sufficient.
13345 20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
13349 20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
13354 20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
13357 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
13358 shall have well-defined behavior, and shall not throw exceptions.
13363 20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
13368 20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
13369 before the current one:
13374 <i>Requires:</i> <tt>T</tt> shall be a complete type.
13377 N.B.: We need this requirement, because otherwise it is not
13378 guaranteed that the c'tors can fulfill their requirements to reject
13379 any type that is convertible to <tt>T*</tt>.
13386 20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
13390 <i>Requires:</i> <tt>i <</tt> the size of the array to which the stored pointer
13391 points. <tt>T</tt> shall be a complete type.
13396 20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
13401 <i>Requires:</i> <tt>T</tt> shall be a complete type. Does not accept pointer types
13402 which are convertible to <tt>T*</tt> (diagnostic required). [ Note: ...]
13405 N.B. Similar to (15) we need this requirement such that <tt>reset</tt> can
13406 reject types which are convertible to <tt>T*</tt>
13415 post Bellevue: Daniel provided revised wording.
13425 <h3><a name="765"></a>765. more on iterator validity</h3>
13426 <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#New">New</a>
13427 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
13428 <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>
13429 <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>
13430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
13431 <p><b>Discussion:</b></p>
13434 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
13435 defines the meaning of the term "invalid iterator" as one that may be
13441 Consider the following code:
13444 <pre> std::deque<int> x, y;
13445 std::deque<int>::iterator i = x.end(), j = y.end();
13450 Given that <code>swap()</code> is required not to invalidate iterators
13451 and using the definition above, what should be the expected result of
13452 comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
13453 and <code>y.end()</code>, respectively, after the <code>swap()</code>?
13458 I.e., is the expression below required to evaluate
13459 to <code>true</code>?
13462 <pre> i == y.end() && j == x.end()
13466 (There are at least two implementations where the expression
13467 returns <code>false</code>.)
13472 More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
13473 make any guarantees about whether iterators actually point to the same
13474 elements or be associated with the same containers after a
13475 non-invalidating operation as they did before?
13480 Here's a motivating example intended to demonstrate the importance of
13484 <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 }
13485 Container::iterator i = y.begin() + 1;
13486 Container::iterator j = y.end();
13488 std::find(i, j, 3);
13492 <code>swap()</code> guarantees that <code>i</code> and <code>j</code>
13493 continue to be valid. Unless the spec says that even though they are
13494 valid they may no longer denote a valid range the code above must be
13495 well-defined. Expert opinions on this differ as does the behavior of
13496 popular implementations for some standard <code>Containers</code>.
13501 <p><b>Proposed resolution:</b></p>
13510 <h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
13511 <p><b>Section:</b> 23.1 [container.requirements], 23.1.3.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13512 <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</p>
13513 <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>
13514 <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>
13515 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
13516 <p><b>Discussion:</b></p>
13518 23.1 [container.requirements]p10 states:
13523 Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
13524 additional requirements:
13530 <li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
13536 23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
13537 additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
13538 <tt>erase()</tt> members. However, 23.1 [container.requirements]p10
13539 does not mention 23.1.3.1 [unord.req.except] that specifies exception
13541 for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1
13542 offers the following guaratee for
13547 No <tt>erase()</tt> function throws an exception unless that exception
13548 is thrown by the container's Hash or Pred object (if any).
13556 According to 23.1 [container.requirements]p10 no
13557 <tt>erase()</tt> function should throw an exception unless otherwise
13558 specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees
13559 for unordered containers, allowing <tt>erase()</tt> to throw if
13560 predicate or hash function throws.
13564 In contrast, associative containers have no exception safety guarantees
13565 section so no <tt>erase()</tt> function should throw, <em>including
13566 <tt>erase(k)</tt></em> that needs to use the predicate function to
13567 perform its work. This means that the predicate of an associative
13568 container is not allowed to throw.
13577 <tt>erase(k)</tt> for associative containers is not allowed to throw. On
13578 the other hand, <tt>erase(k)</tt> for unordered associative containers
13579 is allowed to throw.
13582 <tt>erase(q)</tt> for associative containers is not allowed to throw. On
13583 the other hand, <tt>erase(q)</tt> for unordered associative containers
13584 is allowed to throw if it uses the hash or predicate.
13587 To fulfill 1), predicates of associative containers are not allowed to throw.
13588 Predicates of unordered associative containers are allowed to throw.
13591 2) breaks a widely used programming pattern (flyweight pattern) for
13592 unordered containers, where objects are registered in a global map in
13593 their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
13594 allowed to throw, the destructor of the object would need to rethrow the
13595 exception or swallow it, leaving the object registered.
13600 <p><b>Proposed resolution:</b></p>
13602 Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
13603 safety guarantees".
13608 1 For associative containers, no <tt>clear()</tt> function throws an exception.
13609 <tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
13610 the container's Pred object (if any).
13614 2 For associative containers, if an exception is thrown by any operation
13615 from within an <tt>insert()</tt> function inserting a single element, the
13616 <tt>insert()</tt> function has no effect.
13620 3 For associative containers, no <tt>swap</tt> function throws an exception
13621 unless that exception is thrown by the copy constructor or copy
13622 assignment operator of the container's Pred object (if any).
13627 Change 23.1.3.1 [unord.req.except]p1:
13631 For unordered associative containers, no <tt>clear()</tt> function
13632 throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
13633 <del>function</del> <ins>does not</ins> throw<del>s</del> an exception
13634 unless that exception is thrown by the container's Hash or Pred object
13639 Change 23.1 [container.requirements]p10 to add references to new sections:
13643 Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
13644 <del>and</del> [vector.modifiers]<ins>, [associative.req.except],
13645 [unord.req.except]</ins>) all container types defined in this clause meet
13646 the following additional requirements:
13650 Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
13656 no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
13657 by the copy constructor or assignment operator of the container's
13658 Compare object (if any; see [associative.reqmts])</del>.
13669 <h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
13670 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13671 <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p>
13672 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
13673 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
13674 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13675 <p><b>Discussion:</b></p>
13677 Playing with g++'s C++0X mode, I noticed that the following
13678 code, which used to compile:
13681 <blockquote><pre>#include <vector>
13685 std::vector<char *> v;
13688 </pre></blockquote>
13691 now fails with the following error message:
13694 <blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
13695 function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*,
13696 _Args&& ...) [with _Args = int, _Tp = char*]':
13697 .../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
13698 std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with
13699 _Args = int, _Tp = char*, _Alloc = std::allocator<char*>]'
13700 test.cpp:6: instantiated from here
13701 .../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
13702 conversion from 'int' to 'char*'
13706 As far as I know, g++ follows the current draft here.
13709 Does the committee really intend to break compatibility for such cases?
13719 I just noticed that <tt>std::pair</tt> has the same issue.
13720 The following now fails with GCC's -std=c++0x mode:
13723 <blockquote><pre>#include <utility>
13727 std::pair<char *, char *> p (0,0);
13729 </pre></blockquote>
13732 I have not made any general audit for such problems elsewhere.
13737 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>
13748 Motivation is to handle the old-style int-zero-valued NULL pointers.
13749 Problem: this solution requires concepts in some cases, which some users
13750 will be slow to adopt. Some discussion of alternatives involving
13751 prohibiting variadic forms and additional library-implementation
13755 Discussion of "perfect world" solutions, the only such solution put
13756 forward being to retroactively prohibit use of the integer zero for a
13757 NULL pointer. This approach was deemed unacceptable given the large
13758 bodies of pre-existing code that do use integer zero for a NULL pointer.
13761 Another approach is to change the member names. Yet another approach is
13762 to forbid the extension in absence of concepts.
13765 Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</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-closed.html#763">763</a>) will be subsumed into a
13766 paper to be produced by Alan Talbot in time for review at the 2008
13767 meeting in France. Once this paper is produced, these issues will be
13774 <p><b>Proposed resolution:</b></p>
13776 Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
13782 <th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
13787 <tt>a.push_front(t)</tt>
13793 <tt>a.insert(a.begin(), t)</tt><br>
13794 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
13797 <tt>list, deque</tt>
13803 <tt>a.push_front(rv)</tt>
13809 <tt>a.insert(a.begin(), rv)</tt><br>
13810 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
13813 <tt>list, deque</tt>
13819 <tt>a.push_back(t)</tt>
13825 <tt>a.insert(a.end(), t)</tt><br>
13826 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
13829 <tt>list, deque, vector, basic_string</tt>
13835 <tt>a.push_back(rv)</tt>
13841 <tt>a.insert(a.end(), rv)</tt><br>
13842 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
13845 <tt>list, deque, vector, basic_string</tt>
13853 Change the synopsis in 23.2.2 [deque]:
13856 <blockquote><pre><ins>void push_front(const T& x);</ins>
13857 <ins>void push_front(T&& x);</ins>
13858 <ins>void push_back(const T& x);</ins>
13859 <ins>void push_back(T&& x);</ins>
13860 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
13861 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13862 </pre></blockquote>
13865 Change 23.2.2.3 [deque.modifiers]:
13868 <blockquote><pre><ins>void push_front(const T& x);</ins>
13869 <ins>void push_front(T&& x);</ins>
13870 <ins>void push_back(const T& x);</ins>
13871 <ins>void push_back(T&& x);</ins>
13872 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
13873 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13874 </pre></blockquote>
13877 Change the synopsis in 23.2.4 [list]:
13880 <blockquote><pre><ins>void push_front(const T& x);</ins>
13881 <ins>void push_front(T&& x);</ins>
13882 <ins>void push_back(const T& x);</ins>
13883 <ins>void push_back(T&& x);</ins>
13884 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
13885 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13886 </pre></blockquote>
13889 Change 23.2.4.3 [list.modifiers]:
13892 <blockquote><pre><ins>void push_front(const T& x);</ins>
13893 <ins>void push_front(T&& x);</ins>
13894 <ins>void push_back(const T& x);</ins>
13895 <ins>void push_back(T&& x);</ins>
13896 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args);
13897 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13898 </pre></blockquote>
13901 Change the synopsis in 23.2.6 [vector]:
13904 <blockquote><pre><ins>void push_back(const T& x);</ins>
13905 <ins>void push_back(T&& x);</ins>
13906 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13907 </pre></blockquote>
13910 Change 23.2.6.4 [vector.modifiers]:
13913 <blockquote><pre><ins>void push_back(const T& x);</ins>
13914 <ins>void push_back(T&& x);</ins>
13915 template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args);
13916 </pre></blockquote>
13925 <h3><a name="768"></a>768. Typos in [atomics]?</h3>
13926 <p><b>Section:</b> 29.4.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13927 <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
13928 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
13929 <p><b>Discussion:</b></p>
13931 in the latest publicly available draft, paper
13932 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
13933 in section 29.4.3 [atomics.types.generic], the following specialization of the template
13934 <tt>atomic<></tt> is provided for pointers:
13937 <blockquote><pre>template <class T> struct atomic<T*> : atomic_address {
13938 T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
13939 T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
13941 atomic() = default;
13942 constexpr explicit atomic(T);
13943 atomic(const atomic&) = delete;
13944 atomic& operator=(const atomic&) = delete;
13946 T* operator=(T*) volatile;
13947 T* operator++(int) volatile;
13948 T* operator--(int) volatile;
13949 T* operator++() volatile;
13950 T* operator--() volatile;
13951 T* operator+=(ptrdiff_t) volatile;
13952 T* operator-=(ptrdiff_t) volatile;
13954 </pre></blockquote>
13957 First of all, there is a typo in the non-default constructor which
13958 should take a <tt>T*</tt> rather than a <tt>T</tt>.
13962 As you can see, the specialization redefine and therefore hide a few
13963 methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
13964 <tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
13965 to the other methods, in particular these ones:
13968 <blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
13969 T* load( memory_order = memory_order_seq_cst ) volatile;
13970 T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
13971 bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
13972 bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
13973 </pre></blockquote>
13977 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
13979 definition of the specialization <tt>atomic<T*></tt> matches the one in the
13980 draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
13981 and <tt>compare_swap()</tt> are indeed present.
13985 Strangely, the example implementation does not redefine the method
13986 <tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
13987 hiding the <tt>void*</tt> signature from the base class makes the class
13988 error-prone to say the least: it lets you assign pointers of any type to
13989 a <tt>T*</tt>, without any hint from the compiler.
13993 Is there a true intent to remove them from the specialization or are
13994 they just missing from the definition because of a mistake?
14004 The proposed revisions are accepted.
14007 Further discussion: why is the ctor labeled "constexpr"? Lawrence said
14008 this permits the object to be statically initialized, and that's
14009 important because otherwise there would be a race condition on
14015 <p><b>Proposed resolution:</b></p>
14017 Change the synopsis in 29.4.3 [atomics.types.generic]:
14020 <blockquote><pre>template <class T> struct atomic<T*> : atomic_address {
14021 <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
14022 <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
14023 <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
14024 <ins>bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;</ins>
14025 <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
14027 T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
14028 T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
14030 atomic() = default;
14031 constexpr explicit atomic(T<ins>*</ins>);
14032 atomic(const atomic&) = delete;
14033 atomic& operator=(const atomic&) = delete;
14035 T* operator=(T*) volatile;
14036 T* operator++(int) volatile;
14037 T* operator--(int) volatile;
14038 T* operator++() volatile;
14039 T* operator--() volatile;
14040 T* operator+=(ptrdiff_t) volatile;
14041 T* operator-=(ptrdiff_t) volatile;
14043 </pre></blockquote>
14051 <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
14052 <p><b>Section:</b> 20.5.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14053 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
14054 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14055 <p><b>Discussion:</b></p>
14057 N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed
14058 (implicit) conversion operator to "unspecified-bool-type" by the new
14059 explicit bool conversion, but the inverse conversion should also
14060 use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
14065 <p><b>Proposed resolution:</b></p>
14068 In 20.5 [function.objects], header <tt><functional></tt> synopsis replace:
14071 <blockquote><pre>template<class R, class... ArgTypes>
14072 bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14073 template<class R, class... ArgTypes>
14074 bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
14075 template<class R, class... ArgTypes>
14076 bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14077 template<class R, class... ArgTypes>
14078 bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
14079 </pre></blockquote>
14082 In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
14085 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14087 function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14088 </pre></blockquote>
14091 In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace:
14094 <blockquote><pre>template <class R, class... ArgTypes>
14095 bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14096 template <class R, class... ArgTypes>
14097 bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
14098 template <class R, class... ArgTypes>
14099 bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14100 template <class R, class... ArgTypes>
14101 bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
14102 </pre></blockquote>
14105 In 20.5.15.2.1 [func.wrap.func.con], replace
14108 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14110 function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14111 </pre></blockquote>
14114 In 20.5.15.2.6 [func.wrap.func.nullptr], replace
14117 <blockquote><pre>template <class R, class... ArgTypes>
14118 bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14119 template <class R, class... ArgTypes>
14120 bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
14121 </pre></blockquote>
14127 <blockquote><pre>template <class R, class... ArgTypes>
14128 bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14129 template <class R, class... ArgTypes>
14130 bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
14131 </pre></blockquote>
14139 <h3><a name="770"></a>770. std::function should use rvalue swap</h3>
14140 <p><b>Section:</b> 20.5.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14141 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
14142 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14143 <p><b>Discussion:</b></p>
14145 It is expected that typical implementations of <tt>std::function</tt> will
14146 use dynamic memory allocations at least under given conditions,
14147 so it seems appropriate to change the current lvalue swappabilty of
14148 this class to rvalue swappability.
14152 <p><b>Proposed resolution:</b></p>
14154 In 20.5 [function.objects], header <tt><functional></tt> synopsis, just below of
14157 <blockquote><pre>template<class R, class... ArgTypes>
14158 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
14159 <ins>template<class R, class... ArgTypes>
14160 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
14161 template<class R, class... ArgTypes>
14162 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
14163 </pre></blockquote>
14166 In 20.5.15.2 [func.wrap.func] class <tt>function</tt> definition, change
14169 <blockquote><pre>void swap(function&<ins>&</ins>);
14170 </pre></blockquote>
14173 In 20.5.15.2 [func.wrap.func], just below of
14176 <blockquote><pre>template <class R, class... ArgTypes>
14177 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
14178 <ins>template <class R, class... ArgTypes>
14179 void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
14180 template <class R, class... ArgTypes>
14181 void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins>
14182 </pre></blockquote>
14185 In 20.5.15.2.2 [func.wrap.func.mod] change
14188 <blockquote><pre>void swap(function&<ins>&</ins> other);
14189 </pre></blockquote>
14192 In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
14195 <blockquote><pre><ins>template<class R, class... ArgTypes>
14196 void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
14197 template<class R, class... ArgTypes>
14198 void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins>
14199 </pre></blockquote>
14207 <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
14208 <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
14209 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
14210 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
14211 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
14212 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
14213 <p><b>Discussion:</b></p>
14215 The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
14216 have throws clauses (paragraphs 8 and 16) which say:
14220 <i>Throws:</i> nothing
14224 Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
14225 this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
14226 constructors can fail due to out-of-memory conditions. Either these throws
14227 clauses should be removed or should be more detailled like:
14231 <i>Throws:</i> Nothing if the string construction throws nothing
14235 Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
14236 overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
14237 header <tt><string></tt> synopsis of 21.2 [string.classes] is correct in this
14243 <p><b>Proposed resolution:</b></p>
14245 In 21.4 [string.conversions], remove the paragraphs 8 and 16.
14249 <pre>string to_string(long long val);
14250 string to_string(unsigned long long val);
14251 string to_string(long double val);
14254 <del><i>Throws:</i> nothing</del>
14259 <pre><ins>w</ins>string to_wstring(long long val);
14260 <ins>w</ins>string to_wstring(unsigned long long val);
14261 <ins>w</ins>string to_wstring(long double val);
14264 <del><i>Throws:</i> nothing</del>
14274 <h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3>
14275 <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14276 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
14277 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
14278 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
14279 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14280 <p><b>Discussion:</b></p>
14282 The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
14287 <i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
14288 representation of the value of its argument that would be generated by
14289 calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
14290 or <tt>L"%f"</tt>, respectively.
14294 Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
14295 the 2nd edition of ISO 9899, and the first and the second corrigenda from
14296 2001-09-01 and 2004-11-15). What probably meant here is the function
14297 <tt>swprintf</tt> from <tt><wchar.h>/<cwchar></tt>, but this has the non-equivalent
14301 <blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
14302 const wchar_t * restrict format, ...);
14303 </pre></blockquote>
14306 therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
14311 <p><b>Proposed resolution:</b></p>
14313 Change the current wording of 21.4 [string.conversions]/p. 15 to:
14317 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
14318 <tt>wstring</tt> object holding the character representation of the
14319 value of its argument that would be generated by calling
14320 <tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
14321 val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
14322 <tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
14323 designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
14327 [Hint to the editor: The resolution also adds to mention the name of
14328 the format specifier "fmt"]
14332 I also would like to remark that the current wording of it's equivalent
14333 paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
14337 Change the current wording of 21.4 [string.conversions]/p. 7 to:
14341 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
14342 character representation of the value of its argument that would be
14343 generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
14344 <tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
14345 character buffer of sufficient size</ins>.
14354 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
14355 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14356 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p>
14357 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
14358 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
14359 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14360 <p><b>Discussion:</b></p>
14362 It appears most containers declare but do not define a member-swap
14367 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
14368 member-swap function!
14369 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
14374 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
14375 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
14380 A quick survey of clause 23 shows that the following containers provide a
14381 definition for member-swap:
14384 <blockquote><pre>array
14388 </pre></blockquote>
14391 Whereas the following declare it, but do not define the semantics:
14394 <blockquote><pre>deque
14402 unordered_multi_map
14403 unordered_multi_set
14405 </pre></blockquote>
14408 Suggested resolution:
14411 Provide a definition for each of the affected containers...
14420 Move to Open and ask Alisdair to provide wording.
14424 <p><b>Proposed resolution:</b></p>
14426 Wording provided in
14427 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
14435 <h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
14436 <p><b>Section:</b> 20.3.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14437 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
14438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14439 <p><b>Discussion:</b></p>
14441 The tuple element access API identifies the element in the sequence
14442 using signed integers, and then goes on to enforce the requirement that
14443 I be >= 0. There is a much easier way to do this - declare I as
14447 In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
14450 A second suggestion is that it is hard to imagine an API that deduces
14451 and index at compile time and returns a reference throwing an exception.
14452 Add a specific <em>Throws:</em> Nothing paragraph to each element
14456 In addition to <code>tuple</code>, update the API applies to
14457 <code>pair</code> and <code>array</code>, and should be updated
14462 A third observation is that the return type of the <code>get</code>
14463 functions for <code>std::pair</code> is pseudo-code, but it is not
14464 clearly marked as such. There is actually no need for pseudo-code as
14465 the return type can be specified precisely with a call to
14466 <code>tuple_element</code>. This is already done for
14467 <code>std::tuple</code>, and <code>std::array</code> does not have a
14468 problem as all elements are of type <code>T</code>.
14472 <p><b>Proposed resolution:</b></p>
14474 Update header <utility> synopsis in 20.2 [utility]
14476 <pre><em>// 20.2.3, tuple-like access to pair:</em>
14477 template <class T> class tuple_size;
14478 template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element;
14480 template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
14481 template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
14482 template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
14484 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
14485 <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&);
14486 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
14487 const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&);
14490 Update <strong>20.2.3 [pairs] Pairs</strong>
14492 <pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
14493 <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&);
14494 template<<del>int</del><ins>size_t</ins> I, class T1, class T2>
14495 const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&);
14498 <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>
14501 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>.
14504 <ins><em>Throws:</em> Nothing.</ins>
14509 Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below:
14511 <pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em>
14512 template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >;
14514 <em>// 20.3.1.4, element access:</em>
14515 template <<del>int</del><ins>size_t</ins> I, class... Types>
14516 typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
14517 template <<del>int</del><ins>size_t</ins> I, class ... types>
14518 typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
14522 Update <strong>20.3.1.4 [tuple.helper] Tuple helper classes</strong>
14524 <pre>template <<del>int</del><ins>size_t</ins> I, class... Types>
14525 class tuple_element<I, tuple<Types...> > {
14530 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.
14533 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.
14536 Update <strong>20.3.1.5 [tuple.elem] Element access</strong>
14538 <pre>template <<del>int</del><ins>size_t</ins> I, class... types >
14539 typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
14541 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.
14543 2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
14545 <ins><em>Throws:</em> Nothing.</ins>
14546 <pre>template <<del>int</del><ins>size_t</ins> I, class... types>
14547 typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
14550 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.
14553 4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
14556 <ins><em>Throws:</em> Nothing.</ins>
14561 Update header <array> synopsis in 20.2 [utility]
14563 <pre>template <class T> class tuple_size; <em>// forward declaration</em>
14564 template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em>
14565 template <class T, size_t N>
14566 struct tuple_size<array<T, N> >;
14567 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
14568 struct tuple_element<I, array<T, N> >;
14569 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
14570 T& get(array<T, N>&);
14571 template <<del>int</del><ins>size_t</ins> I, class T, size_t N>
14572 const T& get(const array<T, N>&);
14576 Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
14578 <pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type
14581 3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds.
14584 4 <em>Value:</em> The type <code>T</code>.
14586 <pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a);
14589 5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
14592 <em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
14595 <ins><em>Throws:</em> Nothing.</ins>
14597 <pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a);
14600 6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds.
14603 7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
14606 <ins><em>Throws:</em> Nothing.</ins>
14611 Bellevue: Note also that the phrase "The program is ill-formed if I is
14612 out of bounds" in the requires clauses are probably unnecessary, and
14613 could be removed at the editor's discretion. Also std:: qualification
14614 for pair is also unnecessary.
14621 <h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
14622 <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
14623 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p>
14624 <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>
14625 <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>
14626 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
14627 <p><b>Discussion:</b></p>
14629 The class template array synopsis in 23.2.1 [array]/3 declares a member
14633 <blockquote><pre>void assign(const T& u);
14634 </pre></blockquote>
14637 which's semantic is no-where described. Since this signature is
14638 not part of the container requirements, such a semantic cannot
14639 be derived by those.
14643 I found only one reference to this function in the issue list,
14644 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
14648 what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array?
14652 which does not answer the basic question of this issue.
14656 If this function shall be part of the <tt>std::array</tt>, it's probable
14657 semantic should correspond to that of <tt>boost::array</tt>, but of
14658 course such wording must be added.
14662 <p><b>Proposed resolution:</b></p>
14664 Just after the section 23.2.1.4 [array.data] add the following new section:
14668 23.2.1.5 array::fill [array.fill]
14672 <pre>void fill(const T& u);
14676 1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
14681 [N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
14682 section. If it had, then <tt>assign</tt> would naturally belong to it]
14686 Change the synopsis in 23.2.1 [array]/3:
14689 <blockquote><pre>template <class T, size_t N>
14692 void <del>assign</del> <ins>fill</ins>(const T& u);
14694 </pre></blockquote>
14704 Suggest substituting "fill" instead of "assign".
14707 Set state to Review given substitution of "fill" for "assign".
14715 <h3><a name="777"></a>777. Atomics Library Issue</h3>
14716 <p><b>Section:</b> 29.4.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14717 <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p>
14718 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14719 <p><b>Discussion:</b></p>
14721 The load functions are defined as
14724 <blockquote><pre>C atomic_load(volatile A* object);
14725 C atomic_load_explicit(volatile A* object, memory_order);
14726 C A::load(memory_order order = memory_order_seq_cst) volatile;
14727 </pre></blockquote>
14730 which prevents their use in <tt>const</tt> contexts.
14734 post Bellevue Peter adds:
14740 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
14741 subtle point here. Atomic loads do not generally write to the object, except
14742 potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
14743 architecture, a dummy write with the same value may be required to be issued
14744 by the atomic load to maintain sequential consistency. This, in turn, may
14745 make the following code:
14748 <blockquote><pre>const atomic_int x{};
14754 </pre></blockquote>
14757 dump core under a straightforward implementation that puts const objects in
14758 a read-only section.
14761 There are ways to sidestep the problem, but it needs to be considered.
14764 The tradeoff is between making the data member of the atomic types
14765 mutable and requiring the user to explicitly mark atomic members as
14766 mutable, as is already the case with mutexes.
14772 <p><b>Proposed resolution:</b></p>
14774 Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
14777 <blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
14778 C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
14779 C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
14780 </pre></blockquote>
14788 <h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
14789 <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#Ready">Ready</a>
14790 <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
14791 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
14792 <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>
14793 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14794 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
14795 <p><b>Discussion:</b></p>
14797 A small issue with <tt>std::bitset</tt>: it does not have any constructor
14798 taking a string literal, which is clumsy and looks like an oversigt when
14799 we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
14806 <blockquote><pre>explicit bitset( const char* str );
14807 </pre></blockquote>
14814 <p><b>Proposed resolution:</b></p>
14816 Add to synopsis in 23.3.5 [template.bitset]
14819 <blockquote><pre>explicit bitset( const char* str );
14820 </pre></blockquote>
14823 Add to synopsis in 23.3.5.1 [bitset.cons]
14826 <blockquote><pre>explicit bitset( const char* str );
14829 <i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
14839 <h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
14840 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14841 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
14842 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
14843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14844 <p><b>Discussion:</b></p>
14846 The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
14847 <tt>remove_copy[_if]</tt>,
14848 which seems to be an oversight.
14852 <p><b>Proposed resolution:</b></p>
14854 In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
14858 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
14859 and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
14868 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
14869 and <tt>[result,result + (last - first))</tt> shall not overlap.
14870 <ins>The result of the expression <tt>*first</tt> shall
14871 be writable to the output iterator.</ins>
14880 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
14881 <p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14882 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
14883 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
14884 <p><b>Discussion:</b></p>
14886 Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
14890 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
14891 have no Requires element and the Effects element contains some requirements,
14892 which is probably editorial. Worse is that:
14897 no assignment requirements are specified (neither implicit nor explicit).
14901 the effects clause just speaks of "merges", which is badly worded
14902 near to a circular definition.
14906 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
14907 function arguments or otherwise.
14911 p. 2 says "according to the ordering defined by comp" which is both
14912 incomplete (because
14913 this excludes the first variant with <) and redundant (because the
14914 following subordinate
14915 clause mentions comp again)
14921 <p><b>Proposed resolution:</b></p>
14923 In 25.3.4 [alg.merge] replace p.1+ 2:
14928 <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
14929 <tt>[first2,last2)</tt> into the range
14930 <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
14931 <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
14932 - first1) + (last2 - first2))</tt>, such that resulting range will be
14933 sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
14934 <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or,
14935 respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
14939 <ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing
14940 order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
14941 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i < *(i - 1)</tt> or
14942 <tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
14943 shall be writable to the output iterator.</ins>
14948 [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
14949 therefore proposing to
14950 insert ", respectively," between both predicate tests. This is no
14951 strictly necessary as
14952 other parts of <tt><algorithm></tt> show, just a matter of consistency]
14961 <h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
14962 <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#Ready">Ready</a>
14963 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p>
14964 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
14965 <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>
14966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14967 <p><b>Discussion:</b></p>
14969 A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis])
14970 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
14971 some complex functions that are missing in C++. These are:
14976 7.3.9.4: (required elements of the C99 library)<br>
14977 The <tt>cproj</tt> functions
14980 7.26.1: (optional elements of the C99 library)<br>
14981 <pre>cerf cerfc cexp2
14982 cexpm1 clog10 clog1p
14983 clog2 clgamma ctgamma
14989 I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
14990 C++ functions. This addition is easy to do in one sentence (delegation to C99
14995 Please note also that the current entry <tt>polar</tt>
14996 in 26.3.9 [cmplx.over]/1
14997 should be removed from the mentioned overload list. It does not make sense to require that a
14998 function already expecting <em>scalar</em> arguments
14999 should cast these arguments into corresponding
15000 <tt>complex<T></tt> arguments, which are not accepted by
15005 <p><b>Proposed resolution:</b></p>
15007 In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
15010 <blockquote><pre>template<class T> complex<T> conj(const complex<T>&);
15011 <ins>template<class T> complex<T> proj(const complex<T>&);</ins>
15012 template<class T> complex<T> fabs(const complex<T>&);
15013 </pre></blockquote>
15016 In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
15020 <pre>template<class T> complex<T> proj(const complex<T>& x);
15024 <i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
15025 subclause 7.3.9.4."
15030 In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
15036 The following function templates shall have additional overloads:
15038 <blockquote><pre>arg norm
15039 conj <del>polar</del> <ins>proj</ins>
15041 </pre></blockquote>
15050 <h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
15051 <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#Ready">Ready</a>
15052 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</p>
15053 <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>
15054 <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>
15055 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
15056 <p><b>Discussion:</b></p>
15058 Part of the resolution of n2423, issue 8 was the proposal to
15059 extend the <tt>seed_seq</tt> constructor accepting an input range
15060 as follows (which is now part of N2461):
15063 <blockquote><pre>template<class InputIterator,
15064 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
15065 seed_seq(InputIterator begin, InputIterator end);
15066 </pre></blockquote>
15069 First, the expression <tt>iterator_traits<InputIterator>::value_type</tt>
15070 is invalid due to missing <tt>typename</tt> keyword, which is easy to
15075 Second (and worse), while the language now supports default
15076 template arguments of function templates, this customization
15077 point via the second <tt>size_t</tt> template parameter is of no advantage,
15078 because <tt>u</tt> can never be deduced, and worse - because it is a
15079 constructor function template - it can also never be explicitly
15080 provided (14.8.1 [temp.arg.explicit]/7).
15084 The question arises, which advantages result from a compile-time
15085 knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
15086 suffices, this parameter should be provided as normal function
15087 default argument [Resolution marked (A)], if compile-time knowledge
15088 is important, this could be done via a tagging template or more
15089 user-friendly via a standardized helper generator function
15090 (<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
15100 Fermilab does not have a strong opinion. Would prefer to go with
15101 solution A. Bill agrees that solution A is a lot simpler and does the
15105 Proposed Resolution: Accept Solution A.
15110 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
15115 <p><b>Proposed resolution:</b></p>
15119 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
15122 <blockquote><pre>class seed_seq
15126 template<class InputIterator<del>,
15127 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
15128 seed_seq(InputIterator begin, InputIterator end<ins>,
15129 size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>);
15132 </pre></blockquote>
15135 and do a similar replacement in the member description between
15142 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
15143 member description between p.3 and p.4 replace:
15146 <blockquote><pre>template<class InputIterator<del>,
15147 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
15148 seed_seq(InputIterator begin, InputIterator end);
15149 <ins>template<class InputIterator, size_t u>
15150 seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
15151 </pre></blockquote>
15154 In 26.4.2 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the
15155 class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
15156 after the class <tt>seed_seq</tt> definition add:
15159 <blockquote><pre>template<size_t u, class InputIterator>
15160 seed_seq make_seed_seq(InputIterator begin, InputIterator end);
15161 </pre></blockquote>
15164 In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
15169 The first constructor behaves as if it would provide an
15170 integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
15171 <tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>.
15174 The second constructor uses an implementation-defined mechanism
15175 to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
15176 is called by the function <tt>make_seed_seq</tt>.
15181 In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
15185 <pre>template<size_t u, class InputIterator>
15186 seed_seq make_seed_seq(InputIterator begin, InputIterator end);
15190 where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
15193 <i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
15207 <h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
15208 <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#Ready">Ready</a>
15209 <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
15210 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
15211 <p><b>Discussion:</b></p>
15213 The current working paper
15214 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
15215 integrated just before Bellevue) is
15216 not completely clear whether a given <tt>thread::id</tt> value may be reused once
15217 a thread has exited and has been joined or detached. Posix allows
15218 thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is
15219 not completely clear whether this originally was the right decision, it
15220 is clearly the established practice, and we believe it was always the
15221 intent of the C++ threads API to follow Posix and allow this. Howard
15222 Hinnant's example implementation implicitly relies on allowing reuse
15223 of ids, since it uses Posix thread ids directly.
15227 It is important to be clear on this point, since it the reuse of thread
15228 ids often requires extra care in client code, which would not be
15229 necessary if thread ids were unique across all time. For example, a
15230 hash table indexed by thread id may have to be careful not to associate
15231 data values from an old thread with a new one that happens to reuse the
15232 id. Simply removing the old entry after joining a thread may not be
15233 sufficient, if it creates a visible window between the join and removal
15234 during which a new thread with the same id could have been created and
15235 added to the table.
15239 post Bellevue Peter adds:
15245 There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
15246 reconsider fixing this by disallowing reuse, rather than explicitly allowing
15247 it. Dealing with thread id reuse is an incredibly painful exercise that
15248 would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
15252 In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
15253 atomically in a lock-free manner, as motivated by the recursive lock
15258 <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>
15264 <p><b>Proposed resolution:</b></p>
15266 Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
15271 An object of type <code>thread::id</code> provides
15272 a unique identifier for each thread of execution
15273 and a single distinct value for all thread objects
15274 that do not represent a thread of execution ([thread.threads.class]).
15275 Each thread of execution has a <code>thread::id</code>
15276 that is not equal to the <code>thread::id</code>
15277 of other threads of execution
15278 and that is not equal to
15279 the <code>thread::id</code> of <code>std::thread</code> objects
15280 that do not represent threads of execution.
15281 <ins>The library may reuse the value of a <code>thread::id</code> of a
15282 terminated thread that can no longer be joined.</ins>
15291 <h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
15292 <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15293 <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
15294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
15295 <p><b>Discussion:</b></p>
15297 Table 16 of TR1 requires that all Pseudo Random Number generators have a
15300 <blockquote><pre>seed(integer-type s)
15301 </pre></blockquote>
15304 member function that is equivalent to:
15307 <blockquote><pre>mygen = Generator(s)
15308 </pre></blockquote>
15311 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
15314 <blockquote><pre>template <class Gen>
15316 </pre></blockquote>
15319 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
15323 So... is this a bug in TR1?
15326 <p>This is a real issue BTW, since the Boost implementation does adhere
15327 to the requirements of Table 16, while at least one commercial
15328 implementation does not and follows a strict adherence to sections
15329 5.1.4.5 and 5.1.4.6 instead.
15338 Both engines do have the necessary
15339 constructor, therefore the omission of the <tt>seed()</tt> member
15340 functions appears to be an oversight.
15345 <p><b>Proposed resolution:</b></p>
15354 <h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
15355 <p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15356 <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p>
15357 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
15358 <p><b>Discussion:</b></p>
15360 The draft C++0x thread library requires that the time points of type
15361 <tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
15362 Universal Time (UTC) (section X [datetime.system]). This can lead to
15363 surprising behavior when a library user performs a duration-based wait,
15364 such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
15365 problem may be found in the
15366 <a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
15367 section in POSIX, but in summary:
15372 Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
15373 equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
15374 to address the problem of spurious wakeups.
15378 The typical use of the timed wait operations is to perform a relative
15379 wait. This may be achieved by first calculating an absolute time as the
15380 sum of the current time and the desired duration. In fact, the C++0x
15381 thread library includes duration-based overloads of
15382 <tt>condition_variable::timed_wait()</tt> that behave as if by calling the
15383 corresponding absolute time overload with a time point value of
15384 <tt>get_system_time() + rel_time</tt>.
15388 A UTC clock may be affected by changes to the system time, such as
15389 synchronization with an external source, leap seconds, or manual changes
15394 Should the clock change during a timed wait operation, the actual
15395 duration of the wait will not be the expected length. For example, a
15396 user may intend a timed wait of one second duration but, due to an
15397 adjustment of the system clock backwards by a minute, the wait instead
15403 POSIX solves the problem by introducing a new monotonic clock, which is
15404 unaffected by changes to the system time. When a condition variable is
15405 initialized, the user may specify whether the monotonic clock is to be
15406 used. (It is worth noting that on POSIX systems it is not possible to
15407 use <tt>condition_variable::native_handle()</tt> to access this facility, since
15408 the desired clock type must be specified during construction of the
15409 condition variable object.)
15413 In the context of the C++0x thread library, there are added dimensions
15414 to the problem due to the need to support platforms other than POSIX:
15419 Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
15423 Some environments do not have a monotonic clock, but do have a UTC clock.
15427 The Microsoft Windows API's synchronization functions use relative
15428 timeouts based on an implied monotonic clock. A program that switches
15429 from the Windows API to the C++0x thread library will now find itself
15430 susceptible to clock changes.
15435 One possible minimal solution:
15440 Strike normative references to UTC and an epoch based on 1970-01-01.
15444 Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
15445 implementation-defined (i.e standard library implementors may choose the
15446 appropriate underlying clock based on the capabilities of the target
15451 Add a non-normative note encouraging use of a monotonic clock.
15455 Remove <tt>system_time::seconds_since_epoch()</tt>.
15459 Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
15460 = 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
15466 <p><b>Proposed resolution:</b></p>
15475 <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
15476 <p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15477 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p>
15478 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
15479 <p><b>Discussion:</b></p>
15481 In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
15485 At most <tt>log(last - first) + 2</tt> comparisons.
15489 This should be precised and brought in line with the nomenclature used for
15490 <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
15494 All existing libraries I'm aware of, delegate to
15495 <tt>lower_bound</tt> (+ one further comparison). Since
15496 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
15497 has now WP status, the resolution of #787 should
15498 be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
15499 to <tt>+ O(1)</tt>.
15503 <p><b>Proposed resolution:</b></p>
15505 Change 25.3.3.4 [binary.search]/3
15509 <i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
15517 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
15518 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15519 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
15520 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
15521 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
15522 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
15523 <p><b>Discussion:</b></p>
15525 The description of how an istream_iterator object becomes an
15526 end-of-stream iterator is a) ambiguous and b) out of date WRT
15527 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
15531 <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
15532 input stream for which it was constructed. After it is constructed, and
15533 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
15534 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
15535 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
15536 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
15537 an end of stream input iterator object, which is the only legitimate
15538 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
15539 end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
15540 returned. The result of <tt>operator-></tt> on an end of stream is not defined.
15541 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
15542 store things into istream iterators. The main peculiarity of the istream
15543 iterators is the fact that <tt>++</tt> operators are not equality preserving,
15544 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
15545 is used a new value is read.
15549 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
15550 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
15551 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
15552 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
15553 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
15554 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
15555 void*()</tt> will return a non-null value).
15559 Also I would prefer to be explicit about calling <tt>fail()</tt> here
15560 (there is no <tt>operator void*()</tt> anymore.)
15564 <p><b>Proposed resolution:</b></p>
15566 Change 24.5.1 [istream.iterator]/1:
15570 <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
15571 input stream for which it was constructed. After it is constructed, and
15572 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
15573 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
15574 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
15575 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
15576 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
15577 an end of stream input iterator object, which is the only legitimate
15578 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
15579 end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
15580 returned. The result of <tt>operator-></tt> on an end of stream is not defined.
15581 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
15582 store things into istream iterators. The main peculiarity of the istream
15583 iterators is the fact that <tt>++</tt> operators are not equality preserving,
15584 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
15585 is used a new value is read.
15593 <h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
15594 <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#Ready">Ready</a>
15595 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15596 <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>
15597 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
15598 <p><b>Discussion:</b></p>
15600 <tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
15609 Non-controversial. Bill is right, but Fermilab believes that this is
15610 easy to use badly and hard to use right, and so it should be removed
15611 entirely. Got into TR1 by well defined route, do we have permission to
15612 remove stuff? Should probably check with Jens, as it is believed he is
15613 the originator. Broad consensus that this is not a robust engine
15618 <p><b>Proposed resolution:</b></p>
15620 Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
15623 Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
15631 <h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
15632 <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#Ready">Ready</a>
15633 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15634 <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>
15635 <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>
15636 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
15637 <p><b>Discussion:</b></p>
15639 <tt>piecewise_constant_distribution</tt> is undefined for a range with just one
15640 endpoint. (Probably should be the same as an empty range.)
15644 <p><b>Proposed resolution:</b></p>
15646 Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
15650 b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
15658 <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
15659 <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15660 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15661 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
15662 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15663 <p><b>Discussion:</b></p>
15665 <tt>discrete_distribution</tt> should have a constructor like:
15668 <blockquote><pre>template<class _Fn>
15669 discrete_distribution(result_type _Count, double _Low, double _High,
15671 </pre></blockquote>
15674 (Makes it easier to fill a histogram with function vaues over a range.)
15683 How do you specify the function so that it does not return negative
15684 values? If you do it is a bad construction. This requirement is already
15685 there. Where in each bin does one evaluate the function? In the middle.
15686 Need to revisit tomorrow.
15690 <p><b>Proposed resolution:</b></p>
15697 <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
15698 <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#New">New</a>
15699 <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15700 <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>
15701 <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>
15702 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
15703 <p><b>Discussion:</b></p>
15705 <tt>piecewise_constant_distribution</tt> should have a constructor like:
15708 <blockquote><pre>template<class _Fn>
15709 piecewise_constant_distribution(size_t _Count,
15710 _Ty _Low, _Ty _High, _Fn& _Func);
15711 </pre></blockquote>
15714 (Makes it easier to fill a histogram with function vaues over a range.
15715 The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
15716 <tt>general_pdf_distribution</tt>.)
15720 <p><b>Proposed resolution:</b></p>
15727 <h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
15728 <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#Ready">Ready</a>
15729 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
15730 <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>
15731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
15732 <p><b>Discussion:</b></p>
15734 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
15735 and its earlier predecessors have moved the old binders from
15736 [lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
15737 of the template parameter names (<tt>Operation -> Fn</tt>). During this
15738 renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
15739 <tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
15740 this user access point is probably rarely used.
15744 <p><b>Proposed resolution:</b></p>
15746 Change D.8.1 [depr.lib.binder.1st]:
15750 <pre>template <class Fn>
15752 : public unary_function<typename Fn::second_argument_type,
15753 typename Fn::result_type> {
15755 Fn <del>fn</del> <ins>op</ins>;
15756 typename Fn::first_argument_type value;
15758 binder1st(const Fn& x,
15759 const typename Fn::first_argument_type& y);
15760 typename Fn::result_type
15761 operator()(const typename Fn::second_argument_type& x) const;
15762 typename Fn::result_type
15763 operator()(typename Fn::second_argument_type& x) const;
15769 -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>.
15772 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
15778 Change D.8.3 [depr.lib.binder.2nd]:
15782 <pre>template <class Fn>
15784 : public unary_function<typename Fn::first_argument_type,
15785 typename Fn::result_type> {
15787 Fn <del>fn</del> <ins>op</ins>;
15788 typename Fn::second_argument_type value;
15790 binder2nd(const Fn& x,
15791 const typename Fn::second_argument_type& y);
15792 typename Fn::result_type
15793 operator()(const typename Fn::first_argument_type& x) const;
15794 typename Fn::result_type
15795 operator()(typename Fn::first_argument_type& x) const;
15801 -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>.
15804 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
15815 <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
15816 <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#Open">Open</a>
15817 <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
15818 <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>
15819 <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>
15820 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15821 <p><b>Discussion:</b></p>
15823 The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
15824 defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
15825 Previous versions of this algorithm and the general logic behind it
15826 suggest that this is an oversight and that in the context of the
15827 for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
15828 upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
15829 in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
15834 There are two more minor issues:
15839 Strictly speaking <tt>end - begin</tt> is not defined since
15840 <tt>InputIterator</tt> is not required to be a random access iterator.
15843 Currently all integral types are allowed as input to the <tt>seed_seq</tt>
15844 constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
15845 complicates the implementation without any real benefit to the user.
15846 I'd suggest to exclude <tt>bool</tt>s as input.
15856 Move to OPEN Bill will try to propose a resolution by the next meeting.
15860 post Bellevue: Bill provided wording.
15865 This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted.
15870 <p><b>Proposed resolution:</b></p>
15872 Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
15877 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
15878 low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
15880 in ascending order of significance to make a (possibly very large) unsigned
15881 binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
15886 <blockquote><pre>for( v.clear(); n > 0; n -= 32 )
15887 v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
15888 </pre></blockquote>
15896 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
15897 <p><b>Section:</b> 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15898 <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
15899 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
15900 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
15901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15902 <p><b>Discussion:</b></p>
15904 Classes with trivial special member functions are inherently more
15905 efficient than classes without such functions. This efficiency is
15906 particularly pronounced on modern ABIs that can pass small classes
15907 in registers. Examples include value classes such as complex numbers
15908 and floating-point intervals. Perhaps more important, though, are
15909 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
15910 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
15911 themselves can be trivial, leading to substantial performance wins.
15914 The current working draft make specification of trivial functions
15915 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
15916 As long as the semantics of defaulted and deleted functions match
15917 the intended semantics, specification of defaulted and deleted
15918 functions will yield more efficient programs.
15921 There are at least two cases where specification of an explicitly
15922 defaulted function may be desirable.
15925 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
15926 which prevents static initialization of the pair even when the
15927 types are statically initializable. Changing the definition to
15930 <blockquote><pre>pair() = default;
15931 </pre></blockquote>
15934 would enable such initialization. Unfortunately, the change is
15935 not semantically neutral in that the current definition effectively
15936 forces value initialization whereas the change would not value
15937 initialize in some contexts.
15941 ** Does the committee confirm that forced value initialization
15942 was the intent? If not, does the committee wish to change the
15943 behavior of <tt>std::pair</tt> in C++0x?
15946 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
15947 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
15948 which effectively prevents passing it in registers. To enable
15949 passing <tt>tuples</tt> in registers, the copy constructor should be
15950 make explicitly <tt>default</tt>ed. The new declarations are:
15953 <blockquote><pre>tuple() = default;
15954 tuple(const tuple&) = default;
15955 </pre></blockquote>
15958 This changes is not implementation neutral. In particular, it
15959 prevents implementations based on pointers to the parameter
15960 types. It does however, permit implementations using the
15961 parameter types as bases.
15964 ** How does the committee wish to trade implementation
15965 efficiency versus implementation flexibility?
15975 General agreement; the first half of the issue is NAD.
15978 Before voting on the second half, it was agreed that a "Strongly Favor"
15979 vote meant support for trivial tuples (assuming usual requirements met),
15980 even at the expense of other desired qualities. A "Weakly Favor" vote
15981 meant support only if not at the expense of other desired qualities.
15984 Concensus: Go forward, but not at expense of other desired qualities.
15987 It was agreed to Alisdair should fold this work in with his other
15988 pair/tuple action items, above, and that issue 801 should be "open", but
15989 tabled until Alisdair's proposals are disposed of.
15994 <p><b>Proposed resolution:</b></p>
16003 <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
16004 <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#Open">Open</a>
16005 <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
16006 <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>
16007 <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>
16008 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16009 <p><b>Discussion:</b></p>
16011 <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
16012 object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
16016 This repacking triggers several problems:
16020 Distinctness of the output of <tt>seed_seq::generate</tt> required the
16021 introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise
16022 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
16025 Portability demanded the introduction of the template parameter <tt>u</tt>.
16026 (Otherwise some sequences could not be obtained on computers where no
16027 integer types are exactly 32-bits wide.)
16030 The description and algorithm have become unduly complicated.
16034 I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
16035 Despite it's being simpler, there is NO loss of functionality (see
16039 Here's how the description would read
16043 26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
16047 <pre>template<class InputIterator>
16048 seed_seq(InputIterator begin, InputIterator end);
16052 5 <i>Requires:</i> NO CHANGE
16055 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
16058 <pre>for (InputIterator s = begin; s != end; ++s)
16059 v.push_back((*s) mod 2^32);
16070 The chief virtues here are simplicity, portability, and generality.
16074 Simplicity -- compare the above specification with the
16075 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
16078 Portability -- with <tt>iterator_traits<InputIterator>::value_type =
16079 uint_least32_t</tt> the user is guaranteed to get the same behavior across
16083 Generality -- any behavior that the
16084 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16085 proposal can achieve can be
16086 obtained with this simpler proposal (albeit with a shuffling of bits
16087 in the input sequence).
16091 Arguments (and counter-arguments) against making this change (and
16093 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16099 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
16103 Response: So what? Consider the seed string "ABC". The
16104 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16105 proposal results in
16107 <blockquote><pre>v = { 0x3, 0x434241 };
16108 </pre></blockquote>
16110 while the simplified proposal yields
16112 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
16113 </pre></blockquote>
16115 The results produced by <tt>seed_seq::generate</tt> with the two inputs are
16116 different but nevertheless equivalently "mixed up" and this remains
16117 true even if the seed string is long.
16122 With long strings (e.g., with bit-length comparable to the number of
16123 bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
16124 proposal and <tt>seed_seq::generate</tt> will be slower.
16127 Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
16128 be a big issue. If it is, the user is free to repack the seed vector
16129 before constructing <tt>seed_seq</tt>.
16134 A user can pass an array of 64-bit integers and all the bits will be
16138 Response: Indeed. However, there are many instances in the
16139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16140 where integers are silently coerced to a narrower width and this
16141 should just be a case of the user needing to read the documentation.
16142 The user can of course get equivalent behavior by repacking his seed
16143 into 32-bit pieces. Furthermore, the unportability of the
16144 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16147 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
16148 seed_seq q(s, s+4);
16149 </pre></blockquote>
16151 which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
16152 <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
16153 unsuspecting users.
16159 Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
16168 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
16172 <p><b>Proposed resolution:</b></p>
16174 Change 26.4.7.1 [rand.util.seedseq]:
16178 <pre>template<class InputIterator<del>,
16179 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
16180 seed_seq(InputIterator begin, InputIterator end);
16184 -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
16185 such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type.
16188 -6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence
16189 <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
16192 <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
16193 - begin</tt> elements of the supplied sequence and concatenate all the
16194 extracted bits to initialize a single (possibly very large) unsigned
16195 binary number, <tt>b = ∑<sup>n-1</sup><sub>i=0</sub> (begin[i]
16196 mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
16197 are treated as denoting an unsigned quantity). Then carry out
16198 the following algorithm:</del>
16200 <blockquote><pre><del>
16204 for( ; $n$ > 0; --$n$)
16205 v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
16206 </del></pre></blockquote>
16209 for (InputIterator s = begin; s != end; ++s)
16210 v.push_back((*s) mod 2<sup>32</sup>);
16221 <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
16222 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16223 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
16224 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
16225 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
16226 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16227 <p><b>Discussion:</b></p>
16231 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
16232 19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
16233 declare an expository data member <tt>cat_</tt>:
16235 <blockquote><pre>const error_category& cat_; // exposition only
16236 </pre></blockquote>
16238 which is used to define the semantics of several members. The decision
16239 to use a member of reference type lead to several problems:
16243 The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
16246 The post conditions of all modifiers from
16247 19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
16248 cannot be fulfilled.
16252 The simple fix would be to replace the reference by a pointer member.
16257 I would like to give the editorial remark that in both classes the
16258 constrained <tt>operator=</tt>
16259 overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
16260 usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
16261 parameter the return type would be defined to be <tt>void&</tt> even in otherwise
16262 valid circumstances - this return type must be explicitly provided (In
16263 <tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
16268 The member function <tt>message</tt> throws clauses (
16269 19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
16270 19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
16272 they return a <tt>std::string</tt> by value, which might throw in out-of-memory
16273 conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
16278 <p><b>Proposed resolution:</b></p>
16280 In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
16284 <pre>virtual string message(int ev) const = 0;
16289 <i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
16292 <del><i>Throws:</i> Nothing.</del>
16298 In 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section,
16299 replace the current <tt>operator=</tt> overload by the following:
16303 <pre>template <class ErrorCodeEnum>
16304 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code</ins>>::type&
16305 operator=(ErrorCodeEnum e);
16310 In the private section of the same class replace the current
16311 data member <tt>cat_</tt> definition by:
16315 const error_category<del>&</del><ins>*</ins> cat_; // exposition only
16319 In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
16330 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>.
16336 Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
16340 <pre>error_code(int val, const error_category& cat);
16345 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
16351 In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
16355 <pre>void assign(int val, const error_category& cat);
16362 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
16368 In 19.4.2.3 [syserr.errcode.modifiers], change the <tt>operator=</tt> signature to read:
16372 <pre>template <class ErrorCodeEnum>
16373 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code</ins>>::type&
16374 operator=(ErrorCodeEnum e);
16379 In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
16383 <pre>const error_category& category() const;
16390 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
16396 In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
16400 <pre>string message() const;
16407 <del><i>Throws:</i> Nothing.</del>
16413 In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>
16414 synopsis, constructors section, replace the template constructor
16415 overload declaration by one with an added "::value"
16419 <pre>template <class ErrorConditionEnum>
16420 error_condition(ErrorConditionEnum e,
16421 typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>>::type* = 0);
16426 In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> synopsis,
16428 replace the <tt>operator=</tt> overload declaration by:
16432 <pre>template<typename ErrorConditionEnum>
16433 typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>, <del>error_code</del> <ins>error_condition</ins>>::type &
16434 operator=( ErrorConditionEnum e );
16439 In the private section of the same class replace the current
16440 data member <tt>cat_</tt> definition by:
16443 <blockquote><pre>const error_category<del>&</del><ins>*</ins> cat_; // exposition only
16444 </pre></blockquote>
16447 In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
16451 <pre>error_condition();
16458 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>.
16464 In the same section, change p. 5 to read:
16468 <pre>error_condition(int val, const error_category& cat);
16475 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
16481 In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
16485 <pre>void assign(int val, const error_category& cat);
16489 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
16495 In the same section replace the current <tt>operator=</tt> overload declaration by:
16499 <pre>template <class ErrorConditionEnum>
16500 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value<ins>, error_condition</ins>>::type&
16501 operator=(ErrorConditionEnum e);
16502 </pre></blockquote>
16505 In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
16509 <pre>const error_category& category() const;
16513 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
16519 In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
16523 <pre>string message() const;
16530 <del><i>Throws:</i> Nothing.</del>
16542 <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
16543 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16544 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
16545 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
16546 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
16547 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16548 <p><b>Discussion:</b></p>
16553 <blockquote><pre>namespace posix_error {
16555 address_family_not_supported, // EAFNOSUPPORT
16557 </pre></blockquote>
16560 should rather use the new scoped-enum facility (7.2 [dcl.enum]),
16561 which would avoid the necessity for a new <tt>posix_error</tt>
16562 namespace, if I understand correctly.
16566 Further discussion:
16572 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
16573 Strongly Typed Enums, since renamed Scoped Enums.
16576 Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
16579 Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
16582 The wording for the Proposed resolution was provided by Beman Dawes.
16587 <p><b>Proposed resolution:</b></p>
16589 Change System error support 19.4 [syserr] as indicated:
16592 <blockquote><pre><del>namespace posix_error {</del>
16593 enum <del>posix_errno</del> <ins>class errc</ins> {
16594 address_family_not_supported, // EAFNOSUPPORT
16596 wrong_protocol_type, // EPROTOTYPE
16598 <del>} // namespace posix_error</del>
16600 template <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>>
16601 : public true_type {}
16603 <del>namespace posix_error {</del>
16604 error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
16605 error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
16606 <del>} // namespace posix_error</del>
16607 </pre></blockquote>
16610 Change System error support 19.4 [syserr] :
16614 <del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
16615 specialized for user-defined types to indicate that such a type is
16616 eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
16617 conversions, respectively.</del>
16621 Change System error support 19.4 [syserr] and its subsections:
16627 remove all occurrences of <tt>posix_error::</tt>
16630 change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
16633 change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
16636 change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
16642 Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
16646 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
16647 functions shall behave as specified for the class <tt>error_category</tt>. The
16648 object's name virtual function shall return a pointer to the string
16649 <del>"POSIX"</del> <ins>"GENERIC"</ins>.
16653 Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
16657 <pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
16661 <i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
16666 Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
16670 <pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
16674 <i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
16680 <p><b>Rationale:</b></p>
16683 <th colspan="2">Names Considered</th>
16687 <td><tt>portable</tt></td>
16689 Too non-specific. Did not wish to reserve such a common word in
16690 namespace std. Not quite the right meaning, either.
16695 <td><tt>portable_error</tt></td>
16697 Too long. Explicit qualification is always required for scoped enums, so
16698 a short name is desirable. Not quite the right meaning, either. May be
16699 misleading because <tt>*_error</tt> in the std lib is usually an exception class
16705 <td><tt>std_error</tt></td>
16707 Fairly short, yet explicit. But in fully qualified names like
16708 <tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
16709 quite the right meaning, either. May be misleading because <tt>*_error</tt> in
16710 the std lib is usually an exception class name.
16715 <td><tt>generic</tt></td>
16717 Short enough. The category could be <tt>generic_category</tt>. Fully qualified
16718 names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
16719 namespace std seems dicey.
16724 <td><tt>generic_error</tt></td>
16726 Longish. The category could be <tt>generic_category</tt>. Fully qualified names
16727 like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
16728 <tt>*_error</tt> in the std lib is usually an exception class name.
16733 <td><tt>generic_err</tt></td>
16735 A bit less longish. The category could be <tt>generic_category</tt>. Fully
16736 qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
16741 <td><tt>gen_err</tt></td>
16743 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16744 names like <tt>std::gen_err::not_enough_memory</tt> read well.
16749 <td><tt>generr</tt></td>
16751 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16752 names like <tt>std::generr::not_enough_memory</tt> read well.
16757 <td><tt>error</tt></td>
16759 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16760 names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
16761 this general a name?
16766 <td><tt>err</tt></td>
16768 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16769 names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
16770 looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
16771 it seems fairly intuitive.
16772 Problem: <tt>err</tt> is used throughout the standard library as an argument name
16773 and in examples as a variable name; it seems too confusing to add yet
16774 another use of the name.
16779 <td><tt>errc</tt></td>
16781 Short enough. The "c" stands for "constant". The category could be
16782 <tt>generic_category</tt>. Fully qualified names like
16783 <tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
16784 name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
16785 intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
16795 <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
16796 <p><b>Section:</b> 20.6.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16797 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
16798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16799 <p><b>Discussion:</b></p>
16801 <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
16805 <i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16809 There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
16810 deleter is called with a NULL pointer, and this is probably not what's
16811 intended (the destructor avoids calling the deleter with 0.)
16815 Two, the special check for <tt>get() == p</tt> is generally not needed and such a
16816 situation usually indicates an error in the client code, which is being
16817 masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
16818 self-resets in 2001 and there were no complaints.
16822 One might think that self-resets are necessary for operator= to work; it's specified to perform
16825 <blockquote><pre>reset( u.release() );
16826 </pre></blockquote>
16829 and the self-assignment
16832 <blockquote><pre>p = move(p);
16833 </pre></blockquote>
16836 might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
16837 performed first, zeroing the stored pointer. In other words, <tt>p.reset(
16838 q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
16839 is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
16840 scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
16845 <p><b>Proposed resolution:</b></p>
16848 Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
16852 <pre>void reset(T* p = 0);
16855 -4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16860 Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
16864 <pre>void reset(T* p = 0);
16869 -2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16880 <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
16881 <p><b>Section:</b> 20.3.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16882 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
16883 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16884 <p><b>Discussion:</b></p>
16886 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause
16887 should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
16891 <p><b>Proposed resolution:</b></p>
16893 Add to 20.3.1.2 [tuple.cnstr]:
16898 For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
16899 or assignment of one of the types in <tt>Types</tt> throws an exception.
16908 <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
16909 <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#New">New</a>
16910 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
16911 <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>
16912 <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>
16913 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16914 <p><b>Discussion:</b></p>
16919 <i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
16923 First of all, lvalue-ness and rvalue-ness are properties of an expression,
16924 not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong.
16925 Second, the phrase says exactly what the core language wording says for
16926 folding references in 14.3.1 [temp.arg.type]/p4 and for function return values
16927 in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should
16928 at most be a note with cross-references to those sections.)
16931 The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc.
16932 In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a
16933 property of an expression, orthogonal to its type. (Btw, expressions cannot
16934 have reference type, ever.)
16940 Return type: an rvalue.
16943 is just wrong and also redundant.
16947 <p><b>Proposed resolution:</b></p>
16949 Change 20.2.2 [forward] as indicated:
16953 <pre>template <class T> T&& forward(typename identity<T>::type&& t);
16959 <del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
16963 -7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
16964 as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
16965 as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</tt> (</del>an lvalue<del>)</del>.
16966 In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
16967 <del><tt>double&&</tt> (</del>an rvalue<del>)</del>.
16971 <pre>template <class T> typename remove_reference<T>::type&& move(T&& t);
16977 <del><i>Return type:</i> an rvalue.</del>
16989 <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
16990 <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#New">New</a>
16991 <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
16992 <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>
16993 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
16994 <p><b>Discussion:</b></p>
16996 For the sake of generic programming, the header <code><algorithm></code> should provide an
16997 overload of <code>std::swap</code> for array types:
16998 </p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
17003 It became apparent to me that this overload is missing, when I considered how to write a swap
17004 function for a generic wrapper class template.
17005 (Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
17006 Please look at the following template, <code>W</code>, and suppose that is intended to be a very
17007 <em>generic</em> wrapper:
17008 </p><pre>template<class T> class W {
17013 Clearly <code>W<T></code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
17014 <em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
17015 Moreover, <code>W<T></code> is <em>also</em> Swappable when <code>T</code> is an array type
17016 whose element type is CopyConstructible and CopyAssignable.
17017 Still it is recommended to add a <em>custom</em> swap function template to such a class template,
17018 for the sake of efficiency and exception safety.
17019 (E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
17021 This function template is typically written as follows:
17022 <pre>template<class T> void swap(W<T>& x, W<T>& y) {
17024 swap(x.data, y.data);
17027 Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
17028 For instance, <code>W<std::string[8]></code> is Swappable, but the current Standard does not
17029 allow calling the custom swap function that was especially written for <code>W</code>!
17030 <pre>W<std::string[8]> w1, w2; // Two objects of a Swappable type.
17031 std::swap(w1, w2); // Well-defined, but inefficient.
17033 swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!!
17036 <code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
17037 <code>std::string[8]</code>, which is not supported by the Standard Library.
17038 This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
17039 This swap function should be implemented in terms of swapping the elements of the arrays, so that
17040 it would be non-throwing for arrays whose element types have a non-throwing swap.
17044 Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
17045 arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
17046 means of recursion.
17050 For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
17051 Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
17055 <p><b>Proposed resolution:</b></p>
17057 Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
17060 - <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
17063 Add the following to 25.2.3 [alg.swap]:
17066 <pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
17069 <i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
17072 <i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
17081 <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
17082 <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17083 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
17084 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
17085 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
17086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17087 <p><b>Discussion:</b></p>
17089 The recent draft (as well as the original proposal n2072) uses an
17090 operational semantic
17091 for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
17094 <blockquote><pre>istreambuf_iterator<charT>
17095 </pre></blockquote>
17101 <blockquote><pre>ostreambuf_iterator<charT>
17102 </pre></blockquote>
17105 resp, instead of the iterator instances, with explicitly provided
17106 traits argument (The operational semantic defined by <tt>f</tt> is also traits
17107 dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
17108 c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument.
17111 The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
17113 of n2071 incorporated in N2521, where additional to the problem we
17114 have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
17115 <tt>istreambuf_iterator</tt>).
17119 <p><b>Proposed resolution:</b></p>
17121 In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
17124 <blockquote><pre>template <class charT, class traits, class moneyT>
17125 void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
17126 typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter;
17128 </pre></blockquote>
17131 In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
17134 <blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>;
17135 </pre></blockquote>
17138 In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
17141 <blockquote><pre>template <class charT, class traits, class moneyT>
17142 void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) {
17143 typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
17145 </pre></blockquote>
17148 In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
17151 <blockquote><pre>template <class charT, class traits>
17152 void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) {
17153 typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter;
17155 </pre></blockquote>
17158 In 27.6.4 [ext.manip]/8 add const:
17161 <blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
17162 </pre></blockquote>
17165 In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
17168 <blockquote><pre>template <class charT, class traits>
17169 void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) {
17170 typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
17172 </pre></blockquote>
17175 Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format]
17178 <blockquote><pre>template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
17179 template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
17180 template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
17181 template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
17182 </pre></blockquote>
17190 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
17191 <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#New">New</a>
17192 <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
17193 <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>
17194 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17195 <p><b>Discussion:</b></p>
17196 <blockquote><pre>#include <utility>
17200 std::pair<char *, char *> p (0,0);
17202 </pre></blockquote>
17205 I just got a bug report about that, because it's valid C++03, but not
17206 C++0x. The important realization, for me, is that the emplace
17207 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
17208 issue---didn't cause this break in backward compatibility. The break
17209 actually happened when we added this pair constructor as part of adding
17210 rvalue references into the language, long before variadic templates or
17211 emplace came along:
17214 <blockquote><pre>template<class U, class V> pair(U&& x, V&& y);
17215 </pre></blockquote>
17218 Now, concepts will address this issue by constraining that <tt>pair</tt>
17219 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
17220 "second", e.g. (from
17221 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
17224 <blockquote><pre>template<class U , class V >
17225 requires Constructible<T1, U&&> && Constructible<T2, V&&>
17226 pair(U&& x , V&& y );
17227 </pre></blockquote>
17231 <p><b>Proposed resolution:</b></p>
17240 <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
17241 <p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17242 <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
17243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17244 <p><b>Discussion:</b></p>
17246 Multi-threading is a good thing, but unsolicited multi-threading can
17247 potentially be harmful. For example, <tt>sort()</tt> performance might be
17248 greatly increased via a multithreaded implementation. However, such
17249 a multithreaded implementation could result in concurrent invocations
17250 of the user-supplied comparator. This would in turn result in problems
17251 given a caching comparator that might be written for complex sort keys.
17252 Please note that this is not a theoretical issue, as multithreaded
17253 implementations of <tt>sort()</tt> already exist.
17256 Having a multithreaded <tt>sort()</tt> available is good, but it should not
17257 be the default for programs that are not explicitly multithreaded.
17258 Users should not be forced to deal with concurrency unless they have
17263 This may be covered by
17264 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
17265 Thread-Safety in the Standard Library (Rev 1).
17270 <p><b>Proposed resolution:</b></p>
17279 <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
17280 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17281 <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
17282 <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>
17283 <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>
17284 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17285 <p><b>Discussion:</b></p>
17287 Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
17288 However, that term is nowhere defined. The closest thing we have to a
17289 definition is that the default constructor creates an empty <tt>shared_ptr</tt>
17290 and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
17291 other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
17292 are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
17293 term or stop using it.
17296 One reason it's not good enough to leave this term up to the reader's
17297 intuition is that, in light of
17298 <a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
17299 and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
17300 intuitive understanding is likely to be wrong. Intuitively one might
17301 expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
17302 but, whatever the definition is, that isn't it.
17312 Or, what is an "empty" <tt>shared_ptr</tt>?
17318 Are any other <tt>shared_ptrs</tt> empty?
17321 Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
17322 completely specified by the last mutating operation on that instance.
17323 Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
17327 (*) If it isn't, this is a legitimate defect.
17333 For example, is <tt>shared_ptr((T*) 0)</tt> empty?
17336 No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
17337 specified to have an <tt>use_count()</tt> of 1.
17343 What are the properties of an empty <tt>shared_ptr</tt>?
17346 The properties of an empty <tt>shared_ptr</tt> can be derived from the
17347 specification. One example is that its destructor is a no-op. Another is
17348 that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
17355 We should either clarify this term or stop using it.
17358 I don't agree with the imperative tone
17361 A clarification would be either a no-op - if it doesn't contradict the
17362 existing wording - or a big mistake if it does.
17365 I agree that a clarification that is formally a no-op may add value.
17371 However, that term is nowhere defined.
17374 Terms can be useful without a definition. Consider the following
17375 simplistic example. We have a type <tt>X</tt> with the following operations
17378 <blockquote><pre>X x;
17382 </pre></blockquote>
17384 A default-constructed value is green.<br>
17385 A copy has the same color as the original.<br>
17386 <tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
17387 <tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
17391 Given these definitions, you can determine the color of every instance
17392 of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
17396 Green and red are "nowhere defined" and completely defined at the same time.
17402 Alisdair's wording is fine.
17407 <p><b>Proposed resolution:</b></p>
17409 Append the following sentance to 20.6.12.2 [util.smartptr.shared]
17412 The <code>shared_ptr</code> class template stores a pointer, usually obtained
17413 via <code>new</code>. <code>shared_ptr</code> implements semantics of
17414 shared ownership; the last remaining owner of the pointer is responsible for
17415 destroying the object, or otherwise releasing the resources associated with
17416 the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
17417 a pointer is said to be <i>empty</i>.</ins>
17425 <h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3>
17426 <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17427 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
17428 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
17429 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
17430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17431 <p><b>Discussion:</b></p>
17433 <tt>vector<bool>::swap(reference, reference)</tt> has no definition.
17437 <p><b>Proposed resolution:</b></p>
17446 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
17447 <p><b>Section:</b> 20.5.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17448 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
17449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17450 <p><b>Discussion:</b></p>
17452 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
17453 described in the rvalue core proposal.
17457 <p><b>Proposed resolution:</b></p>
17466 <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
17467 <p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17468 <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
17469 <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>
17470 <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>
17471 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17472 <p><b>Discussion:</b></p>
17474 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
17475 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
17478 However, no guarantees are provided for the copy ctor of the functor
17479 returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can
17480 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
17481 call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper,
17482 TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4.
17483 Everything without an exception-specification may throw
17484 implementation-defined exceptions unless otherwise specified, C++03
17488 Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
17489 to cover both calling <tt>bind()</tt> and copying the returned functor?
17498 <tt>tuple</tt> construction should probably have a similar guarantee.
17503 <p><b>Proposed resolution:</b></p>
17512 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
17513 <p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17514 <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
17515 <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>
17516 <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>
17517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17518 <p><b>Discussion:</b></p>
17520 The functor retureed by <tt>bind()</tt> should have a move constructor that
17521 requires only move construction of its contained functor and bound arguments.
17522 That way move-only functors can be passed to objects such as <tt>thread</tt>.
17525 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
17529 <p><b>Proposed resolution:</b></p>
17538 <h3><a name="818"></a>818. wording for memory ordering</h3>
17539 <p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17540 <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
17541 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17542 <p><b>Discussion:</b></p>
17544 29.1 [atomics.order] p1 says in the table that
17550 <th>Element</th><th>Meaning</th>
17553 <td><tt>memory_order_acq_rel</tt></td>
17554 <td>the operation has both acquire and release semantics</td>
17560 To my naked eye, that seems to imply that even an atomic read has both
17561 acquire and release semantics.
17565 Then, p1 says in the table:
17571 <th>Element</th><th>Meaning</th>
17574 <td><tt>memory_order_seq_cst</tt></td>
17575 <td>the operation has both acquire and release semantics,
17576 and, in addition, has sequentially-consistent operation ordering</td>
17582 So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
17587 I'm then reading p2, where it says:
17591 The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
17592 on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
17593 are release operations on the affected locations.
17597 That seems to imply that atomic reads only have acquire semantics. If that
17598 is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
17599 load/store operations as well?
17603 Also, the table in p1 contains phrases with "thus" that seem to indicate
17604 consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in
17605 normative text, for the fear of redundant or inconsistent specification with
17606 the other normative text.
17610 Double-check 29.4.4 [atomics.types.operations] that each
17611 operation clearly says whether it's a load or a store operation, or
17612 both. (It could be clearer, IMO. Solution not in current proposed resolution.)
17616 29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in
17617 1.10 [intro.multithread], it's just used in notes there.
17621 And why does 29.4.4 [atomics.types.operations] p9 for "load" say:
17626 <i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
17627 nor <tt>memory_order_acq_rel</tt>.
17631 (Since this is exactly the same restriction as for "store", it seems to be a typo.)
17635 And then: 29.4.4 [atomics.types.operations] p12:
17639 These operations are read-modify-write operations in the sense of the
17640 "synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
17641 evaluation that produced the input value synchronize with any evaluation
17642 that reads the updated value.
17646 This is redundant with 1.10 [intro.multithread], see above for the reasoning.
17650 <p><b>Proposed resolution:</b></p>
17652 Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
17653 1.7 [intro.memory].
17654 Rephrase the table in as follows (maybe don't use a table):
17659 For <tt>memory_order_relaxed</tt>, no operation orders memory.
17663 For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
17664 a store operation performs a release operation on the affected memory location.
17668 For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
17669 a load operation performs an acquire operation on the affected memory location.
17674 Rephrase 29.1 [atomics.order] p2:
17678 <del>The <tt>memory_order_seq_cst</tt> operations that load a value are
17679 acquire operations on the affected locations. The
17680 <tt>memory_order_seq_cst</tt> operations that store a value are release
17681 operations on the affected locations.</del>
17682 <del>In addition, in a consistent
17683 execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
17684 total order <tt>S</tt> on all
17685 <tt>memory_order_seq_cst</tt> operations, consistent with the happens before
17686 order and modification orders for all affected locations, such that each
17687 <tt>memory_order_seq_cst</tt> operation observes either the last preceding
17688 modification according to this order <tt>S</tt>, or the result of an operation
17689 that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
17690 required that <tt>S</tt> include locks, it can always be extended to an order
17691 that does include lock and unlock operations, since the ordering between
17692 those is already included in the happens before ordering. <i>-- end note</i>]
17696 Rephrase 29.4.4 [atomics.types.operations] p12 as:
17700 <i>Effects:</i> Atomically replaces the value pointed to by object or by
17701 this with desired. Memory is affected according to the value of order.
17702 These operations are read-modify-write operations <del>in the sense of the
17703 "synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
17704 evaluation that produced the input value synchronize with any evaluation
17705 that reads the updated value</del>.
17709 Same in p15, p20, p22.
17718 <h3><a name="819"></a>819. rethrow_if_nested</h3>
17719 <p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17720 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
17721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17722 <p><b>Discussion:</b></p>
17724 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
17725 got it quite right.
17729 The current wording says:
17733 <pre>template <class E> void rethrow_if_nested(const E& e);
17737 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
17738 is publicly derived from <tt>nested_exception</tt>.
17744 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
17745 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
17746 required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
17747 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
17751 <p><b>Proposed resolution:</b></p>
17758 <h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
17759 <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#New">New</a>
17760 <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
17761 <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>
17762 <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>
17763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17764 <p><b>Discussion:</b></p>
17766 As of N2521, the Working Paper appears to be silent about what
17767 <tt>current_exception()</tt> should do if it tries to copy the currently handled
17768 exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the
17769 function needs to allocate memory and the attempt fails, it returns an
17770 <tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
17771 doesn't say anything about what should happen if memory allocation
17772 succeeds but the actual copying fails.
17776 I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
17777 to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
17778 object that refers to an instance of the copy ctor's thrown exception
17779 (but if that has a throwing copy ctor, an infinite loop can occur), or
17780 (3) call <tt>terminate()</tt>.
17784 I believe that <tt>terminate()</tt> is the most reasonable course of action, but
17785 before we go implement that, I wanted to raise this issue.
17795 The current practice is to not have throwing copy constructors in
17796 exception classes, because this can lead to <tt>terminate()</tt> as described in
17797 15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
17798 consistent and does not introduce any new problems.
17802 However, the resolution of core issue 475 may relax this requirement:
17806 The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
17807 return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
17808 should not be called if that constructor exits with an exception.
17812 Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
17813 (3) doesn't seem reasonable as it is deemed too drastic a response in a
17814 recoverable situation.
17818 Option (2) cannot be adopted by itself, because a potential infinite
17819 recursion will need to be terminated by one of the other options.
17825 <p><b>Proposed resolution:</b></p>
17827 Add the following paragraph after 18.7.5 [propagation]/7:
17832 <i>Returns (continued):</i> If the attempt to copy the current exception
17833 object throws an exception, the function returns an <tt>exception_ptr</tt> that
17834 refers to the thrown exception or, if this is not possible, to an
17835 instance of <tt>bad_exception</tt>.
17838 [<i>Note:</i> The copy constructor of the thrown exception may also fail, so
17839 the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
17840 infinite recursion. <i>-- end note.</i>]
17850 <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
17851 <p><b>Section:</b> 20.6.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17852 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
17853 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17854 <p><b>Discussion:</b></p>
17856 Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> I noticed the following:
17860 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
17864 -1- <i>Requires:</i> Does not accept pointer types which are convertible
17865 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
17866 required). [<i>Note:</i> One implementation technique is to create a private
17867 templated overload. <i>-- end note</i>]
17872 This could be cleaned up by mandating the overload as a public deleted
17873 function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
17874 to be a stronger match than the deleted overload. Words...
17878 <p><b>Proposed resolution:</b></p>
17880 Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
17886 void reset(T* p = 0);
17887 <ins>void reset( nullptr_t );</ins>
17888 <ins>template< typename T > void reset( T ) = delete;</ins>
17889 void swap(unique_ptr&& u);
17894 Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
17898 <pre>void reset(pointer p = pointer());
17899 <ins>void reset(nullptr_t);</ins>
17903 <del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
17904 to <tt>pointer</tt> (diagnostic
17905 required). [<i>Note:</i> One implementation technique is to create a private
17906 templated overload. <i>-- end note</i>]</del>
17909 <i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
17915 Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready).
17924 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
17925 <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#New">New</a>
17926 <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
17927 <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>
17928 <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>
17929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
17930 <p><b>Discussion:</b></p>
17932 I just noticed that the following program is legal in C++03, but
17933 is forbidden in the current draft:
17936 <blockquote><pre>#include <vector>
17937 #include <iostream>
17943 explicit Toto( Toto const& ) {}
17949 std::vector< Toto > v( 10 ) ;
17952 </pre></blockquote>
17955 Is this change intentional? (And if so, what is the
17956 justification? I wouldn't call such code good, but I don't see
17957 any reason to break it unless we get something else in return.)
17962 <p><b>Proposed resolution:</b></p>
17964 In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
17970 <th>expression</th><th>post-condition</th>
17973 <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
17976 <td colspan="2" align="center">...</td>
17982 In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
17988 <th>expression</th><th>post-condition</th>
17991 <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
17994 <td colspan="2" align="center">...</td>
18004 <h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3>
18005 <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#New">New</a>
18006 <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
18007 <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>
18008 <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>
18009 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18010 <p><b>Discussion:</b></p>
18012 N2588 seems to have added an <tt>operator()</tt> member function to the
18013 <tt>identity<></tt> helper in 20.2.2 [forward]. I believe this change makes it no
18014 longer possible to instantiate <tt>identity<void></tt>, as it would require
18015 forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
18019 Suggested resolution: Specialize <tt>identity<void></tt> so as not to require
18020 the member function's presence.
18024 <p><b>Proposed resolution:</b></p>
18033 <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
18034 <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#New">New</a>
18035 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
18036 <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>
18037 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18038 <p><b>Discussion:</b></p>
18040 In the current working paper, the <tt><string></tt> header synopsis at the end of
18041 21.2 [string.classes] lists a single <tt>operator<<</tt> overload
18042 for <tt>basic_string</tt>.
18045 <blockquote><pre>template<class charT, class traits, class Allocator>
18046 basic_ostream<charT, traits>&
18047 operator<<(basic_ostream<charT, traits>&& os,
18048 const basic_string<charT,traits,Allocator>& str);
18049 </pre></blockquote>
18052 The definition in 21.3.8.9 [string.io] lists two:
18055 <blockquote><pre>template<class charT, class traits, class Allocator>
18056 basic_ostream<charT, traits>&
18057 operator<<(basic_ostream<charT, traits>& os,
18058 const basic_string<charT,traits,Allocator>& str);
18060 template<class charT, class traits, class Allocator>
18061 basic_ostream<charT, traits>&
18062 operator<<(basic_ostream<charT, traits>&& os,
18063 const basic_string<charT,traits,Allocator>& str);
18064 </pre></blockquote>
18067 I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
18068 signatures in 21.3.8.9 [string.io] should be deleted.
18072 <p><b>Proposed resolution:</b></p>
18081 <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
18082 <p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8
18083 [util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
18084 [bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
18085 [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18086 <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
18087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18088 <p><b>Discussion:</b></p>
18090 Should the following use rvalues references to stream in insert/extract
18095 <li>19.4.2.1 [syserr.errcode.overview]</li>
18096 <li>20.6.12.2.8 [util.smartptr.shared.io]</li>
18097 <li>22.2.8 [facets.examples]</li>
18098 <li>23.3.5.3 [bitset.operators]</li>
18099 <li>26.3.6 [complex.ops]</li>
18100 <li>Doubled signatures in 27.5 [stream.buffers] for character inserters
18101 (ref 27.6.2.6.4 [ostream.inserters.character])
18102 + definition 27.6.2.6.4 [ostream.inserters.character]</li>
18103 <li>28.9 [re.submatch]</li>
18107 <p><b>Proposed resolution:</b></p>
18116 <h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
18117 <p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18118 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
18119 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18120 <p><b>Discussion:</b></p>
18122 In the spirit of <tt>printf vs iostream</tt>...
18126 POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
18127 implication is that in the absence of <tt>'</tt> no grouping characters are
18128 inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
18129 grouping characters. Can this be considered a defect worth fixing for
18130 C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
18139 I'm not sure it constitutes a defect, but I would be in favor of adding
18140 another flag (and corresponding manipulator).
18149 I don't know if it qualifies as a defect but I agree that there
18150 should be an easy way to control whether the thousands separator
18151 should or shouldn't be inserted. A new flag would be in line with
18152 the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
18153 <tt>showbase</tt>).
18157 <p><b>Proposed resolution:</b></p>
18166 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
18167 <p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18168 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
18169 <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>
18170 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18171 <p><b>Discussion:</b></p>
18173 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
18174 <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
18175 static initialization for <tt>shared_ptr</tt> variables, eliminating another
18176 unfair advantage of raw pointers.
18180 <p><b>Proposed resolution:</b></p>
18189 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
18190 <p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18191 <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
18192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18193 <p><b>Discussion:</b></p>
18195 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
18198 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
18199 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
18200 we should strive to eliminate such regressions in expressive power where
18201 possible, both to ease migration and to not provide incentives to (or
18202 force) people to forego the C++ primitives in favor of pthreads.
18206 <p><b>Proposed resolution:</b></p>
18215 <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
18216 <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#New">New</a>
18217 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
18218 <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>
18219 <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>
18220 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18221 <p><b>Discussion:</b></p>
18222 <p>Consider this code:</p>
18225 <pre>exception_ptr xp;</pre>
18226 <pre>try {do_something(); }
18228 catch (const runtime_error& ) {xp = current_exception();}
18232 rethrow_exception(xp);</pre>
18236 Say <code>do_something()</code> throws an exception object of type <code>
18237 range_error</code>. What is the type of the exception object thrown by <code>
18238 rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
18239 if it were of type <code>runtime_error</code> it still isn't possible to
18240 propagate an exception and the exception_ptr/current_exception/rethrow_exception
18241 machinery serves no useful purpose.
18245 Unfortunately, the current wording does not explicitly say that. Different
18246 people read the current wording and come to different conclusions. While it may
18247 be possible to deduce the correct type from the current wording, it would be
18248 much clearer to come right out and explicitly say what the type of the referred
18259 I don't like the proposed resolution of 829. The normative text is
18260 unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
18261 exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
18262 exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
18265 A better way to address this is to simply add the non-normative example
18266 in question as a clarification. The term <i>currently handled exception</i>
18267 should be italicized and cross-referenced. A [<i>Note:</i> the currently
18268 handled exception is the exception that a throw expression without an
18269 operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
18275 <p><b>Proposed resolution:</b></p>
18278 After 18.7.5 [propagation] , paragraph 7, add the indicated text:
18282 <pre>exception_ptr current_exception();</pre>
18286 <i>Returns:</i> <code>exception_ptr</code> object that refers
18287 to the currently handled exception or a copy of the currently handled
18288 exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
18289 the function needs to allocate memory and the attempt fails, it returns an
18290 <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
18291 It is unspecified whether the return values of two successive calls to
18292 <code>current_exception</code> refer to the same exception object.
18293 [<i>Note:</i> that is, it
18294 is unspecified whether <code>current_exception</code>
18295 creates a new copy each time it is called.
18296 <i>-- end note</i>]
18300 <ins><i>Remarks:</i> The type of the exception object
18301 referred to by the returned <code>exception_ptr</code> is the most-derived
18302 type of the currently handled exception.</ins>
18306 <i>Throws:</i> nothing.
18318 <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
18319 <p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18320 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
18321 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
18322 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
18323 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18324 <p><b>Discussion:</b></p>
18326 Paragraph 4 of 21.1 [char.traits] mentions that this
18327 section specifies two specializations (<code>char_traits<char></code>
18328 and (<code>char_traits<wchar_t></code>). However, there are actually
18329 four specializations provided, i.e. in addition to the two above also
18330 <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
18331 I guess this was just an oversight and there is nothing wrong with just
18340 <tt>char_traits< char16/32_t ></tt>
18341 should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and all the specializations
18342 taking a <tt>char_traits</tt> parameter in that header.
18346 <p><b>Proposed resolution:</b></p>
18348 Replace paragraph 4 of 21.1 [char.traits] by:
18352 This subclause specifies a struct template, <code>char_traits<charT></code>,
18353 and four explicit specializations of it, <code>char_traits<char></code>,
18354 <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
18355 <code>char_traits<wchar_t></code>, all of which appear in the header
18356 <string> and satisfy the requirements below.
18365 <h3><a name="831"></a>831. wrong type for not_eof()</h3>
18366 <p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18367 <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
18368 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
18369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18370 <p><b>Discussion:</b></p>
18372 In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
18373 is using an argument of type <i>e</i> which denotes an object of
18374 type <code>X::int_type</code>. However, the specializations in
18375 21.1.3 [char.traits.specializations] all use <code>char_type</code>.
18376 This would effectively mean that the argument type actually can't
18377 represent EOF in the first place. I'm pretty sure that the type used
18378 to be <code>int_type</code> which is quite obviously the only sensible
18382 This issue is close to being editorial. I suspect that the proposal
18383 changing this section to include the specializations for <code>char16_t</code>
18384 and <code>char32_t</code> accidentally used the wrong type.
18388 <p><b>Proposed resolution:</b></p>
18390 In 21.1.3.1 [char.traits.specializations.char],
18391 21.1.3.2 [char.traits.specializations.char16_t],
18392 21.1.3.3 [char.traits.specializations.char32_t], and
18393 [char.traits.specializations.wchar_t] correct the
18394 argument type from <code>char_type</code> to <code>int_type</code>.
18402 <h3><a name="832"></a>832. Applying constexpr to System error support</h3>
18403 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18404 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
18405 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
18406 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
18407 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18408 <p><b>Discussion:</b></p>
18410 Initialization of objects of class <tt>error_code</tt>
18411 (19.4.2 [syserr.errcode]) and class
18412 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
18413 the new <tt>constexpr</tt> feature
18414 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
18415 of C++0x. Less code will need to be
18416 generated for both library implementations and user programs when
18417 manipulating constant objects of these types.
18421 This was not proposed originally because the constant expressions
18422 proposal was moving into the standard at about the same time as the
18423 Diagnostics Enhancements proposal
18424 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
18425 and it wasn't desirable to
18426 make the later depend on the former. There were also technical concerns
18427 as to how <tt>constexpr</tt> would apply to references. Those concerns are now
18428 resolved; <tt>constexpr</tt> can't be used for references, and that fact is
18429 reflected in the proposed resolution.
18433 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
18437 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
18438 exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
18439 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
18440 While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
18441 presenting it as a pointer becomes more or less required with this
18442 proposal, given <tt>constexpr</tt> does not play well with references. The
18443 proposed resolution thus changes the private member to a pointer, which
18444 also brings it in sync with real implementations.
18448 <p><b>Proposed resolution:</b></p>
18450 The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
18451 applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
18452 <tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
18453 proposal must be adjusted accordingly.
18457 Change 19.4.1.1 [syserr.errcat.overview] Class
18458 <tt>error_category</tt> overview <tt>error_category</tt> synopsis as
18462 <blockquote><pre><del>const error_category& get_generic_category();</del>
18463 <del>const error_category& get_system_category();</del>
18465 <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
18466 <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
18467 </pre></blockquote>
18470 Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
18474 <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
18477 <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
18478 to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
18479 class <tt>error_category</tt>.
18483 <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
18484 functions shall behave as specified for the class <tt>error_category</tt>. The
18485 object's <tt>name</tt> virtual function shall return a pointer to the string
18486 <tt>"GENERIC"</tt>.
18489 <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
18493 <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
18494 to <del>an</del> <ins>a statically
18495 initialized</ins> object of a type derived from class <tt>error_category</tt>.
18499 <del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
18500 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
18501 shall return a pointer to the string <tt>"system"</tt>. The object's
18502 <tt>default_error_condition</tt> virtual function shall behave as follows:
18506 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
18507 shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
18508 function shall return <tt>error_condition(ev, system_category)</tt>. What
18509 constitutes correspondence for any given operating system is
18510 unspecified. [<i>Note:</i> The number of potential system error codes is large
18511 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
18512 Thus implementations are given latitude in determining correspondence.
18513 <i>-- end note</i>]
18518 Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
18521 <blockquote><pre>class error_code {
18524 <ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
18526 void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
18528 const error_category<del>&</del><ins>*</ins> category() const;
18531 int val_; // exposition only
18532 const error_category<del>&</del><ins>*</ins> cat_; // exposition only
18533 </pre></blockquote>
18536 Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
18540 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
18543 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
18546 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18549 <i>Throws:</i> Nothing.
18554 Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
18558 <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
18561 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18564 <i>Throws:</i> Nothing.
18569 Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated:
18573 <pre>const error_category<del>&</del><ins>*</ins> category() const;
18577 <i>Returns:</i> <tt>cat_</tt>.
18580 <i>Throws:</i> Nothing.
18585 Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated:
18589 <pre>class error_condition {
18592 <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
18594 void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
18596 const error_category<del>&</del><ins>*</ins> category() const;
18599 int val_; // exposition only
18600 const error_category<del>&</del><ins>*</ins> cat_; // exposition only
18605 Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
18609 <pre>constexpr error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
18612 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
18615 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18618 <i>Throws:</i> Nothing.
18623 Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
18627 <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
18630 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18633 <i>Throws:</i> Nothing.
18638 Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
18642 <pre>const error_category<del>&</del><ins>*</ins> category() const;
18645 <i>Returns:</i> <tt>cat_</tt>.
18648 <i>Throws:</i> Nothing.
18653 Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>".
18654 Appears approximately six times.
18658 <i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
18659 paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
18660 "<tt>category()->equivalent(</tt>".
18668 <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
18669 <p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18670 <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
18671 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18672 <p><b>Discussion:</b></p>
18674 Once the C++0x standard library is feature complete, the LWG needs to
18675 review 17.4.1.3 [compliance] Freestanding implementations header list to
18676 ensure it reflects LWG consensus.
18680 <p><b>Proposed resolution:</b></p>
18687 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
18688 <p><b>Section:</b> 20.6.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18689 <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
18690 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18691 <p><b>Discussion:</b></p>
18693 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful
18694 extension point for <tt>unique_ptr</tt> by granting support for an optional
18695 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
18696 (In the following: <tt>pointer</tt>).
18699 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
18700 impact on at least two key features of <tt>unique_ptr</tt>:
18704 <li>Operational fail-safety.</li>
18705 <li>(Well-)Definedness of expressions.</li>
18709 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
18710 operations cannot throw and therefore adds proper wording to the affected
18711 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
18712 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
18713 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
18714 an exception"-clauses or it has to be said explicitly that all used
18716 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
18717 to be as near as possible to the advantages of native pointers which cannot
18718 fail and thus strongly favor the second choice. Also, the alternative position
18719 would make it much harder to write safe and simple template code for
18720 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
18721 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
18722 be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>).
18726 <p><b>Proposed resolution:</b></p>
18728 Add the following sentence just at the end of the newly proposed
18729 20.6.11.2 [unique.ptr.single]/p. 3:
18733 <tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well
18734 defined behavior, and shall not throw exceptions.
18742 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
18743 <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#New">New</a>
18744 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18745 <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>
18746 <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>
18747 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18748 <p><b>Discussion:</b></p>
18752 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
18753 now integrated into the working paper, overlooks a couple of minor
18759 First, being an unformatted function once again, <code>flush()</code>
18760 is required to create a sentry object whose constructor must, among
18761 other things, flush the tied stream. When two streams are tied
18762 together, either directly or through another intermediate stream
18763 object, flushing one will also cause a call to <code>flush()</code> on
18764 the other tied stream(s) and vice versa, ad infinitum. The program
18765 below demonstrates the problem.
18770 Second, as Bo Persson notes in his
18771 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
18772 for streams with the <code>unitbuf</code> flag set such
18773 as <code>std::stderr</code>, the destructor of the sentry object will
18774 again call <code>flush()</code>. This seems to create an infinite
18775 recursion for <code>std::cerr << std::flush;</code>
18779 <pre>#include <iostream>
18783 std::cout.tie (&std::cerr);
18784 std::cerr.tie (&std::cout);
18785 std::cout << "cout\n";
18786 std::cerr << "cerr\n";
18791 <p><b>Proposed resolution:</b></p>
18794 I think an easy way to plug the first hole is to add a requires clause
18795 to <code>ostream::tie(ostream *tiestr)</code> requiring the this
18796 pointer not be equal to any pointer on the list starting
18797 with <code>tiestr->tie()</code>
18798 through <code>tiestr()->tie()->tie()</code> and so on. I am not
18799 proposing that we require implementations to traverse this list,
18800 although I think we could since the list is unlikely to be very long.
18805 Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
18811 <i>Requires:</i> If <code>(tiestr != 0)</code> is
18812 true, <code>tiestr</code> must not be reachable by traversing the
18813 linked list of tied stream objects starting
18814 from <code>tiestr->tie()</code>.
18819 In addition, to prevent the infinite recursion that Bo writes about in
18820 his comp.lang.c++.moderated post, I propose to change
18821 27.6.2.4 [ostream::sentry], p2 like so:
18826 If <code>((os.flags() & ios_base::unitbuf) &&
18827 !uncaught_exception())</code> is true,
18828 calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>.
18836 <h3><a name="836"></a>836.
18837 effects of <code>money_base::space</code> and
18838 <code>money_base::none</code> on <code>money_get</code>
18840 <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18841 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18842 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
18843 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
18844 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18845 <p><b>Discussion:</b></p>
18848 In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
18853 Where <code>space</code> or <code>none</code> appears in the format
18854 pattern, except at the end, optional white space (as recognized
18855 by <code>ct.is</code>) is consumed after any required space.
18860 This requirement can be (and has been) interpreted two mutually
18861 exclusive ways by different readers. One possible interpretation
18869 where <code>money_base::space</code> appears in the format, at least
18870 one space is required, and
18875 where <code>money_base::none</code> appears in the format, space is
18876 allowed but not required.
18888 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
18893 <p><b>Proposed resolution:</b></p>
18896 I propose to change the text to make it clear that the first
18897 interpretation is intended, that is, to make following change to
18898 22.2.6.1.2 [locale.money.get.virtuals], p2:
18904 When <code><ins>money_base::</ins>space</code>
18905 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
18906 element </ins>in the format pattern, <del>except at the end, optional
18907 white space (as recognized by <code>ct.is</code>) is consumed after
18908 any required space.</del> <ins>no white space is consumed. Otherwise,
18909 where <code>money_base::space</code> appears in any of the initial
18910 elements of the format pattern, at least one white space character is
18911 required. Where <code>money_base::none</code> appears in any of the
18912 initial elements of the format pattern, white space is allowed but not
18913 required. In either case, any required followed by all optional white
18914 space (as recognized by <code>ct.is()</code>) is consumed.</ins>
18915 If <code>(str.flags() & str.showbase)</code> is <code>false</code>, ...
18923 <h3><a name="837"></a>837.
18924 <code>basic_ios::copyfmt()</code> overly loosely specified
18926 <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#New">New</a>
18927 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18928 <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>
18929 <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>
18930 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
18931 <p><b>Discussion:</b></p>
18934 The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
18939 <i>Effects</i>: If <code>(this == &rhs)</code> does
18940 nothing. Otherwise assigns to the member objects of <code>*this</code>
18941 the corresponding member objects of <code>rhs</code>, except that
18946 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
18951 <code>exceptions()</code> is altered last by
18952 calling <code>exceptions(rhs.except)</code>
18957 the contents of arrays pointed at by <code>pword</code>
18958 and <code>iword</code> are copied not the pointers themselves
18965 Since the rest of the text doesn't specify what the member objects
18966 of <code>basic_ios</code> are this seems a little too loose.
18971 <p><b>Proposed resolution:</b></p>
18974 I propose to tighten things up by adding a <i>Postcondition</i> clause
18975 to the function like so:
18979 <i>Postconditions:</i>
18984 <th colspan="2"><code>copyfmt()</code> postconditions</th>
18993 <td><code>rdbuf()</code></td>
18994 <td><i>unchanged</i></td>
18997 <td><code>tie()</code></td>
18998 <td><code>rhs.tie()</code></td>
19001 <td><code>rdstate()</code></td>
19002 <td><i>unchanged</i></td>
19005 <td><code>exceptions()</code></td>
19006 <td><code>rhs.exceptions()</code></td>
19009 <td><code>flags()</code></td>
19010 <td><code>rhs.flags()</code></td>
19013 <td><code>width()</code></td>
19014 <td><code>rhs.width()</code></td>
19017 <td><code>precision()</code></td>
19018 <td><code>rhs.precision()</code></td>
19021 <td><code>fill()</code></td>
19022 <td><code>rhs.fill()</code></td>
19025 <td><code>getloc()</code></td>
19026 <td><code>rhs.getloc()</code></td>
19033 The format of the table follows Table 117 (as
19034 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
19040 The intent of the new table is not to impose any new requirements or
19041 change existing ones, just to be more explicit about what I believe is
19050 <h3><a name="838"></a>838.
19051 can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
19053 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19054 <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
19055 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
19056 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
19057 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
19058 <p><b>Discussion:</b></p>
19061 From message c++std-lib-20003...
19066 The description of <code>istream_iterator</code> in
19067 24.5.1 [istream.iterator], p1 specifies that objects of the
19068 class become the <i>end-of-stream</i> (EOS) iterators under the
19069 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
19070 with this paragraph):
19075 If the end of stream is reached (<code>operator void*()</code> on the
19076 stream returns <code>false</code>), the iterator becomes equal to
19077 the <i>end-of-stream</i> iterator value.
19082 One possible implementation approach that has been used in practice is
19083 for the iterator to set its <code>in_stream</code> pointer to 0 when
19084 it reaches the end of the stream, just like the default ctor does on
19085 initialization. The problem with this approach is that
19086 the <i>Effects</i> clause for <code>operator++()</code> says the
19087 iterator unconditionally extracts the next value from the stream by
19088 evaluating <code>*in_stream >> value</code>, without checking
19089 for <code>(in_stream == 0)</code>.
19094 Conformance to the requirement outlined in the <i>Effects</i> clause
19095 can easily be verified in programs by setting <code>eofbit</code>
19096 or <code>failbit</code> in <code>exceptions()</code> of the associated
19097 stream and attempting to iterate past the end of the stream: each
19098 past-the-end access should trigger an exception. This suggests that
19099 some other, more elaborate technique might be intended.
19104 Another approach, one that allows <code>operator++()</code> to attempt
19105 to extract the value even for EOS iterators (just as long
19106 as <code>in_stream</code> is non-0) is for the iterator to maintain a
19107 flag indicating whether it has reached the end of the stream. This
19108 technique would satisfy the presumed requirement implied by
19109 the <i>Effects</i> clause mentioned above, but it isn't supported by
19110 the exposition-only members of the class (no such flag is shown). This
19111 approach is also found in existing practice.
19116 The inconsistency between existing implementations raises the question
19117 of whether the intent of the specification is that a non-EOS iterator
19118 that has reached the EOS become a non-EOS one again after the
19119 stream's <code>eofbit</code> flag has been cleared? That is, are the
19120 assertions in the program below expected to pass?
19124 <pre> sstream strm ("1 ");
19125 istream_iterator eos;
19126 istream_iterator it (strm);
19129 assert (it == eos);
19131 strm << "2 3 ";
19132 assert (it != eos);
19139 Or is it intended that once an iterator becomes EOS it stays EOS until
19140 the end of its lifetime?
19145 <p><b>Proposed resolution:</b></p>
19148 The discussion of this issue on the reflector suggests that the intent
19149 of the standard is for an <code>istreambuf_iterator</code> that has
19150 reached the EOS to remain in the EOS state until the end of its
19151 lifetime. Implementations that permit EOS iterators to return to a
19152 non-EOS state may only do so as an extension, and only as a result of
19153 calling <code>istream_iterator</code> member functions on EOS
19154 iterators whose behavior is in this case undefined.
19159 To this end we propose to change 24.5.1 [istream.iterator], p1,
19165 The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream
19166 is not defined. For any other iterator value a <code>const T*</code>
19167 is returned.<ins> Invoking <code>operator++()</code> on
19168 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
19169 to store things into istream iterators...
19174 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
19179 <pre>istream_iterator();</pre>
19181 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
19182 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
19184 <pre>istream_iterator(istream_type &s);</pre>
19186 <i>Effects</i>: Initializes <code>in_stream</code> with &s. value
19187 may be initialized during construction or the first time it is
19189 <ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins>
19191 <pre>istream_iterator(const istream_iterator &x);</pre>
19193 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
19194 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
19196 <pre>istream_iterator& operator++();</pre>
19198 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
19199 <i>Effects</i>: <code>*in_stream >> value</code>.
19201 <pre>istream_iterator& operator++(int);</pre>
19203 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
19205 <blockquote><pre>istream_iterator tmp (*this);
19206 *in_stream >> value;
OSDN Git Service
