| blob | fc705efb44261306ba9952894352780627edca1a |
1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
4 <style>ins {background-color:#FFFFA0}
5 del {background-color:#FFFFA0}</style></head>
8 <table>
9 <tbody><tr>
12 </tr>
13 <tr>
16 </tr>
17 <tr>
20 </tr>
21 <tr>
24 </tr>
25 </tbody></table>
29 <ul>
30 <li>
31 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
32 <li>
33 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
34 <li>
35 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
36 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
37 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
38 </ul>
39 <p>The purpose of this document is to record the status of issues
40 which have come before the Library Working Group (LWG) of the ANSI
41 (J16) and ISO (WG21) C++ Standards Committee. Issues represent
43 are not to be used to request new features. </p>
45 <p>This document contains only library issues which are actively being
46 considered by the Library Working Group. That is, issues which have a
47 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>,
48 <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
49 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
50 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
52 <p>The issues in these lists are not necessarily formal ISO Defect
53 Reports (DR's). While some issues will eventually be elevated to
54 official Defect Report status, other issues will be disposed of in
57 <p>This document is in an experimental format designed for both
58 viewing via a world-wide web browser and hard-copy printing. It
59 is available as an HTML file for browsing or PDF file for
60 printing.</p>
63 different versions; a Committee Version and a Public
64 Version. Beginning with Revision 14 the two versions were combined
65 into a single version.</p>
68 reminder to the LWG of current progress on issues. Such notes are
69 strictly unofficial and should be read with caution as they may be
70 incomplete or incorrect. Be aware that LWG support for a particular
71 resolution can quickly change if new viewpoints or killer examples are
72 presented in subsequent discussions.</p>
74 <p>For the most current official version of this document see
76 Requests for further information about this document should include
78 submitted to Information Technology Industry Council (ITI), 1250 Eye
81 <p>Public information as to how to obtain a copy of the C++ Standard,
82 join the standards committee, submit an issue, or comment on an issue
83 can be found in the comp.std.c++ FAQ.
84 Public discussion of C++ Standard related issues occurs on <a href="news://comp.std.c++/">news:comp.std.c++</a>.
85 </p>
87 <p>For committee members, files available on the committee's private
88 web site include the HTML version of the Standard itself. HTML
89 hyperlinks from this issues list to those files will only work for
90 committee members who have downloaded them into the same disk
91 directory as the issues list files. </p>
93 <ul>
94 <li>R40:
96 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>.
97 </li>
98 <li>R39:
100 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
101 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.
102 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
103 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-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
104 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
105 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
106 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
107 </li>
108 <li>R38:
110 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
111 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>
112 </li>
113 <li>R37:
115 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>.
116 </li>
117 <li>R36:
119 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
121 </li>
122 <li>R35:
124 </li>
125 <li>R34:
126 2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
127 </li>
128 <li>R33:
130 </li>
131 <li>R32:
134 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
135 </li>
136 <li>R31:
138 new issues received after the post-Sydney mailing. Added
139 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-active.html#478">478</a>.
140 </li>
141 <li>R30:
142 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
143 Voted all "Ready" issues from R29 into the working paper.
144 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-active.html#462">462</a>.
145 </li>
146 <li>R29:
147 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>.
148 </li>
149 <li>R28:
150 Post-Kona mailing: reflects decisions made at the Kona meeting.
151 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>.
152 </li>
153 <li>R27:
154 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>.
155 </li>
156 <li>R26:
157 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
158 All issues in Ready status were voted into DR status. All issues in
159 DR status were voted into WP status.
160 </li>
161 <li>R25:
162 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>.
163 </li>
164 <li>R24:
165 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
166 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
167 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
168 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
169 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
170 </li>
171 <li>R23:
172 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>.
173 Moved issues in the TC to TC status.
174 </li>
175 <li>R22:
176 Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
177 </li>
178 <li>R21:
179 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>.
180 </li>
181 <li>R20:
182 Post-Redmond mailing; reflects actions taken in Redmond. Added
183 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
184 <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
185 not discussed at the meeting.
187 All Ready issues were moved to DR status, with the exception of issues
188 <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>.
190 Noteworthy issues discussed at Redmond include
191 <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-active.html#233">233</a>,
192 <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-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
193 </li>
194 <li>R19:
195 Pre-Redmond mailing. Added new issues
196 <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>.
197 </li>
198 <li>R18:
199 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
200 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
201 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>.
203 Changed status of issues
204 <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>
205 <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>
206 <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>
207 <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>
208 <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>
209 <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>
211 to DR.
213 Changed status of issues
214 <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>
215 <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>
216 <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>
217 <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>
218 <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>
219 <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>
220 <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>
221 <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>
222 <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>
223 to Ready.
225 Closed issues
226 <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>
227 <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>
229 as NAD.
231 </li>
232 <li>R17:
233 Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
234 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>.
235 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>.
236 </li>
237 <li>R16:
238 post-Toronto mailing; reflects actions taken in Toronto. Added new
239 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
240 <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>,
241 <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>,
242 <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>,
243 <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>,
244 <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>,
245 <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>,
246 <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>,
247 <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>,
248 <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>,
249 <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>,
250 <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>,
251 <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>,
252 <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
253 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
254 <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
255 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
256 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
257 the bug in enough places.
258 </li>
259 <li>R15:
260 pre-Toronto mailing. Added issues
261 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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
262 changes so that we pass Weblint tests.
263 </li>
264 <li>R14:
265 post-Tokyo II mailing; reflects committee actions taken in
266 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)
267 </li>
268 <li>R13:
269 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>.
270 </li>
271 <li>R12:
272 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
273 <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
274 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
276 </li>
277 <li>R11:
278 post-Kona mailing: Updated to reflect LWG and full committee actions
280 <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>
281 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
282 "closed" documents. Changed the proposed resolution of issue
283 <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
285 </li>
286 <li>R10:
287 pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
288 <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>,
289 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
290 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
291 </li>
292 <li>R9:
293 pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
294 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
296 </li>
297 <li>R8:
298 post-Dublin mailing. Updated to reflect LWG and full committee actions
300 </li>
301 <li>R7:
302 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>,
303 <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>,
304 <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>,
305 <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)
306 </li>
307 <li>R6:
308 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
309 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
310 </li>
311 <li>R5:
312 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
313 <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
315 </li>
316 <li>R4:
317 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
318 <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
320 </li>
321 <li>R3:
322 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>
324 </li>
325 <li>R2:
326 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,
327 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
328 </li>
329 <li>R1:
330 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
331 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
332 </li>
333 </ul>
334 <h2>
338 suggestion from the issue submitter, and should not be construed as
339 the view of LWG.</p>
342 but is not yet ready to move the issue forward. There are several
343 possible reasons for open status:</p>
344 <ul>
345 <li>Consensus may have not yet have been reached as to how to deal
346 with the issue.</li>
347 <li>Informal consensus may have been reached, but the LWG awaits
349 <li>The LWG wishes to consult additional technical experts before
350 proceeding.</li>
352 </ul>
355 construed as the view of LWG. Comments on the current state of
356 discussions are often given at the end of open issues in an italic
357 font. Such comments are for information only and should not be given
358 undue importance.</p>
361 the issue is a duplicate of another issue, and will not be further
363 issue number. </p>
366 the issue is not a defect in the Standard, and the issue is ready to
367 forward to the full committee as a proposed record of response. A
372 for which the LWG previously reached informal consensus.</p>
375 that the issue is a defect in the Standard, the <b>Proposed
376 Resolution</b> is correct, and the issue is ready to forward to the
377 full committee for further action as a Defect Report (DR).</p>
380 committee has voted to forward the issue to the Project Editor to be
381 processed as a Potential Defect Report. The Project Editor reviews
382 the issue, and then forwards it to the WG21 Convenor, who returns it
383 to the full committee for final disposition. This issues list
384 accords the status of DR to all these Defect Reports regardless of
385 where they are in that process.</p>
388 WG21 committee has voted to accept the Defect Report's Proposed
389 Resolution as a Technical Corrigenda. Action on this issue is thus
390 complete and no further action is possible under ISO rules.</p>
393 resolution has not been accepted as a Technical Corrigendum, but
394 the full WG21 committee has voted to apply the Defect Report's Proposed
395 Resolution to the working paper.</p>
398 committee has determined that this issue is not a defect in the
399 Standard. Action on this issue is thus complete and no further
400 action is possible under ISO rules.</p>
403 status, the LWG believes that this issue should be revisited at the
404 next revision of the standard. It is usually paired with NAD.</p>
406 <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
407 they first appear on the issues list. They may progress to
408 <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
409 is actively working on them. When the LWG has reached consensus on
410 the disposition of an issue, the status will then change to
411 <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 <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
412 forward Ready issues to the Project Editor, they are given the
413 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
414 become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
415 or are closed without action other than a Record of Response
416 (<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
417 only issues which are truly defects in the Standard move to the
418 formal ISO DR status.
419 </p>
422 <hr>
423 <a name="23"><h3>23. Num_get overflow result</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
424 <p>The current description of numeric input does not account for the
425 possibility of overflow. This is an implicit result of changing the
426 description to rely on the definition of scanf() (which fails to
427 report overflow), and conflicts with the documented behavior of
428 traditional and current implementations. </p>
430 <p>Users expect, when reading a character sequence that results in a
431 value unrepresentable in the specified type, to have an error
432 reported. The standard as written does not permit this. </p>
436 <p>
437 I don't feel comfortable with the proposed resolution to issue 23: It
438 kind of simplifies the issue to much. Here is what is going on:
439 </p>
441 <p>
442 Currently, the behavior of numeric overflow is rather counter intuitive
443 and hard to trace, so I will describe it briefly:
444 </p>
446 <ul>
447 <li>
448 According to 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
450 return an input error; otherwise a value is converted to the rules
452 </li>
453 <li>
455 </li>
456 <li>
458 character matching the conversion specification could be extracted
460 to fail due to an input error and clearly does not apply to the case
461 of overflow.
462 </li>
463 <li>
464 Thus, the conversion is performed according to the rules of
467 </li>
468 <li>
470 many matching characters as there are and on overflow continue to
471 consume matching characters but also return a value identical to
472 the maximum (or minimum for signed types if there was a leading minus)
474 </li>
475 <li>
476 Thus, according to the current wording in the standard, overflows
479 before trying a conversion. With the current wording, it can be
480 detected whether the overflow was due to a positive or negative
481 number for signed types.
482 </li>
483 </ul>
487 <p>The basic problem is that we've defined our behavior,
488 including our error-reporting behavior, in terms of C90. However,
489 C90's method of reporting overflow in scanf is not technically an
493 upon overflow. We considered three options based on this:</p>
494 <ol>
495 <li>Set failbit upon conversion error (including overflow), and
496 don't store any value.</li>
498 indicated the precise nature of the error.</li>
499 <li>Set failbit upon conversion error. If the error was due to
501 overflow indication.</li>
502 </ol>
509 <p>Discussed at Lillehammer. General outline of what we want the
510 solution to look like: we want to say that overflow is an error, and
511 provide a way to distinguish overflow from other kinds of errors.
512 Choose candidate field the same way scanf does, but don't describe
513 the rest of the process in terms of format. If a finite input field
514 is too large (positive or negative) to be represented as a finite
515 value, then set failbit and assign the nearest representable value.
516 Bill will provide wording.</p>
518 <hr>
519 <a name="96"><h3>96. Vector<bool> is not a container</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
521 pointer types are not references and pointers. </p>
523 <p>Also it forces everyone to have a space optimization instead of a
524 speed one.</p>
527 Nonconforming, Forces Optimization Choice.</p>
532 <p><i>[In Dublin many present felt that failure to meet Container
533 requirements was a defect. There was disagreement as to whether
534 or not the optimization requirements constituted a defect.]</i></p>
536 <p><i>[The LWG looked at the following resolutions in some detail:
537 <br>
540 Container requirements.<br>
542 * Add a new category of container requirements which
545 <br>
546 No alternative had strong, wide-spread, support and every alternative
548 <br>
549 There was also mention of a transition scheme something like (1) add
553 <p><i>[Modifying container requirements to permit returning proxies
555 was also discussed.]</i></p>
557 <p><i>[It was also noted that there is a partial but ugly workaround in
559 allocator.]</i></p>
563 of a two step approach: a) deprecate, b) provide replacement under a
565 my dead body. This resolution was mentioned in the LWG report to the
566 full committee, where several additional committee members indicated
567 over-my-dead-body positions.]</i></p>
569 <p>Discussed at Lillehammer. General agreement that we should
571 a different name, e.g. bit_vector. This might make it possible to
573 after C++0x. There was also a suggestion that
574 in C++0x we could additional say that it's implementation defined
576 primary template, but there wasn't general agreement that this was a
577 good idea.</p>
581 <hr>
582 <a name="201"><h3>201. Numeric limits terminology wrong</h3></a><p><b>Section:</b> 18.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.limits"> [lib.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 21 Dec 1999</p>
583 <p>
584 In some places in this section, the terms "fundamental types" and
586 The current usage is incorrect because void is a fundamental type and
587 pointers are scalar types, neither of which should have
588 specializations of numeric_limits.
589 </p>
591 <p><i>[Lillehammer: it remains true that numeric_limits is using
592 imprecise language. However, none of the proposals for changed
593 wording are clearer. A redesign of numeric_limits is needed, but this
594 is more a task than an open issue.]</i></p>
595 <hr>
596 <a name="233"><h3>233. Insertion hints in associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Apr 2000</p>
597 <p>
601 to where it should go. Table 69 claims that the execution time is
602 amortized constant if the insert winds up taking place adjacent to
605 insert.
606 </p>
607 <p>
608 The question is whether there is any guarantee about the relationship
610 is.
611 </p>
612 <p>
613 I believe the present state is that there is no guarantee: The user
615 disregard it entirely.
616 </p>
620 The vote [in Redmond] was on whether to elaborately specify the use of
621 the hint, or to require behavior only if the value could be inserted
622 adjacent to the hint. I would like to ensure that we have a chance to
623 vote for a deterministic treatment: "before, if possible, otherwise
624 after, otherwise anywhere appropriate", as an alternative to the
625 proposed "before or after, if possible, otherwise [...]".
626 </p>
631 <p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
632 change</p>
634 <blockquote>
635 iterator p is a hint pointing to where the insert
636 should start to search.
637 </blockquote>
641 <blockquote>
642 insertion adjacent to iterator p is preferred if
643 more than one insertion point is valid.
644 </blockquote>
648 <blockquote>
649 logarithmic in general, but amortized constant if
650 t is inserted right after p.
651 </blockquote>
655 <blockquote>
656 logarithmic in general, but amortized constant if
657 t is inserted adjacent to iterator p.
658 </blockquote>
660 <p><i>[Toronto: there was general agreement that this is a real defect:
661 when inserting an element x into a multiset that already contains
662 several copies of x, there is no way to know whether the hint will be
663 used. The proposed resolution was that the new element should always
664 be inserted as close to the hint as possible. So, for example, if
665 there is a subsequence of equivalent values, then providing a.begin()
666 as the hint means that the new element should be inserted before the
667 subsequence even if a.begin() is far away. JC van Winkel supplied
668 precise wording for this proposed resolution, and also for an
669 alternative resolution in which hints are only used when they are
670 adjacent to the insertion point.]</i></p>
672 <p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
673 in which an insertion hint would be used even when it is far from the
674 insertion point. This was contingent on seeing a reference
675 implementation showing that it is possible to implement this
676 requirement without loss of efficiency. John Potter provided such a
677 reference implementation.]</i></p>
679 <p><i>[Redmond: The LWG was reluctant to adopt the proposal that
680 emerged from Copenhagen: it seemed excessively complicated, and went
681 beyond fixing the defect that we identified in Toronto. PJP provided
682 the new wording described in this issue. Nathan agrees that we
683 shouldn't adopt the more detailed semantics, and notes: "we know that
684 you can do it efficiently enough with a red-black tree, but there are
685 other (perhaps better) balanced tree techniques that might differ
688 <p><i>[Curaçao: Nathan should give us the alternative wording he
689 suggests so the LWG can decide between the two options.]</i></p>
691 <p><i>[Lillehammer: The LWG previously rejected the more detailed
692 semantics, because it seemed more loike a new feature than like
693 defect fixing. We're now more sympathetic to it, but we (especially
694 Bill) are still worried about performance. N1780 describes a naive
695 algorithm, but it's not clear whether there is a non-naive
696 implementation. Is it possible to implement this as efficently as
697 the current version of insert?]</i></p>
699 <p><i>[Post Lillehammer: N1780 updated in post meeting mailing with
700 feedback from Lillehammer with more information regarding performance.
701 ]</i></p>
703 <hr>
704 <a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p>
708 <blockquote>
709 Complexity: If first and last are forward iterators, bidirectional
710 iterators, or random access iterators, the complexity is linear in
711 the number of elements in the range [first, last) plus the distance
712 to the end of the vector. If they are input iterators, the complexity
713 is proportional to the number of elements in the range [first, last)
714 times the distance to the end of the vector.
715 </blockquote>
717 <p>First, this fails to address the non-iterator forms of
720 <p>Second, the complexity for input iterators misses an edge case --
721 it requires that an arbitrary number of elements can be added at
726 complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
729 <blockquote>
730 Complexity: In the worst case, inserting a single element into a
731 deque takes time linear in the minimum of the distance from the
732 insertion point to the beginning of the deque and the distance
733 from the insertion point to the end of the deque. Inserting a
734 single element either at the beginning or end of a deque always
735 takes constant time and causes a single call to the copy constructor
736 of T.
737 </blockquote>
741 <blockquote>
742 Complexity: The complexity is linear in the number of elements
743 inserted plus the distance to the end of the vector.
744 </blockquote>
746 <p><i>[For input iterators, one may achieve this complexity by first
750 <p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p>
752 <blockquote>
753 Complexity: The complexity is linear in the number of elements
754 inserted plus the shorter of the distances to the beginning and
755 end of the deque. Inserting a single element at either the
756 beginning or the end of a deque causes a single call to the copy
757 constructor of T.
758 </blockquote>
761 <p>This is a real defect, and proposed resolution fixes it: some
762 complexities aren't specified that should be. This proposed
763 resolution does constrain deque implementations (it rules out the
764 most naive possible implementations), but the LWG doesn't see a
765 reason to permit that implementation.</p>
766 <hr>
767 <a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt>
768 </h3></a><p><b>Section:</b> 19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Aug 2000</p>
769 <p>
770 Many of the standard exception types which implementations are
771 required to throw are constructed with a const std::string&
772 parameter. For example:
773 </p>
776 namespace std {
777 class out_of_range : public logic_error {
778 public:
779 explicit out_of_range(const string& what_arg);
780 };
781 }
783 1 The class out_of_range defines the type of objects thrown as excep-
784 tions to report an argument value not in its expected range.
786 out_of_range(const string& what_arg);
788 Effects:
789 Constructs an object of class out_of_range.
790 Postcondition:
791 strcmp(what(), what_arg.c_str()) == 0.
792 </pre>
794 <p>
795 There are at least two problems with this:
796 </p>
797 <ol>
798 <li>A program which is low on memory may end up throwing
799 std::bad_alloc instead of out_of_range because memory runs out while
800 constructing the exception object.</li>
801 <li>An obvious implementation which stores a std::string data member
802 may end up invoking terminate() during exception unwinding because the
803 exception object allocates memory (or rather fails to) as it is being
804 copied.</li>
805 </ol>
807 <p>
808 There may be no cure for (1) other than changing the interface to
809 out_of_range, though one could reasonably argue that (1) is not a
810 defect. Personally I don't care that much if out-of-memory is reported
811 when I only have 20 bytes left, in the case when out_of_range would
812 have been reported. People who use exception-specifications might care
813 a lot, though.
814 </p>
816 <p>
817 There is a cure for (2), but it isn't completely obvious. I think a
818 note for implementors should be made in the standard. Avoiding
819 possible termination in this case shouldn't be left up to chance. The
820 cure is to use a reference-counted "string" implementation
821 in the exception object. I am not necessarily referring to a
822 std::string here; any simple reference-counting scheme for a NTBS
823 would do.
824 </p>
828 <p>
829 ...I'm not so concerned about (1). After all, a library implementation
830 can add const char* constructors as an extension, and users don't
832 a lame position to be forced into. FWIW, std::exception and
833 std::bad_alloc don't require a temporary basic_string.
834 </p>
836 <p>
837 ...I don't think the fixed-size buffer is a solution to the problem,
838 strictly speaking, because you can't satisfy the postcondition
839 <br>
841 <br>
842 For all values of what_arg (i.e. very long values). That means that
843 the only truly conforming solution requires a dynamic allocation.
844 </p>
848 <p>The most important progress we made at the Redmond meeting was
849 realizing that there are two separable issues here: the const
850 string& constructor, and the copy constructor. If a user writes
852 string& constructor is invoked before anything gets thrown. The
853 copy constructor is potentially invoked during stack unwinding.</p>
855 <p>The copy constructor is a more serious problem, becuase failure
857 constructor must be nothrow. <i>Curaçao: Howard thinks this
858 requirement may already be present.</i></p>
860 <p>The fundamental problem is that it's difficult to get the nothrow
861 requirement to work well with the requirement that the exception
862 objects store a string of unbounded size, particularly if you also try
863 to make the const string& constructor nothrow. Options discussed
864 include:</p>
866 <ul>
867 <li>Limit the size of a string that exception objects are required to
868 throw: change the postconditions of 19.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
869 and 19.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
870 "strncmp(what(), what_arg._str(), N) == 0, where N is an
873 copy constructor. It's the implementor's responsibility to get it
874 right. (An implementor might use a simple refcount class.)</li>
875 <li>Compromise between the two: an implementation is not allowed to
876 throw if the string's length is less than some N, but, if it doesn't
877 throw, the string must compare equal to the argument.</li>
879 </ul>
886 <p>Throwing a bad_alloc while trying to construct a message for another
887 exception-derived class is not necessarily a bad thing. And the
892 <p>All involved would like to see const char* constructors added, but
895 <p>I believe the no throw specs currently decorating these functions
896 could be improved by some kind of static no throw spec checking
897 mechanism (in a future C++ language). As they stand, the copy
898 constructors might fail via a call to unexpected. I think what is
899 intended here is that the copy constructors can't fail.</p>
901 <p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
902 Post-Redmond: James Kanze noticed that the copy constructors of
903 exception-derived classes do not have nothrow clauses. Those
904 classes have no copy constructors declared, meaning the
905 compiler-generated implicit copy constructors are used, and those
906 compiler-generated constructors might in principle throw anything.]</i></p>
908 <hr>
909 <a name="258"><h3>258. Missing allocator requirement</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Aug 2000</p>
910 <p>
911 From lib-7752:
912 </p>
914 <p>
915 I've been assuming (and probably everyone else has been assuming) that
916 allocator instances have a particular property, and I don't think that
917 property can be deduced from anything in Table 32.
918 </p>
920 <p>
921 I think we have to assume that allocator type conversion is a
922 homomorphism. That is, if x1 and x2 are of type X, where
923 X::value_type is T, and if type Y is X::template
925 </p>
927 <p>
928 Further discussion: Howard Hinnant writes, in lib-7757:
929 </p>
931 <p>
932 I think I can prove that this is not provable by Table 32. And I agree
933 it needs to be true except for the "and only if". If x1 != x2, I see no
934 reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't
935 think of a practical instance where this would happen, or be valuable.
936 But I also don't see a need to add that extra restriction. I think we
937 only need:
938 </p>
940 <blockquote>
941 if (x1 == x2) then Y(x1) == Y(x2)
942 </blockquote>
944 <p>
945 If we decide that == on allocators is transitive, then I think I can
946 prove the above. But I don't think == is necessarily transitive on
947 allocators. That is:
948 </p>
950 <p>
951 Given x1 == x2 and x2 == x3, this does not mean x1 == x3.
952 </p>
956 <blockquote>
957 <p>
958 x1 can deallocate pointers from: x1, x2, x3 <br>
959 x2 can deallocate pointers from: x1, x2, x4 <br>
960 x3 can deallocate pointers from: x1, x3 <br>
961 x4 can deallocate pointers from: x2, x4
962 </p>
964 <p>
965 x1 == x2, and x2 == x4, but x1 != x4
966 </p>
967 </blockquote>
970 <p><i>[Toronto: LWG members offered multiple opinions. One
974 the second line from the bottom in table 32 already implies the
975 desired property. This issue should be considered in light of
976 other issues related to allocator instances.]</i></p>
977 <hr>
978 <a name="290"><h3>290. Requirements to for_each and its function object</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p>
979 <p>The specification of the for_each algorithm does not have a
980 "Requires" section, which means that there are no
981 restrictions imposed on the function object whatsoever. In essence it
982 means that I can provide any function object with arbitrary side
983 effects and I can still expect a predictable result. In particular I
984 can expect that the function object is applied exactly last - first
985 times, which is promised in the "Complexity" section.
986 </p>
988 <p>I don't see how any implementation can give such a guarantee
989 without imposing requirements on the function object.
990 </p>
992 <p>Just as an example: consider a function object that removes
993 elements from the input sequence. In that case, what does the
994 complexity guarantee (applies f exactly last - first times) mean?
995 </p>
997 <p>One can argue that this is obviously a nonsensical application and
998 a theoretical case, which unfortunately it isn't. I have seen
999 programmers shooting themselves in the foot this way, and they did not
1000 understand that there are restrictions even if the description of the
1001 algorithm does not say so.
1002 </p>
1004 <p><i>[Lillehammer: This is more general than for_each. We don't want
1005 the function object in transform invalidiating iterators
1007 saying that user code operating on a range may not invalidate
1008 iterators unless otherwise specified. Bill will provide wording.]</i></p>
1010 <hr>
1011 <a name="294"><h3>294. User defined macros and standard headers</h3></a><p><b>Section:</b> 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p>
1012 <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
1013 translation unit that includes a header shall not contain any macros
1014 that define names declared in that header." As I read this, it
1015 would mean that the following program is legal:</p>
1019 </pre>
1025 <p>I think that this phrase was probably formulated before it was
1026 decided that a standard header may freely include other standard
1027 headers. The phrase would be perfectly appropriate for C, for
1028 example. In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
1029 it isn't stringent enough.</p>
1031 <p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
1032 <blockquote>
1033 <p>Each name defined as a macro in a header is reserved to the
1034 implementation for any use if the translation unit includes
1037 <p>A translation unit that includes a header shall not contain any
1038 macros that define names declared or defined in that header. Nor shall
1039 such a translation unit define macros for names lexically
1040 identical to keywords.</p>
1043 using the #undef directive.</p>
1044 </blockquote>
1048 <blockquote>
1049 <p>A translation unit that includes a standard library header shall not
1050 #define or #undef names declared in any standard library header.</p>
1052 <p>A translation unit shall not #define or #undef names lexically
1053 identical to keywords.</p>
1054 </blockquote>
1058 <hr>
1059 <a name="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p><b>Section:</b> 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p>
1060 <p>
1061 In section 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
1062 Table 75 gives the return type of *r-- as convertible to T. This is
1063 not consistent with Table 74 which gives the return type of *r++ as
1064 T&. *r++ = t is valid while *r-- = t is invalid.
1065 </p>
1067 <p>
1068 In section 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
1069 Table 76 gives the return type of a[n] as convertible to T. This is
1070 not consistent with the semantics of *(a + n) which returns T& by
1071 Table 74. *(a + n) = t is valid while a[n] = t is invalid.
1072 </p>
1074 <p>
1075 Discussion from the Copenhagen meeting: the first part is
1076 uncontroversial. The second part, operator[] for Random Access
1077 Iterators, requires more thought. There are reasonable arguments on
1078 both sides. Return by value from operator[] enables some potentially
1079 useful iterators, e.g. a random access "iota iterator" (a.k.a
1081 to do this with return-by-reference, since the reference would be to a
1083 arbitrary Random Access Iterator as template argument, and its
1084 operator[] returns by reference. If we decided that the return type
1085 in Table 76 was correct, we would have to change
1087 code.
1088 </p>
1090 <p>
1092 Random Access Iterator requirements has been present from an early
1093 stage. In both the STL proposal adopted by the committee
1095 Stepanov and Lee), the Random Access Iterator requirements say that
1096 operator[]'s return value is "convertible to T". In N0527
1098 (R.1), and in the STL implementation that HP released to the public,
1099 reverse_iterator's operator[] returns by reference. In 1995, the
1101 original intent for operator[] is unclear.
1102 </p>
1104 <p>
1105 In the long term it may be desirable to add more fine-grained
1106 iterator requirements, so that access method and traversal strategy
1107 can be decoupled. (See "Improved Iterator Categories and
1109 about issue 299 should keep this possibility in mind.
1110 </p>
1112 <p>Further discussion: I propose a compromise between John Potter's
1118 common case uses of random access iterators, while at the same time
1119 allowing iterators such as counting iterator and caching file
1120 iterators to remain random access iterators (iterators where the
1122 lifetime of the iterator).
1123 </p>
1125 <p>
1126 Note that the compromise resolution necessitates a change to
1129 </p>
1131 <p>
1132 Note also there is one kind of mutable random access iterator that
1133 will no longer meet the new requirements. Currently, iterators that
1135 mutable random access iterartor, even though the expression <tt>a[n] =
1136 t</tt> will only modify a temporary that goes away. With this proposed
1139 </p>
1143 <p>
1144 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1147 </p>
1149 <p>
1150 In section 24.1.5 [lib.random.access.iterators], change the
1152 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1156 </p>
1158 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1159 iterator redesign]</i></p>
1161 <hr>
1162 <a name="342"><h3>342. seek and eofbit</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 2001</p>
1165 <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
1166 description of seekg in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
1167 like:</p>
1169 <blockquote>
1170 Behaves as an unformatted input function (as described in 27.6.1.3,
1171 paragraph 1), except that it does not count the number of characters
1172 extracted and does not affect the value returned by subsequent calls to
1173 gcount(). After constructing a sentry object, if fail() != true,
1174 executes rdbuf()Â>pubseekpos( pos).
1175 </blockquote>
1177 <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,
1180 <blockquote>
1181 Each unformatted input function begins execution by constructing an
1182 object of class sentry with the default argument noskipws (second)
1183 argument true. If the sentry object returns true, when converted to a
1184 value of type bool, the function endeavors to obtain the requested
1185 input. Otherwise, if the sentry constructor exits by throwing an
1186 exception or if the sentry object returns false, when converted to a
1187 value of type bool, the function returns without attempting to obtain
1188 any input. In either case the number of extracted characters is set to
1189 0; unformatted input functions taking a character array of non-zero
1190 size as an argument shall also store a null character (using charT())
1191 in the first location of the array. If an exception is thrown during
1192 input then ios::badbit is turned on in *this'ss error state. If
1194 the number of characters extracted. If no exception has been thrown it
1195 ends by storing the count in a member object and returning the value
1196 specified. In any event the sentry object is destroyed before leaving
1197 the unformatted input function.
1198 </blockquote>
1202 <blockquote>
1203 If, after any preparation is completed, is.good() is true, ok_ != false
1204 otherwise, ok_ == false.
1205 </blockquote>
1207 <p>
1208 So although the seekg paragraph says that the operation proceeds if
1209 !fail(), the behavior of unformatted functions says the operation
1210 proceeds only if good(). The two statements are contradictory when only
1211 eofbit is set. I don't think the current text is clear which condition
1212 should be respected.
1213 </p>
1218 "unformatted". That makes specific claims about sentry that
1219 aren't quite appropriate for seeking, which has less fragile failure
1220 modes than actual input. If we do really mean that it's unformatted
1221 input, it should behave the same way as other unformatted input. On
1222 the other hand, "principle of least surprise" is that seeking from EOF
1223 ought to be OK.</p>
1226 <p>Change 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> to:</p>
1227 <blockquote>
1228 Behaves as an unformatted input function (as described in 27.6.1.3,
1229 paragraph 1), except that it does not count the number of characters
1230 extracted, does not affect the value returned by subsequent calls to
1231 gcount(), and does not examine the value returned by the sentry
1232 object. After constructing a sentry object, if <tt>fail() !=
1234 case of success, the function calls clear().
1237 </blockquote>
1242 <p>In C, fseek does clear EOF. This is probably what most users would
1243 expect. We agree that having eofbit set should not deter a seek,
1244 and that a successful seek should clear eofbit. Note
1248 <hr>
1249 <a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p><b>Section:</b> 20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p>
1250 <p>
1251 The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
1252 the construction of an unsafe binding between incompatible pointer
1253 types. For example, given a function whose first parameter type is
1254 'pointer to T', it's possible without error to bind an argument of
1255 type 'pointer to U' when U does not derive from T:
1256 </p>
1257 <pre> foo(T*, int);
1259 struct T {};
1260 struct U {};
1262 U u;
1264 int* p;
1265 int* q;
1267 for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding
1268 </pre>
1270 <p>
1271 The definition of bind1st() includes a functional-style conversion to
1272 map its argument to the expected argument type of the bound function
1273 (see below):
1274 </p>
1275 <pre> typename Operation::first_argument_type(x)
1276 </pre>
1278 <p>
1279 A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
1280 semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
1281 as a reinterpret_cast, thus masking the error.
1282 </p>
1284 <p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
1286 <p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1:
1287 "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
1294 <p>There is no point in fixing bind1st and bind2nd. tr1::bind is a
1295 superior solution. It solves this problem and others.</p>
1296 <hr>
1297 <a name="369"><h3>369. io stream objects and static ctors</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p>
1298 <p>
1299 Is it safe to use standard iostream objects from constructors of
1300 static objects? Are standard iostream objects constructed and are
1301 their associations established at that time?
1302 </p>
1306 <p>
1308 objects are constructed and their associations are established before
1309 the body of main() begins execution. It also refers to ios_base::Init
1310 class as the panacea for constructors of static objects.
1311 </p>
1313 <p>
1314 However, there's nothing in 27.3 [lib.iostream.objects],
1316 that would require implementations to allow access to standard
1317 iostream objects from constructors of static objects.
1318 </p>
1322 <p>Core text refers to some magic object ios_base::Init, which will
1323 be discussed below:</p>
1325 <blockquote>
1326 "The [standard iostream] objects are constructed, and their
1327 associations are established at some time prior to or during
1328 first time an object of class basic_ios<charT,traits>::Init
1329 is constructed, and in any case before the body of main
1331 </blockquote>
1333 <p>
1335 to initialize standard iostream objects earlier than required.
1336 </p>
1339 and unsupported claim:</p>
1341 <blockquote>
1342 "Constructors and destructors for static objects can access these
1343 [standard iostream] objects to read input from stdin or write output
1345 </blockquote>
1347 <p>
1348 The only bit of magic is related to that ios_base::Init class. AFAIK,
1349 the rationale behind ios_base::Init was to bring an instance of this
1351 related header. Such an inclusion would support the claim of footnote
1352 quoted above, because in order to use some standard iostream object it
1354 </p>
1356 <p>
1357 However, while Standard explicitly describes ios_base::Init as
1358 an appropriate class for doing the trick, I failed to found a
1359 mention of an _instance_ of ios_base::Init in Standard.
1360 </p>
1363 <p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
1364 of the paragraph, the following two sentences:</p>
1366 <blockquote>
1368 constructs an ios_base::Init object, these stream objects shall
1369 be constructed before dynamic initialization of non-local
1370 objects defined later in that translation unit, and these stream
1371 objects shall be destroyed after the destruction of dynamically
1372 initialized non-local objects defined later in that translation unit.
1373 </blockquote>
1378 <p>
1379 The original proposed resolution unconditionally required
1380 implementations to define an ios_base::Init object of some
1382 overspecification. First, defining the object may be unnecessary
1383 and even detrimental to performance if an implementation can
1384 guarantee that the 8 standard iostream objects will be initialized
1385 before any other user-defined object in a program. Second, there
1386 is no need to require implementations to document the name of the
1387 object.</p>
1389 <p>
1390 The new proposed resolution gives users guidance on what they need to
1391 do to ensure that stream objects are constructed during startup.</p>
1392 <hr>
1393 <a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p>
1394 <p>
1395 The requirements for multiset and multimap containers (23.1
1396 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
1398 the stability of the required (mutating) member functions. It appears
1399 the standard allows these functions to reorder equivalent elements of
1400 the container at will, yet the pervasive red-black tree implementation
1401 appears to provide stable behaviour.
1402 </p>
1404 <p>This is of most concern when considering the behaviour of erase().
1405 A stability requirement would guarantee the correct working of the
1406 following 'idiom' that removes elements based on a certain predicate
1407 function.
1408 </p>
1412 while (i != m.end()) {
1413 if (pred(i))
1414 m.erase (i++);
1415 else
1416 ++i;
1417 }
1418 </pre>
1420 <p>
1422 througout this loop, absence of the stability requirement could
1423 potentially result in elements being skipped. This would make
1424 this code incorrect, and, furthermore, means that there is no way
1425 of erasing these elements without iterating first over the entire
1426 container, and second over the elements to be erased. This would
1427 be unfortunate, and have a negative impact on both performance and
1428 code simplicity.
1429 </p>
1431 <p>
1432 If the stability requirement is intended, it should be made explicit
1433 (probably through an extra paragraph in clause 23.1.2).
1434 </p>
1435 <p>
1436 If it turns out stability cannot be guaranteed, i'd argue that a
1437 remark or footnote is called for (also somewhere in clause 23.1.2) to
1438 warn against relying on stable behaviour (as demonstrated by the code
1439 above). If most implementations will display stable behaviour, any
1440 problems emerging on an implementation without stable behaviour will
1441 be hard to track down by users. This would also make the need for an
1442 erase_if() member function that much greater.
1443 </p>
1445 <p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
1449 <p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4:
1450 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
1451 are <i>stable</i>: they preserve the relative ordering of equivalent
1452 elements.</p>
1454 <p><i>[Lillehammer: Matt provided wording]</i></p>
1455 <p><i>[Joe Gottman points out that the provided wording does not address
1456 multimap and multiset. N1780 also addresses this issue and suggests
1457 wording.]</i></p>
1459 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
1461 <p><b>Rationale:</b></p>
1462 <p>The LWG agrees that this guarantee is necessary for common user
1463 idioms to work, and that all existing implementations provide this
1464 property. Note that this resolution guarantees stability for
1465 multimap and multiset, not for all associative containers in
1466 general.</p>
1468 <hr>
1469 <a name="376"><h3>376. basic_streambuf semantics</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
1470 <p>
1471 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
1472 the four conditions should be mutually exclusive, but they are not.
1473 The first two cases, as written, are subcases of the third.</p>
1475 <p>
1476 As written, it is unclear what should be the result if cases 1 and 2
1477 are both true, but case 3 is false.
1478 </p>
1480 <p><b>Proposed resolution:</b></p>
1482 <p>Rewrite these conditions as:</p>
1483 <blockquote>
1484 <p>
1485 (which & (ios_base::in|ios_base::out)) == ios_base::in
1486 </p>
1488 <p>
1489 (which & (ios_base::in|ios_base::out)) == ios_base::out
1490 </p>
1492 <p>
1493 (which & (ios_base::in|ios_base::out)) ==
1494 (ios_base::in|ios_base::out)
1495 and way == either ios_base::beg or ios_base::end
1496 </p>
1498 <p>Otherwise</p>
1499 </blockquote>
1501 <p><b>Rationale:</b></p>
1502 <p>It's clear what we wanted to say, we just failed to say it. This
1503 fixes it.</p>
1504 <hr>
1505 <a name="382"><h3>382. codecvt do_in/out result</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p>
1506 <p>
1507 It seems that the descriptions of codecvt do_in() and do_out() leave
1508 sufficient room for interpretation so that two implementations of
1509 codecvt may not work correctly with the same filebuf. Specifically,
1510 the following seems less than adequately specified:
1511 </p>
1513 <ol>
1514 <li>
1515 the conditions under which the functions terminate
1516 </li>
1517 <li>
1518 precisely when the functions return ok
1519 </li>
1520 <li>
1521 precisely when the functions return partial
1522 </li>
1523 <li>
1524 the full set of conditions when the functions return error
1525 </li>
1526 </ol>
1528 <ol>
1529 <li>
1530 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
1531 function: ...Stops if it encounters a character it cannot
1532 convert... This assumes that there *is* a character to
1533 convert. What happens when there is a sequence that doesn't form a
1534 valid source character, such as an unassigned or invalid UNICODE
1535 character, or a sequence that cannot possibly form a character
1537 </li>
1538 <li>
1539 Table 53 says that the function returns codecvt_base::ok
1542 with from pointing to '\xc0' and (from_end==from + 1).
1543 It is not clear whether the return value should be ok
1544 or partial (see below).
1545 </li>
1546 <li>
1547 Table 53 says that the function returns codecvt_base::partial
1549 set up the same way as above, it is not clear whether the return
1550 value should be partial or ok (see above).
1551 </li>
1552 <li>
1553 Table 53, in the row describing the meaning of error mistakenly
1556 is intended, although that is not sufficient. The functions
1557 may also fail when they encounter an invalid source sequence
1558 that cannot possibly form a valid source character (e.g., as
1559 explained in bullet 1 above).
1560 </li>
1561 </ol>
1562 <p>
1563 Finally, the conditions described at the end of 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
1564 </p>
1565 <blockquote>
1566 "A return value of partial, if (from_next == from_end),
1567 indicates that either the destination sequence has not
1568 absorbed all the available destination elements, or that
1569 additional source elements are needed before another
1570 destination element can be produced."
1571 </blockquote>
1572 <p>
1573 If the value is partial, it's not clear to me that (from_next
1574 ==from_end) could ever hold if there isn't enough room
1575 in the destination buffer. In order for (from_next==from_end) to
1576 hold, all characters in that range must have been successfully
1577 converted (according to 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
1578 further source characters to convert, no more room in the
1579 destination buffer can be needed.
1580 </p>
1581 <p>
1582 It's also not clear to me that (from_next==from_end) could ever
1583 hold if additional source elements are needed to produce another
1584 destination character (not element as incorrectly stated in the
1585 text). partial is returned if "not all source characters have
1586 been converted" according to Table 53, which also implies that
1587 (from_next==from) does NOT hold.
1588 </p>
1589 <p>
1590 Could it be that the intended qualifying condition was actually
1591 (from_next != from_end), i.e., that the sentence was supposed
1592 to read
1593 </p>
1594 <blockquote>
1596 </blockquote>
1597 <p>
1598 which would make perfect sense, since, as far as I understand it,
1599 partial can only occur if (from_next != from_end)?
1600 </p>
1601 <p><b>Proposed resolution:</b></p>
1603 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
1604 fixed. Right now, the description of codecvt is too vague for it to
1605 be a useful contract between providers and clients of codecvt
1606 facets. (Note that both vendors and users can be both providers and
1607 clients of codecvt facets.) The major philosophical issue is whether
1608 the standard should only describe mappings that take a single wide
1609 character to multiple narrow characters (and vice versa), or whether
1610 it should describe fully general N-to-M conversions. When the
1611 original standard was written only the former was contemplated, but
1612 today, in light of the popularity of utf8 and utf16, that doesn't
1613 seem sufficient for C++0x. Bill supports general N-to-M conversions;
1614 we need to make sure Martin and Howard agree.]</i></p>
1616 <hr>
1617 <a name="384"><h3>384. equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 18 Oct 2002</p>
1618 <p>
1619 Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
1620 states that at most 2 * log(last - first) + 1
1621 comparisons are allowed for equal_range.
1622 </p>
1624 <p>It is not possible to implement equal_range with these constraints.</p>
1626 <p>In a range of one element as in:</p>
1627 <pre> int x = 1;
1628 equal_range(&x, &x + 1, 1)
1629 </pre>
1631 <p>it is easy to see that at least 2 comparison operations are needed.</p>
1633 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
1635 <p>I have checked a few libraries and they all use the same (nonconforming)
1636 algorithm for equal_range that has a complexity of</p>
1637 <pre> 2* log(distance(first, last)) + 2.
1638 </pre>
1639 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
1641 <p>
1642 It is easy to see that 2 * log(distance) + 2 comparisons are enough
1643 since equal range can be implemented with lower_bound and upper_bound
1644 (both log(distance) + 1).
1645 </p>
1647 <p>
1648 I think it is better to require something like 2log(distance) + O(1) (or
1649 even logarithmic as multiset::equal_range).
1650 Then an implementation has more room to optimize for certain cases (e.g.
1651 have log(distance) characteristics when at most match is found in the range
1652 but 2log(distance) + 4 for the worst case).
1653 </p>
1655 <p><b>Proposed resolution:</b></p>
1656 <p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
1657 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1659 <p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
1660 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1662 <p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
1663 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
1665 <p><i>[Matt provided wording]</i></p>
1666 <p><b>Rationale:</b></p>
1667 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
1668 Ê decided that threw away too much valuable information.Ê The fact
1669 Ê that lower_bound is twice as fast as equal_range is important.
1670 Ê However, it's better to allow an arbitrary additive constant than to
1671 Ê specify an exact count.Ê An exact count would have to
1672 Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to
1673 Ê get this wrong, and don't provide any substantial value for users.</p>
1674 <hr>
1675 <a name="385"><h3>385. Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p>
1676 <p>
1677 Many function templates have parameters that are passed by value;
1678 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
1679 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>. Are the corresponding template parameters
1680 (<tt>Predicate</tt> in this case) implicitly required to be
1681 CopyConstructible, or does that need to be spelled out explicitly?
1682 </p>
1684 <p>
1685 This isn't quite as silly a question as it might seem to be at first
1686 sight. If you call <tt>find_if</tt> in such a way that template
1687 argument deduction applies, then of course you'll get call by value
1688 and you need to provide a copy constructor. If you explicitly provide
1689 the template arguments, however, you can force call by reference by
1690 writing something like <tt>find_if<my_iterator,
1691 my_predicate&></tt>. The question is whether implementation
1692 are required to accept this, or whether this is ill-formed because
1693 my_predicate& is not CopyConstructible.
1694 </p>
1696 <p>
1697 The scope of this problem, if it is a problem, is unknown. Function
1698 object arguments to generic algorithms in clauses 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>
1699 and 26 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numerics"> [lib.numerics]</a> are obvious examples. A review of the whole
1700 library is necessary.
1701 </p>
1702 <p><b>Proposed resolution:</b></p>
1703 <p><i>[
1704 This is really two issues. First, predicates are typically passed by
1705 value but we don't say they must be Copy Constructible. They should
1706 be. Second: is specialization allowed to transform value arguments
1707 into references? References aren't copy constructible, so this should
1708 not be allowed.
1709 ]</i></p>
1710 <hr>
1711 <a name="387"><h3>387. std::complex over-encapsulated</h3></a><p><b>Section:</b> 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p>
1712 <p>
1713 The absence of explicit description of std::complex<T> layout
1714 makes it imposible to reuse existing software developed in traditional
1715 languages like Fortran or C with unambigous and commonly accepted
1716 layout assumptions. There ought to be a way for practitioners to
1717 predict with confidence the layout of std::complex<T> whenever T
1718 is a numerical datatype. The absence of ways to access individual
1719 parts of a std::complex<T> object as lvalues unduly promotes
1720 severe pessimizations. For example, the only way to change,
1721 independently, the real and imaginary parts is to write something like
1722 </p>
1724 <pre>complex<T> z;
1725 // ...
1726 // set the real part to r
1727 z = complex<T>(r, z.imag());
1728 // ...
1729 // set the imaginary part to i
1730 z = complex<T>(z.real(), i);
1731 </pre>
1733 <p>
1734 At this point, it seems appropriate to recall that a complex number
1735 is, in effect, just a pair of numbers with no particular invariant to
1736 maintain. Existing practice in numerical computations has it that a
1737 complex number datatype is usually represented by Cartesian
1738 coordinates. Therefore the over-encapsulation put in the specification
1739 of std::complex<> is not justified.
1740 </p>
1742 <p><b>Proposed resolution:</b></p>
1743 <p>Add the following requirements to 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.2/4:</p>
1744 <blockquote>
1745 <p>If z is an lvalue expression of type cv std::complex<T> then</p>
1747 <ul>
1748 <li>the expression reinterpret_cast<cv T(&)[2]>(z)
1749 is well-formed; and</li>
1750 <li>reinterpret_cast<cvT(&)[2]>(z)[0]designates the
1751 real part of z; and</li>
1752 <li>reinterpret_cast<cvT(&)[2]>(z)[1]designates the
1753 imaginary part of z.</li>
1754 </ul>
1756 <p>
1757 Moreover, if a is an expression of pointer type cv complex<T>*
1758 and the expression a[i] is well-defined for an integer expression
1759 i then:
1760 </p>
1762 <ul>
1763 <li>reinterpret_cast<cvT*>(a)[2+i] designates the real
1764 part of a[i]; and</li>
1765 <li>reinterpret_cast<cv T*>(a)[2+i+1] designates the
1766 imaginary part of a[i].</li>
1767 </ul>
1768 </blockquote>
1770 <p>In the header synopsis in 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, replace</p>
1771 <pre> template<class T> T real(const complex<T>&);
1772 template<class T> T imag(const complex<T>&);
1773 </pre>
1775 <p>with</p>
1777 <pre> template<class T> const T& real(const complex<T>&);
1778 template<class T> T& real( complex<T>&);
1779 template<class T> const T& imag(const complex<T>&);
1780 template<class T> T& imag( complex<T>&);
1781 </pre>
1783 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 1, change</p>
1784 <pre> template<class T> T real(const complex<T>&);
1785 </pre>
1786 <p>to</p>
1787 <pre> template<class T> const T& real(const complex<T>&);
1788 template<class T> T& real( complex<T>&);
1789 </pre>
1793 <p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> paragraph 2, change</p>
1795 </pre>
1799 </pre>
1801 part of <i>x</i></p>.
1803 <p><i>[Kona: The layout guarantee is absolutely necessary for C
1804 compatibility. However, there was disagreement about the other part
1805 of this proposal: retrieving elements of the complex number as
1806 lvalues. An alternative: continue to have real() and imag() return
1807 rvalues, but add set_real() and set_imag(). Straw poll: return
1808 lvalues - 2, add setter functions - 5. Related issue: do we want
1809 reinterpret_cast as the interface for converting a complex to an
1810 array of two reals, or do we want to provide a more explicit way of
1811 doing it? Howard will try to resolve this issue for the next
1812 meeting.]</i></p>
1814 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
1816 <p><b>Rationale:</b></p>
1817 <p>The LWG believes that C99 compatibility would be enough
1818 justification for this change even without other considerations. All
1819 existing implementations already have the layout proposed here.</p>
1820 <hr>
1821 <a name="394"><h3>394. behavior of formatted output on failure</h3></a><p><b>Section:</b> 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Dec 2002</p>
1822 <p>
1823 There is a contradiction in Formatted output about what bit is
1824 supposed to be set if the formatting fails. On sentence says it's
1825 badbit and another that it's failbit.
1826 </p>
1827 <p>
1828 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
1829 functions:
1830 </p><pre> ... If the generation fails, then the formatted output function
1831 does setstate(ios::failbit), which might throw an exception.
1832 </pre>
1833 <p></p>
1834 <p>
1835 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
1836 </p>
1837 <p>
1838 ... The formatting conversion occurs as if it performed the
1839 following code fragment:
1840 </p>
1841 <p>
1842 </p><pre> bool failed =
1843 use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
1844 > >
1845 (getloc()).put(*this, *this, fill(), val). failed();
1847 ... If failed is true then does setstate(badbit) ...
1848 </pre>
1849 <p></p>
1850 <p>
1851 The original intent of the text, according to Jerry Schwarz (see
1852 c++std-lib-10500), is captured in the following paragraph:
1853 </p>
1854 <p>
1856 of some underlying failure, such as disk full or socket closure;
1858 because of some inconsistency such as negative widths. So typically
1859 if you clear badbit and try to output something else you'll fail
1860 again, but if you clear failbit and try to output something else
1861 you'll succeed.
1862 </p>
1863 <p>
1864 In the case of the arithmetic inserters, since num_put cannot
1865 report failure by any means other than exceptions (in response
1866 to which the stream must set badbit, which prevents the kind of
1867 recoverable error reporting mentioned above), the only other
1868 detectable failure is if the iterator returned from num_put
1869 returns true from failed().
1870 </p>
1871 <p>
1872 Since that can only happen (at least with the required iostream
1873 specializations) under such conditions as the underlying failure
1874 referred to above (e.g., disk full), setting badbit would seem
1875 to be the appropriate response (indeed, it is required in
1876 27.6.2.5.2, p1). It follows that failbit can never be directly
1877 set by the arithmetic (it can only be set by the sentry object
1878 under some unspecified conditions).
1879 </p>
1880 <p>
1881 The situation is different for other formatted output functions
1882 which can fail as a result of the streambuf functions failing
1883 (they may do so by means other than exceptions), and which are
1884 then required to set failbit.
1885 </p>
1886 <p>
1887 The contradiction, then, is that ostream::operator<<(int) will
1888 set badbit if the disk is full, while operator<<(ostream&,
1889 char) will set failbit under the same conditions. To make the behavior
1890 consistent, the Common requirements sections for the Formatted output
1891 functions should be changed as proposed below.
1892 </p>
1893 <p><b>Proposed resolution:</b></p>
1896 <p><i>[Kona: There's agreement that this is a real issue. What we
1897 decided at Kona: 1. An error from the buffer (which can be detected
1898 either directly from streambuf's member functions or by examining a
1899 streambuf_iterator) should always result in badbit getting set.
1900 2. There should never be a circumstance where failbit gets set.
1901 That represents a formatting error, and there are no circumstances
1902 under which the output facets are specified as signaling a
1903 formatting error. (Even more so for string output that for numeric
1904 because there's nothing to format.) If we ever decide to make it
1905 possible for formatting errors to exist then the facets can signal
1906 the error directly, and that should go in clause 22, not clause 27.
1908 eliminated. It's not clear whether it's intended to mean a buffer
1909 error (e.g. a full disk), a formatting error, or something else.
1910 Most people thought it was supposed to refer to buffer errors; if
1911 so, we should say so. Martin will provide wording.]</i></p>
1913 <p><b>Rationale:</b></p>
1915 <hr>
1916 <a name="396"><h3>396. what are characters zero and one</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p>
1917 <p>
1918 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
1919 having the value of 0 or 1 but there is no definition of what
1920 that means for charT other than char and wchar_t. And even for
1921 those two types, the values 0 and 1 are not actually what is
1922 intended -- the values '0' and '1' are. This, along with the
1923 converse problem in the description of to_string() in 23.3.5.2,
1924 p33, looks like a defect remotely related to DR 303.
1925 </p>
1926 <p>
1927 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
1928 </p>
1929 <pre>23.3.5.1:
1930 -6- An element of the constructed string has value zero if the
1931 corresponding character in str, beginning at position pos,
1932 is 0. Otherwise, the element has the value one.
1933 </pre>
1934 <pre>23.3.5.2:
1935 -33- Effects: Constructs a string object of the appropriate
1936 type and initializes it to a string of length N characters.
1937 Each character is determined by the value of its
1938 corresponding bit position in *this. Character position N
1939 ?- 1 corresponds to bit position zero. Subsequent decreasing
1940 character positions correspond to increasing bit positions.
1941 Bit value zero becomes the character 0, bit value one becomes
1942 the character 1.
1943 </pre>
1944 <p>
1945 Also note the typo in 23.3.5.1, p6: the object under construction
1946 is a bitset, not a string.
1947 </p>
1948 <p><b>Proposed resolution:</b></p>
1949 <p>Change the constructor's function declaration immediately before
1950 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p3 to:</p>
1951 <pre> template <class charT, class traits, class Allocator>
1952 explicit
1953 bitset(const basic_string<charT, traits, Allocator>& str,
1954 typename basic_string<charT, traits, Allocator>::size_type pos = 0,
1955 typename basic_string<charT, traits, Allocator>::size_type n =
1956 basic_string<charT, traits, Allocator>::npos,
1957 charT zero = charT('0'), charT one = charT('1'))
1958 </pre>
1959 <p>Change the first two sentences of 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p6 to: "An
1960 element of the constructed string has value 0 if the corresponding
1965 "The function then throws invalid_argument if any of the rlen
1966 characters in str beginning at position pos is other than <i>zero</i>
1967 or <i>one</i>. The function uses traits::eq() to compare the character
1968 values."
1969 </p>
1972 immediately before 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to:</p>
1976 </pre>
1977 <p>Change the last sentence of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> p33 to: "Bit
1978 value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
1979 character <tt><i>one</i></tt>.</p>
1980 <p>Change 23.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> p8 to:</p>
1981 <p><b>Returns</b>:</p>
1982 <pre> os << x.template to_string<charT,traits,allocator<charT> >(
1983 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'),
1984 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1'));
1985 </pre>
1986 <p><b>Rationale:</b></p>
1987 <p>There is a real problem here: we need the character values of '0'
1988 and '1', and we have no way to get them since strings don't have
1990 provide an extra object, either a ctype facet or a full locale,
1991 which would be used to widen '0' and '1'. However, there was some
1992 discomfort about using such a heavyweight mechanism. The proposed
1993 resolution allows those users who care about this issue to get it
1994 right.</p>
1995 <p>We fix the inserter to use the new arguments. Note that we already
1996 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>
1998 <hr>
1999 <a name="397"><h3>397. ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p>
2000 <p>
2001 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2002 </p>
2003 <p>
2004 27.6.2.3, p4 says this about the ostream::sentry dtor:
2005 </p>
2006 <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
2007 is true, calls os.flush().
2008 </pre>
2009 <p>
2010 27.6.2.6, p7 that describes ostream::flush() says:
2011 </p>
2012 <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
2013 If that function returns ?-1 calls setstate(badbit) (which
2014 may throw ios_base::failure (27.4.4.3)).
2015 </pre>
2016 <p>
2017 That seems like a defect, since both pubsync() and setstate() can
2018 throw an exception.
2019 </p>
2020 <p><b>Proposed resolution:</b></p>
2021 <p><i>[
2022 The contradiction is real. Clause 17 says destructors may never
2023 throw exceptions, and clause 27 specifies a destructor that does
2024 throw. In principle we might change either one. We're leaning
2026 clause, and then putting in a footnote saying the sentry destructor
2027 is the only one that can throw. PJP suggests specifying that
2028 sentry::~sentry() should internally catch any exceptions it might cause.
2029 ]</i></p>
2030 <hr>
2031 <a name="398"><h3>398. effects of end-of-file on unformatted input functions</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p>
2032 <p>
2033 While reviewing unformatted input member functions of istream
2034 for their behavior when they encounter end-of-file during input
2035 I found that the requirements vary, sometimes unexpectedly, and
2036 in more than one case even contradict established practice (GNU
2037 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2038 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2039 </p>
2040 <p>
2041 The following unformatted input member functions set eofbit if they
2042 encounter an end-of-file (this is the expected behavior, and also
2043 the behavior of all major implementations):
2044 </p>
2045 <p>
2046 </p><pre> basic_istream<charT, traits>&
2047 get (char_type*, streamsize, char_type);
2048 </pre>
2049 <p></p>
2050 <p>
2051 Also sets failbit if it fails to extract any characters.
2052 </p>
2053 <p>
2054 </p><pre> basic_istream<charT, traits>&
2055 get (char_type*, streamsize);
2056 </pre>
2057 <p></p>
2058 <p>
2059 Also sets failbit if it fails to extract any characters.
2060 </p>
2061 <p>
2062 </p><pre> basic_istream<charT, traits>&
2063 getline (char_type*, streamsize, char_type);
2064 </pre>
2065 <p></p>
2066 <p>
2067 Also sets failbit if it fails to extract any characters.
2068 </p>
2069 <p>
2070 </p><pre> basic_istream<charT, traits>&
2071 getline (char_type*, streamsize);
2072 </pre>
2073 <p></p>
2074 <p>
2075 Also sets failbit if it fails to extract any characters.
2076 </p>
2077 <p>
2078 </p><pre> basic_istream<charT, traits>&
2079 ignore (int, int_type);
2080 </pre>
2081 <p></p>
2082 <p>
2083 </p><pre> basic_istream<charT, traits>&
2084 read (char_type*, streamsize);
2085 </pre>
2086 <p></p>
2087 <p>
2088 Also sets failbit if it encounters end-of-file.
2089 </p>
2090 <p>
2091 </p><pre> streamsize readsome (char_type*, streamsize);
2092 </pre>
2093 <p></p>
2095 <p>
2096 The following unformated input member functions set failbit but
2097 not eofbit if they encounter an end-of-file (I find this odd
2098 since the functions make it impossible to distinguish a general
2099 failure from a failure due to end-of-file; the requirement is
2100 also in conflict with all major implementation which set both
2101 eofbit and failbit):
2102 </p>
2103 <p>
2104 </p><pre> int_type get();
2105 </pre>
2106 <p></p>
2107 <p>
2108 </p><pre> basic_istream<charT, traits>&
2109 get (char_type&);
2110 </pre>
2111 <p></p>
2112 <p>
2113 These functions only set failbit of they extract no characters,
2114 otherwise they don't set any bits, even on failure (I find this
2115 inconsistency quite unexpected; the requirement is also in
2116 conflict with all major implementations which set eofbit
2117 whenever they encounter end-of-file):
2118 </p>
2119 <p>
2120 </p><pre> basic_istream<charT, traits>&
2121 get (basic_streambuf<charT, traits>&, char_type);
2122 </pre>
2123 <p></p>
2124 <p>
2125 </p><pre> basic_istream<charT, traits>&
2126 get (basic_streambuf<charT, traits>&);
2127 </pre>
2128 <p></p>
2129 <p>
2130 This function sets no bits (all implementations except for
2131 STLport and Classic Iostreams set eofbit when they encounter
2132 end-of-file):
2133 </p>
2134 <p>
2135 </p><pre> int_type peek ();
2136 </pre>
2137 <p></p>
2138 <p><b>Proposed resolution:</b></p>
2139 <p>Informally, what we want is a global statement of intent saying
2140 that eofbit gets set if we trip across EOF, and then we can take
2141 away the specific wording for individual functions. A full review
2142 is necessary. The wording currently in the standard is a mishmash,
2143 and changing it on an individual basis wouldn't make things better.
2144 Dietmar will do this work.</p>
2145 <hr>
2146 <a name="401"><h3>401. incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 27 Feb 2003</p>
2147 <p>
2148 I think that in par2 of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> the last two
2149 lines of table 32 contain two incorrect type casts. The lines are ...
2150 </p>
2152 <pre> a.construct(p,t) Effect: new((void*)p) T(t)
2153 a.destroy(p) Effect: ((T*)p)?->~T()
2154 </pre>
2156 <p>
2157 .... with the prerequisits coming from the preceding two paragraphs, especially
2158 from table 31:
2159 </p>
2161 <pre> alloc<T> a ;// an allocator for T
2162 alloc<T>::pointer p ;// random access iterator
2163 // (may be different from T*)
2164 alloc<T>::reference r = *p;// T&
2165 T const& t ;
2166 </pre>
2168 <p>
2170 this would require then conversions to T* and void* for all
2171 alloc<T>::pointer, so it would implicitely introduce extra
2172 requirements for alloc<T>::pointer, additionally to the only
2173 current requirement (being a random access iterator).
2174 </p>
2175 <p><b>Proposed resolution:</b></p>
2176 <p>
2180 </p>
2182 <p>
2185 in 13.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/over.html#over.ref"> [over.ref]</a> (for which I have filed another DR on 29.11.2002).
2186 </p>
2188 <p><i>[Kona: The LWG thinks this is somewhere on the border between
2189 Open and NAD. The intend is clear: <tt>construct</tt> constructs an
2190 object at the location <i>p</i>. It's reading too much into the
2191 description to think that literally calling <tt>new</tt> is
2192 required. Tweaking this description is low priority until we can do
2193 a thorough review of allocators, and, in particular, allocators with
2194 non-default pointer types.]</i></p>
2196 <hr>
2197 <a name="408"><h3>408. Is vector<reverse_iterator<char*> > forbidden?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p>
2198 <p>
2199 I've been discussing iterator semantics with Dave Abrahams, and a
2200 surprise has popped up. I don't think this has been discussed before.
2201 </p>
2203 <p>
2204 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> says that the only operation that can be performed on "singular"
2205 iterator values is to assign a non-singular value to them. (It
2206 doesn't say they can be destroyed, and that's probably a defect.)
2207 Some implementations have taken this to imply that there is no need
2208 to initialize the data member of a reverse_iterator<> in the default
2209 constructor. As a result, code like
2210 </p>
2211 <blockquote>
2212 std::vector<std::reverse_iterator<char*> > v(7);
2213 v.reserve(1000);
2214 </blockquote>
2215 <p>
2216 invokes undefined behavior, because it must default-initialize the
2217 vector elements, and then copy them to other storage. Of course many
2218 other vector operations on these adapters are also left undefined,
2219 and which those are is not reliably deducible from the standard.
2220 </p>
2222 <p>
2223 I don't think that 24.1 was meant to make standard-library iterator
2224 types unsafe. Rather, it was meant to restrict what operations may
2225 be performed by functions which take general user- and standard
2226 iterators as arguments, so that raw pointers would qualify as
2227 iterators. However, this is not clear in the text, others have come
2228 to the opposite conclusion.
2229 </p>
2231 <p>
2232 One question is whether the standard iterator adaptors have defined
2233 copy semantics. Another is whether they have defined destructor
2234 semantics: is
2235 </p>
2236 <blockquote>
2237 { std::vector<std::reverse_iterator<char*> > v(7); }
2238 </blockquote>
2239 <p>
2240 undefined too?
2241 </p>
2243 <p>
2244 Note this is not a question of whether algorithms are allowed to
2245 rely on copy semantics for arbitrary iterators, just whether the
2246 types we actually supply support those operations. I believe the
2247 resolution must be expressed in terms of the semantics of the
2248 adapter's argument type. It should make clear that, e.g., the
2249 reverse_iterator<T> constructor is actually required to execute
2250 T(), and so copying is defined if the result of T() is copyable.
2251 </p>
2253 <p>
2254 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2255 constructor more precisely, has some relevance to this issue.
2256 However, it is not the whole story.
2257 </p>
2259 <p>
2260 The issue was whether
2261 </p>
2262 <blockquote>
2263 reverse_iterator() { }
2264 </blockquote>
2265 <p>
2266 is allowed, vs.
2267 </p>
2268 <blockquote>
2269 reverse_iterator() : current() { }
2270 </blockquote>
2272 <p>
2273 The difference is when T is char*, where the first leaves the member
2274 uninitialized, and possibly equal to an existing pointer value, or
2275 (on some targets) may result in a hardware trap when copied.
2276 </p>
2278 <p>
2279 8.5 paragraph 5 seems to make clear that the second is required to
2280 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
2281 types.
2282 </p>
2284 <p>
2285 But that only takes care of reverse_iterator, and doesn't establish
2286 a policy for all iterators. (The reverse iterator adapter was just
2287 an example.) In particular, does my function
2288 </p>
2289 <blockquote>
2290 template <typename Iterator>
2291 void f() { std::vector<Iterator> v(7); }
2292 </blockquote>
2293 <p>
2294 evoke undefined behavior for some conforming iterator definitions?
2295 I think it does, now, because vector<> will destroy those singular
2296 iterator values, and that's explicitly disallowed.
2297 </p>
2299 <p>
2300 24.1 shouldn't give blanket permission to copy all singular iterators,
2301 because then pointers wouldn't qualify as iterators. However, it
2302 should allow copying of that subset of singular iterator values that
2303 are default-initialized, and it should explicitly allow destroying any
2304 iterator value, singular or not, default-initialized or not.
2305 </p>
2307 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
2308 <p><b>Proposed resolution:</b></p>
2310 <p><i>[
2311 We don't want to require all singular iterators to be copyable,
2312 because that is not the case for pointers. However, default
2313 construction may be a special case. Issue: is it really default
2314 construction we want to talk about, or is it something like value
2315 initialization? We need to check with core to see whether default
2316 constructed pointers are required to be copyable; if not, it would be
2317 wrong to impose so strict a requirement for iterators.
2318 ]</i></p>
2320 <hr>
2321 <a name="416"><h3>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3></a><p><b>Section:</b> 18.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.c.limits"> [lib.c.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2322 <p>
2324 Given two overloads of the function foo(), one taking an argument of type
2325 int and the other taking a long, which one will the call foo(LONG_MAX)
2326 resolve to? The expected answer should be foo(long), but whether that
2327 is true depends on the #defintion of the LONG_MAX macro, specifically
2328 its type. This issue is about the fact that the type of these macros
2329 is not actually required to be the same as the the type each respective
2330 limit.
2331 <br>
2333 Section 18.2.2 of the C++ Standard does not specify the exact types of
2334 the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h>
2335 headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
2336 <br>
2338 Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
2339 these constants] shall be replaced by constant expressions suitable for use
2340 in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
2341 the following shall be replaced by expressions that have the same type as
2342 would an expression that is an object of the corresponding type converted
2343 according to the integer promotions."
2344 <br>
2347 LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
2348 converted to the first of the following set of types that can represent it:
2349 int, long int, long long int. So on an implementation where (sizeof(long)
2350 == sizeof(int)) this type is actually int, while on an implementation where
2351 (sizeof(long) > sizeof(int)) holds this type will be long.
2352 <br>
2354 This is not an issue in C since the type of the macro cannot be detected
2355 by any conforming C program, but it presents a portability problem in C++
2356 where the actual type is easily detectable by overload resolution.
2358 </p>
2359 <p><b>Proposed resolution:</b></p>
2361 <p><i>[Kona: the LWG does not believe this is a defect. The C macro
2362 definitions are what they are; we've got a better
2363 mechanism, <tt>std::numeric_limits</tt>, that is specified more
2364 precisely than the C limit macros. At most we should add a
2365 nonnormative note recommending that users who care about the exact
2366 types of limit quantities should use <limits> instead of
2367 <climits>.]</i></p>
2369 <hr>
2370 <a name="417"><h3>417. what does ctype::do_widen() return on failure</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2371 <p>
2372 The Effects and Returns clauses of the do_widen() member function of
2373 the ctype facet fail to specify the behavior of the function on failure.
2374 That the function may not be able to simply cast the narrow character
2375 argument to the type of the result since doing so may yield the wrong value
2376 for some wchar_t encodings. Popular implementations of ctype<wchar_t> that
2377 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
2378 when the argument's MSB is set. There is no way for the the rest of locale
2379 and iostream to reliably detect this failure.
2380 </p>
2381 <p><b>Proposed resolution:</b></p>
2382 <p><i>[Kona: This is a real problem. Widening can fail. It's unclear
2383 what the solution should be. Returning WEOF works for the wchar_t
2384 specialization, but not in general. One option might be to add a
2385 default, like <i>narrow</i>. But that's an incompatible change.
2386 Using <i>traits::eof</i> might seem like a good idea, but facets
2387 don't have access to traits (a recurring problem). We could
2388 have <i>widen</i> throw an exception, but that's a scary option;
2389 existing library components aren't written with the assumption
2390 that <i>widen</i> can throw.]</i></p>
2391 <hr>
2392 <a name="418"><h3>418. exceptions thrown during iostream cleanup</h3></a><p><b>Section:</b> 27.4.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::Init"> [lib.ios::Init]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2393 <p>
2394 The dtor of the ios_base::Init object is supposed to call flush() on the
2395 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
2396 This call may cause an exception to be thrown.
2397 </p>
2399 <p>
2400 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
2401 </p>
2403 <p>
2404 The question is: What should this dtor do if one or more of these calls
2405 to flush() ends up throwing an exception? This can happen quite easily
2406 if one of the facets installed in the locale imbued in the iostream
2407 object throws.
2408 </p>
2409 <p><b>Proposed resolution:</b></p>
2410 <p><i>[Kona: We probably can't do much better than what we've got, so
2411 the LWG is leaning toward NAD. At the point where the standard
2412 stream objects are being cleaned up, the usual error reporting
2413 mechanism are all unavailable. And exception from flush at this
2414 point will definitely cause problems. A quality implementation
2415 might reasonably swallow the exception, or call abort, or do
2416 something even more drastic.]</i></p>
2417 <hr>
2418 <a name="419"></a><h3><a name="419">419. istream extractors not setting failbit if eofbit is already set</a></h3><p><b>Section:</b> 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2419 <p>
2421 27.6.1.1.2, p2 says that istream::sentry ctor prepares for input if is.good()
2422 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2423 true if the stream state is good after any preparation. 27.6.1.2.1, p1 then
2424 says that a formatted input function endeavors to obtain the requested input
2425 if the sentry's operator bool() returns true.
2427 Given these requirements, no formatted extractor should ever set failbit if
2428 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2429 all implementations I tested. The program below prints out
2431 eof = 1, fail = 0
2432 eof = 1, fail = 1
2434 on all of them.
2435 </p>
2436 <pre>
2437 #include <sstream>
2438 #include <cstdio>
2440 int main()
2441 {
2444 int i = 0;
2446 strm >> i;
2449 !!strm.eof (), !!strm.fail ());
2451 strm >> i;
2454 !!strm.eof (), !!strm.fail ());
2455 }
2457 </pre>
2458 <p>
2459 <br>
2461 Comments from Jerry Schwarz (c++std-lib-11373):
2462 <br>
2464 Jerry Schwarz wrote:
2465 <br>
2467 I don't know where (if anywhere) it says it in the standard, but the
2468 formatted extractors are supposed to set failbit if they don't extract
2469 any characters. If they didn't then simple loops like
2470 <br>
2472 while (cin >> x);
2473 <br>
2475 would loop forever.
2476 <br>
2478 Further comments from Martin Sebor:
2479 <br>
2481 The question is which part of the extraction should prevent this from happening
2482 by setting failbit when eofbit is already set. It could either be the sentry
2483 object or the extractor. It seems that most implementations have chosen to
2484 set failbit in the sentry [...] so that's the text that will need to be
2485 corrected.
2487 </p>
2488 <p><b>Proposed resolution:</b></p>
2489 <p>Kona: Possibly NAD. If eofbit is set then good() will return false. We
2490 then set <i>ok</i> to false. We believe that the sentry's
2491 constructor should always set failbit when <i>ok</i> is false, and
2492 we also think the standard already says that. Possibly it could be
2493 clearer.</p>
2495 <hr>
2496 <a name="421"><h3>421. is basic_streambuf copy-constructible?</h3></a><p><b>Section:</b> 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2497 <p>
2498 The reflector thread starting with c++std-lib-11346 notes that the class
2499 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
2500 is copy-constructible but that the semantics of the copy constructors
2501 are not defined anywhere. Further, different implementations behave
2502 differently in this respect: some prevent copy construction of objects
2503 of these types by declaring their copy ctors and assignment operators
2504 private, others exhibit undefined behavior, while others still give
2505 these operations well-defined semantics.
2506 </p>
2508 <p>
2509 Note that this problem doesn't seem to be isolated to just the three
2510 types mentioned above. A number of other types in the library section
2511 of the standard provide a compiler-generated copy ctor and assignment
2512 operator yet fail to specify their semantics. It's believed that the
2513 only types for which this is actually a problem (i.e. types where the
2514 compiler-generated default may be inappropriate and may not have been
2515 intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
2516 </p>
2517 <p><b>Proposed resolution:</b></p>
2518 <p>
2519 27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
2520 </p>
2522 <blockquote>
2523 <pre>basic_streambuf(const basic_streambuf& sb);
2524 basic_streambuf& operator=(const basic_streambuf& sb);
2525 </pre>
2526 </blockquote>
2528 <p>Insert after 27.5.2.1, paragraph 2:</p>
2529 <blockquote>
2530 <pre>basic_streambuf(const basic_streambuf& sb);
2531 </pre>
2533 <p>Constructs a copy of sb.</p>
2534 <p>Postcondtions:</p>
2535 <pre> eback() == sb.eback()
2536 gptr() == sb.gptr()
2537 egptr() == sb.egptr()
2538 pbase() == sb.pbase()
2539 pptr() == sb.pptr()
2540 epptr() == sb.epptr()
2541 getloc() == sb.getloc()
2542 </pre>
2544 <pre>basic_streambuf& operator=(const basic_streambuf& sb);
2545 </pre>
2547 <p>Assigns the data members of sb to this.</p>
2549 <p>Postcondtions:</p>
2550 <pre> eback() == sb.eback()
2551 gptr() == sb.gptr()
2552 egptr() == sb.egptr()
2553 pbase() == sb.pbase()
2554 pptr() == sb.pptr()
2555 epptr() == sb.epptr()
2556 getloc() == sb.getloc()
2557 </pre>
2559 <p>Returns: *this.</p>
2560 </blockquote>
2562 <p>27.7.1 [lib.stringbuf]:</p>
2564 <b>Option A:</b>
2566 <blockquote>
2567 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
2569 <pre>basic_stringbuf(const basic_stringbuf&); // not defined
2570 basic_stringbuf& operator=(const basic_stringbuf&); // not defined
2571 </pre>
2572 </blockquote>
2574 <b>Option B:</b>
2576 <blockquote>
2577 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
2579 <pre>basic_stringbuf(const basic_stringbuf& sb);
2580 basic_stringbuf& operator=(const basic_stringbuf& sb);
2581 </pre>
2583 <p>27.7.1.1, insert after paragraph 4:</p>
2585 <pre>basic_stringbuf(const basic_stringbuf& sb);</pre>
2587 <p>
2588 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
2589 </p>
2591 <p>Postcondtions: </p>
2592 <pre> str() == sb.str()
2593 gptr() - eback() == sb.gptr() - sb.eback()
2594 egptr() - eback() == sb.egptr() - sb.eback()
2595 pptr() - pbase() == sb.pptr() - sb.pbase()
2596 getloc() == sb.getloc()
2597 </pre>
2599 <p>
2600 Note: The only requirement on epptr() is that it point beyond the
2601 initialized range if an output sequence exists. There is no requirement
2602 that epptr() - pbase() == sb.epptr() - sb.pbase().
2603 </p>
2605 <pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre>
2606 <p>After assignment the basic_stringbuf has the same state as if it
2607 were initially copy constructed from sb, except that the
2608 basic_stringbuf is allowed to retain any excess capacity it might have,
2609 which may in turn effect the value of epptr().
2610 </p>
2611 </blockquote>
2613 <p>27.8.1.1 [lib.filebuf]</p>
2615 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
2617 <blockquote>
2618 <pre>private:
2619 basic_filebuf(const basic_filebuf&); // not defined
2620 basic_filebuf& operator=(const basic_filebuf&); // not defined
2621 </pre>
2622 </blockquote>
2623 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
2624 derived classes. We are leaning toward allowing basic_streambuf to
2625 be copyable, and specifying its precise semantics. (Probably the
2626 obvious: copying the buffer pointers.) We are less sure whether
2627 the streambuf derived classes should be copyable. Howard will
2628 write up a proposal.]</i></p>
2630 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
2631 being copyable: it can lead to an encapsulation violation. Filebuf
2632 inherits from streambuf. Now suppose you inhert a my_hijacking_buf
2633 from streambuf. You can copy the streambuf portion of a filebuf to a
2634 my_hijacking_buf, giving you access to the pointers into the
2635 filebuf's internal buffer. Perhaps not a very strong argument, but
2636 it was strong enough to make people nervous. There was weak
2637 preference for having streambuf not be copyable. There was weak
2638 preference for having stringbuf not be copyable even if streambuf
2639 is. Move this issue to open for now.
2640 ]</i></p>
2642 <p><b>Rationale:</b></p>
2643 <p>
2644 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
2645 and assignment operator are the same as currently implied by the lack
2646 of declarations: public and simply copies the data members. This
2647 resolution is not a change but a clarification of the current
2648 standard.
2649 </p>
2651 <p>
2652 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
2653 basic_stringbuf not copyable. This is likely the status-quo of
2654 current implementations. B) Reasonable copy semantics of
2655 basic_stringbuf can be defined and implemented. A copyable
2656 basic_streambuf is arguably more useful than a non-copyable one. This
2657 should be considered as new functionality and not the fixing of a
2658 defect. If option B is chosen, ramifications from issue 432 are taken
2659 into account.
2660 </p>
2662 <p>
2663 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
2664 basic_filebuf.
2665 </p>
2667 <hr>
2668 <a name="422"><h3>422. explicit specializations of member functions of class templates</h3></a><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2669 <p>
2670 It has been suggested that 17.4.3.1, p1 may or may not allow programs to
2671 explicitly specialize members of standard templates on user-defined types.
2672 The answer to the question might have an impact where library requirements
2674 member functions they will be able to detect an implementation's strict
2675 conformance to Effects clauses that describe the behavior of the function
2676 in terms of the other member function (the one explicitly specialized by
2678 </p>
2679 <p><b>Proposed resolution:</b></p>
2681 <p>
2682 Add the following sentence immediately after the text of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>, p1:
2683 </p>
2685 <blockquote>
2686 The behavior of a program that declares explicit specializations
2687 of any members of class templates or explicit specializations of
2688 any member templates of classes or class templates defined in
2689 this library is undefined.
2690 </blockquote>
2693 <p><i>[Kona: straw poll was 6-1 that user programs should not be
2694 allowed to specialize individual member functions of standard
2695 library class templates, and that doing so invokes undefined
2696 behavior. Post-Kona: Martin provided wording.]</i></p>
2698 <p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
2699 to specialize individual member functions unless they specialize the
2700 whole class, but we're not sure these words say what we want them to;
2701 they could be read as prohibiting the specialization of any standard
2702 library class templates. We need to consult with CWG to make sure we
2703 use the right wording.]</i></p>
2705 <hr>
2706 <a name="423"><h3>423. effects of negative streamsize in iostreams</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2708 <p>
2709 A third party test suite tries to exercise istream::ignore(N) with
2710 a negative value of N and expects that the implementation will treat
2711 N as if it were 0. Our implementation asserts that (N >= 0) holds and
2712 aborts the test.
2713 </p>
2715 <p>
2716 I can't find anything in section 27 that prohibits such values but I don't
2717 see what the effects of such calls should be, either (this applies to
2718 a number of unformatted input functions as well as some member functions
2719 of the basic_streambuf template).
2720 </p>
2721 <p><b>Proposed resolution:</b></p>
2722 <p>
2723 I propose that we add to each function in clause 27 that takes an argument,
2725 is to allow negative streamsize values in calls to precision() and width()
2726 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
2727 ostream::write().
2728 </p>
2730 <p><i>[Kona: The LWG agreed that this is probably what we want. However, we
2731 need a review to find all places where functions in clause 27 take
2732 arguments of type streamsize that shouldn't be allowed to go
2733 negative. Martin will do that review.]</i></p>
2735 <hr>
2736 <a name="424"></a><h3><a name="424">424. normative notes</a></h3><p><b>Section:</b> 17.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.summary"> [lib.structure.summary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2738 <p>
2739 The text in 17.3.1.1, p1 says:
2740 <br>
2743 paragraphs are normative."
2744 <br>
2747 some of which are clearly intended to be normative (see list 1), while
2748 some others are not (see list 2). There are also those where the intent
2749 is not so clear (see list 3).
2750 <br>
2752 List 1 -- Examples of (presumably) normative Notes:
2753 <br>
2755 20.4.1.1, p3, 20.4.1.1, p10, 21.3.1, p11, 22.1.1.2, p11, 23.2.1.3, p2,
2756 25.3.7, p3, 26.2.6, p14a, 27.5.2.4.3, p7.
2757 <br>
2759 List 2 -- Examples of (presumably) informative Notes:
2760 <br>
2762 18.4.1.3, p3, 21.3.5.6, p14, 22.2.1.5.2, p3, 25.1.1, p4, 26.2.5, p1,
2763 27.4.2.5, p6.
2764 <br>
2766 List 3 -- Examples of Notes that are not clearly either normative
2767 or informative:
2768 <br>
2770 22.1.1.2, p8, 22.1.1.5, p6, 27.5.2.4.5, p4.
2771 <br>
2773 None of these lists is meant to be exhaustive.
2774 </p>
2776 <p><b>Proposed resolution:</b></p>
2778 <p><i>[Definitely a real problem. The big problem is there's material
2779 that doesn't quite fit any of the named paragraph categories
2780 (e.g. <b>Effects</b>). Either we need a new kind of named
2781 paragraph, or we need to put more material in unnamed paragraphs
2782 jsut after the signature. We need to talk to the Project Editor
2783 about how to do this.
2784 ]</i></p>
2786 <hr>
2787 <a name="427"><h3>427. stage 2 and rationale of DR 221</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2788 <p>
2789 The requirements specified in Stage 2 and reiterated in the rationale
2790 of DR 221 (and echoed again in DR 303) specify that num_get<charT>::
2791 do_get() compares characters on the stream against the widened elements
2793 </p>
2795 <p>
2796 An implementation is required to allow programs to instantiate the num_get
2797 template on any charT that satisfies the requirements on a user-defined
2798 character type. These requirements do not include the ability of the
2799 character type to be equality comparable (the char_traits template must
2800 be used to perform tests for equality). Hence, the num_get template cannot
2801 be implemented to support any arbitrary character type. The num_get template
2802 must either make the assumption that the character type is equality-comparable
2803 (as some popular implementations do), or it may use char_traits<charT> to do
2804 the comparisons (some other popular implementations do that). This diversity
2805 of approaches makes it difficult to write portable programs that attempt to
2806 instantiate the num_get template on user-defined types.
2807 </p>
2808 <p><b>Proposed resolution:</b></p>
2809 <p><i>[Kona: the heart of the problem is that we're theoretically
2810 supposed to use traits classes for all fundamental character
2811 operations like assignment and comparison, but facets don't have
2812 traits parameters. This is a fundamental design flaw and it
2813 appears all over the place, not just in this one place. It's not
2814 clear what the correct solution is, but a thorough review of facets
2815 and traits is in order. The LWG considered and rejected the
2816 possibility of changing numeric facets to use narrowing instead of
2817 widening. This may be a good idea for other reasons (see issue
2818 <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
2819 issue. Whether we use widen or narrow the <tt>num_get</tt> facet
2820 still has no idea which traits class the user wants to use for
2821 the comparison, because only streams, not facets, are passed traits
2822 classes. The standard does not require that two different
2823 traits classes with the same <tt>char_type</tt> must necessarily
2824 have the same behavior.]</i></p>
2826 <p>Informally, one possibility: require that some of the basic
2827 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
2828 and <tt>assign</tt>, must behave the same way for all traits classes
2829 with the same <tt>char_type</tt>. If we accept that limitation on
2830 traits classes, then the facet could reasonably be required to
2831 use <tt>char_traits<charT></tt></p>.
2833 <hr>
2834 <a name="430"><h3>430. valarray subset operations</h3></a><p><b>Section:</b> 26.3.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
2835 <p>
2836 The standard fails to specify the behavior of valarray::operator[](slice)
2838 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
2839 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
2840 object (e.g., slice (2, 1, 1) for a valarray of size 1).
2841 </p>
2842 <p><b>Proposed resolution:</b></p>
2843 <p><i>[Kona: the LWG believes that invalid slices should invoke
2844 undefined behavior. Valarrays are supposed to be designed for high
2845 performance, so we don't want to require specific checking. We
2846 need wording to express this decision.]</i></p>
2847 <hr>
2848 <a name="431"></a><h3><a name="431">431. Swapping containers with unequal allocators</a></h3><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Sep 2003</p>
2849 <p>Clause 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4 says that implementations
2850 are permitted to supply containers that are unable to cope with
2851 allocator instances and that container implementations may assume
2852 that all instances of an allocator type compare equal. We gave
2853 implementers this latitude as a temporary hack, and eventually we
2854 want to get rid of it. What happens when we're dealing with
2855 allocators that <i>don't</i> compare equal?
2856 </p>
2858 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
2859 objects of type <tt>vector<int, my_alloc></tt> and that
2860 <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if
2861 we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p>
2863 <p>1. This operation is illegal. Perhaps we could say that an
2864 implementation is required to check and to throw an exception, or
2865 perhaps we could say it's undefined behavior.</p>
2866 <p>2. The operation performs a slow swap (i.e. using three
2867 invocations of <tt>operator=</tt>, leaving each allocator with its
2868 original container. This would be an O(N) operation.</p>
2869 <p>3. The operation swaps both the vectors' contents and their
2870 allocators. This would be an O(1) operation. That is:</p>
2871 <blockquote>
2872 <pre> my_alloc a1(...);
2873 my_alloc a2(...);
2874 assert(a1 != a2);
2876 vector<int, my_alloc> v1(a1);
2877 vector<int, my_alloc> v2(a2);
2878 assert(a1 == v1.get_allocator());
2879 assert(a2 == v2.get_allocator());
2881 v1.swap(v2);
2882 assert(a1 == v2.get_allocator());
2883 assert(a2 == v1.get_allocator());
2884 </pre>
2885 </blockquote>
2887 <p><b>Proposed resolution:</b></p>
2889 <p><i>[Kona: This is part of a general problem. We need a paper
2890 saying how to deal with unequal allocators in general.]</i></p>
2892 <p><i>[pre-Sydney: Howard argues for option 3 in n1599.]</i></p>
2894 <hr>
2895 <a name="446"><h3>446. Iterator equality between different containers</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 16 Dec 2003</p>
2896 <p>
2897 What requirements does the standard place on equality comparisons between
2898 iterators that refer to elements of different containers. For example, if
2899 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
2900 Is it allowed to throw an exception?
2901 </p>
2903 <p>
2904 The standard appears to be silent on both questions.
2905 </p>
2906 <p><b>Proposed resolution:</b></p>
2908 <p><i>[Sydney: The intention is that comparing two iterators from
2909 different containers is undefined, but it's not clear if we say that,
2910 or even whether it's something we should be saying in clause 23 or in
2911 clause 24. Intuitively we might want to say that equality is defined
2912 only if one iterator is reachable from another, but figuring out how
2913 to say it in any sensible way is a bit tricky: reachability is defined
2914 in terms of equality, so we can't also define equality in terms of
2915 reachability.
2916 ]</i></p>
2918 <hr>
2919 <a name="454"><h3>454. basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
2920 <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
2921 </pre>
2923 <p>should be supplemented with the overload:</p>
2925 <pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
2926 </pre>
2928 <p>
2929 Depending on the operating system, one of these forms is fundamental and
2930 the other requires an implementation-defined mapping to determine the
2931 actual filename.
2932 </p>
2934 <p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
2935 provide wording.]</i></p>
2937 <p><b>Proposed resolution:</b></p>
2939 <p>Change from:</p>
2940 <blockquote>
2941 <pre>basic_filebuf<charT,traits>* open(
2942 const char* s,
2943 ios_base::openmode mode );
2944 </pre>
2946 <p>
2947 Effects: If is_open() != false, returns a null pointer.
2948 Otherwise, initializes the filebuf as required. It then
2950 by calling std::fopen(s,modstr)).</p>
2951 </blockquote>
2953 <p>to:</p>
2955 <blockquote>
2956 <pre>basic_filebuf<charT,traits>* open(
2957 const char* s,
2958 ios_base::openmode mode );
2960 basic_filebuf<charT,traits>* open(
2961 const wchar_t* ws,
2962 ios_base::openmode mode );
2963 </pre>
2965 <p>
2966 Effects: If is_open() != false, returns a null pointer.
2967 Otherwise, initializes the filebuf as required. It then
2969 by calling std::fopen(s,modstr)).
2970 For the second signature, the NTBS s is determined from the
2971 WCBS ws in an implementation-defined manner.
2972 </p>
2974 <p>
2976 as a WCBS, the NTBS s in the first signature may instead
2977 be mapped to a WCBS; if so, it follows the same mapping
2978 rules as the first argument to open.)
2979 </p>
2980 </blockquote>
2982 <p><b>Rationale:</b></p>
2983 <p>
2984 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
2985 this to Ready. The controversy was because the mapping between wide
2986 names and files in a filesystem is implementation defined. The
2987 counterargument, which most but not all LWG members accepted, is that
2988 the mapping between narrow files names and files is also
2989 implemenation defined.</p>
2992 (1) Why just basic_filebuf, instead of also basic_fstream (and
2993 possibly other things too). (2) Why not also constructors that take
2994 std::basic_string? (3) We might want to wait until we see Beman's
2995 filesystem library; we might decide that it obviates this.]</i></p>
2997 <hr>
2998 <a name="456"><h3>456. Traditional C header files are overspecified</h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
3000 <p>The C++ Standard effectively requires that the traditional C headers
3001 (of the form <xxx.h>) be defined in terms of the newer C++
3002 headers (of the form <cxxx>). Clauses 17.4.1.2/4 and D.5 combine
3003 to require that:</p>
3005 <ul>
3006 <li>Including the header <cxxx> declares a C name in namespace std.</li>
3008 <li> Including the header <xxx.h> declares a C name in namespace std
3009 (effectively by including <cxxx>), then imports it into the global
3010 namespace with an individual using declaration.</li>
3011 </ul>
3013 <p>
3014 The rules were left in this form despited repeated and heated objections
3015 from several compiler vendors. The C headers are often beyond the direct
3016 control of C++ implementors. In some organizations, it's all they can do
3017 to get a few #ifdef __cplusplus tests added. Third-party library vendors
3018 can perhaps wrap the C headers. But neither of these approaches supports
3019 the drastic restructuring required by the C++ Standard. As a result, it is
3020 still widespread practice to ignore this conformance requirement, nearly
3021 seven years after the committee last debated this topic. Instead, what is
3022 often implemented is:
3023 </p>
3025 <ul>
3026 <li> Including the header <xxx.h> declares a C name in the
3027 global namespace.</li>
3029 <li> Including the header <cxxx> declares a C name in the
3030 global namespace (effectively by including <xxx.h>), then
3031 imports it into namespace std with an individual using declaration.</li>
3032 </ul>
3034 <p>
3035 The practical benefit for implementors with the second approach is that
3036 they can use existing C library headers, as they are pretty much obliged
3037 to do. The practical cost for programmers facing a mix of implementations
3038 is that they have to assume weaker rules:</p>
3040 <ul>
3041 <li> If you want to assuredly declare a C name in the global
3042 namespace, include <xxx.h>. You may or may not also get the
3043 declaration in namespace std.</li>
3045 <li> If you want to assuredly declare a C name in namespace std,
3046 include <cxxx.h>. You may or may not also get the declaration in
3047 the global namespace.</li>
3048 </ul>
3050 <p>
3051 There also exists the <i>possibility</i> of subtle differences due to
3052 Koenig lookup, but there are so few non-builtin types defined in the C
3053 headers that I've yet to see an example of any real problems in this
3054 area.
3055 </p>
3057 <p>
3058 It is worth observing that the rate at which programmers fall afoul of
3059 these differences has remained small, at least as measured by newsgroup
3060 postings and our own bug reports. (By an overwhelming margin, the
3061 commonest problem is still that programmers include <string> and can't
3062 understand why the typename string isn't defined -- this a decade after
3063 the committee invented namespace std, nominally for the benefit of all
3064 programmers.)
3065 </p>
3067 <p>
3068 We should accept the fact that we made a serious mistake and rectify it,
3069 however belatedly, by explicitly allowing either of the two schemes for
3070 declaring C names in headers.
3071 </p>
3073 <p><i>[Sydney: This issue has been debated many times, and will
3074 certainly have to be discussed in full committee before any action
3075 can be taken. However, the preliminary sentiment of the LWG was in
3076 favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer
3077 suggests that we might also want to undeprecate the
3078 C-style <tt>.h</tt> headers.]</i></p>
3080 <p><b>Proposed resolution:</b></p>
3081 <hr>
3082 <a name="458"><h3>458. 24.1.5 contains unintented limitation for operator-</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 27 Feb 2004</p>
3083 <p>
3084 In 24.1.5 [lib.random.access.iterators], table 76 the operational
3086 This means, that the expression -n must be valid, which is not the case
3087 for unsigned types.
3088 </p>
3090 <p><i>[
3091 Sydney: Possibly not a real problem, since difference type is required
3092 to be a signed integer type. However, the wording in the standard may
3093 be less clear than we would like.
3094 ]</i></p>
3096 <p><b>Proposed resolution:</b></p>
3097 <p>
3098 To remove this limitation, I suggest to change the
3099 operational semantics for this column to:
3100 </p>
3101 <code>
3102 { Distance m = n;
3103 if (m >= 0)
3104 while (m--) --r;
3105 else
3106 while (m++) ++r;
3107 return r; }
3108 </code>
3110 <hr>
3111 <a name="459"><h3>459. Requirement for widening in stage 2 is overspecification</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 16 Mar 2004</p>
3112 <p>When parsing strings of wide-character digits, the standard
3114 the widened atoms against the characters that are being parsed.
3115 Simply narrowing the wide characters would be far simpler, and
3116 probably more efficient. The two choices are equivalent except in
3117 convoluted test cases, and many implementations already ignore the
3118 standard and use narrow instead of widen.</p>
3120 <p>
3121 First, I disagree that using narrow() instead of widen() would
3122 necessarily have unfortunate performance implications. A possible
3123 implementation of narrow() that allows num_get to be implemented
3124 in a much simpler and arguably comparably efficient way as calling
3125 widen() allows, i.e. without making a virtual call to do_narrow every
3126 time, is as follows:
3127 </p>
3129 <pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
3130 {
3131 const unsigned wi = unsigned (wc);
3133 if (wi > UCHAR_MAX)
3134 return typeid (*this) == typeid (ctype<wchar_t>) ?
3135 dflt : do_narrow (wc, dflt);
3137 if (narrow_ [wi] < 0) {
3138 const char nc = do_narrow (wc, dflt);
3139 if (nc == dflt)
3140 return dflt;
3141 narrow_ [wi] = nc;
3142 }
3144 return char (narrow_ [wi]);
3145 }
3146 </pre>
3148 <p>
3149 Second, I don't think the change proposed in the issue (i.e., to use
3150 narrow() instead of widen() during Stage 2) would be at all
3151 drastic. Existing implementations with the exception of libstdc++
3152 currently already use narrow() so the impact of the change on programs
3153 would presumably be isolated to just a single implementation. Further,
3154 since narrow() is not required to translate alternate wide digit
3155 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> to
3156 their narrow equivalents (i.e., the portable source characters '0'
3157 through '9'), the change does not necessarily imply that these
3158 alternate digits would be treated as ordinary digits and accepted as
3159 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p13 forbids narrow() to translate an alternate
3160 digit character, wc, to an ordinary digit in the basic source
3161 character set unless the expression
3162 (ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in
3163 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
3164 5.2.1, respectively) for charT of either char or wchar_t.
3165 </p>
3167 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
3168 you're only trafficking in char and wchar_t we're only dealing with a
3169 stable character set, so you don't really need either 'widen' or
3170 'narrow': can just use literals. Finally, it's not even clear whether
3171 widen-vs-narrow is the right question; arguably we should be using
3172 codecvt instead.]</i></p>
3174 <p><b>Proposed resolution:</b></p>
3175 <p>Change stage 2 so that implementations are permitted to use either
3176 technique to perform the comparison:</p>
3177 <ol>
3178 <li> call widen on the atoms and compare (either by using
3179 operator== or char_traits<charT>::eq) the input with
3180 the widened atoms, or</li>
3181 <li> call narrow on the input and compare the narrow input
3182 with the atoms</li>
3183 <li> do (1) or (2) only if charT is not char or wchar_t,
3184 respectively; i.e., avoid calling widen or narrow
3185 if it the source and destination types are the same</li>
3186 </ol>
3187 <hr>
3188 <a name="462"><h3>462. Destroying objects with static storage duration</h3></a><p><b>Section:</b> 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 23 Mar 2004</p>
3189 <p>
3190 3.6.3 Termination spells out in detail the interleaving of static
3191 destructor calls and calls to functions registered with atexit. To
3192 match this behavior requires intimate cooperation between the code
3193 that calls destructors and the exit/atexit machinery. The former
3194 is tied tightly to the compiler; the latter is a primitive mechanism
3195 inherited from C that traditionally has nothing to do with static
3196 construction and destruction. The benefits of intermixing destructor
3197 calls with atexit handler calls is questionable at best, and <i>very</i>
3198 difficult to get right, particularly when mixing third-party C++
3199 libraries with different third-party C++ compilers and C libraries
3200 supplied by still other parties.
3201 </p>
3203 <p>
3204 I believe the right thing to do is defer all static destruction
3205 until after all atexit handlers are called. This is a change in
3206 behavior, but one that is likely visible only to perverse test
3207 suites. At the very least, we should <i>permit</i> deferred destruction
3208 even if we don't require it.
3209 </p>
3210 <p><b>Proposed resolution:</b></p>
3212 <p><i>[If this is to be changed, it should probably be changed by CWG.
3213 At this point, however, the LWG is leaning toward NAD. Implementing
3214 what the standard says is hard work, but it's not impossible and
3215 most vendors went through that pain years ago. Changing this
3216 behavior would be a user-visible change, and would break at least
3217 one real application.]</i></p>
3219 <p>
3220 </p>
3221 <hr>
3222 <a name="463"><h3>463. auto_ptr usability issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Rani Sharoni <b>Date:</b> 7 Dec 2003</p>
3224 <p>
3225 TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
3226 member of auto_ptr (20.4.5.3/4) obsolete.
3227 </p>
3229 <p>
3230 The sole purpose of this obsolete conversion member is to enable copy
3231 initialization base from r-value derived (or any convertible types like
3232 cv-types) case:
3233 </p>
3234 <pre>#include <memory>
3235 using std::auto_ptr;
3237 struct B {};
3238 struct D : B {};
3240 auto_ptr<D> source();
3241 int sink(auto_ptr<B>);
3242 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
3243 </pre>
3245 <p>
3246 The excellent analysis of conversion operations that was given in the final
3247 auto_ptr proposal
3248 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
3249 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
3250 wrong and actually comes to forbid the loophole that was exploited by the
3251 auto_ptr designers.
3252 </p>
3254 <p>
3255 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
3256 ever allowed this case. This is probably because it requires 3 user defined
3257 conversions and in fact current compilers conform to DR #84.
3258 </p>
3260 <p>
3261 I was surprised to discover that the obsolete conversion member actually has
3262 negative impact of the copy initialization base from l-value derived
3263 case:</p>
3264 <pre>auto_ptr<D> dp;
3265 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
3266 </pre>
3268 <p>
3269 I'm sure that the original intention was allowing this initialization using
3270 the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
3271 since in this copy initialization it's merely user defined conversion (UDC)
3272 and the obsolete conversion member is UDC with the same rank (for the early
3273 overloading stage) there is an ambiguity between them.
3274 </p>
3276 <p>
3277 Removing the obsolete member will have impact on code that explicitly
3278 invokes it:
3279 </p>
3280 <pre>int y = sink(source().operator auto_ptr<B>());
3281 </pre>
3283 <p>
3284 IMHO no one ever wrote such awkward code and the reasonable workaround for
3285 #1 is:
3286 </p>
3287 <pre>int y = sink( auto_ptr<B>(source()) );
3288 </pre>
3290 <p>
3291 I was even more surprised to find out that after removing the obsolete
3292 conversion member the initialization was still ill-formed:
3293 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
3294 </p>
3296 <p>
3297 This copy initialization semantically requires copy constructor which means
3298 that both template conversion constructor and the auto_ptr_ref conversion
3299 member (20.4.5.3/3) are required which is what was explicitly forbidden in
3300 DR #84. This is a bit amusing case in which removing ambiguity results with
3301 no candidates.
3302 </p>
3304 <p>
3305 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
3306 </p>
3307 <pre>int f(auto_ptr<B>, std::string);
3308 auto_ptr<B> source2();
3310 // string constructor throws while auto_ptr_ref
3313 </pre>
3315 <p>
3316 The theoretic execution sequence that will cause a leak:
3317 </p>
3318 <ol>
3319 <li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li>
3320 <li>call string::string(char const*) and throw</li>
3321 </ol>
3323 <p>
3324 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
3325 returns auto_ptr_ref<Y> that holds *this and this is another defect since
3326 the type of *this is auto_ptr<X> where X might be different from Y. Several
3327 library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
3328 is much more reasonable. Other vendor implemented auto_ptr_ref as
3329 defectively required and it results with awkward and catastrophic code:
3330 int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
3331 paths
3332 </p>
3334 <p>
3335 Dave Abrahams noticed that there is no specification saying that
3336 auto_ptr_ref copy constructor can't throw.
3337 </p>
3339 <p>
3340 My proposal comes to solve all the above issues and significantly simplify
3341 auto_ptr implementation. One of the fundamental requirements from auto_ptr
3342 is that it can be constructed in an intuitive manner (i.e. like ordinary
3343 pointers) but with strict ownership semantics which yield that source
3344 auto_ptr in initialization must be non-const. My idea is to add additional
3345 constructor template with sole propose to generate ill-formed, diagnostic
3346 required, instance for const auto_ptr arguments during instantiation of
3347 declaration. This special constructor will not be instantiated for other
3348 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
3349 in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
3350 legitimate since the actual argument can't be const yet non const r-value
3351 are acceptable.
3352 </p>
3354 <p>
3356 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
3357 GCC and VC) consume the new implementation as expected and allow all
3358 intuitive initialization and assignment cases while rejecting illegal cases
3359 that involve const auto_ptr arguments.
3360 </p>
3362 <p>The proposed auto_ptr interface:</p>
3364 <pre>namespace std {
3365 template<class X> class auto_ptr {
3366 public:
3367 typedef X element_type;
3369 // 20.4.5.1 construct/copy/destroy:
3370 explicit auto_ptr(X* p=0) throw();
3371 auto_ptr(auto_ptr&) throw();
3372 template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
3373 auto_ptr& operator=(auto_ptr&) throw();
3374 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
3375 ~auto_ptr() throw();
3377 // 20.4.5.2 members:
3378 X& operator*() const throw();
3379 X* operator->() const throw();
3380 X* get() const throw();
3381 X* release() throw();
3382 void reset(X* p=0) throw();
3384 private:
3385 template<class U>
3386 auto_ptr(U& rhs, typename
3387 unspecified_error_on_const_auto_ptr<U>::type = 0);
3388 };
3389 }
3390 </pre>
3392 <p>
3393 One compliant technique to implement the unspecified_error_on_const_auto_ptr
3394 helper class is using additional private auto_ptr member class template like
3395 the following:
3396 </p>
3397 <pre>template<typename T> struct unspecified_error_on_const_auto_ptr;
3399 template<typename T>
3400 struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
3401 { typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
3402 </pre>
3404 <p>
3405 There are other techniques to implement this helper class that might work
3406 better for different compliers (i.e. better diagnostics) and therefore I
3407 suggest defining its semantic behavior without mandating any specific
3408 implementation. IMO, and I didn't found any compiler that thinks otherwise,
3409 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
3410 verifying this with core language experts.
3411 </p>
3413 <p><b>Further changes in standard text:</b></p>
3414 <p>Remove section 20.4.5.3</p>
3416 <p>Change 20.4.5/2 to read something like:
3417 Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
3418 ill-formed declaration that will require unspecified diagnostic.</p>
3420 <p>Change 20.4.5.1/4,5,6 to read:</p>
3422 <pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre>
3423 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
3424 <p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p>
3425 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
3427 <p>Change 20.4.5.1/10</p>
3428 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
3429 </pre>
3430 <p>
3431 10 Requires: Y* can be implicitly converted to X*. The expression delete
3432 get() is well formed.
3433 </p>
3435 <p>LWG TC DR #127 is obsolete.</p>
3437 <p>
3438 Notice that the copy constructor and copy assignment operator should remain
3439 as before and accept non-const auto_ptr& since they have effect on the form
3440 of the implicitly declared copy constructor and copy assignment operator of
3441 class that contains auto_ptr as member per 12.8/5,10:
3442 </p>
3443 <pre>struct X {
3444 // implicit X(X&)
3445 // implicit X& operator=(X&)
3446 auto_ptr<D> aptr_;
3447 };
3448 </pre>
3450 <p>
3451 In most cases this indicates about sloppy programming but preserves the
3452 current auto_ptr behavior.
3453 </p>
3455 <p>
3456 Dave Abrahams encouraged me to suggest fallback implementation in case that
3457 my suggestion that involves removing of auto_ptr_ref will not be accepted.
3458 In this case removing the obsolete conversion member to auto_ptr<Y> and
3459 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
3460 cases. The two constructors that I suggested will co exist with the current
3461 members but will make auto_ptr_ref obsolete in initialization contexts.
3462 auto_ptr_ref will be effective in assignment contexts as suggested in DR
3463 #127 and I can't see any serious exception safety issues in those cases
3464 (although it's possible to synthesize such). auto_ptr_ref<X> semantics will
3465 have to be revised to say that it strictly holds pointer of type X and not
3466 reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
3467 constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
3468 from r-value derived to base).
3469 </p>
3471 <p><b>Proposed resolution:</b></p>
3472 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
3473 want to fix auto_ptr for C++-0x, or remove it and replace it with
3474 move_ptr and unique_ptr.]</i></p>
3475 <hr>
3476 <a name="466"><h3>466. basic_string ctor should prevent null pointer error</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 10 Jun 2004</p>
3477 <p>
3478 Today, my colleagues and me wasted a lot of time. After some time, I
3479 found the problem. It could be reduced to the following short example:
3480 </p>
3482 <pre> #include <string>
3483 int main() { std::string( 0 ); }
3484 </pre>
3486 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
3487 Comeau online) compile the above without errors or warnings! The
3488 programs (at least for the GCC) resulted in a SEGV.</p>
3490 <p>I know that the standard explicitly states that the ctor of string
3491 requires a char* which is not zero. STLs could easily detect the above
3492 case with a private ctor for basic_string which takes a single 'int'
3493 argument. This would catch the above code at compile time and would not
3494 ambiguate any other legal ctors.</p>
3496 <p><b>Proposed resolution:</b></p>
3497 <p><i>[Redmond: No great enthusiasm for doing this. If we do,
3498 however, we want to do it for all places that take <tt>charT*</tt>
3499 pointers, not just the single-argument constructor. The other
3500 question is whether we want to catch this at compile time (in which
3501 case we catch the error of a literal 0, but not an expression whose
3502 value is a null pointer), at run time, or both.]</i></p>
3504 <hr>
3505 <a name="470"><h3>470. accessing containers from their elements' special functions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
3507 <p>
3508 The standard doesn't prohibit the destructors (or any other special
3509 functions) of containers' elements invoked from a member function
3511 member function on the same container object, potentially while the
3512 container is in an intermediate state, or even changing the state
3513 of the container object while it is being modified. This may result
3514 in some surprising (i.e., undefined) behavior.
3515 </p>
3517 <p>Read email thread starting with c++std-lib-13637 for more.</p>
3519 <p><b>Proposed resolution:</b></p>
3521 <p>Add to Container Requirements the following new paragraph:</p>
3523 <pre> Unless otherwise specified, the behavior of a program that
3524 invokes a container member function f from a member function
3525 g of the container's value_type on a container object c that
3526 called g from its mutating member function h, is undefined.
3527 I.e., if v is an element of c, directly or indirectly calling
3528 c.h() from v.g() called from c.f(), is undefined.
3529 </pre>
3531 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
3532 issue, not clause 23. We get the same issue, for example, if we
3533 try to destroy a stream from one of the stream's callback functions.]</i></p>
3536 <hr>
3537 <a name="471"><h3>471. result of what() implementation-defined</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
3539 <p>[lib.exception] specifies the following:</p>
3540 <pre> exception (const exception&) throw();
3541 exception& operator= (const exception&) throw();
3543 -4- Effects: Copies an exception object.
3544 -5- Notes: The effects of calling what() after assignment
3545 are implementation-defined.
3546 </pre>
3548 <p>
3549 First, does the Note only apply to the assignment operator? If so,
3550 what are the effects of calling what() on a copy of an object? Is
3551 the returned pointer supposed to point to an identical copy of
3552 the NTBS returned by what() called on the original object or not?
3553 </p>
3555 <p>
3556 Second, is this Note intended to extend to all the derived classes
3557 in section 19? I.e., does the standard provide any guarantee for
3558 the effects of what() called on a copy of any of the derived class
3559 described in section 19?
3560 </p>
3562 <p>
3563 Finally, if the answer to the first question is no, I believe it
3564 constitutes a defect since throwing an exception object typically
3565 implies invoking the copy ctor on the object. If the answer is yes,
3566 then I believe the standard ought to be clarified to spell out
3567 exactly what the effects are on the copy (i.e., after the copy
3568 ctor was called).
3569 </p>
3571 <p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is
3572 fuzzy too.]</i></p>
3574 <p><b>Proposed resolution:</b></p>
3575 <hr>
3576 <a name="473"><h3>473. underspecified ctype calls</h3></a><p><b>Section:</b> 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p>
3577 <p>
3578 Most ctype member functions come in two forms: one that operates
3579 on a single character at a time and another form that operates
3580 on a range of characters. Both forms are typically described by
3581 a single Effects and/or Returns clause.
3582 </p>
3583 <p>
3584 The Returns clause of each of the single-character non-virtual forms
3585 suggests that the function calls the corresponding single character
3586 virtual function, and that the array form calls the corresponding
3587 virtual array form. Neither of the two forms of each virtual member
3588 function is required to be implemented in terms of the other.
3589 </p>
3590 <p>
3591 There are three problems:
3592 </p>
3593 <p>
3594 1. One is that while the standard does suggest that each non-virtual
3595 member function calls the corresponding form of the virtual function,
3596 it doesn't actually explicitly require it.
3597 </p>
3598 <p>
3599 Implementations that cache results from some of the virtual member
3600 functions for some or all values of their arguments might want to
3601 call the array form from the non-array form the first time to fill
3602 the cache and avoid any or most subsequent virtual calls. Programs
3603 that rely on each form of the virtual function being called from
3604 the corresponding non-virtual function will see unexpected behavior
3605 when using such implementations.
3606 </p>
3607 <p>
3608 2. The second problem is that either form of each of the virtual
3609 functions can be overridden by a user-defined function in a derived
3610 class to return a value that is different from the one produced by
3611 the virtual function of the alternate form that has not been
3612 overriden.
3613 </p>
3614 <p>
3615 Thus, it might be possible for, say, ctype::widen(c) to return one
3616 value, while for ctype::widen(&c, &c + 1, &wc) to set
3617 wc to another value. This is almost certainly not intended. Both
3618 forms of every function should be required to return the same result
3619 for the same character, otherwise the same program using an
3620 implementation that calls one form of the functions will behave
3621 differently than when using another implementation that calls the
3623 </p>
3624 <p>
3625 3. The last problem is that the standard text fails to specify whether
3626 one form of any of the virtual functions is permitted to be implemented
3627 in terms of the other form or not, and if so, whether it is required
3628 or permitted to call the overridden virtual function or not.
3629 </p>
3630 <p>
3631 Thus, a program that overrides one of the virtual functions so that
3632 it calls the other form which then calls the base member might end
3633 up in an infinite loop if the called form of the base implementation
3634 of the function in turn calls the other form.
3635 </p>
3636 <p><b>Proposed resolution:</b></p>
3638 <p>
3639 Lillehammer: Part of this isn't a real problem. We already talk about
3640 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
3641 each other, so users don't know which ones to override to avoid avoid
3642 infinite loops.</p>
3644 <p>This is a problem for all facet virtuals, not just ctype virtuals,
3645 so we probably want a blanket statement in clause 22 for all
3646 facets. The LWG is leaning toward a blanket prohibition, that a
3647 facet's virtuals may never call each other. We might want to do that
3648 in clause 27 too, for that matter. A review is necessary. Bill will
3649 provide wording.</p>
3650 <hr>
3651 <a name="475"><h3>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 9 Jul 2004</p>
3652 <p>
3653 It is not clear whether the function object passed to for_each is allowed to
3654 modify the elements of the sequence being iterated over.
3655 </p>
3657 <p>
3659 Non-modifying sequence operations". 'Non-modifying sequence operation' is
3660 never defined.
3661 </p>
3663 <p>
3664 25(5) says: "If an algorithm's Effects section says that a value pointed to
3665 by any iterator passed as an argument is modified, then that algorithm has
3666 an additional type requirement: The type of that argument shall satisfy the
3668 </p>
3670 <p>for_each's Effects section does not mention whether arguments can be
3671 modified:</p>
3673 <blockquote>
3674 "Effects: Applies f to the result of dereferencing every iterator in the
3676 </blockquote>
3678 <p>
3680 the sense that neither the algorithms themselves nor the function objects
3681 passed to the algorithms may modify the sequences or elements in any way.
3682 This DR affects only for_each.
3683 </p>
3685 <p>
3686 We suspect that for_each's classification in "non-modifying sequence
3687 operations" means that the algorithm itself does not inherently modify the
3688 sequence or the elements in the sequence, but that the function object
3689 passed to it may modify the elements it operates on.
3690 </p>
3692 <p>
3693 The original STL document by Stepanov and Lee explicitly prohibited the
3694 function object from modifying its argument.
3696 implementations, however, does not impose this restriction.
3697 As a result, we suspect that the use of for_each with function objects that modify
3698 their arguments is wide-spread.
3699 If the restriction was reinstated, all such code would become non-conforming.
3700 Further, none of the other algorithms in the Standard
3701 could serve the purpose of for_each (transform does not guarantee the order in
3702 which its function object is called).
3703 </p>
3705 <p>
3706 We suggest that the standard be clarified to explicitly allow the function object
3707 passed to for_each modify its argument.</p>
3709 <p><b>Proposed resolution:</b></p>
3710 <p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
3711 the type of 'first' satisfies the requirements of a mutable iterator,
3712 'f' may apply nonconstant functions through the dereferenced iterators
3713 passed to it.
3714 </p>
3716 <p><b>Rationale:</b></p>
3717 <p>The LWG believes that nothing in the standard prohibits function
3718 objects that modify the sequence elements. The problem is that
3720 title may be confusing. A nonnormative note should clarify that.</p>
3721 <hr>
3722 <a name="478"><h3>478. Should forward iterator requirements table have a line for r->m?</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p>
3723 <p>
3724 The Forward Iterator requirements table contains the following:
3725 </p>
3726 <pre> expression return type operational precondition
3727 semantics
3728 ========== ================== =========== ==========================
3729 a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined.
3730 otherwise const U&
3732 r->m U& (*r).m pre: (*r).m is well-defined.
3733 </pre>
3735 <p>The second line may be unnecessary. Paragraph 11 of
3736 [lib.iterator.requirements] says:
3737 </p>
3739 <blockquote>
3740 In the following sections, a and b denote values of type const X, n
3741 denotes a value of the difference type Distance, u, tmp, and m
3742 denote identifiers, r denotes a value of X&, t denotes a value of
3743 value type T, o denotes a value of some type that is writable to
3744 the output iterator.
3745 </blockquote>
3747 <p>
3748 Because operators can be overloaded on an iterator's const-ness, the
3749 current requirements allow iterators to make many of the operations
3750 specified using the identifiers a and b invalid for non-const
3751 iterators.</p>
3753 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
3754 <p><b>Proposed resolution:</b></p>
3757 table. Change</p>
3758 <blockquote>
3760 </blockquote>
3762 <p> to </p>
3764 <blockquote>
3766 </blockquote>
3768 <p>in paragraph 11 of [lib.iterator.requirements].</p>
3771 <p><b>Rationale:</b></p>
3772 <p>
3773 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
3774 </p>
3775 <hr>
3776 <a name="479"><h3>479. Container requirements and placement new</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 1 Aug 2004</p>
3777 <p>Nothing in the standard appears to make this program ill-formed:</p>
3779 <pre> struct C {
3780 void* operator new( size_t s ) { return ::operator new( s ); }
3781 // NOTE: this hides in-place and nothrow new
3782 };
3784 int main() {
3785 vector<C> v;
3786 v.push_back( C() );
3787 }
3788 </pre>
3790 <p>Is that intentional? We should clarify whether or not we intended
3791 to require containers to support types that define their own special
3792 versions of <tt>operator new</tt>.</p>
3794 <p><i>[
3795 Lillehammer: A container will definitely never use this overridden
3796 operator new, but whether it will fail to compile is unclear from the
3797 standard. Are containers supposed to use qualified or unqualified
3798 placement new? 20.4.1.1 is somewhat relevant, but the standard
3799 doesn't make it completely clear whether containers have to use
3800 Allocator::construct(). If containers don't use it, the details of how
3801 containers use placement new are unspecified. That is the real bug,
3802 but it needs to be fixed as part of the allocator overhaul. Weak
3803 support that the eventual solution should make this code well formed.
3804 ]</i></p>
3806 <p><b>Proposed resolution:</b></p>
3807 <hr>
3808 <a name="482"><h3>482. Swapping pairs</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Sep 2004</p>
3809 <p>(Based on recent comp.std.c++ discussion)</p>
3811 <p>Pair (and tuple) should specialize std::swap to work in terms of
3812 std::swap on their components. For example, there's no obvious reason
3813 why swapping two objects of type pair<vector<int>,
3814 list<double> > should not take O(1).</p>
3815 <p><b>Proposed resolution:</b></p>
3818 <p><i>[Lillehammer: We agree it should be swappable. Howard will
3819 provide wording.]</i></p>
3821 <hr>
3822 <a name="484"><h3>484. Convertible to T</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 16 Sep 2004</p>
3823 <p>From comp.std.c++:</p>
3825 <p>
3826 I note that given an input iterator a for type T,
3828 </p>
3831 While I assume it is the obvious definition (an implicit conversion), I
3832 can't find an exact definition. Is there one?</p>
3834 <p>Slightly more worryingly, there doesn't seem to be any restriction on
3836 iterators a and b. I would personally assume that most people would
3837 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
3838 the standard requires that, and that whatever type *a is (call it U)
3839 could have == defined on it with totally different symantics and still
3840 be a valid inputer iterator.</p>
3842 <p>Is this a correct reading? When using input iterators should I write
3843 T(*a) all over the place to be sure that the object i'm using is the
3844 class I expect?</p>
3846 <p>This is especially a nuisance for operations that are defined to be
3848 implementations could return say an int and avoid an unnessary
3849 conversion. However all implementations I have seen simply return a
3850 bool anyway. Typical implemtations of STL algorithms just write
3851 things like <tt>while(a!=b && *a!=0)</tt>. But strictly
3852 speaking, there are lots of types that are convertible to T but
3853 that also overload the appropriate operators so this doesn't behave
3854 as expected.</p>
3856 <p>If we want to make code like this legal (which most people seem to
3857 expect), then we'll need to tighten up what we mean by "convertible
3858 to T".</p>
3860 <p><b>Proposed resolution:</b></p>
3862 well-defined in core. The second part is basically about pathological
3863 overloads. It's a minor problem but a real one. So leave open for
3864 now, hope we solve it as part of iterator redesign.]</i></p>
3865 <hr>
3866 <a name="485"><h3>485. output iterator insufficently constrained</h3></a><p><b>Section:</b> 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 13 Oct 2004</p>
3867 <p>
3868 The note on 24.1.2 Output iterators insufficently limits what can be
3869 performed on output iterators. While it requires that each iterator is
3870 progressed through only once and that each iterator is written to only
3871 once, it does not require the following things:</p>
3873 <p>Note: Here it is assumed that x is an output iterator of type X which
3874 has not yet been assigned to.</p>
3876 <p>a) That each value of the output iterator is written to:
3877 The standard allows:
3878 ++x; ++x; ++x;
3879 </p>
3881 <p>
3882 b) That assignments to the output iterator are made in order
3883 X a(x); ++a; *a=1; *x=2; is allowed
3884 </p>
3886 <p>
3887 c) Chains of output iterators cannot be constructed:
3888 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
3889 wording (I believe) x,a,b,c could be written to in any order.
3890 </p>
3892 <p>I do not believe this was the intension of the standard?</p>
3893 <p><b>Proposed resolution:</b></p>
3894 <p><i>[Lillehammer: Real issue. There are lots of constraints we
3895 intended but didn't specify. Should be solved as part of iterator
3896 redesign.]</i></p>
3897 <hr>
3898 <a name="488"><h3>488. rotate throws away useful information</h3></a><p><b>Section:</b> 25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 22 Nov 2004</p>
3899 <p>
3900 rotate takes 3 iterators: first, middle and last which point into a
3901 sequence, and rearranges the sequence such that the subrange [middle,
3902 last) is now at the beginning of the sequence and the subrange [first,
3903 middle) follows. The return type is void.
3904 </p>
3906 <p>
3907 In many use cases of rotate, the client needs to know where the
3908 subrange [first, middle) starts after the rotate is performed. This
3909 might look like:
3910 </p>
3911 <pre> rotate(first, middle, last);
3912 Iterator i = advance(first, distance(middle, last));
3913 </pre>
3915 <p>
3916 Unless the iterators are random access, the computation to find the
3917 start of the subrange [first, middle) has linear complexity. However,
3918 it is not difficult for rotate to return this information with
3919 negligible additional computation expense. So the client could code:
3920 </p>
3921 <pre> Iterator i = rotate(first, middle, last);
3922 </pre>
3924 <p>
3925 and the resulting program becomes significantly more efficient.
3926 </p>
3928 <p>
3929 While the backwards compatibility hit with this change is not zero, it
3930 is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
3931 a significant benefit to the change.
3932 </p>
3934 <p><b>Proposed resolution:</b></p>
3935 <p>In 25p2, change:</p>
3936 <pre> template<class ForwardIterator>
3937 void rotate(ForwardIterator first, ForwardIterator middle,
3938 ForwardIterator last);
3939 </pre>
3941 <p>to:</p>
3943 <pre> template<class ForwardIterator>
3944 ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
3945 ForwardIterator last);
3946 </pre>
3948 <p>In 25.2.10, change:</p>
3950 <pre> template<class ForwardIterator>
3951 void rotate(ForwardIterator first, ForwardIterator middle,
3952 ForwardIterator last);
3953 </pre>
3955 <p>to:</p>
3957 <pre> template<class ForwardIterator>
3958 ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
3959 ForwardIterator last);
3960 </pre>
3962 <p>In 25.2.10 insert a new paragraph after p1:</p>
3964 <blockquote>
3965 <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
3966 </blockquote>
3968 <p><i>[
3969 The LWG agrees with this idea, but has one quibble: we want to make
3971 actually called, just that the nth iterator is returned. (Calling
3972 advance is observable behavior, since users can specialize it for
3973 their own iterators.) Howard will provide wording.
3974 ]</i></p>
3976 <p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
3978 <hr>
3979 <a name="492"><h3>492. Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p>
3980 <p>Various clauses other than clause 25 make use of iterator arithmetic not
3981 supported by the iterator category in question.
3982 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
3983 paragraph 9, but this paragraph does not provide semantics to the
3985 between iterators.</p>
3987 <p>1) Examples of current wording:</p>
3989 <p>Current wording outside clause 25:</p>
3991 <p>
3999 </p>
4001 <p>
4002 [Important note: The list is not complete, just an illustration. The
4003 same issue might well apply to other paragraphs not listed here.]</p>
4005 <p>None of these expressions is valid for the corresponding iterator
4006 category.</p>
4008 <p>Current wording in clause 25:</p>
4010 <p>
4012 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4013 (last2-first2))"
4016 </p>
4018 <p>
4019 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4020 neither of these four cases:</p>
4022 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4024 <p>
4025 "In the description of the algorithms operator + and - are used for some
4026 of the iterator categories for which they do not have to be defined. In
4027 these cases the semantics of a+n is the same as that of</p>
4028 <pre>{X tmp = a;
4029 advance(tmp, n);
4030 return tmp;
4031 }
4032 </pre>
4035 <p>
4037 where n denotes a value of a distance type between two iterators [Note:
4043 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4044 may be negative only for random access and bidirectional iterators.",
4045 and none of the paragraphs quoted above requires the iterators on which
4046 the algorithms operate to be of random access or bidirectional category.
4047 </p>
4049 <p>2) Description of intended behavior:</p>
4051 <p>
4052 For the rest of this Defect Report, it is assumed that the expression
4054 described in current 25 [lib.algorithms], paragraph 9, but applying to
4057 iterator denoting the same position as iterator1 does. The terms
4060 type between two iterators.</p>
4062 <p>
4063 All implementations known to the author of this Defect Report comply
4064 with these assumptions.
4065 No impact on current code is expected.</p>
4067 <p>3) Proposed fixes:</p>
4070 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4072 <p>
4073 "In the description of the algorithms operator + and - are used for some
4074 of the iterator categories for which they do not have to be defined. In
4075 this paragraph, a and b denote values of an iterator type, and n denotes
4076 a value of a distance type between two iterators. In these cases the
4077 semantics of a+n is the same as that of</p>
4078 <pre>{X tmp = a;
4079 advance(tmp, n);
4080 return tmp;
4081 }
4082 </pre>
4083 <p>,the semantics of a-n denotes the value of an iterator i for which the
4084 following condition holds:
4085 advance(i, n) == a,
4086 and that of b-a is the same as of
4087 return distance(a, b)".
4088 </p>
4090 <p>Comments to the new wording:</p>
4092 <p>
4093 a) The wording " In this paragraph, a and b denote values of an iterator
4094 type, and n denotes a value of a distance type between two iterators."
4096 the types of the values on which they operate.
4097 b) The wording ",the semantics of a-n denotes the value of an iterator i
4098 for which the following condition holds: advance(i, n) == a" was added
4100 was used to avoid a dependency on the semantics of a+n, as the wording
4102 be deserved.
4103 c) DR 225 is not considered in the new wording.
4104 </p>
4106 <p>
4107 Proposed fixes regarding invalid iterator arithmetic expressions outside
4108 clause 25:</p>
4110 <p>
4111 Either
4112 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4113 before any current invalid iterator arithmetic expression. In that case,
4114 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4115 modified and could read: "For the rest of this International Standard,
4116 ...." / "In the description of the following clauses including this
4119 clause 25.
4120 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
4121 obsolete.
4122 Alternatively,
4123 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
4124 paragraph 9, to the beginning of each clause containing invalid iterator
4125 arithmetic expressions.
4126 Alternatively,
4127 c) Fix each paragraph (both current wording and possible resolutions of
4128 DRs) containing invalid iterator arithmetic expressions separately.
4129 </p>
4131 <p>5) References to other DRs:</p>
4133 <p>
4134 See DR 225.
4135 See DR 237. The resolution could then also read "Linear in last -
4136 first".
4137 </p>
4138 <p><b>Proposed resolution:</b></p>
4140 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
4141 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
4142 not quite broad enough, because there are some arithmetic expressions
4143 it doesn't cover. Bill will provide wording.]</i></p>
4145 <hr>
4146 <a name="495"><h3>495. Clause 22 template parameter requirements</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Jan 2005</p>
4147 <p>It appears that there are no requirements specified for many of the
4148 template parameters in clause 22. It looks like this issue has never
4149 come up, except perhaps for Facet.</p>
4151 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
4152 either, which is the wording that allows requirements on template
4153 parameters to be identified by name.</p>
4155 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
4156 changed to cover clause 22. A better change, which will cover us in
4157 the future, would be to say that it applies to all the library
4158 clauses. Then if a template gets added to any library clause we are
4159 covered.</p>
4161 <p>charT, InputIterator, and other names with requirements defined
4162 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
4163 But there are a few template arguments names which I don't think have
4164 requirements given elsewhere:</p>
4166 <ul>
4167 <li>internT and externT. The fix is to add wording saying that internT
4168 and externT must meet the same requirements as template arguments
4169 named charT.</li>
4171 <li>stateT. I'm not sure about this one. There already is some wording,
4172 but it seems a bit vague.</li>
4174 <li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to
4176 text identifies the requirements for the name International but not
4177 for Intl.</li>
4178 </ul>
4179 <p><b>Proposed resolution:</b></p>
4180 <p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p>
4181 <blockquote>
4182 The Requirements subclauses may describe names that are used to
4183 specify constraints on template arguments.153) These names are used in
4184 clauses 20, 23, 25, and 26 to describe the types that may be supplied
4185 as arguments by a C++ program when instantiating template components
4186 from the library.
4187 </blockquote>
4188 <p>to:</p>
4189 <blockquote>
4190 The Requirements subclauses may describe names that are used to
4191 specify constraints on template arguments.153) These names are used in
4192 library clauses to describe the types that may be supplied as
4193 arguments by a C++ program when instantiating template components from
4194 the library.
4195 </blockquote>
4197 <p>In the front matter of class 22, locales, add:</p>
4198 <blockquote>
4199 Template parameter types internT and externT shall meet the
4200 requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
4201 </blockquote>
4202 <p><b>Rationale:</b></p>
4203 <p>
4204 Again, a blanket clause isn't blanket enough. Also, we've got a
4205 couple of names that we don't have blanket requirement statements
4206 for. The only issue is what to do about stateT. This wording is
4207 thin, but probably adequate.</p>
4208 <hr>
4209 <a name="497"><h3>497. meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b> 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Mar 2005</p>
4211 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
4213 <blockquote>
4214 <p>static const bool traps;<br>
4215 -59- true if trapping is implemented for the type.204)
4216 <br>
4217 Footnote 204: Required by LIA-1.
4218 </p>
4219 </blockquote>
4223 <p>
4224 In the context of floating point numbers it seems reasonable to expect
4226 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
4227 without causing a trap (i.e., on UNIX without having to worry about
4228 getting a signal). When traps is true, I would expect any of the
4229 operations in section 7 of IEEE 754 to cause a trap (and my program
4230 to get a SIGFPE). So, for example, on Alpha, I would expect traps
4231 to be true by default (unless I compiled my program with the -ieee
4232 option), false by default on most other popular architectures,
4233 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
4234 traps to be explicitly enabled by the program.
4235 </p>
4237 <p>
4238 Another possible interpretation of p59 is that traps should be true
4239 on any implementation that supports traps regardless of whether they
4240 are enabled by default or not. I don't think such an interpretation
4241 makes the traps member very useful, even though that is how traps is
4242 implemented on several platforms. It is also the only way to implement
4243 traps on platforms that allow programs to enable and disable trapping
4244 at runtime.
4245 </p>
4246 <p><b>Proposed resolution:</b></p>
4247 <p>Change p59 to read:</p>
4248 <blockquote>True if, at program startup, there exists a value of the type that
4249 would cause an arithmetic operation using that value to trap.</blockquote>
4250 <p><b>Rationale:</b></p>
4251 <p>
4252 Real issue, since trapping can be turned on and off. Unclear what a
4253 static query can say about a dynamic issue. The real advice we should
4254 give users is to use cfenv for these sorts of queries. But this new
4255 proposed resolution is at least consistent and slightly better than
4256 nothing.</p>
4257 <hr>
4258 <a name="498"><h3>498. Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b> 25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 4 May 2005</p>
4259 <p>
4260 Problem:
4261 The iterator requirements for partition() and stable_partition() [25.2.12]
4262 are listed as BidirectionalIterator, however, there are efficient algorithms
4263 for these functions that only require ForwardIterator that have been known
4264 since before the standard existed. The SGI implementation includes these (see
4265 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
4266 and
4267 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
4268 </p>
4269 <p><b>Proposed resolution:</b></p>
4270 <p>
4271 Change 25.2.12 from </p>
4272 <blockquote><pre>template<class BidirectionalIterator, class Predicate>
4273 BidirectionalIterator partition(BidirectionalIterato r first,
4274 BidirectionalIterator last,
4275 Predicate pred);
4276 </pre></blockquote>
4277 <p>to </p>
4278 <blockquote><pre>template<class ForwardIterator, class Predicate>
4279 ForwardIterator partition(ForwardIterator first,
4280 ForwardIterator last,
4281 Predicate pred);
4282 </pre></blockquote>
4283 <p>Change the complexity from </p>
4285 <blockquote><p>
4286 At most (last - first)/2 swaps are done. Exactly (last - first)
4287 applications of the predicate are done.
4288 </p></blockquote>
4290 <p>to </p>
4292 <blockquote><p>
4293 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
4294 swaps are done; otherwise at most (last - first) swaps are done. Exactly
4295 (last - first) applications of the predicate are done.
4296 </p></blockquote>
4298 <p><b>Rationale:</b></p>
4300 as just one example) - my motivation for extending it to include forward
4301 iterators is slist - without this extension you can't partition an slist
4302 (without writing your own partition). Holes like this in the standard
4303 library weaken the argument for generic programming (ideally I'd be able
4304 to provide a library that would refine std::partition() to other concepts
4305 without fear of conflicting with other libraries doing the same - but
4306 that is a digression). I consider the fact that partition isn't defined
4307 to work for ForwardIterator a minor embarrassment.
4309 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
4310 by next meeting. Sean provided further rationale by post-meeting
4311 mailing.]</i></p>
4313 <hr>
4314 <a name="499"><h3>499. Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b> 25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 12 Apr 2005</p>
4315 <blockquote>
4316 <p>
4317 17.3.1.1 Summary</p>
4319 <p>
4320 1 The Summary provides a synopsis of the category, and introduces the
4321 first-level subclauses. Each subclause also provides a summary, listing
4322 the headers specified in the subclause and the library entities
4323 provided in each header.
4324 </p>
4325 <p>
4327 other paragraphs are normative.
4328 </p>
4329 </blockquote>
4333 <blockquote>
4334 <p>
4335 25.3.1.2 stable_sort
4336 </p>
4337 <pre>template<class RandomAccessIterator>
4338 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
4340 template<class RandomAccessIterator, class Compare>
4341 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
4342 </pre>
4343 <p>
4344 1 Effects: Sorts the elements in the range [first, last).
4345 </p>
4346 <p>
4347 2 Complexity: It does at most N(log N)^2 (where N == last - first)
4348 comparisons; if enough extra memory is available, it is N log N.
4349 </p>
4350 <p>
4351 3 Notes: Stable: the relative order of the equivalent elements is
4352 preserved.
4353 </p>
4354 </blockquote>
4356 <p>
4357 The Notes para is informative, and nowhere else is stability mentioned above.
4358 </p>
4360 <p>
4363 is repeated several times in the Standard library clauses for
4364 describing various functions. How is it that stability is talked about
4365 in the informative paragraph? Or am I missing something obvious?
4366 </p>
4367 <p><b>Proposed resolution:</b></p>
4368 <p>
4369 </p>
4370 <hr>
4371 <a name="501"><h3>501. Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b> 20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 7 Jun 2005</p>
4372 <blockquote>
4373 "For templates greater, less, greater_equal, and less_equal,
4374 the specializations for any pointer type yield a total order, even if
4376 </blockquote>
4378 <p>
4379 The standard should do much better than guarantee that these provide a
4380 total order, it should guarantee that it can be used to test if memory
4381 overlaps, i.e. write a portable memmove. You can imagine a platform
4382 where the built-in operators use a uint32_t comparison (this tests for
4383 overlap on this platform) but the less<T*> functor is allowed to be
4384 defined to use a int32_t comparison. On this platform, if you use
4385 std::less with the intent of making a portable memmove, comparison on
4386 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
4387 incorrect results.
4388 </p>
4389 <p><b>Proposed resolution:</b></p>
4390 <p>
4391 Add a footnote to 20.3.3/8 saying:
4392 </p>
4394 <blockquote>
4395 Given a p1 and p2 such that p1 points to N objects of type T and p2
4396 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
4397 less returns the same value when comparing all pointers in [p1,p1+N) to
4398 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
4399 such that less returns the same value when comparing all pointers in
4400 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
4401 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
4402 For the sake of completeness, the null pointer value (4.10) for T is
4403 considered to be an array of 1 object that doesn't overlap with any
4404 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
4405 and not_equal_to give the expected results based on the total ordering
4406 semantics of less. For T of void, treat it as having similar semantics
4407 as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv
4408 void*>(a, b) which gives the same results as less<cv char*>((cv
4409 char*)(cv void*)a, (cv char*)(cv void*)b).
4410 </blockquote>
4412 <p>
4413 I'm also thinking there should be a footnote to 20.3.3/1 saying that if
4414 A and B are similar types (4.4/4), comp<A>(a,b) returns the same value
4415 as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might
4416 be problematic if there is some really funky operator overloading going
4417 on that does different things based on cv (that should be undefined
4418 behavior if somebody does that though). This at least should be
4419 guaranteed for all POD types (especially pointers) that use the
4420 built-in comparison operators.
4421 </p>
4423 <hr>
4424 <a name="502"><h3>502. Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 7 Jun 2005</p>
4425 <p>
4426 Motivation:
4427 </p>
4429 <p>
4430 This requirement seems obvious to me, it is the essence of code modularity.
4431 I have complained to Mr. Plauger that the Dinkumware library does not
4432 observe this principle but he objected that this behaviour is not covered in
4433 the standard.
4434 </p>
4435 <p><b>Proposed resolution:</b></p>
4436 <p>
4437 Append the following point to 22.1.1.1.1:
4438 </p>
4440 <p>
4441 6. The implementation of a facet of Table 52 parametrized with an
4442 InputIterator/OutputIterator should use that iterator only as character
4443 source/sink respectively.
4444 For a *_get facet, it means that the value received depends only on the
4445 sequence of input characters and not on how they are accessed.
4446 For a *_put facet, it means that the sequence of characters output depends
4447 only on the value to be formatted and not of how the characters are stored.
4448 </p>
4449 <hr>
4450 <a name="503"><h3>503. more on locales</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 20 Jun 2005</p>
4451 <p>
4452 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
4455 locale. Otherwise, you can't switch to a locale that enforces a different
4456 mapping between narrow and wide characters, or that defines additional
4457 uppercase characters.
4458 </p>
4460 <p>
4461 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
4462 </p>
4464 <p>
4465 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
4466 a homing sequence for the basic character set, which might very well need
4467 one.
4468 </p>
4470 <p>
4471 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
4472 between wide and narrow characters be taken as one-for-one.
4473 </p>
4475 <p>
4476 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
4477 I can tell. The muddle is, as before, calling Table 51 a list of
4478 instantiations. But the constraint it applies seems to me to cover
4479 *all* defined uses of num_get/put, so why bother to say so?
4480 </p>
4482 <p>
4483 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
4484 return '.' or L'.'.) Presumably this means "as appropriate for the
4487 Surely we don't want to do that.
4488 </p>
4490 <p>
4491 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
4492 return ',' or L','.) As above, this probably means "as appropriate for the
4494 character ('\0') for the thousands separator. Even if we agree that we
4495 don't mean to block changes in decimal point or thousands separator,
4496 we should also eliminate this clear incompatibility with C.
4497 </p>
4499 <p>
4500 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
4501 return the empty string, indicating no grouping." Same considerations
4502 as for do_decimal_point.
4503 </p>
4505 <p>
4506 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
4508 </p>
4510 <p>
4511 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
4513 </p>
4515 <p>
4516 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
4517 as num_get/put.
4518 </p>
4520 <p>
4521 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
4522 as num_get/put.
4523 </p>
4525 <p>
4526 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
4527 in Table 51 ... return an object of type pattern initialized to
4529 locale, as well as any other locale."
4530 </p>
4532 <p>
4533 3) We constrain the use_facet calls that can be made by num_get/put,
4534 so why don't we do the same for money_get/put? Or for any of the
4535 other facets, for that matter?
4536 </p>
4538 <p>
4539 4) As an almost aside, we spell out when a facet needs to use the ctype
4540 facet, but several also need to use a codecvt facet and we don't say so.
4541 </p>
4543 <p>
4544 </p>
4545 <hr>
4546 <a name="504"><h3>504. Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4547 <p>
4549 g is an ... object returning values of unsigned integral type ..."
4550 </p>
4552 <p>
4554 </p>
4556 <blockquote>
4557 ... s is a value of integral type, g is an lvalue of a type other than X that
4560 ...
4561 </blockquote>
4563 <p>
4565 </p>
4567 <blockquote>
4568 creates an engine with the initial internal state
4569 determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
4570 </blockquote>
4572 <p><i>[
4573 Mont Tremblant: Both s and g should be unsigned long.
4574 This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
4575 ]</i></p>
4578 <p>
4579 Jens: Just requiring X(unsigned long) still makes it possible
4580 for an evil library writer to also supply a X(int) that does something
4581 unexpected. The wording above requires that X(s) always performs
4582 as if X(unsigned long) would have been called. I believe that is
4583 sufficient and implements our intentions from Mont Tremblant. I
4584 see no additional use in actually requiring a X(unsigned long)
4585 signature. u.seed(s) is covered by its reference to X(s), same
4586 arguments.
4587 </p>
4588 <hr>
4589 <a name="505"><h3>505. Result_type in random distribution requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4590 <p>
4591 Table 17: Random distribution requirements
4592 </p>
4593 <p>
4595 this type denotes the type of the values that the distribution consumes.
4596 </p>
4597 <p>
4598 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
4599 provides a second typedef ("result_type") that denotes the type of the values the
4600 distribution produces when called.
4601 </p>
4603 <p>
4604 It seems to me that this is also a requirement
4605 for all distributions and should therefore be indicated as such via a new second
4606 row to this table 17:
4607 </p>
4609 <tbody><tr>
4614 </tr>
4615 </tbody></table>
4616 <hr>
4617 <a name="506"><h3>506. Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4618 <p>
4619 Paragraph 3 requires that template argument U (which corresponds to template
4620 parameter Engine) satisfy all uniform random number generator requirements.
4621 However, there is no analogous requirement regarding the template argument
4622 that corresponds to template parameter Distribution. We believe there should
4623 be, and that it should require that this template argument satisfy all random
4624 distribution requirements.
4625 </p>
4627 <p>
4629 </p>
4630 <p>
4631 Consequence 2: Add max() and min() functions to those distributions that
4632 do not already have them.
4633 </p>
4635 <p><i>[
4636 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
4637 Marc supports having min and max to satisfy generic programming interface.
4638 ]</i></p>
4640 <hr>
4641 <a name="507"><h3>507. Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4642 <p>
4643 Paragraph 11 of [tr.rand.var] equires that the member template
4644 </p>
4646 </pre></blockquote>
4647 <p>
4648 return
4649 </p>
4650 <blockquote><pre>distribution()(e, value)
4651 </pre></blockquote>
4652 <p>
4653 However, not all distributions have an operator() with a corresponding signature.
4654 </p>
4656 <p>
4657 We therefore recommend that we insert the following precondition before paragraph 11:
4658 </p>
4659 <blockquote>
4661 </blockquote>
4662 <hr>
4663 <a name="508"><h3>508. Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b> TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4664 <p>
4665 The fifth of these engines with predefined parameters, ranlux64_base_01,
4666 appears to have an unintentional error for which there is a simple correction.
4667 The two pre-defined subtract_with_carry_01 engines are given as:
4668 </p>
4671 </pre></blockquote>
4672 <p>
4673 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
4674 random number generation proposal, but that the simple correction to
4675 </p>
4677 </pre></blockquote>
4678 <p>
4679 does meet the intent of defining well-known good parameterizations.
4680 </p>
4681 <p>
4682 The ranlux64_base_01 engine as presented fails to meet the intent for
4683 predefined engines, stated in proposal N1398 (section E):
4684 </p>
4685 <blockquote><p>
4686 In order to make good random numbers available to a large number of library
4687 users, this proposal not only defines generic random-number engines, but also
4688 provides a number of predefined well-known good parameterizations for those.
4689 </p></blockquote>
4690 <p>
4692 long period and so meets this criterion. This property makes it suitable for
4693 use in the excellent discard_block engines defined subsequently. The proof
4695 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
4696 as defined in [tr.rand.eng.sub1]).
4697 </p>
4698 <p>
4701 explicit factorization would be a challenge). In consequence, while it is
4702 certainly possible for some seeding states that this engine would have a very
4703 long period, it is not at all Òwell-knownÓ that this is the case. The intent
4704 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
4705 use in the physics community. This is isomorphic to the predefined ranlux_base_01,
4706 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
4708 </p>
4710 <p>
4711 To achieve this intended behavior, the correct template parameteriztion would be:
4712 </p>
4714 </pre></blockquote>
4715 <p>
4716 The sequence of mantissa bits delivered by this is isomorphic (treating each
4717 double as having the bits of two floats) to that delivered by ranlux_base_01.
4718 </p>
4719 <p>
4721 </p>
4722 <ol>
4726 </ol>
4728 <hr>
4729 <a name="509"><h3>509. Uniform_int template parameters</h3></a><p><b>Section:</b> TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4730 <p>
4731 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
4732 template parameter, IntType, used as the input_type and as the result_type
4733 of the distribution. We believe there is no reason to conflate these types
4734 in this way.
4735 </p>
4737 <p>
4738 We recommend that there be a second template parameter to
4739 reflect the distributionÕs input_type, and that the existing first template
4740 parameter continue to reflect (solely) the result_type:
4741 </p>
4743 class uniform_int
4744 {
4745 public:
4746 // types
4747 typedef UIntType input_type;
4748 typedef IntType result_type;
4749 </pre></blockquote>
4750 <hr>
4751 <a name="510"><h3>510. Input_type for bernoulli_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4752 <p>
4753 In [tr.rand.dist.bern] the distribution currently requires;
4754 </p>
4755 <blockquote><pre>typedef int input_type;
4756 </pre></blockquote>
4758 <p>
4759 We believe this is an unfortunate choice, and recommend instead:
4760 </p>
4761 <blockquote><pre>typedef unsigned int input_type;
4762 </pre></blockquote>
4763 <hr>
4764 <a name="511"><h3>511. Input_type for binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4765 <p>
4766 Unlike all other distributions in TR1, this binomial_distribution has an
4767 implementation-defined input_type. We believe this is an unfortunate choice,
4768 because it hinders users from writing portable code. It also hinders the
4769 writing of compliance tests. We recommend instead:
4770 </p>
4771 <blockquote><pre>typedef RealType input_type;
4772 </pre></blockquote>
4773 <p>
4774 While this choice is somewhat arbitrary (as it was for some of the other
4775 distributions), we make this particular choice because (unlike all other
4776 distributions) otherwise this template would not publish its RealType
4777 argument and so users could not write generic code that accessed this
4778 second template parameter. In this respect, the choice is consistent with
4779 the other distributions in TR1.
4780 </p>
4781 <p>
4782 We have two reasons for recommending that a real type be specified instead.
4783 One reason is based specifically on characteristics of binomial distribution
4784 implementations, while the other is based on mathematical characteristics of
4785 probability distribution functions in general.
4786 </p>
4787 <p>
4788 Implementations of binomial distributions commonly use Stirling approximations
4789 for values in certain ranges. It is far more natural to use real values to
4790 represent these approximations than it would be to use integral values to do
4791 so. In other ranges, implementations reply on the Bernoulli distribution to
4792 obtain values. While TR1Õs bernoulli_distribution::input_type is specified as
4793 int, we believe this would be better specified as double.
4794 </p>
4795 <p>
4796 This brings us to our main point: The notion of a random distribution rests
4797 on the notion of a cumulative distribution function, which in turn mathematically
4798 depends on a continuous dependent variable. Indeed, such a distribution function
4799 would be meaningless if it depended on discrete values such as integersÑand this
4800 remains true even if the distribution function were to take discrete steps.
4801 </p>
4802 <p>
4803 Although this note is specifically about binomial_distribution::input_type,
4804 we intend to recommend that all of the random distributionsÕ input_types be
4805 specified as a real type (either a RealType template parameter, or double,
4806 as appropriate).
4807 </p>
4808 <p>
4809 Of the nine distributions in TR1, four already have this characteristic
4810 (uniform_real, exponential_distribution, normal_distribution, and
4811 gamma_distribution). We have already argued the case for the binomial the
4812 remaining four distributions.
4813 </p>
4814 <p>
4815 In the case of uniform_int, we believe that the calculations to produce an
4816 integer result in a specified range from an integer in a different specified
4817 range is best done using real arithmetic. This is because it involves a
4818 product, one of whose terms is the ratio of the extents of the two ranges.
4819 Without real arithmetic, the results become less uniform: some numbers become
4820 more (or less) probable that they should be. This is, of course, undesireable
4821 behavior in a uniform distribution.
4822 </p>
4823 <p>
4824 Finally, we believe that in the case of the bernoulli_distribution (briefly
4825 mentioned earlier), as well as the cases of the geometric_distribution and the
4826 poisson_distribution, it would be far more natural to have a real input_type.
4827 This is because the most natural computation involves the random number
4828 delivered and the distributionÕs parameter p (in the case of bernoulli_distribution,
4829 for example, the computation is a comparison against p), and p is already specified
4830 in each case as having some real type.
4831 </p>
4833 <blockquote><pre>typedef RealType input_type;
4834 </pre></blockquote>
4835 <hr>
4836 <a name="512"><h3>512. Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4837 <p>
4838 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine
4839 is to be seeded given a single unsigned long. This algorithm is seriously
4840 flawed in the case where the engine parameter w (also known as word_size)
4841 exceeds 31 [bits]. The key part of the paragraph reads:
4842 </p>
4843 <blockquote>
4845 </blockquote>
4846 <p>
4847 and so forth.
4848 </p>
4849 <p>
4850 Since the specified linear congruential engine, lcg, delivers numbers with
4853 is that roughly the first 400 numbers delivered will be conspicuously
4854 close to either zero or one.
4855 </p>
4856 <p>
4857 Unfortunately, this is not an innocuous flaw: One of the predefined engines
4858 in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
4859 this poor behavior, while the original N1378 proposal states that these
4860 pre-defined engines are intended to be of "known good properties."
4861 </p>
4863 <p>
4865 void seed(unsigned long value = 19780503) by
4866 </p>
4868 <blockquote>
4876 <blockquote><pre><ins>
4878 seed(lcg);
4879 </ins></pre></blockquote>
4885 </blockquote>
4887 <p><i>[
4888 Jens provided revised wording post Mont Tremblant.
4889 ]</i></p>
4892 <p>
4893 Jens: I'm using an explicit type here, because fixing the
4894 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a> even
4895 stricter) requirements we have for seed(Gen&).
4896 </p>
4897 <hr>
4898 <a name="513"><h3>513. Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4899 <p>
4900 Paragraph 3 begins:
4901 </p>
4902 <blockquote>
4903 The size of the state is r.
4904 </blockquote>
4905 <p>
4906 However, this is not quite consistent with the remainder of the paragraph
4907 which specifies a total of nr+1 items in the textual representation of
4908 the state. We recommend the sentence be corrected to match:
4909 </p>
4910 <blockquote>
4911 The size of the state is nr+1.
4912 </blockquote>
4913 <p>
4914 To give meaning to the coefficient n, it may be also desirable to move
4915 nÕs definition from later in the paragraph. Either of the following
4916 seem reasonable formulations:
4917 </p>
4918 <blockquote>
4919 With n=..., the size of the state is nr+1.
4920 </blockquote>
4921 <blockquote>
4922 The size of the state is nr+1, where n=... .
4923 </blockquote>
4924 <p>
4925 </p>
4927 <p><i>[
4929 used as an argument for big-O complexity notation, thus
4930 constant factors and additions don't count.
4931 ]</i></p>
4932 <hr>
4933 <a name="514"><h3>514. Size of state for subtract_with_carry</h3></a><p><b>Section:</b> TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4934 <p>
4935 Paragraph 2 begins:
4936 </p>
4937 <blockquote>
4938 The size of the state is r.
4939 </blockquote>
4940 <p>
4941 However, the next sentence specifies a total of r+1 items in the textual
4942 representation of the state, r specific xÕs as well as a specific carry.
4943 This makes a total of r+1 items that constitute the size of the state,
4944 rather than r.
4945 </p>
4947 <p>
4948 We recommend the sentence be corrected to match:
4949 </p>
4950 <blockquote>
4951 The size of the state is r+1.
4952 </blockquote>
4954 <p><i>[
4956 used as an argument for big-O complexity notation, thus
4957 constant factors and additions don't count.
4958 ]</i></p>
4960 <hr>
4961 <a name="515"><h3>515. Random number engine traits</h3></a><p><b>Section:</b> TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
4962 <p>
4963 To accompany the concept of a pseudo-random number engine as defined in Table 17,
4964 we propose and recommend an adjunct template, engine_traits, to be declared in
4965 [tr.rand.synopsis] as:
4966 </p>
4968 class engine_traits;
4969 </pre></blockquote>
4970 <p>
4971 This templateÕs primary purpose would be as an aid to generic programming involving
4972 pseudo-random number engines. Given only the facilities described in tr1, it would
4973 be very difficult to produce any algorithms involving the notion of a generic engine.
4974 The intent of this proposal is to provide, via engine_traits<>, sufficient
4975 descriptive information to allow an algorithm to employ a pseudo-random number engine
4976 without regard to its exact type, i.e., as a template parameter.
4977 </p>
4978 <p>
4979 For example, today it is not possible to write an efficient generic function that
4980 requires any specific number of random bits. More specifically, consider a
4981 cryptographic application that internally needs 256 bits of randomness per call:
4982 </p>
4984 void crypto( Eng& e, InIter in, OutIter out );
4985 </pre></blockquote>
4986 <p>
4987 Without knowning the number of bits of randomness produced per call to a provided
4988 engine, the algorithm has no means of determining how many times to call the engine.
4989 </p>
4990 <p>
4991 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
4992 template as:
4993 </p>
4995 class engine_traits
4996 {
4997 static std::size_t bits_of_randomness = 0u;
4998 static std::string name() { return "unknown_engine"; }
4999 // TODO: other traits here
5000 };
5001 </pre></blockquote>
5002 <p>
5003 Further, each engine described in [tr.rand.engine] would be accompanied by a
5004 complete specialization of this new engine_traits template.
5005 </p>
5007 <p>
5009 </p>
5010 <hr>
5011 <a name="516"><h3>516. Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
5012 <p>
5013 Paragraph 6 says:
5014 </p>
5015 <blockquote>
5016 ... obtained by successive invocations of g, ...
5017 </blockquote>
5018 <p>
5019 We recommend instead:
5020 </p>
5021 <blockquote>
5023 </blockquote>
5024 <p>
5025 as the context seems to require only 32-bit quantities be used here.
5026 </p>
5028 <p>
5030 </p>
5031 <hr>
5032 <a name="517"><h3>517. Should include name in external representation</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
5033 <p>
5034 The last two rows of Table 16 deal with the i/o requirements of an engine,
5035 specifying that the textual representation of an engineÕs state,
5036 appropriately formatted, constitute the engineÕs external representation.
5037 </p>
5038 <p>
5039 This seems adequate when an engineÕs type is known. However, it seems
5040 inadequate in the context of generic code, where it becomes useful and
5041 perhaps even necessary to determine an engineÕs type via input.
5042 </p>
5043 <p>
5044 </p>
5046 <p>
5047 We therefore recommend that, in each of these two rows of Table 16, the
5049 followed by the textual representation."
5050 </p>
5051 <hr>
5052 <a name="518"><h3>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b> TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Jul 2005</p>
5053 <p>
5054 Issue 371 deals with stability of multiset/multimap under insert and erase
5055 (i.e. do they preserve the relative order in ranges of equal elements).
5056 The same issue applies to unordered_multiset and unordered_multimap.
5057 </p>
5059 <p>
5060 </p>
5061 <hr>
5062 <a name="519"><h3>519. Data() undocumented</h3></a><p><b>Section:</b> TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p>
5063 <p>
5065 </p>
5067 <p>
5068 Add a new section, after 6.2.2.3:
5069 </p>
5070 <blockquote><pre>T* data()
5071 const T* data() const;
5072 </pre></blockquote>
5073 <p>
5075 </p>
5076 <p>
5078 </p>
5079 <blockquote>
5082 </blockquote>
5083 <hr>
5084 <a name="520"><h3>520. Result_of and pointers to data members</h3></a><p><b>Section:</b> TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p>
5085 <p>
5086 In the original proposal for binders, the return type of bind() when
5087 called with a pointer to member data as it's callable object was
5088 defined to be mem_fn(ptr); when Peter Dimov and I unified the
5089 descriptions of the TR1 function objects we hoisted the descriptions
5090 of return types into the INVOKE pseudo-function and into result_of.
5091 Unfortunately, we left pointer to member data out of result_of, so
5092 bind doesn't have any specified behavior when called with a pointer
5093 to member data.
5094 </p>
5096 <p><i>[
5097 Pete and Peter will provide wording.
5098 ]</i></p>
5099 <hr>
5100 <a name="521"><h3>521. Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b> TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p>
5101 <p>
5104 </p>
5105 <blockquote>
5106 a pointer to member function type with cv-qualifier cv and no arguments;
5107 the type T1 is cv T* and R is the return type of the pointer to member function;
5108 </blockquote>
5109 <p>
5110 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
5111 function. It should be a pointer to the class that T is a pointer to member of.
5112 Like this:
5113 </p>
5114 <blockquote>
5115 a pointer to a member function R T0::f() cv (where cv represents the member
5116 function's cv-qualifiers); the type T1 is cv T0*
5117 </blockquote>
5118 <p>
5120 </p>
5121 <blockquote>
5122 a pointer to a member function R T0::f(T2) cv (where cv represents the member
5123 function's cv-qualifiers); the type T1 is cv T0*
5124 </blockquote>
5126 <hr>
5127 <a name="522"><h3>522. Tuple doesn't define swap</h3></a><p><b>Section:</b> TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 3 Jul 2005</p>
5128 <p>
5129 Tuple doesn't define swap(). It should.
5130 </p>
5132 <hr>
5133 <a name="523"><h3>523. regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b> TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p>
5134 <p>
5135 A problem with TR1 regex is currently being discussed on the Boost
5136 developers list. It involves the handling of case-insensitive matching
5137 of character ranges such as [Z-a]. The proper behavior (according to the
5138 ECMAScript standard) is unimplementable given the current specification
5139 of the TR1 regex_traits<> class template. John Maddock, the author of
5140 the TR1 regex proposal, agrees there is a problem. The full discussion
5142 message copied below). We don't have any recommendations as yet.
5143 </p>
5144 <p>
5145 -- Begin original message --
5146 </p>
5147 <p>
5148 The situation of interest is described in the ECMAScript specification
5150 </p>
5151 <p>
5152 "Even if the pattern ignores case, the case of the two ends of a range
5153 is significant in determining which characters belong to the range.
5154 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5155 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5156 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5157 </p>
5158 <p>
5159 A more interesting case is what should happen when doing a
5160 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5161 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5162 Boost.Regex (it throws an exception from the regex constructor).
5163 </p>
5164 <p>
5165 The tough pill to swallow is that, given the specification in TR1, I
5166 don't think there is any effective way to handle this situation.
5167 According to the spec, case-insensitivity is handled with
5168 regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
5169 if they compare equal after both are sent through the translate_nocase
5170 function. But I don't see any way of using this translation function to
5171 make character ranges case-insensitive. Consider the difficulty of
5172 detecting whether "z" is in the range [Z-a]. Applying the transformation
5173 to "z" has no effect (it is essentially std::tolower). And we're not
5174 allowed to apply the transformation to the ends of the range, because as
5176 </p>
5177 <p>
5178 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5179 is to redefine translate_nocase to return a string_type containing all
5180 the characters that should compare equal to the specified character. But
5181 this function is hard to implement for Unicode, and it doesn't play nice
5182 with the existing ctype facet. What a mess!
5183 </p>
5184 <p>
5185 -- End original message --
5186 </p>
5188 <p><i>[
5189 John Maddock adds:
5190 ]</i></p>
5192 <p>
5193 One small correction, I have since found that ICU's regex package does
5194 implement this correctly, using a similar mechanism to the current
5195 TR1.Regex.
5196 </p>
5197 <p>
5198 Given an expression [c1-c2] that is compiled as case insensitive it:
5199 </p>
5200 <p>
5201 Enumerates every character in the range c1 to c2 and converts it to it's
5202 case folded equivalent. That case folded character is then used a key to a
5203 table of equivalence classes, and each member of the class is added to the
5204 list of possible matches supported by the character-class. This second step
5205 isn't possible with our current traits class design, but isn't necessary if
5206 the input text is also converted to a case-folded equivalent on the fly.
5207 </p>
5208 <p>
5209 ICU applies similar brute force mechanisms to character classes such as
5210 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5211 is less noticeable in this case.
5212 </p>
5213 <p>
5214 Quick and dirty performance comparisons show that expressions such as
5216 slower than a "normal" expression). For an application that uses a lot of
5217 regexes this could have a noticeable performance impact. ICU also has an
5218 advantage in that it knows the range of valid characters codes: code points
5219 outside that range are assumed not to require enumeration, as they can not
5220 be part of any equivalence class. I presume that if we want the TR1.Regex
5221 to work with arbitrarily large character sets enumeration really does become
5222 impractical.
5223 </p>
5224 <p>
5225 Finally note that Unicode has:
5226 </p>
5227 <p>
5228 Three cases (upper, lower and title).
5229 One to many, and many to one case transformations.
5230 Character that have context sensitive case translations - for example an
5231 uppercase sigma has two different lowercase forms - the form chosen depends
5232 on context(is it end of a word or not), a caseless match for an upper case
5233 sigma should match either of the lower case forms, which is why case folding
5234 is often approximated by tolower(toupper(c)).
5235 </p>
5236 <p>
5237 Probably we need some way to enumerate character equivalence classes,
5238 including digraphs (either as a result or an input), and some way to tell
5239 whether the next character pair is a valid digraph in the current locale.
5240 </p>
5241 <p>
5242 Hoping this doesn't make this even more complex that it was already,
5243 </p>
5246 <hr>
5247 <a name="524"><h3>524. regex named character classes and case-insensitivity don't mix</h3></a><p><b>Section:</b> TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p>
5248 <p>
5249 This defect is also being discussed on the Boost developers list. The
5250 full discussion can be found here:
5252 </p>
5253 <p>
5254 -- Begin original message --
5255 </p>
5256 <p>
5257 Also, I may have found another issue, closely related to the one under
5258 discussion. It regards case-insensitive matching of named character
5259 classes. The regex_traits<> provides two functions for working with
5260 named char classes: lookup_classname and isctype. To match a char class
5261 such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
5262 bitmask. Later, you pass a char and the bitmask to isctype and get a
5263 bool yes/no answer.
5264 </p>
5265 <p>
5266 But how does case-insensitivity work in this scenario? Suppose we're
5267 doing a case-insensitive match on [[:lower:]]. It should behave as if it
5268 were [[:lower:][:upper:]], right? But there doesn't seem to be enough
5269 smarts in the regex_traits interface to do this.
5270 </p>
5271 <p>
5272 Imagine I write a traits class which recognizes [[:fubar:]], and the
5273 "fubar" char class happens to be case-sensitive. How is the regex engine
5274 to know that? And how should it do a case-insensitive match of a
5275 character against the [[:fubar:]] char class? John, can you confirm this
5276 is a legitimate problem?
5277 </p>
5278 <p>
5279 I see two options:
5280 </p>
5281 <p>
5282 1) Add a bool icase parameter to lookup_classname. Then,
5283 lookup_classname( "upper", true ) will know to return lower|upper
5284 instead of just upper.
5285 </p>
5286 <p>
5287 2) Add a isctype_nocase function
5288 </p>
5289 <p>
5290 I prefer (1) because the extra computation happens at the time the
5291 pattern is compiled rather than when it is executed.
5292 </p>
5293 <p>
5294 -- End original message --
5295 </p>
5297 <p>
5298 For what it's worth, John has also expressed his preference for option
5299 (1) above.
5300 </p>
5302 <hr>
5303 <a name="525"><h3>525. type traits definitions not clear</h3></a><p><b>Section:</b> TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 11 Jul 2005</p>
5304 <p>
5305 It is not completely clear how the primary type traits deal with
5306 cv-qualified types. And several of the secondary type traits
5307 seem to be lacking a definition.
5308 </p>
5310 <hr>
5311 <a name="526"><h3>526. Is it undefined if a function in the standard changes in parameters?</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 14 Sep 2005</p>
5312 <p>
5313 Problem: There are a number of places in the C++ standard library where
5314 it is possible to write what appear to be sensible ways of calling
5315 functions, but which can cause problems in some (or all)
5316 implementations, as they cause the values given to the function to be
5317 changed in a way not specified in standard (and therefore not coded to
5318 correctly work). These fall into two similar categories.
5319 </p>
5321 <p>
5322 1) Parameters taken by const reference can be changed during execution
5323 of the function
5324 </p>
5326 <p>
5327 Examples:
5328 </p>
5330 <p>
5332 </p>
5333 <p>
5334 v.insert(v.begin(), v[2]);
5335 </p>
5336 <p>
5337 v[2] can be changed by moving elements of vector
5338 </p>
5341 <p>
5343 </p>
5344 <p>
5345 l.remove(*l.begin());
5346 </p>
5347 <p>
5348 Will delete the first element, and then continue trying to access it.
5349 This is particularily vicious, as it will appear to work in almost all
5350 cases.
5351 </p>
5353 <p>
5354 2) A range is given which changes during the execution of the function:
5355 Similarly,
5356 </p>
5358 <p>
5360 </p>
5362 <p>
5363 This kind of problem has been partly covered in some cases. For example
5364 std::copy(first, last, result) states that result cannot be in the range
5365 [first, last). However, does this cover the case where result is a
5366 reverse_iterator built from some iterator in the range [first, last)?
5367 Also, std::copy would still break if result was reverse_iterator(last +
5368 1), yet this is not forbidden by the standard
5369 </p>
5371 <p>
5372 Solution:
5373 </p>
5375 <p>
5376 One option would be to try to more carefully limit the requirements of
5377 each function. There are many functions which would have to be checked.
5378 However as has been shown in the std::copy case, this may be difficult.
5379 A simpler, more global option would be to somewhere insert text similar to:
5380 </p>
5382 <p>
5383 If the execution of any function would change either any values passed
5384 by reference or any value in any range passed to a function in a way not
5385 defined in the definition of that function, the result is undefined.
5386 </p>
5388 <p>
5390 I read through carefully). I can see no harm on applying it to much of
5391 the rest of the standard.
5392 </p>
5394 <p>
5395 Some existing parts of the standard could be improved to fit with this,
5396 for example the requires for 25.2.1 (Copy) could be adjusted to:
5397 </p>
5399 <p>
5400 Requires: For each non-negative integer n < (last - first), assigning to
5401 *(result + n) must not alter any value in the range [first + n, last).
5402 </p>
5404 <p>
5405 However, this may add excessive complication.
5406 </p>
5408 <p>
5409 One other benefit of clearly introducing this text is that it would
5410 allow a number of small optimisations, such as caching values passed
5411 by const reference.
5412 </p>
5415 <p>
5416 </p>
5417 <hr>
5418 <a name="527"><h3>527. tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b> TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 01 Oct 2005</p>
5419 <p>
5420 The original bind proposal gives the guarantee that tr1::bind(f, t1,
5421 ..., tN) does not throw when the copy constructors of f, t1, ..., tN
5422 don't.
5423 </p>
5425 <p>
5426 This guarantee is not present in the final version of TR1.
5427 </p>
5429 <p>
5430 I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
5431 </p>
5433 <p>
5434 </p>
5435 <hr>
5436 <a name="528"><h3>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b> TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Oct 2005</p>
5437 <p>
5438 while implementing the resolution of issue 6.19 I'm noticing the
5440 unordered_multiset:
5441 </p>
5443 <blockquote>
5444 "The iterator and const_iterator types are both const types. It is
5445 unspecified whether they are the same type"
5446 </blockquote>
5448 <p>
5449 Now, according to the resolution of 6.19, we have overloads of insert
5450 with hint and erase (single and range) both for iterator and
5451 const_iterator, which, AFAICS, can be meaningful at the same time *only*
5452 if iterator and const_iterator *are* in fact different types.
5453 </p>
5454 <p>
5455 Then, iterator and const_iterator are *required* to be different types?
5456 Or that is an unintended consequence? Maybe the overloads for plain
5457 iterators should be added only to unordered_map and unordered_multimap?
5458 Or, of course, I'm missing something?
5459 </p>
5462 <p>
5464 </p>
5465 <p>
5468 It is unspecified whether they are the same type. <ins>If they are the
5469 same type, those signatures that become otherwise indistinguishable
5470 collapse into a single signature.</ins>
5471 </p>
5473 <hr>
5474 <a name="529"><h3>529. The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b> 17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 25 Oct 2005</p>
5475 <p>
5477 </p>
5479 <blockquote>
5480 Violation of the preconditions specified in a function's
5481 Required behavior: paragraph results in undefined behavior unless the
5482 function's Throws: paragraph specifies throwing an exception when the
5483 precondition is violated.
5484 </blockquote>
5486 <p>
5487 This implies that a precondition violation can lead to defined
5488 behavior. That conflicts with the only reasonable definition of
5489 precondition: that a violation leads to undefined behavior. Any other
5490 definition muddies the waters when it comes to analyzing program
5491 correctness, because precondition violations may be routinely done in
5492 correct code (e.g. you can use std::vector::at with the full
5493 expectation that you'll get an exception when your index is out of
5494 range, catch the exception, and continue). Not only is it a bad
5495 example to set, but it encourages needless complication and redundancy
5496 in the standard. For example:
5497 </p>
5500 21.3.3 basic_string capacity
5502 void resize(size_type n, charT c);
5506 7 Effects: Alters the length of the string designated by *this as follows:
5507 </pre></blockquote>
5509 <p>
5510 The Requires clause is entirely redundant and can be dropped. We
5511 could make that simplifying change (and many others like it) even
5513 the redundant and error-prone Requires: clause.
5514 </p>
5517 <p>
5519 </p>
5521 <blockquote>
5522 Violation of the preconditions specified in a function's
5525 an exception when the precondition is violated</del>.
5526 </blockquote>
5528 <p>
5529 2. Go through and remove redundant Requires: clauses. Specifics to be
5530 provided by Dave A.
5531 </p>
5532 <hr>
5533 <a name="530"><h3>530. Must elements of a string be contiguous?</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Nov 2005</p>
5534 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
5535 that the elements of a vector must be stored in contiguous memory.
5538 <p>We almost require contiguity already. Clause 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>
5540 is a similar guarantee if we access the string's elements via the
5545 I don't believe it's possible to write a useful and standard-
5547 aware of any non-contiguous implementation. We should just require
5548 it.
5549 </p>
5551 <p>Add the following text to the end of 23.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative"> [lib.associative]</a>,
5554 <blockquote>
5557 it obeys the identity
5560 </p>
5561 </blockquote>
5562 <hr>
5563 <a name="531"><h3>531. array forms of unformatted input functions</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Nov 2005</p>
5564 <p>
5565 The array forms of unformatted input functions don't seem to have well-defined
5566 semantics for zero-element arrays in a couple of cases. The affected ones
5570 c++std-lib-16071.
5571 </p>
5573 <p>
5575 </p>
5576 <p>
5577 </p><ul>
5578 <li>
5580 are stored;
5581 </li>
5582 </ul>
5583 <p></p>
5584 <p>
5588 </p>
5589 <p>
5590 </p><ul>
5591 <li>
5593 are stored (in which case the function calls
5595 </li>
5596 </ul>
5597 <p></p>
5599 <p>
5602 terminating NUL character unless the the array has non-zero size, Robert
5605 </p>
5606 <p>
5607 </p><blockquote>
5610 (using charT()) into the next successive location of the array.
5612 </blockquote>
5613 <p></p>
5614 <hr>
5615 <a name="532"><h3>532. Tuple comparison</h3></a><p><b>Section:</b> TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 29 Nov 2005</p>
5616 <p>
5618 defined in terms of std::less rather than operator<, in order to
5619 support comparison of tuples of pointers.
5620 </p>
5622 <p>
5624 </p>
5626 <blockquote>
5627 Returns: The result of a lexicographical comparison between t and
5630 some tuple r is a tuple containing all but the first element of
5631 r. For any two zero-length tuples e and f, e < f returns false.
5632 </blockquote>
5634 <p>
5635 to:
5636 </p>
5638 <blockquote>
5639 <p>
5640 Returns: The result of a lexicographical comparison between t and
5641 u. For any two zero-length tuples e and f, e < f returns false.
5644 tuple r is a tuple containing all but the first element of r, and
5645 cmp(x,y) is an unspecified function template defined as follows.
5646 </p>
5647 <p>
5648 Where T is the type of x and U is the type of y:
5649 </p>
5651 <p>
5652 if T and U are pointer types and T is convertible to U, returns
5654 </p>
5656 <p>
5658 </p>
5660 <p>
5661 otherwise, returns (bool)(x < y)
5662 </p>
5663 </blockquote>
5664 <hr>
5665 <a name="533"><h3>533. typo in 2.2.3.10/1</h3></a><p><b>Section:</b> TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 9 Nov 2005</p>
5666 <p>
5668 says:
5669 </p>
5670 <blockquote>
5672 </blockquote>
5673 <p>
5675 </p>
5677 <p>
5678 Therefore, I think should be:
5679 </p>
5680 <blockquote>
5682 </blockquote>
5683 <hr>
5684 <a name="534"><h3>534. Missing basic_string members</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 16 Nov 2005</p>
5685 <p>
5686 OK, we all know std::basic_string is bloated and already has way too
5687 many members. However, I propose it is missing 3 useful members that
5688 are often expected by users believing it is a close approximation of the
5690 </p>
5692 <p>
5693 i/ pop_back.
5694 </p>
5696 <p>
5697 This is the one I feel most strongly about, as I only just discovered it
5698 was missing as we are switching to a more conforming standard library
5700 </p>
5702 <p>
5703 I find it particularly inconsistent to support push_back, but not
5704 pop_back.
5705 </p>
5707 <p>
5708 ii/ back.
5709 </p>
5711 <p>
5712 There are certainly cases where I want to examine the last character of
5713 a string before deciding to append, or to trim trailing path separators
5714 from directory names etc. *rbegin() somehow feels inelegant.
5715 </p>
5717 <p>
5718 iii/ front
5719 </p>
5721 <p>
5722 This one I don't feel strongly about, but if I can get the first two,
5723 this one feels that it should be added as a 'me too' for consistency.
5724 </p>
5726 <p>
5727 I believe this would be similarly useful to the data() member recently
5728 added to vector, or at() member added to the maps.
5729 </p>
5731 <p>
5732 </p>
5733 <hr>
5734 <a name="535"><h3>535. std::string::swap specification poorly worded</h3></a><p><b>Section:</b> 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 14 Dec 2005</p>
5735 <p>
5736 std::string::swap currently says for effects and postcondition:
5737 </p>
5739 <blockquote>
5740 <p>
5742 </p>
5744 <p>
5747 </p>
5748 </blockquote>
5750 <p>
5751 Specifying both Effects and Postcondition seems redundant, and the postcondition
5752 needs to be made stronger. Users would be unhappy if the characters were not in
5753 the same order after the swap.
5754 </p>
5756 <blockquote>
5757 <p>
5759 </p>
5761 <p>
5766 </p>
5767 </blockquote>
5769 </body></html>