1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> 2<html> 3<head><title>C++ Standard Library Defect Report List</title></head> 4<body bgcolor="#ffffff" text="#000000"> 5<table> 6<tr> 7<td align="left">Doc. no.</td> 8<td align="left">J16/02-0049 = WG21 N1391</td> 9</tr> 10<tr> 11<td align="left">Date:</td> 12<td align="left">10 Sep 2002</td> 13</tr> 14<tr> 15<td align="left">Project:</td> 16<td align="left">Programming Language C++</td> 17</tr> 18<tr> 19<td align="left">Reply to:</td> 20<td align="left">Matt Austern <austern@apple.com></td> 21</tr> 22</table> 23<h1>C++ Standard Library Defect Report List (Revision 23)</h1> 24 <p>Reference ISO/IEC IS 14882:1998(E)</p> 25 <p>Also see:</p> 26 <ul> 27 <li> 28<a href="lwg-toc.html">Table of Contents</a> for all library issues.</li> 29 <li> 30<a href="lwg-index.html">Index by Section</a> for all library issues.</li> 31 <li> 32<a href="lwg-status.html">Index by Status</a> for all library issues.</li> 33 <li><a href="lwg-active.html">Library Active Issues List</a></li> 34 <li><a href="lwg-closed.html">Library Closed Issues List</a></li> 35 </ul> 36 <p>This document contains only library issues which have been closed 37 by the Library Working Group (LWG) after being found to be defects 38 in the standard. That is, issues which have a status of <a href="lwg-active.html#DR">DR</a>, <a href="lwg-active.html#TC">TC</a>, or <a href="lwg-active.html#RR">RR</a>. See the 39 <a href="lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the 40 <a href="lwg-active.html">Library Active Issues List</a> for active issues and more information. The 41 introductory material in that document also applies to this 42 document.</p> 43<h2>Revision History</h2> 44<ul> 45<li>R23: 46Pre-Santa Cruz mailing. Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>. 47Moved issues in the TC to TC status. 48</li> 49<li>R22: 50Post-Curaçao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>. 51</li> 52<li>R21: 53Pre-Curaçao mailing. Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>. 54</li> 55<li>R20: 56Post-Redmond mailing; reflects actions taken in Redmond. Added 57new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues 58<a href="lwg-active.html#347">347</a>-<a href="lwg-active.html#350">350</a> were added since Redmond, hence 59not discussed at the meeting. 60 61All Ready issues were moved to DR status, with the exception of issues 62<a href="lwg-defects.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>. 63 64Noteworthy issues discussed at Redmond include 65<a href="lwg-active.html#120">120</a> <a href="lwg-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>, 66<a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>. 67</li> 68<li>R19: 69Pre-Redmond mailing. Added new issues 70<a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>. 71</li> 72<li>R18: 73Post-Copenhagen mailing; reflects actions taken in Copenhagen. 74Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed 75new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>. 76 77Changed status of issues 78<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a> 79<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a> 80<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a> 81<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a> 82<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a> 83<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a> 84<a href="lwg-defects.html#268">268</a> 85to DR. 86 87Changed status of issues 88<a href="lwg-defects.html#49">49</a> <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a> 89<a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a> 90<a href="lwg-defects.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a> 91<a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a> 92<a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a> 93<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a> 94<a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a> 95<a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a> 96<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a> 97to Ready. 98 99Closed issues 100<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a> 101<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a> 102<a href="lwg-closed.html#314">314</a> 103as NAD. 104 105</li> 106<li>R17: 107Pre-Copenhagen mailing. Converted issues list to XML. Added proposed 108resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>. 109Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>. 110</li> 111<li>R16: 112post-Toronto mailing; reflects actions taken in Toronto. Added new 113issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>. Changed status of issues 114<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>, 115<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>, 116<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>, 117<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>, 118<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>, 119<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>, 120<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>, 121<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>, 122<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>, 123<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>, 124<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>, 125<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>, 126<a href="lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="lwg-active.html#23">23</a>. Reopened 127issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and 128<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed 129issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it 130appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix 131the bug in enough places. 132</li> 133<li>R15: 134pre-Toronto mailing. Added issues 135<a href="lwg-active.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting 136changes so that we pass Weblint tests. 137</li> 138<li>R14: 139post-Tokyo II mailing; reflects committee actions taken in 140Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242) 141</li> 142<li>R13: 143pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>. 144</li> 145<li>R12: 146pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to 147<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution 148of issue <a href="lwg-defects.html#29">29</a>. Add further rationale to issue 149<a href="lwg-closed.html#178">178</a>. 150</li> 151<li>R11: 152post-Kona mailing: Updated to reflect LWG and full committee actions 153in Kona (99-0048/N1224). Note changed resolution of issues 154<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a> 155to <a href="lwg-defects.html#198">198</a>. Closed issues list split into "defects" and 156"closed" documents. Changed the proposed resolution of issue 157<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution 158of issue <a href="lwg-defects.html#38">38</a>. 159</li> 160<li>R10: 161pre-Kona updated. Added proposed resolutions <a href="lwg-defects.html#83">83</a>, 162<a href="lwg-defects.html#86">86</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>, 163<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to 164<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) 165</li> 166<li>R9: 167pre-Kona mailing. Added issues <a href="lwg-closed.html#140">140</a> to 168<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and 169"closed" documents. (99-0030/N1206, 25 Aug 99) 170</li> 171<li>R8: 172post-Dublin mailing. Updated to reflect LWG and full committee actions 173in Dublin. (99-0016/N1193, 21 Apr 99) 174</li> 175<li>R7: 176pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>, 177<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>, 178<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>, 179<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99) 180</li> 181<li>R6: 182pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>, 183and <a href="lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) 184</li> 185<li>R5: 186update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues 187<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare 188for making list public. (30 Dec 98) 189</li> 190<li>R4: 191post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>, 192<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several 193issues corrected. (22 Oct 98) 194</li> 195<li>R3: 196post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a> 197added, many issues updated to reflect LWG consensus (12 Oct 98) 198</li> 199<li>R2: 200pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added, 201issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98) 202</li> 203<li>R1: 204Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code 205format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98) 206</li> 207</ul> 208<h2>Defect Reports</h2> 209<hr> 210<a name="1"><h3>1. C library linkage editing oversight</h3></a><p> 211<b>Section:</b> 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p> 212<p>The change specified in the proposed resolution below did not make 213it into the Standard. This change was accepted in principle at the 214London meeting, and the exact wording below was accepted at the 215Morristown meeting.</p> 216<p><b>Proposed resolution:</b></p> 217<p>Change 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2 218from:</p> 219 220<blockquote> 221 <p>It is unspecified whether a name from the Standard C library 222 declared with external linkage has either extern "C" or 223 extern "C++" linkage.</p> 224</blockquote> 225 226<p>to:</p> 227 228<blockquote> 229 <p>Whether a name from the Standard C library declared with external 230 linkage has extern "C" or extern "C++" linkage 231 is implementation defined. It is recommended that an implementation 232 use extern "C++" linkage for this purpose.</p> 233</blockquote> 234<hr> 235<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p> 236<b>Section:</b> 18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p> 237<p>We appear not to have covered all the possibilities of 238 exit processing with respect to 239atexit registration. <br> 240<br> 241Example 1: (C and C++)</p> 242 243<pre> #include <stdlib.h> 244 void f1() { } 245 void f2() { atexit(f1); } 246 247 int main() 248 { 249 atexit(f2); // the only use of f2 250 return 0; // for C compatibility 251 }</pre> 252 253<p>At program exit, f2 gets called due to its registration in 254main. Running f2 causes f1 to be newly registered during the exit 255processing. Is this a valid program? If so, what are its 256semantics?</p> 257 258<p> 259Interestingly, neither the C standard, nor the C++ draft standard nor 260the forthcoming C9X Committee Draft says directly whether you can 261register a function with atexit during exit processing.</p> 262 263<p> 264All 3 standards say that functions are run in reverse order of their 265registration. Since f1 is registered last, it ought to be run first, 266but by the time it is registered, it is too late to be first.</p> 267 268<p>If the program is valid, the standards are self-contradictory about 269its semantics.</p> 270 271<p>Example 2: (C++ only)</p> 272 273<pre> 274 void F() { static T t; } // type T has a destructor 275 276 int main() 277 { 278 atexit(F); // the only use of F 279 } 280</pre> 281 282<p>Function F registered with atexit has a local static variable t, 283and F is called for the first time during exit processing. A local 284static object is initialized the first time control flow passes 285through its definition, and all static objects are destroyed during 286exit processing. Is the code valid? If so, what are its semantics?</p> 287 288<p> 289Section 18.3 "Start and termination" says that if a function 290F is registered with atexit before a static object t is initialized, F 291will not be called until after t's destructor completes.</p> 292 293<p> 294In example 2, function F is registered with atexit before its local 295static object O could possibly be initialized. On that basis, it must 296not be called by exit processing until after O's destructor 297completes. But the destructor cannot be run until after F is called, 298since otherwise the object could not be constructed in the first 299place.</p> 300 301<p>If the program is valid, the standard is self-contradictory about 302its semantics.</p> 303 304<p>I plan to submit Example 1 as a public comment on the C9X CD, with 305a recommendation that the results be undefined. (Alternative: make it 306unspecified. I don't think it is worthwhile to specify the case where 307f1 itself registers additional functions, each of which registers 308still more functions.)</p> 309 310<p>I think we should resolve the situation in the whatever way the C 311committee decides. </p> 312 313<p>For Example 2, I recommend we declare the results undefined.</p> 314 315<p><i>[See reflector message lib-6500 for further discussion.]</i></p> 316 317<p><b>Proposed resolution:</b></p> 318<p>Change section 18.3/8 from:</p> 319<blockquote> 320 First, objects with static storage duration are destroyed and 321 functions registered by calling atexit are called. Objects with 322 static storage duration are destroyed in the reverse order of the 323 completion of their constructor. (Automatic objects are not 324 destroyed as a result of calling exit().) Functions registered with 325 atexit are called in the reverse order of their registration. A 326 function registered with atexit before an object obj1 of static 327 storage duration is initialized will not be called until obj1's 328 destruction has completed. A function registered with atexit after 329 an object obj2 of static storage duration is initialized will be 330 called before obj2's destruction starts. 331</blockquote> 332<p>to:</p> 333<blockquote> 334 First, objects with static storage duration are destroyed and 335 functions registered by calling atexit are called. Non-local objects 336 with static storage duration are destroyed in the reverse order of 337 the completion of their constructor. (Automatic objects are not 338 destroyed as a result of calling exit().) Functions registered with 339 atexit are called in the reverse order of their registration, except 340 that a function is called after any previously registered functions 341 that had already been called at the time it was registered. A 342 function registered with atexit before a non-local object obj1 of 343 static storage duration is initialized will not be called until 344 obj1's destruction has completed. A function registered with atexit 345 after a non-local object obj2 of static storage duration is 346 initialized will be called before obj2's destruction starts. A local 347 static object obj3 is destroyed at the same time it would be if a 348 function calling the obj3 destructor were registered with atexit at 349 the completion of the obj3 constructor. 350</blockquote> 351<p><b>Rationale:</b></p> 352<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis 353supporting to the proposed resolution.</p> 354<hr> 355<a name="5"><h3>5. String::compare specification questionable</h3></a><p> 356<b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p> 357<p>At the very end of the basic_string class definition is the signature: int 358compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the 359following text this is defined as: returns 360basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( 361basic_string<charT,traits,Allocator>(s,n2); </p> 362 363<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a 364= Allocator()) clearly requires that s != NULL and n < npos and further states that it 365throws length_error if n == npos, it appears the compare() signature above should always 366throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some 367null terminated character array. </p> 368 369<p>This appears to be a typo since the obvious intent is to allow either the call above or 370something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p> 371 372<p>This would imply that what was really intended was two signatures int compare(size_type 373pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const 374charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p> 375<p><b>Proposed resolution:</b></p> 376<p>Replace the compare signature in 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> 377(at the very end of the basic_string synopsis) which reads:</p> 378 379<blockquote> 380 <p><tt>int compare(size_type pos1, size_type n1,<br> 381 const charT* s, 382 size_type n2 = npos) const;</tt></p> 383</blockquote> 384 385<p>with:</p> 386 387<blockquote> 388 <p><tt>int compare(size_type pos1, size_type n1,<br> 389 const charT* s) const;<br> 390 int compare(size_type pos1, size_type n1,<br> 391 const charT* s, 392 size_type n2) const;</tt></p> 393</blockquote> 394 395<p>Replace the portion of 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> 396paragraphs 5 and 6 which read:</p> 397 398<blockquote> 399 <p> 400<tt>int compare(size_type pos, size_type n1,<br> 401 charT * s, size_type n2 402 = npos) const;<br> 403 </tt>Returns:<tt><br> 404 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> 405 406 basic_string<charT,traits,Allocator>( s, n2))</tt> 407</p> 408</blockquote> 409 410<p>with:</p> 411 412<blockquote> 413 <p> 414<tt>int compare(size_type pos, size_type n1,<br> 415 const charT * s) const;<br> 416 </tt>Returns:<tt><br> 417 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> 418 419 basic_string<charT,traits,Allocator>( s ))<br> 420 <br> 421 int compare(size_type pos, size_type n1,<br> 422 const charT * s, 423 size_type n2) const;<br> 424 </tt>Returns:<tt><br> 425 basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> 426 427 basic_string<charT,traits,Allocator>( s, n2))</tt> 428</p> 429</blockquote> 430 431<p>Editors please note that in addition to splitting the signature, the third argument 432becomes const, matching the existing synopsis.</p> 433<p><b>Rationale:</b></p> 434<p>While the LWG dislikes adding signatures, this is a clear defect in 435the Standard which must be fixed. The same problem was also 436identified in issues 7 (item 5) and 87.</p> 437<hr> 438<a name="7"><h3>7. String clause minor problems</h3></a><p> 439<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p> 440<p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template 441<class InputIterator> insert(iterator, InputIterator, 442InputIterator) makes no sense. It refers to a member function that 443doesn't exist. It also talks about the return value of a void 444function. </p> 445 446<p>(2) Several versions of basic_string::replace don't appear in the 447class synopsis. </p> 448 449<p>(3) basic_string::push_back appears in the synopsis, but is never 450described elsewhere. In the synopsis its argument is const charT, 451which doesn't makes much sense; it should probably be charT, or 452possible const charT&. </p> 453 454<p>(4) basic_string::pop_back is missing. </p> 455 456<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2 457= npos) make no sense. First, it's const charT* in the synopsis and 458charT* in the description. Second, given what it says in RETURNS, 459leaving out the final argument will always result in an exception 460getting thrown. This is paragraphs 5 and 6 of 46121.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> 462</p> 463 464<p>(6) In table 37, in section 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, 465there's a note for X::move(s, p, n). It says "Copies correctly 466even where p is in [s, s+n)". This is correct as far as it goes, 467but it doesn't go far enough; it should also guarantee that the copy 468is correct even where s in in [p, p+n). These are two orthogonal 469guarantees, and neither one follows from the other. Both guarantees 470are necessary if X::move is supposed to have the same sort of 471semantics as memmove (which was clearly the intent), and both 472guarantees are necessary if X::move is actually supposed to be 473useful. </p> 474<p><b>Proposed resolution:</b></p> 475<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br> 476<br> 477 EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br> 478<br> 479ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in 480the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br> 481<br> 482ITEM 3: Change the declaration of push_back in the string synopsis (21.3, 483[lib.basic.string]) from:</p> 484 485<p> void push_back(const charT)<br> 486<br> 487to<br> 488<br> 489 void push_back(charT)<br> 490<br> 491Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br> 492<br> 493 void basic_string::push_back(charT c);<br> 494 EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br> 495<br> 496ITEM 4: Not a defect. The omission appears to have been deliberate.<br> 497<br> 498ITEM 5: Duplicate; see issue 5 (and 87).<br> 499<br> 500ITEM 6: In table 37, Replace:<br> 501<br> 502 "Copies correctly even where p is in [s, s+n)."<br> 503<br> 504with:<br> 505<br> 506 "Copies correctly even where the ranges [p, p+n) and [s, 507s+n) overlap."</p> 508<hr> 509<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p> 510<b>Section:</b> 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p> 511<p>It appears there's an important guarantee missing from clause 51222. We're told that invoking locale::global(L) sets the C locale if L 513has a name. However, we're not told whether or not invoking 514setlocale(s) sets the global C++ locale. </p> 515 516<p>The intent, I think, is that it should not, but I can't find any 517such words anywhere. </p> 518<p><b>Proposed resolution:</b></p> 519<p>Add a sentence at the end of 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>, 520paragraph 2: </p> 521 522<blockquote> 523 <p>No library function other than <tt>locale::global()</tt> shall affect 524 the value returned by <tt>locale()</tt>. </p> 525 526</blockquote> 527<hr> 528<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p> 529<b>Section:</b> 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p> 530<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that 531section 3.7.3.1 of CD2 seems to allow for the possibility that all 532calls to operator new(0) yield the same pointer, an implementation 533technique specifically prohibited by ARM 5.3.3.Was this prohibition 534really lifted? Does the FDIS agree with CD2 in the regard? [Issues 535list maintainer's note: the IS is the same.]</p> 536<p><b>Proposed resolution:</b></p> 537<p>Change the last paragraph of 3.7.3 from:</p> 538<blockquote> 539 <p>Any allocation and/or deallocation functions defined in a C++ program shall 540 conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p> 541</blockquote> 542<p>to:</p> 543<blockquote> 544 <p>Any allocation and/or deallocation functions defined in a C++ program, 545 including the default versions in the library, shall conform to the semantics 546 specified in 3.7.3.1 and 3.7.3.2.</p> 547</blockquote> 548<p>Change 3.7.3.1/2, next-to-last sentence, from :</p> 549<blockquote> 550 <p>If the size of the space requested is zero, the value returned shall not be 551 a null pointer value (4.10).</p> 552</blockquote> 553<p>to:</p> 554<blockquote> 555 <p>Even if the size of the space requested is zero, the request can fail. If 556 the request succeeds, the value returned shall be a non-null pointer value 557 (4.10) p0 different from any previously returned value p1, unless that value 558 p1 was since passed to an operator delete.</p> 559</blockquote> 560<p>5.3.4/7 currently reads:</p> 561<blockquote> 562 <p>When the value of the expression in a direct-new-declarator is zero, the 563 allocation function is called to allocate an array with no elements. The 564 pointer returned by the new-expression is non-null. [Note: If the library 565 allocation function is called, the pointer returned is distinct from the 566 pointer to any other object.]</p> 567</blockquote> 568<p>Retain the first sentence, and delete the remainder.</p> 569<p>18.4.1 currently has no text. Add the following:</p> 570<blockquote> 571 <p>Except where otherwise specified, the provisions of 3.7.3 apply to the 572 library versions of operator new and operator delete.</p> 573</blockquote> 574<p>To 18.4.1.3, add the following text:</p> 575<blockquote> 576 <p>The provisions of 3.7.3 do not apply to these reserved placement forms of 577 operator new and operator delete.</p> 578</blockquote> 579<p><b>Rationale:</b></p> 580<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis 581supporting to the proposed resolution.</p> 582<hr> 583<a name="11"><h3>11. Bitset minor problems</h3></a><p> 584<b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p> 585<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is 586not documented in 23.3.5.2. </p> 587 588<p>(2) The class synopsis only gives a single signature for bitset<>::operator[], 589reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded 590on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p> 591 592<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before 593trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should 594go in the Effects clause.</p> 595<p><b>Proposed resolution:</b></p> 596<p>ITEMS 1 AND 2:<br> 597<br> 598In the bitset synopsis (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>), 599replace the member function <br> 600<br> 601<tt> reference operator[](size_t pos);<br> 602</tt><br> 603with the two member functions<br> 604<br> 605<tt> bool operator[](size_t pos) const; <br> 606 reference operator[](size_t pos); <br> 607</tt><br> 608Add the following text at the end of 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, 609immediately after paragraph 45:</p> 610 611<blockquote> 612 <p> 613<tt>bool operator[](size_t pos) const;</tt><br> 614 Requires: pos is valid<br> 615 Throws: nothing<br> 616 Returns: <tt>test(pos)</tt><br> 617 <br> 618 <tt>bitset<N>::reference operator[](size_t pos);</tt> <br> 619 Requires: pos is valid<br> 620 Throws: nothing<br> 621 Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos] 622 == this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos, 623 val);</tt> 624</p> 625</blockquote> 626<p><b>Rationale:</b></p> 627<p>The LWG believes Item 3 is not a defect. "Formatted 628input" implies the desired semantics. See 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>. 629</p> 630<hr> 631<a name="13"><h3>13. Eos refuses to die</h3></a><p> 632<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p> 633<p>In 27.6.1.2.3, there is a reference to "eos", which is 634the only one in the whole draft (at least using Acrobat search), so 635it's undefined. </p> 636<p><b>Proposed resolution:</b></p> 637<p>In 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with 638"charT()"</p> 639<hr> 640<a name="14"><h3>14. Locale::combine should be const</h3></a><p> 641<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 642<p>locale::combine is the only member function of locale (other than constructors and 643destructor) that is not const. There is no reason for it not to be const, and good reasons 644why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 645paragraph 6: "An instance of a locale is immutable." </p> 646 647<p>History: this member function originally was a constructor. it happened that the 648interface it specified had no corresponding language syntax, so it was changed to a member 649function. As constructors are never const, there was no "const" in the interface 650which was transformed into member "combine". It should have been added at that 651time, but the omission was not noticed. </p> 652<p><b>Proposed resolution:</b></p> 653<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> and also in 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add 654"const" to the declaration of member combine: </p> 655<blockquote> 656 <pre>template <class Facet> locale combine(const locale& other) const; </pre> 657</blockquote> 658<hr> 659<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p> 660<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 661<p>locale::name() is described as returning a string that can be passed to a locale 662constructor, but there is no matching constructor. </p> 663<p><b>Proposed resolution:</b></p> 664<p>In 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace 665"<tt>locale(name())</tt>" with 666"<tt>locale(name().c_str())</tt>". 667</p> 668<hr> 669<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p> 670<b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 671<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get 672edited in properly. Instead, the member do_widen appears four times, with wrong argument 673lists. </p> 674<p><b>Proposed resolution:</b></p> 675<p>The correct declarations for the overloaded members 676<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied 677from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p> 678<hr> 679<a name="17"><h3>17. Bad bool parsing</h3></a><p> 680<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 681<p>This section describes the process of parsing a text boolean value from the input 682stream. It does not say it recognizes either of the sequences "true" or 683"false" and returns the corresponding bool value; instead, it says it recognizes 684only one of those sequences, and chooses which according to the received value of a 685reference argument intended for returning the result, and reports an error if the other 686sequence is found. (!) Furthermore, it claims to get the names from the ctype<> 687facet rather than the numpunct<> facet, and it examines the "boolalpha" 688flag wrongly; it doesn't define the value "loc"; and finally, it computes 689wrongly whether to use numeric or "alpha" parsing.<br> 690<br> 691I believe the correct algorithm is "as if": </p> 692 693<pre> // in, err, val, and str are arguments. 694 err = 0; 695 const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc()); 696 const string_type t = np.truename(), f = np.falsename(); 697 bool tm = true, fm = true; 698 size_t pos = 0; 699 while (tm && pos < t.size() || fm && pos < f.size()) { 700 if (in == end) { err = str.eofbit; } 701 bool matched = false; 702 if (tm && pos < t.size()) { 703 if (!err && t[pos] == *in) matched = true; 704 else tm = false; 705 } 706 if (fm && pos < f.size()) { 707 if (!err && f[pos] == *in) matched = true; 708 else fm = false; 709 } 710 if (matched) { ++in; ++pos; } 711 if (pos > t.size()) tm = false; 712 if (pos > f.size()) fm = false; 713 } 714 if (tm == fm || pos == 0) { err |= str.failbit; } 715 else { val = tm; } 716 return in;</pre> 717 718<p>Notice this works reasonably when the candidate strings are both empty, or equal, or 719when one is a substring of the other. The proposed text below captures the logic of the 720code above.</p> 721<p><b>Proposed resolution:</b></p> 722<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14, 723change "&&" to "&".</p> 724 725<p>Then, replace paragraphs 15 and 16 as follows:</p> 726 727<blockquote> 728 729 <p>Otherwise target sequences are determined "as if" by 730 calling the members <tt>falsename()</tt> and 731 <tt>truename()</tt> of the facet obtained by 732 <tt>use_facet<numpunct<charT> >(str.getloc())</tt>. 733 Successive characters in the range <tt>[in,end)</tt> (see 734 [lib.sequence.reqmts]) are obtained and matched against 735 corresponding positions in the target sequences only as necessary to 736 identify a unique match. The input iterator <tt>in</tt> is 737 compared to <tt>end</tt> only when necessary to obtain a 738 character. If and only if a target sequence is uniquely matched, 739 <tt>val</tt> is set to the corresponding value.</p> 740 741</blockquote> 742 743<blockquote> 744 <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character 745 successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to 746 <tt>str.eofbit</tt> if, when seeking another character to match, it is found that 747 <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to 748 <tt>(str.failbit|str.eofbit)</tt>if 749 the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets 750 <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields 751 <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields 752 <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets 753 <tt>true</tt>:"1" 754 and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt> 755 and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields 756 <tt>err==str.failbit</tt>. --end example]</p> 757</blockquote> 758<hr> 759<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p> 760<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 761<p>In the list of num_get<> non-virtual members on page 22-23, the member 762that parses bool values was omitted from the list of definitions of non-virtual 763members, though it is listed in the class definition and the corresponding 764virtual is listed everywhere appropriate. </p> 765<p><b>Proposed resolution:</b></p> 766<p>Add at the beginning of 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> 767another get member for bool&, copied from the entry in 76822.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p> 769<hr> 770<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p> 771<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 772<p> 773In the definitions of codecvt<>::do_out and do_in, they are 774specified to return noconv if "no conversion is 775needed". This definition is too vague, and does not say 776normatively what is done with the buffers. 777</p> 778<p><b>Proposed resolution:</b></p> 779<p> 780Change the entry for noconv in the table under paragraph 4 in section 78122.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read: 782</p> 783<blockquote> 784 <p> 785<tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type, 786 and input sequence is identical to converted sequence.</p> 787</blockquote> 788<p>Change the Note in paragraph 2 to normative text as follows:</p> 789<blockquote> 790 <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the 791 same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>. 792 <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is 793 unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p> 794</blockquote> 795<hr> 796<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p> 797<b>Section:</b> 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 798<p>The synopsis for numpunct<>::do_thousands_sep, and the 799definition of numpunct<>::thousands_sep which calls it, specify 800that it returns a value of type char_type. Here it is erroneously 801described as returning a "string_type". </p> 802<p><b>Proposed resolution:</b></p> 803<p>In 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change 804"string_type" to "char_type". </p> 805<hr> 806<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p> 807<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 808<p>In the second table in the section, captioned "Required 809instantiations", the instantiations for codecvt_byname<> 810have been omitted. These are necessary to allow users to construct a 811locale by name from facets. </p> 812<p><b>Proposed resolution:</b></p> 813<p>Add in 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned 814"Required instantiations", in the category "ctype" 815the lines </p> 816 817<blockquote> 818 <pre>codecvt_byname<char,char,mbstate_t>, 819codecvt_byname<wchar_t,char,mbstate_t> </pre> 820</blockquote> 821<hr> 822<a name="22"><h3>22. Member open vs. flags</h3></a><p> 823<b>Section:</b> 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 824<p>The description of basic_istream<>::open leaves unanswered questions about how it 825responds to or changes flags in the error status for the stream. A strict reading 826indicates that it ignores the bits and does not change them, which confuses users who do 827not expect eofbit and failbit to remain set after a successful open. There are three 828reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit 829and eofbit on call to open(). </p> 830<p><b>Proposed resolution:</b></p> 831<p>In 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote: 832</p> 833 834<blockquote> 835 <p>A successful open does not change the error state.</p> 836</blockquote> 837<p><b>Rationale:</b></p> 838<p>This may seem surprising to some users, but it's just an instance 839of a general rule: error flags are never cleared by the 840implementation. The only way error flags are are ever cleared is if 841the user explicitly clears them by hand.</p> 842 843<p>The LWG believed that preserving this general rule was 844important enough so that an exception shouldn't be made just for this 845one case. The resolution of this issue clarifies what the LWG 846believes to have been the original intent.</p> 847 848<hr> 849<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p> 850<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 851<p>The description of codecvt<>::do_out and do_in mentions a 852symbol "do_convert" which is not defined in the 853standard. This is a leftover from an edit, and should be "do_in 854and do_out". </p> 855<p><b>Proposed resolution:</b></p> 856<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change 857"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in 858or do_out". </p> 859<hr> 860<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p> 861<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 862<p>In the description of operator<< applied to strings, the standard says that uses 863the smaller of os.width() and str.size(), to pad "as described in stage 3" 864elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p> 865<p><b>Proposed resolution:</b></p> 866<p>Change 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 4 from:<br> 867<br> 868 "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>; 869..."<br> 870<br> 871to: <br> 872<br> 873 "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>; 874..."</p> 875<hr> 876<a name="26"><h3>26. Bad sentry example</h3></a><p> 877<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 878<p>In paragraph 6, the code in the example: </p> 879 880<pre> template <class charT, class traits = char_traits<charT> > 881 basic_istream<charT,traits>::sentry( 882 basic_istream<charT,traits>& is, bool noskipws = false) { 883 ... 884 int_type c; 885 typedef ctype<charT> ctype_type; 886 const ctype_type& ctype = use_facet<ctype_type>(is.getloc()); 887 while ((c = is.rdbuf()->snextc()) != traits::eof()) { 888 if (ctype.is(ctype.space,c)==0) { 889 is.rdbuf()->sputbackc (c); 890 break; 891 } 892 } 893 ... 894 }</pre> 895 896<p>fails to demonstrate correct use of the facilities described. In 897particular, it fails to use traits operators, and specifies incorrect 898semantics. (E.g. it specifies skipping over the first character in the 899sequence without examining it.) </p> 900<p><b>Proposed resolution:</b></p> 901<p>Remove the example above from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> 902paragraph 6.</p> 903<p><b>Rationale:</b></p> 904<p>The originally proposed replacement code for the example was not 905correct. The LWG tried in Kona and again in Tokyo to correct it 906without success. In Tokyo, an implementor reported that actual working 907code ran over one page in length and was quite complicated. The LWG 908decided that it would be counter-productive to include such a lengthy 909example, which might well still contain errors.</p> 910<hr> 911<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p> 912<b>Section:</b> 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 913<p>The string::erase(iterator first, iterator last) is specified to return an element one 914place beyond the next element after the last one erased. E.g. for the string 915"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e', 916while 'd' has not been erased. </p> 917<p><b>Proposed resolution:</b></p> 918<p>In 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p> 919 920<blockquote> 921 <p>Returns: an iterator which points to the element immediately following _last_ prior to 922 the element being erased. </p> 923</blockquote> 924 925<p>to read </p> 926 927<blockquote> 928 <p>Returns: an iterator which points to the element pointed to by _last_ prior to the 929 other elements being erased. </p> 930</blockquote> 931<hr> 932<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p> 933<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 934<p>The description of the vector form of ctype<char>::is can be interpreted to mean 935something very different from what was intended. Paragraph 4 says </p> 936 937<blockquote> 938 <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to 939 table()[(unsigned char)*p]. </p> 940</blockquote> 941 942<p>This is intended to copy the value indexed from table()[] into the place identified in 943vec[]. </p> 944<p><b>Proposed resolution:</b></p> 945<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p> 946 947<blockquote> 948 <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low] 949 the value table()[(unsigned char)*p]. </p> 950</blockquote> 951<hr> 952<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p> 953<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 954<p>Sections 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention 955a function ios_base::init, which is not defined. Probably they mean 956basic_ios<>::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, 957paragraph 3. </p> 958<p><b>Proposed resolution:</b></p> 959<p>[R12: modified to include paragraph 5.]</p> 960 961<p>In 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p> 962 963<blockquote> 964 <p>ios_base::init </p> 965</blockquote> 966 967<p>to </p> 968 969<blockquote> 970 <p>basic_ios<char>::init </p> 971</blockquote> 972 973<p>Also, make a similar change in 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it 974should read </p> 975 976<blockquote> 977 <p>basic_ios<wchar_t>::init </p> 978</blockquote> 979<hr> 980<a name="30"><h3>30. Wrong header for LC_*</h3></a><p> 981<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 982<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>, 983where they are in fact defined elsewhere to appear in <clocale>. </p> 984<p><b>Proposed resolution:</b></p> 985<p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change 986"<cctype>" to read "<clocale>". </p> 987<hr> 988<a name="31"><h3>31. Immutable locale values</h3></a><p> 989<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 990<p>Paragraph 6, says "An instance of <tt>locale</tt> is 991<i>immutable</i>; once a facet reference is obtained from it, 992...". This has caused some confusion, because locale variables 993are manifestly assignable. </p> 994<p><b>Proposed resolution:</b></p> 995<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p> 996 997<blockquote> 998 <p>An instance of <tt>locale</tt> is immutable; once a facet 999 reference is obtained from it, that reference remains usable as long 1000 as the locale value itself exists.</p> 1001</blockquote> 1002 1003<p>with</p> 1004 1005<blockquote> 1006 <p>Once a facet reference is obtained from a locale object by 1007 calling use_facet<>, that reference remains usable, and the 1008 results from member functions of it may be cached and re-used, as 1009 long as some locale object refers to that facet.</p> 1010</blockquote> 1011<hr> 1012<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p> 1013<b>Section:</b> 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1014<p>The description of the required state before calling virtual member 1015basic_streambuf<>::pbackfail requirements is inconsistent with the conditions 1016described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it. 1017Specifically, the latter says it calls pbackfail if: </p> 1018 1019<p> traits::eq(c,gptr()[-1]) is false </p> 1020 1021<p>where pbackfail claims to require: </p> 1022 1023<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p> 1024 1025<p>It appears that the pbackfail description is wrong. </p> 1026<p><b>Proposed resolution:</b></p> 1027<p>In 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p> 1028 1029<blockquote> 1030 <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p> 1031</blockquote> 1032 1033<p>to </p> 1034 1035<blockquote> 1036 <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>" 1037 </p> 1038</blockquote> 1039<p><b>Rationale:</b></p> 1040<p>Note deliberate reordering of arguments for clarity in addition to the correction of 1041the argument value.</p> 1042<hr> 1043<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p> 1044<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1045<p>In the table defining the results from do_out and do_in, the specification for the 1046result <i>error</i> says </p> 1047 1048<blockquote> 1049 <p>encountered a from_type character it could not convert </p> 1050</blockquote> 1051 1052<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or 1053an internT for do_out. </p> 1054<p><b>Proposed resolution:</b></p> 1055<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition 1056in the table for the case of _error_ with </p> 1057 1058<blockquote> 1059 <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p> 1060</blockquote> 1061<hr> 1062<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p> 1063<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1064<p>In paragraph 19, Effects:, members truename() and falsename are used from facet 1065ctype<charT>, but it has no such members. Note that this is also a problem in 106622.2.2.1.2, addressed in (4). </p> 1067<p><b>Proposed resolution:</b></p> 1068<p>In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects: 1069clause for member put(...., bool), replace the initialization of the 1070string_type value s as follows: </p> 1071 1072<blockquote> 1073 <pre>const numpunct& np = use_facet<numpunct<charT> >(loc); 1074string_type s = val ? np.truename() : np.falsename(); </pre> 1075</blockquote> 1076<hr> 1077<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p> 1078<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1079<p>In 27.4.5.1 <a href="lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator 1080named "unitbuf". Unlike other manipulators, it's not listed 1081in synopsis. Similarly for "nounitbuf". </p> 1082<p><b>Proposed resolution:</b></p> 1083<p>Add to the synopsis for <ios> in 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after 1084the entry for "nouppercase", the prototypes: </p> 1085 1086<blockquote> 1087 <pre>ios_base& unitbuf(ios_base& str); 1088ios_base& nounitbuf(ios_base& str); </pre> 1089</blockquote> 1090<hr> 1091<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p> 1092<b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1093<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is 1094specified badly, so that an implementation which only keeps the last value stored appears 1095to conform. In particular, it says: </p> 1096 1097<p>The reference returned may become invalid after another call to the object's iword 1098member with a different index ... </p> 1099 1100<p>This is not idle speculation; at least one implementation was done this way. </p> 1101<p><b>Proposed resolution:</b></p> 1102<p>Add in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in 1103paragraph 4, replace the sentence: </p> 1104 1105<blockquote> 1106 <p>The reference returned may become invalid after another call to the object's iword 1107 [pword] member with a different index, after a call to its copyfmt member, or when the 1108 object is destroyed. </p> 1109</blockquote> 1110 1111<p>with: </p> 1112 1113<blockquote> 1114 <p>The reference returned is invalid after any other operations on the object. However, 1115 the value of the storage referred to is retained, so that until the next call to copyfmt, 1116 calling iword [pword] with the same index yields another reference to the same value. </p> 1117</blockquote> 1118 1119<p>substituting "iword" or "pword" as appropriate. </p> 1120<hr> 1121<a name="37"><h3>37. Leftover "global" reference</h3></a><p> 1122<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1123<p>In the overview of locale semantics, paragraph 4, is the sentence </p> 1124 1125<blockquote> 1126 <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws 1127 the standard exception bad_cast. </p> 1128</blockquote> 1129 1130<p>This is not supported by the definition of use_facet<>, and represents semantics 1131from an old draft. </p> 1132<p><b>Proposed resolution:</b></p> 1133<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized 1134expression </p> 1135 1136<blockquote> 1137 <p>(or, failing that, in the global locale) </p> 1138</blockquote> 1139<hr> 1140<a name="38"><h3>38. Facet definition incomplete</h3></a><p> 1141<b>Section:</b> 22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1142<p>It has been noticed by Esa Pulkkinen that the definition of 1143"facet" is incomplete. In particular, a class derived from 1144another facet, but which does not define a member <i>id</i>, cannot 1145safely serve as the argument <i>F</i> to use_facet<F>(loc), 1146because there is no guarantee that a reference to the facet instance 1147stored in <i>loc</i> is safely convertible to <i>F</i>. </p> 1148<p><b>Proposed resolution:</b></p> 1149<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which 1150reads: </p> 1151 1152<blockquote> 1153 <p>Get a reference to a facet of a locale. </p> 1154</blockquote> 1155 1156<p>with: </p> 1157 1158<blockquote> 1159 <p>Requires: <tt>Facet</tt> is a facet class whose definition 1160 contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p> 1161</blockquote> 1162 1163<p><i>[ 1164Kona: strike as overspecification the text "(not inherits)" 1165from the original resolution, which read "... whose definition 1166contains (not inherits) the public static member 1167<tt>id</tt>..." 1168]</i></p> 1169 1170<hr> 1171<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p> 1172<b>Section:</b> 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1173<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph 11743, the standard contains three lines of garbage text left over from a previous edit. </p> 1175 1176<blockquote> 1177 <pre>istreambuf_iterator<charT,traits> tmp = *this; 1178sbuf_->sbumpc(); 1179return(tmp); </pre> 1180</blockquote> 1181<p><b>Proposed resolution:</b></p> 1182<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the 1183end of paragraph 3. </p> 1184<hr> 1185<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p> 1186<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1187<p>Paragraph 3 of the locale examples is a description of part of an 1188implementation technique that has lost its referent, and doesn't mean 1189anything. </p> 1190<p><b>Proposed resolution:</b></p> 1191<p>Delete 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This 1192initialization/identification system depends...", or (at the 1193editor's option) replace it with a place-holder to keep the paragraph 1194numbering the same. </p> 1195<hr> 1196<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p> 1197<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1198<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit, 1199which may throw an exception". However, ios_base offers no 1200interface to set or to test badbit; those interfaces are defined in 1201basic_ios<>. </p> 1202<p><b>Proposed resolution:</b></p> 1203<p>Change the description in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in 1204paragraph 2, and also in paragraph 4, as follows. Replace</p> 1205 1206<blockquote> 1207 <p>If the function fails it sets badbit, which may throw an exception.</p> 1208</blockquote> 1209 1210<p>with</p> 1211 1212<blockquote> 1213 <p>If the function fails, and <tt>*this</tt> is a base sub-object of 1214 a <tt>basic_ios<></tt> object or sub-object, the effect is 1215 equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt> 1216 on the derived object (which may throw <tt>failure</tt>).</p> 1217</blockquote> 1218 1219<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to 1220setstate(badbit).]</i></p> 1221 1222<hr> 1223<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p> 1224<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 1225<p>The basic_string<> copy constructor: </p> 1226 1227<pre>basic_string(const basic_string& str, size_type pos = 0, 1228 size_type n = npos, const Allocator& a = Allocator()); </pre> 1229 1230<p>specifies an Allocator argument default value that is 1231counter-intuitive. The natural choice for a the allocator to copy from 1232is str.get_allocator(). Though this cannot be expressed in 1233default-argument notation, overloading suffices. </p> 1234 1235<p>Alternatively, the other containers in Clause 23 (deque, list, 1236vector) do not have this form of constructor, so it is inconsistent, 1237and an evident source of confusion, for basic_string<> to have 1238it, so it might better be removed. </p> 1239<p><b>Proposed resolution:</b></p> 1240<p> In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy 1241constructor as follows: </p> 1242 1243<blockquote> 1244 <pre>basic_string(const basic_string& str); 1245basic_string(const basic_string& str, size_type pos, size_type n = npos, 1246 const Allocator& a = Allocator());</pre> 1247</blockquote> 1248 1249<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration 1250as above. Add to paragraph 5, Effects:</p> 1251 1252<blockquote> 1253 <p>In the first form, the Allocator value used is copied from 1254 <tt>str.get_allocator()</tt>.</p> 1255</blockquote> 1256<p><b>Rationale:</b></p> 1257<p>The LWG believes the constructor is actually broken, rather than 1258just an unfortunate design choice.</p> 1259 1260<p>The LWG considered two other possible resolutions:</p> 1261 1262<p>A. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy 1263constructor as follows:</p> 1264 1265<blockquote> 1266 <pre>basic_string(const basic_string& str, size_type pos = 0, 1267 size_type n = npos); 1268basic_string(const basic_string& str, size_type pos, 1269 size_type n, const Allocator& a); </pre> 1270</blockquote> 1271 1272<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration 1273as above. Add to paragraph 5, Effects: </p> 1274 1275<blockquote> 1276 <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the 1277 value <tt>str.get_allocator()</tt>. </p> 1278</blockquote> 1279 1280<p>B. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace 1281the declaration of the copy constructor as follows: </p> 1282 1283<blockquote> 1284 <pre>basic_string(const basic_string& str, size_type pos = 0, 1285 size_type n = npos); </pre> 1286</blockquote> 1287 1288<p>The proposed resolution reflects the original intent of the LWG. It 1289was also noted by Pete Becker that this fix "will cause 1290a small amount of existing code to now work correctly."</p> 1291 1292<p><i>[ 1293Kona: issue editing snafu fixed - the proposed resolution now correctly 1294reflects the LWG consensus. 1295]</i></p> 1296<hr> 1297<a name="46"><h3>46. Minor Annex D errors</h3></a><p> 1298<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p> 1299<p>See lib-6522 and edit-814.</p> 1300<p><b>Proposed resolution:</b></p> 1301<p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of 1302basic_streambuf<char>) from:</p> 1303 1304<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre> 1305 1306<p>to:</p> 1307 1308<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre> 1309 1310<p>In D.7.4 <a href="future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after 1311int_type:</p> 1312 1313<pre> namespace std { 1314 class strstream 1315 : public basic_iostream<char> { 1316 public: 1317 // Types 1318 typedef char char_type; 1319 typedef typename char_traits<char>::int_type int_type 1320 typedef typename char_traits<char>::pos_type pos_type;</pre> 1321<hr> 1322<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p> 1323<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p> 1324<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That 1325section has two RETURNS clauses, and they make no sense as 1326stated. They make perfect sense, though, if you swap them. Am I 1327correct in thinking that paragraphs 2 and 4 just got mixed up by 1328accident?</p> 1329<p><b>Proposed resolution:</b></p> 1330<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p> 1331<hr> 1332<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p> 1333<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p> 1334<p>27.4.2.1.1, paragraph 2, says that class failure initializes the 1335base class, exception, with exception(msg). Class exception (see 133618.6.1) has no such constructor.</p> 1337<p><b>Proposed resolution:</b></p> 1338<p>Replace 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p> 1339 1340<blockquote> 1341 <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p> 1342</blockquote> 1343<hr> 1344<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p> 1345<b>Section:</b> 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p> 1346<p>Two problems</p> 1347 1348<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) 1349returns. Does it return f, or does it return the previous 1350synchronization state? My guess is the latter, but the standard 1351doesn't say so.</p> 1352 1353<p>(2) 27.4.2.4 doesn't say what it means for streams to be 1354synchronized with stdio. Again, of course, I can make some 1355guesses. (And I'm unhappy about the performance implications of those 1356guesses, but that's another matter.)</p> 1357<p><b>Proposed resolution:</b></p> 1358<p>Change the following sentence in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a> 1359returns clause from:</p> 1360 1361<blockquote> 1362 <p> 1363<tt>true</tt> if the standard iostream objects (27.3) are 1364 synchronized and otherwise returns <tt>false</tt>.</p> 1365</blockquote> 1366 1367<p>to:</p> 1368 1369<blockquote> 1370 <p> 1371<tt>true</tt> if the previous state of the standard iostream 1372 objects (27.3) was synchronized and otherwise returns 1373 <tt>false</tt>.</p> 1374</blockquote> 1375 1376<p>Add the following immediately after 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, 1377paragraph 2:</p> 1378 1379<blockquote> 1380<p>When a standard iostream object str is <i>synchronized</i> with a 1381standard stdio stream f, the effect of inserting a character c by</p> 1382<pre> 1383 fputc(f, c); 1384</pre> 1385 1386<p>is the same as the effect of</p> 1387<pre> 1388 str.rdbuf()->sputc(c); 1389</pre> 1390 1391<p>for any sequence of characters; the effect of extracting a 1392character c by</p> 1393<pre> 1394 c = fgetc(f); 1395</pre> 1396 1397<p>is the same as the effect of:</p> 1398<pre> 1399 c = str.rdbuf()->sbumpc(c); 1400</pre> 1401 1402<p>for any sequences of characters; and the effect of pushing 1403back a character c by</p> 1404<pre> 1405 ungetc(c, f); 1406</pre> 1407 1408<p>is the same as the effect of</p> 1409<pre> 1410 str.rdbuf()->sputbackc(c); 1411</pre> 1412 1413<p>for any sequence of characters. [<i>Footnote</i>: This implies 1414that operations on a standard iostream object can be mixed arbitrarily 1415with operations on the corresponding stdio stream. In practical 1416terms, synchronization usually means that a standard iostream object 1417and a standard stdio object share a buffer. <i>--End Footnote</i>]</p> 1418</blockquote> 1419 1420<p><i>[pre-Copenhagen: PJP and Matt contributed the definition 1421of "synchronization"]</i></p> 1422 1423<p><i>[post-Copenhagen: proposed resolution was revised slightly: 1424text was added in the non-normative footnote to say that operations 1425on the two streams can be mixed arbitrarily.]</i></p> 1426<hr> 1427<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p> 1428<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p> 1429<p>As written, ios_base has a copy constructor and an assignment 1430operator. (Nothing in the standard says it doesn't have one, and all 1431classes have copy constructors and assignment operators unless you 1432take specific steps to avoid them.) However, nothing in 27.4.2 says 1433what the copy constructor and assignment operator do. </p> 1434 1435<p>My guess is that this was an oversight, that ios_base is, like 1436basic_ios, not supposed to have a copy constructor or an assignment 1437operator.</p> 1438 1439<p> 1440Jerry Schwarz comments: Yes, its an oversight, but in the opposite 1441sense to what you're suggesting. At one point there was a definite 1442intention that you could copy ios_base. It's an easy way to save the 1443entire state of a stream for future use. As you note, to carry out 1444that intention would have required a explicit description of the 1445semantics (e.g. what happens to the iarray and parray stuff). 1446</p> 1447<p><b>Proposed resolution:</b></p> 1448<p>In 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy 1449constructor and operator= members as being private.</p> 1450<p><b>Rationale:</b></p> 1451<p>The LWG believes the difficulty of specifying correct semantics 1452outweighs any benefit of allowing ios_base objects to be copyable.</p> 1453<hr> 1454<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p> 1455<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p> 1456<p>The std::sort algorithm can in general only sort a given sequence 1457by moving around values. The list<>::sort() member on the other 1458hand could move around values or just update internal pointers. Either 1459method can leave iterators into the list<> dereferencable, but 1460they would point to different things. </p> 1461 1462<p>Does the FDIS mandate anywhere which method should be used for 1463list<>::sort()?</p> 1464 1465<p>Matt Austern comments:</p> 1466 1467<p>I think you've found an omission in the standard. </p> 1468 1469<p>The library working group discussed this point, and there was 1470supposed to be a general requirement saying that list, set, map, 1471multiset, and multimap may not invalidate iterators, or change the 1472values that iterators point to, except when an operation does it 1473explicitly. So, for example, insert() doesn't invalidate any iterators 1474and erase() and remove() only invalidate iterators pointing to the 1475elements that are being erased. </p> 1476 1477<p>I looked for that general requirement in the FDIS, and, while I 1478found a limited form of it for the sorted associative containers, I 1479didn't find it for list. It looks like it just got omitted. </p> 1480 1481<p>The intention, though, is that list<>::sort does not 1482invalidate any iterators and does not change the values that any 1483iterator points to. There would be no reason to have the member 1484function otherwise.</p> 1485<p><b>Proposed resolution:</b></p> 1486<p>Add a new paragraph at the end of 23.1:</p> 1487 1488<blockquote> 1489 <p>Unless otherwise specified (either explicitly or by defining a function in terms of 1490 other functions), invoking a container member function or passing a container as an 1491 argument to a library function shall not invalidate iterators to, or change the values of, 1492 objects within that container. </p> 1493</blockquote> 1494<p><b>Rationale:</b></p> 1495<p>This was US issue CD2-23-011; it was accepted in London but the 1496change was not made due to an editing oversight. The wording in the 1497proposed resolution below is somewhat updated from CD2-23-011, 1498particularly the addition of the phrase "or change the values 1499of"</p> 1500<hr> 1501<a name="52"><h3>52. Small I/O problems</h3></a><p> 1502<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p> 1503<p>First, 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious: 1504it should be titled "basic_ios<>() effects", not 1505"ios_base() effects". </p> 1506 1507<p>[The second item is a duplicate; see issue <a href="lwg-closed.html#6">6</a> for 1508resolution.]</p> 1509 1510<p>Second, 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple 1511different things wrong with it, some of which I've already discussed 1512with Jerry, but the most obvious mechanical sort of error is that it 1513uses expressions like P(i) and p(i), without ever defining what sort 1514of thing "i" is. 1515</p> 1516 1517<p>(The other problem is that it requires support for streampos 1518arithmetic. This is impossible on some systems, i.e. ones where file 1519position is a complicated structure rather than just a number. Jerry 1520tells me that the intention was to require syntactic support for 1521streampos arithmetic, but that it wasn't actually supposed to do 1522anything meaningful except on platforms, like Unix, where genuine 1523arithmetic is possible.) </p> 1524<p><b>Proposed resolution:</b></p> 1525<p>Change 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from 1526"ios_base() effects" to "basic_ios<>() 1527effects". </p> 1528<hr> 1529<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p> 1530<b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p> 1531<p>There's nothing in 27.4.4 saying what basic_ios's destructor does. 1532The important question is whether basic_ios::~basic_ios() destroys 1533rdbuf().</p> 1534<p><b>Proposed resolution:</b></p> 1535<p>Add after 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p> 1536 1537<blockquote> 1538 <p><tt>virtual ~basic_ios();</tt></p> 1539 <p> 1540<b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p> 1541</blockquote> 1542<p><b>Rationale:</b></p> 1543<p>The LWG reviewed the additional question of whether or not 1544<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is 1545clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6. This issue was reviewed at length 1546by the LWG, which removed from the original proposed resolution a 1547footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set 1548<tt>badbit</tt>".</p> 1549<hr> 1550<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p> 1551<b>Section:</b> 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p> 1552<p>The class synopsis for basic_streambuf shows a (virtual) 1553destructor, but the standard doesn't say what that destructor does. My 1554assumption is that it does nothing, but the standard should say so 1555explicitly. </p> 1556<p><b>Proposed resolution:</b></p> 1557<p>Add after 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p> 1558 1559<blockquote> 1560 <p><tt>virtual ~basic_streambuf();</tt></p> 1561 <p> 1562<b>Effects</b>: None.</p> 1563</blockquote> 1564<hr> 1565<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p> 1566<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p> 1567<p>Several member functions in clause 27 are defined in certain 1568circumstances to return an "invalid stream position", a term 1569that is defined nowhere in the standard. Two places (27.5.2.4.2, 1570paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to 1571a definition in _lib.iostreams.definitions_, a nonexistent 1572section. </p> 1573 1574<p>I suspect that the invalid stream position is just supposed to be 1575pos_type(-1). Probably best to say explicitly in (for example) 157627.5.2.4.2 that the return value is pos_type(-1), rather than to use 1577the term "invalid stream position", define that term 1578somewhere, and then put in a cross-reference. </p> 1579 1580<p>The phrase "invalid stream position" appears ten times in 1581the C++ Standard. In seven places it refers to a return value, and it 1582should be changed. In three places it refers to an argument, and it 1583should not be changed. Here are the three places where "invalid 1584stream position" should not be changed:</p> 1585 1586<blockquote> 1587 <p>27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br> 1588 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br> 1589 D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17 1590 </p> 1591</blockquote> 1592<p><b>Proposed resolution:</b></p> 1593<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an 1594object of class pos_type that stores an invalid stream position 1595(_lib.iostreams.definitions_)" to "Returns 1596<tt>pos_type(off_type(-1))</tt>". 1597</p> 1598 1599<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns 1600an object of class pos_type that stores an invalid stream 1601position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p> 1602 1603<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object 1604stores an invalid stream position" to "the return value is 1605<tt>pos_type(off_type(-1))</tt>". </p> 1606 1607<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an 1608invalid stream position (27.4.3)" to "returns 1609<tt>pos_type(off_type(-1))</tt>" </p> 1610 1611<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise 1612returns an invalid stream position (_lib.iostreams.definitions_)" 1613to "Otherwise returns <tt>pos_type(off_type(-1))</tt>" 1614</p> 1615 1616<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object 1617stores an invalid stream position" to "the return value is 1618<tt>pos_type(off_type(-1))</tt>" </p> 1619 1620<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object 1621stores an invalid stream position" to "the return value is 1622<tt>pos_type(off_type(-1))</tt>"</p> 1623<hr> 1624<a name="56"><h3>56. Showmanyc's return type</h3></a><p> 1625<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p> 1626<p>The class summary for basic_streambuf<>, in 27.5.2, says that 1627showmanyc has return type int. However, 27.5.2.4.3 says that its 1628return type is streamsize. </p> 1629<p><b>Proposed resolution:</b></p> 1630<p>Change <tt>showmanyc</tt>'s return type in the 163127.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p> 1632<hr> 1633<a name="57"><h3>57. Mistake in char_traits</h3></a><p> 1634<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p> 1635<p>21.1.3.2, paragraph 3, says "The types streampos and 1636wstreampos may be different if the implementation supports no shift 1637encoding in narrow-oriented iostreams but supports one or more shift 1638encodings in wide-oriented streams". </p> 1639 1640<p>That's wrong: the two are the same type. The <iosfwd> summary 1641in 27.2 says that streampos and wstreampos are, respectively, synonyms 1642for fpos<char_traits<char>::state_type> and 1643fpos<char_traits<wchar_t>::state_type>, and, flipping back 1644to clause 21, we see in 21.1.3.1 and 21.1.3.2 that 1645char_traits<char>::state_type and 1646char_traits<wchar_t>::state_type must both be mbstate_t. </p> 1647<p><b>Proposed resolution:</b></p> 1648<p>Remove the sentence in 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which 1649begins "The types streampos and wstreampos may be 1650different..." . </p> 1651<hr> 1652<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p> 1653<b>Section:</b> 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p> 1654<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the 1655next pointer for the input sequence by n." </p> 1656 1657<p>The straightforward interpretation is that it is just gptr() += 1658n. An alternative interpretation, though, is that it behaves as if it 1659calls sbumpc n times. (The issue, of course, is whether it might ever 1660call underflow.) There is a similar ambiguity in the case of 1661pbump. </p> 1662 1663<p>(The "classic" AT&T implementation used the 1664former interpretation.)</p> 1665<p><b>Proposed resolution:</b></p> 1666<p>Change 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p> 1667 1668<blockquote> 1669 <p>Effects: Advances the next pointer for the input sequence by n.</p> 1670</blockquote> 1671 1672<p>to:</p> 1673 1674<blockquote> 1675 <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p> 1676</blockquote> 1677 1678<p>Make the same change to 27.5.2.3.2 <a href="lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump 1679effects.</p> 1680<hr> 1681<a name="60"><h3>60. What is a formatted input function?</h3></a><p> 1682<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p> 1683<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all 1684formatted input functions. Some of the functions defined in section 168527.6.1.2 explicitly say that those requirements apply ("Behaves 1686like a formatted input member (as described in 27.6.1.2.1)"), but 1687others don't. The question: is 27.6.1.2.1 supposed to apply to 1688everything in 27.6.1.2, or only to those member functions that 1689explicitly say "behaves like a formatted input member"? Or 1690to put it differently: are we to assume that everything that appears 1691in a section called "Formatted input functions" really is a 1692formatted input function? I assume that 27.6.1.2.1 is intended to 1693apply to the arithmetic extractors (27.6.1.2.2), but I assume that it 1694is not intended to apply to extractors like </p> 1695 1696<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre> 1697 1698<p>and </p> 1699 1700<pre> basic_istream& operator>>(basic_streammbuf*);</pre> 1701 1702<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted 1703output. </p> 1704 1705<p>Comments from Judy Ward: It seems like the problem is that the 1706basic_istream and basic_ostream operator <<()'s that are used 1707for the manipulators and streambuf* are in the wrong section and 1708should have their own separate section or be modified to make it clear 1709that the "Common requirements" listed in section 27.6.1.2.1 1710(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not 1711apply to them. </p> 1712 1713<p>Additional comments from Dietmar Kühl: It appears to be somewhat 1714nonsensical to consider the functions defined in 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input 1715function" but since these functions are defined in a section 1716labeled "Formatted input functions" it is unclear to me 1717whether these operators are considered formatted input functions which 1718have to conform to the "common requirements" from 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not 1719just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is 1720set (... but setting <tt>noskipws</tt> using the manipulator syntax 1721would also skip whitespace :-)</p> <p>It is not clear which functions 1722are to be considered unformatted input functions. As written, it seems 1723that all functions in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input 1724functions. However, it does not really make much sense to construct a 1725sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is 1726unclear what happens to the <tt>gcount()</tt> if 1727eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or 1728<tt>sync()</tt> is called: These functions don't extract characters, 1729some of them even "unextract" a character. Should this still 1730be reflected in <tt>gcount()</tt>? Of course, it could be read as if 1731after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> 1732(the last unformatted input function, <tt>gcount()</tt>, didn't 1733extract any character) and after a call to <tt>putback()</tt> 1734<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input 1735function <tt>putback()</tt> did "extract" back into the 1736stream). Correspondingly for <tt>unget()</tt>. Is this what is 1737intended? If so, this should be clarified. Otherwise, a corresponding 1738clarification should be used.</p> 1739<p><b>Proposed resolution:</b></p> 1740<p> 1741In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1. 1742Change the beginning of the second sentence from "The conversion 1743occurs" to "These extractors behave as formatted input functions (as 1744described in 27.6.1.2.1). After a sentry object is constructed, 1745the conversion occurs" 1746</p> 1747 1748<p> 1749In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1. 1750Add an effects clause. "Effects: None. This extractor does 1751not behave as a formatted input function (as described in 175227.6.1.2.1). 1753</p> 1754 1755<p> 1756In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the 1757effects clause to "Effects: Calls pf(*this). This extractor does not 1758behave as a formatted input function (as described in 27.6.1.2.1). 1759</p> 1760 1761<p> 1762In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the 1763effects clause to "Effects: Calls pf(*this). This extractor does not 1764behave as a formatted input function (as described in 27.6.1.2.1). 1765</p> 1766 1767<p> 1768In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the 1769first two sentences from "If sb is null, calls setstate(failbit), 1770which may throw ios_base::failure (27.4.4.3). Extracts characters 1771from *this..." to "Behaves as a formatted input function (as described 1772in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may 1773throw ios_base::failure (27.4.4.3). After a sentry object is 1774constructed, extracts characters from *this...". 1775</p> 1776 1777<p> 1778In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an 1779effects clause. "Effects: none. This member function does not behave 1780as an unformatted input function (as described in 27.6.1.3, paragraph 1)." 1781</p> 1782 1783<p> 1784In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the 1785beginning of the first sentence of the effects clause from "Extracts a 1786character" to "Behaves as an unformatted input function (as described 1787in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a 1788character" 1789</p> 1790 1791<p> 1792In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the 1793beginning of the first sentence of the effects clause from "Extracts a 1794character" to "Behaves as an unformatted input function (as described 1795in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a 1796character" 1797</p> 1798 1799<p> 1800In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the 1801beginning of the first sentence of the effects clause from "Extracts 1802characters" to "Behaves as an unformatted input function (as described 1803in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts 1804characters" 1805</p> 1806 1807<p> 1808[No change needed in paragraph 10, because it refers to paragraph 7.] 1809</p> 1810 1811<p> 1812In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the 1813beginning of the first sentence of the effects clause from "Extracts 1814characters" to "Behaves as an unformatted input function (as described 1815in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts 1816characters" 1817</p> 1818 1819<p> 1820[No change needed in paragraph 15.] 1821</p> 1822 1823<p> 1824In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the 1825beginning of the first sentence of the effects clause from "Extracts 1826characters" to "Behaves as an unformatted input function (as described 1827in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts 1828characters" 1829</p> 1830 1831<p> 1832[No change needed in paragraph 23.] 1833</p> 1834 1835<p> 1836In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the 1837beginning of the first sentence of the effects clause from "Extracts 1838characters" to "Behaves as an unformatted input function (as described 1839in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts 1840characters" 1841</p> 1842 1843<p> 1844In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an 1845Effects clause: "Effects: Behaves as an unformatted input function (as 1846described in 27.6.1.3, paragraph 1). After constructing a sentry 1847object, reads but does not extract the current input character." 1848</p> 1849 1850<p> 1851In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the 1852first sentence of the Effects clause from "If !good() calls" to 1853Behaves as an unformatted input function (as described in 27.6.1.3, 1854paragraph 1). After constructing a sentry object, if !good() calls" 1855</p> 1856 1857<p> 1858In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the 1859first sentence of the Effects clause from "If !good() calls" to 1860"Behaves as an unformatted input function (as described in 27.6.1.3, 1861paragraph 1). After constructing a sentry object, if !good() calls" 1862</p> 1863 1864<p> 1865In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the 1866first sentence of the Effects clause from "If !good() calls..." to 1867"Behaves as an unformatted input function (as described in 27.6.1.3, 1868paragraph 1). After constructing a sentry object, if !good() 1869calls..." Add a new sentence to the end of the Effects clause: 1870"[Note: this function extracts no characters, so the value returned 1871by the next call to gcount() is 0.]" 1872</p> 1873 1874<p> 1875In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the 1876first sentence of the Effects clause from "If !good() calls" to 1877"Behaves as an unformatted input function (as described in 27.6.1.3, 1878paragraph 1). After constructing a sentry object, if !good() calls". 1879Add a new sentence to the end of the Effects clause: "[Note: this 1880function extracts no characters, so the value returned by the next 1881call to gcount() is 0.]" 1882</p> 1883 1884<p> 1885In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the 1886first sentence of the Effects clause from "If !rdbuf() is" to "Behaves 1887as an unformatted input function (as described in 27.6.1.3, paragraph 18881), except that it does not count the number of characters extracted 1889and does not affect the value returned by subsequent calls to 1890gcount(). After constructing a sentry object, if rdbuf() is" 1891</p> 1892 1893<p> 1894In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an 1895Effects clause: "Effects: Behaves as an unformatted input function (as 1896described in 27.6.1.3, paragraph 1), except that it does not count the 1897number of characters extracted and does not affect the value returned 1898by subsequent calls to gcount()." Change the first sentence of 1899paragraph 37 from "if fail()" to "after constructing a sentry object, 1900if fail()". 1901</p> 1902 1903<p> 1904In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the 1905first sentence of the Effects clause from "If fail()" to "Behaves 1906as an unformatted input function (as described in 27.6.1.3, paragraph 19071), except that it does not count the number of characters extracted 1908and does not affect the value returned by subsequent calls to 1909gcount(). After constructing a sentry object, if fail() 1910</p> 1911 1912<p> 1913In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the 1914first sentence of the Effects clause from "If fail()" to "Behaves 1915as an unformatted input function (as described in 27.6.1.3, paragraph 19161), except that it does not count the number of characters extracted 1917and does not affect the value returned by subsequent calls to 1918gcount(). After constructing a sentry object, if fail() 1919</p> 1920 1921<p> 1922In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change 1923the beginning of the third sentence from "The formatting conversion" 1924to "These extractors behave as formatted output functions (as 1925described in 27.6.2.5.1). After the sentry object is constructed, the 1926conversion occurs". 1927</p> 1928 1929<p> 1930In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an 1931effects clause: "Effects: None. Does not behave as a formatted output 1932function (as described in 27.6.2.5.1).". 1933</p> 1934 1935<p> 1936In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the 1937effects clause to "Effects: calls pf(*this). This extractor does not 1938behave as a formatted output function (as described in 27.6.2.5.1).". 1939</p> 1940 1941<p> 1942In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the 1943effects clause to "Effects: calls pf(*this). This extractor does not 1944behave as a formatted output function (as described in 27.6.2.5.1).". 1945</p> 1946 1947<p> 1948In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first 1949sentence from "If sb" to "Behaves as a formatted output function (as 1950described in 27.6.2.5.1). After the sentry object is constructed, if 1951sb". 1952</p> 1953 1954<p> 1955In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first 1956sentence from "Inserts the character" to "Behaves as an unformatted 1957output function (as described in 27.6.2.6, paragraph 1). After 1958constructing a sentry object, inserts the character". 1959</p> 1960 1961<p> 1962In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first 1963sentence from "Obtains characters" to "Behaves as an unformatted 1964output function (as described in 27.6.2.6, paragraph 1). After 1965constructing a sentry object, obtains characters". 1966</p> 1967 1968<p> 1969In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new 1970sentence at the end of the paragraph: "Does not behave as an 1971unformatted output function (as described in 27.6.2.6, paragraph 1)." 1972</p> 1973<p><b>Rationale:</b></p> 1974<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60, 1975by Judy Ward and Matt Austern. This proposed resolution is section 1976VI of that paper.</p> 1977<hr> 1978<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p> 1979<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p> 1980<p>The introduction to the section on unformatted input (27.6.1.3) 1981says that every unformatted input function catches all exceptions that 1982were thrown during input, sets badbit, and then conditionally rethrows 1983the exception. That seems clear enough. Several of the specific 1984functions, however, such as get() and read(), are documented in some 1985circumstances as setting eofbit and/or failbit. (The standard notes, 1986correctly, that setting eofbit or failbit can sometimes result in an 1987exception being thrown.) The question: if one of these functions 1988throws an exception triggered by setting failbit, is this an exception 1989"thrown during input" and hence covered by 27.6.1.3, or does 199027.6.1.3 only refer to a limited class of exceptions? Just to make 1991this concrete, suppose you have the following snippet. </p> 1992 1993<pre> 1994 char buffer[N]; 1995 istream is; 1996 ... 1997 is.exceptions(istream::failbit); // Throw on failbit but not on badbit. 1998 is.read(buffer, N);</pre> 1999 2000<p>Now suppose we reach EOF before we've read N characters. What 2001iostate bits can we expect to be set, and what exception (if any) will 2002be thrown? </p> 2003<p><b>Proposed resolution:</b></p> 2004<p> 2005In 27.6.1.3, paragraph 1, after the sentence that begins 2006"If an exception is thrown...", add the following 2007parenthetical comment: "(Exceptions thrown from 2008<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)" 2009</p> 2010<p><b>Rationale:</b></p> 2011<p>The LWG looked to two alternative wordings, and choose the proposed 2012resolution as better standardese.</p> 2013<hr> 2014<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p> 2015<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p> 2016<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it 2017"calls rdbuf()->pubsync() and, if that function returns -1 2018... returns traits::eof()." </p> 2019 2020<p>That looks suspicious, because traits::eof() is of type 2021traits::int_type while the return type of sync() is int. </p> 2022<p><b>Proposed resolution:</b></p> 2023<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns 2024<tt>traits::eof()</tt>" to "returns <tt>-1</tt>". 2025</p> 2026<hr> 2027<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p> 2028<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p> 2029<p>Clause 27 details an exception-handling policy for formatted input, 2030unformatted input, and formatted output. It says nothing for 2031unformatted output (27.6.2.6). 27.6.2.6 should either include the same 2032kind of exception-handling policy as in the other three places, or 2033else it should have a footnote saying that the omission is 2034deliberate. </p> 2035<p><b>Proposed resolution:</b></p> 2036<p> 2037In 27.6.2.6, paragraph 1, replace the last sentence ("In any 2038case, the unformatted output function ends by destroying the sentry 2039object, then returning the value specified for the formatted output 2040function.") with the following text: 2041</p> 2042<blockquote> 2043If an exception is thrown during output, then <tt>ios::badbit</tt> is 2044turned on [Footnote: without causing an <tt>ios::failure</tt> to be 2045thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() & 2046badbit) != 0</tt> then the exception is rethrown. In any case, the 2047unformatted output function ends by destroying the sentry object, 2048then, if no exception was thrown, returning the value specified for 2049the formatted output function. 2050</blockquote> 2051<p><b>Rationale:</b></p> 2052<p> 2053This exception-handling policy is consistent with that of formatted 2054input, unformatted input, and formatted output. 2055</p> 2056<hr> 2057<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt> 2058</h3></a><p> 2059<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p> 2060<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two 2061different ways, depending on whether the second sentence is read as an 2062elaboration of the first. </p> 2063<p><b>Proposed resolution:</b></p> 2064<p>Replace 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins 2065"If the function inserts no characters ..." with:</p> 2066 2067<blockquote> 2068 <p>If the function inserts no characters, it calls 2069 <tt>setstate(failbit)</tt>, which may throw 2070 <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters 2071 because it caught an exception thrown while extracting characters 2072 from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt> 2073 (27.4.4.3), then the caught exception is rethrown. </p> 2074</blockquote> 2075<hr> 2076<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p> 2077<b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p> 2078<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf 2079"Performs an operation that is defined separately for each class 2080derived from strstreambuf". This is obviously an incorrect 2081cut-and-paste from basic_streambuf. There are no classes derived from 2082strstreambuf. </p> 2083<p><b>Proposed resolution:</b></p> 2084<p>D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects 2085clause which currently says "Performs an operation that is 2086defined separately for each class derived from strstreambuf" 2087with:</p> 2088 2089<blockquote> 2090 <p> 2091<b>Effects</b>: implementation defined, except that 2092 <tt>setbuf(0,0)</tt> has no effect.</p> 2093</blockquote> 2094<hr> 2095<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p> 2096<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p> 2097<p>Extractors for char* (27.6.1.2.3) do not store a null character 2098after the extracted character sequence whereas the unformatted 2099functions like get() do. Why is this?</p> 2100 2101<p>Comment from Jerry Schwarz: There is apparently an editing 2102glitch. You'll notice that the last item of the list of what stops 2103extraction doesn't make any sense. It was supposed to be the line that 2104said a null is stored.</p> 2105<p><b>Proposed resolution:</b></p> 2106<p>27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list 2107item from:</p> 2108 2109<blockquote> 2110 A null byte (<tt>charT()</tt>) in the next position, which may be 2111 the first position if no characters were extracted. 2112</blockquote> 2113 2114<p>to become a new paragraph which reads:</p> 2115 2116<blockquote> 2117 Operator>> then stores a null byte (<tt>charT()</tt>) in the 2118 next position, which may be the first position if no characters were 2119 extracted. 2120</blockquote> 2121<hr> 2122<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p> 2123<b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p> 2124<p>The issue is this: Must the elements of a vector be in contiguous memory?</p> 2125 2126<p>(Please note that this is entirely separate from the question of 2127whether a vector iterator is required to be a pointer; the answer to 2128that question is clearly "no," as it would rule out 2129debugging implementations)</p> 2130<p><b>Proposed resolution:</b></p> 2131<p>Add the following text to the end of 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>, 2132paragraph 1. </p> 2133 2134<blockquote> 2135 <p>The elements of a vector are stored contiguously, meaning that if 2136 v is a <tt>vector<T, Allocator></tt> where T is some type 2137 other than <tt>bool</tt>, then it obeys the identity <tt>&v[n] 2138 == &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p> 2139</blockquote> 2140<p><b>Rationale:</b></p> 2141<p>The LWG feels that as a practical matter the answer is clearly 2142"yes". There was considerable discussion as to the best way 2143to express the concept of "contiguous", which is not 2144directly defined in the standard. Discussion included:</p> 2145 2146<ul> 2147 <li>An operational definition similar to the above proposed resolution is 2148 already used for valarray (26.3.2.3 <a href="lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li> 2149 <li>There is no need to explicitly consider a user-defined operator& 2150 because elements must be copyconstructible (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3) 2151 and copyconstructible (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies 2152 requirements for operator&.</li> 2153 <li>There is no issue of one-past-the-end because of language rules.</li> 2154</ul> 2155<hr> 2156<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p> 2157<b>Section:</b> 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p> 2158<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p> 2159 2160<p>uncaught_exception() doesn't have a throw specification.</p> 2161 2162<p>It is intentional ? Does it means that one should be prepared to 2163handle exceptions thrown from uncaught_exception() ?</p> 2164 2165<p>uncaught_exception() is called in exception handling contexts where 2166exception safety is very important.</p> 2167<p><b>Proposed resolution:</b></p> 2168<p>In 15.5.3 <a href="except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p> 2169<hr> 2170<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p> 2171<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p> 2172<p>The locale facet member <tt>time_get<>::do_get_monthname</tt> 2173is described in 22.2.5.1.2 <a href="lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments, 2174consistent with do_get_weekday and with its specified use by member 2175get_monthname. However, in the synopsis, it is specified instead with 2176four arguments. The missing argument is the "end" iterator 2177value.</p> 2178<p><b>Proposed resolution:</b></p> 2179<p>In 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to 2180the declaration of member do_monthname as follows:</p> 2181 2182<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&, 2183 ios_base::iostate& err, tm* t) const;</pre> 2184<hr> 2185<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt> 2186</h3></a><p> 2187<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p> 2188<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns" 2189clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced 2190parentheses and a spurious <b>n</b>.</p> 2191<p><b>Proposed resolution:</b></p> 2192<p>Replace 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the 2193following:</p> 2194 2195<blockquote> 2196 <b>Returns</b>: The maximum value that 2197 <tt>do_length(state, from, from_end, 1)</tt> can return for any 2198 valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value 2199 <tt>state</tt>. The specialization <tt>codecvt<char, char, 2200 mbstate_t>::do_max_length()</tt> returns 1. 2201</blockquote> 2202<hr> 2203<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p> 2204<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt 2205Austern <b>Date:</b> 18 Sep 1998</p> 2206<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5) 2207and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first 2208parameter of the member functions <tt>length</tt> and 2209<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member 2210function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2, 2211paragraph 9) say that the type is <tt>stateT&</tt>. Either the 2212synopsis or the summary must be changed. </p> 2213 2214<p>If (as I believe) the member function descriptions are correct, 2215then we must also add text saying how <tt>do_length</tt> changes its 2216<tt>stateT</tt> argument. </p> 2217<p><b>Proposed resolution:</b></p> 2218<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 2219change the <tt>stateT</tt> argument type on both member 2220<tt>length()</tt> and member <tt>do_length()</tt> from </p> 2221 2222<blockquote> 2223 <p><tt>const stateT&</tt></p> 2224</blockquote> 2225 2226<p>to</p> 2227 2228<blockquote> 2229 <p><tt>stateT&</tt></p> 2230</blockquote> 2231 2232<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member 2233<tt>do_length</tt> a paragraph:</p> 2234 2235<blockquote> 2236 <p>Effects: The effect on the <tt>state</tt> argument is ``as if'' 2237 it called <tt>do_in(state, from, from_end, from, to, to+max, 2238 to)</tt> for <tt>to</tt> pointing to a buffer of at least 2239 <tt>max</tt> elements.</p> 2240</blockquote> 2241<hr> 2242<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p> 2243<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Sep 1998</p> 2244<p>This issue concerns the requirements on classes derived from 2245<tt>codecvt</tt>, including user-defined classes. What are the 2246restrictions on the conversion from external characters 2247(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)? 2248Or, alternatively, what assumptions about <tt>codecvt</tt> facets can 2249the I/O library make? </p> 2250 2251<p>The question is whether it's possible to convert from internal 2252characters to external characters one internal character at a time, 2253and whether, given a valid sequence of external characters, it's 2254possible to pick off internal characters one at a time. Or, to put it 2255differently: given a sequence of external characters and the 2256corresponding sequence of internal characters, does a position in the 2257internal sequence correspond to some position in the external 2258sequence? </p> 2259 2260<p>To make this concrete, suppose that <tt>[first, last)</tt> is a 2261sequence of <i>M</i> external characters and that <tt>[ifirst, 2262ilast)</tt> is the corresponding sequence of <i>N</i> internal 2263characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>, 2264applied to <tt>[first, last)</tt>, yields <tt>[ifirst, 2265ilast)</tt>. Now the question: does there necessarily exist a 2266subsequence of external characters, <tt>[first, last_1)</tt>, such 2267that the corresponding sequence of internal characters is the single 2268character <tt>*ifirst</tt>? 2269</p> 2270 2271<p>(What a "no" answer would mean is that 2272<tt>my_encoding</tt> translates sequences only as blocks. There's a 2273sequence of <i>M</i> external characters that maps to a sequence of 2274<i>N</i> internal characters, but that external sequence has no 2275subsequence that maps to <i>N-1</i> internal characters.) </p> 2276 2277<p>Some of the wording in the standard, such as the description of 2278<tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, 2279paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be 2280possible to pick off internal characters one at a time from a sequence 2281of external characters. However, this is never explicitly stated one 2282way or the other. </p> 2283 2284<p>This issue seems (and is) quite technical, but it is important if 2285we expect users to provide their own encoding facets. This is an area 2286where the standard library calls user-supplied code, so a well-defined 2287set of requirements for the user-supplied code is crucial. Users must 2288be aware of the assumptions that the library makes. This issue affects 2289positioning operations on <tt>basic_filebuf</tt>, unbuffered input, 2290and several of <tt>codecvt</tt>'s member functions. </p> 2291<p><b>Proposed resolution:</b></p> 2292<p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p> 2293 2294<blockquote> 2295<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt> 2296(27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p> 2297<pre> 2298 do_out(state, from, from_end, from_next, to, to_lim, to_next) 2299</pre> 2300would return <tt>ok</tt>, where <tt>from != from_end</tt>, then 2301<pre> 2302 do_out(state, from, from + 1, from_next, to, to_end, to_next) 2303</pre> 2304must also return <tt>ok</tt>, and that if 2305<pre> 2306 do_in(state, from, from_end, from_next, to, to_lim, to_next) 2307</pre> 2308would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then 2309<pre> 2310 do_in(state, from, from_end, from_next, to, to + 1, to_next) 2311</pre> 2312<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this 2313means that <tt>basic_filebuf</tt> assumes that the mapping from 2314internal to external characters is 1 to N: a <tt>codecvt</tt> that is 2315used by <tt>basic_filebuf</tt> must be able to translate characters 2316one internal character at a time. <i>--End Footnote</i>]</p> 2317</blockquote> 2318 2319<p><i>[Redmond: Minor change in proposed resolution. Original 2320proposed resolution talked about "success", with a parenthetical 2321comment that success meant returning <tt>ok</tt>. New wording 2322removes all talk about "success", and just talks about the 2323return value.]</i></p> 2324 2325<p><b>Rationale:</b></p> 2326 2327 <p>The proposed resoluion says that conversions can be performed one 2328 internal character at a time. This rules out some encodings that 2329 would otherwise be legal. The alternative answer would mean there 2330 would be some internal positions that do not correspond to any 2331 external file position.</p> 2332 <p> 2333 An example of an encoding that this rules out is one where the 2334 <tt>internT</tt> and <tt>externT</tt> are of the same type, and 2335 where the internal sequence <tt>c1 c2</tt> corresponds to the 2336 external sequence <tt>c2 c1</tt>. 2337 </p> 2338 <p>It was generally agreed that <tt>basic_filebuf</tt> relies 2339 on this property: it was designed under the assumption that 2340 the external-to-internal mapping is N-to-1, and it is not clear 2341 that <tt>basic_filebuf</tt> is implementable without that 2342 restriction. 2343 </p> 2344 <p> 2345 The proposed resolution is expressed as a restriction on 2346 <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather 2347 than a blanket restriction on all <tt>codecvt</tt> facets, 2348 because <tt>basic_filebuf</tt> is the only other part of the 2349 library that uses <tt>codecvt</tt>. If a user wants to define 2350 a <tt>codecvt</tt> facet that implements a more general N-to-M 2351 mapping, there is no reason to prohibit it, so long as the user 2352 does not expect <tt>basic_filebuf</tt> to be able to use it. 2353 </p> 2354<hr> 2355<a name="78"><h3>78. Typo: event_call_back</h3></a><p> 2356<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2357<p>typo: event_call_back should be event_callback </p> 2358<p><b>Proposed resolution:</b></p> 2359<p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change 2360"event_call_back" to "event_callback". </p> 2361<hr> 2362<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p> 2363<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2364<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p> 2365<pre> template<class T> complex<T> polar(const T&, const T&); </pre> 2366 2367<p>In 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p> 2368<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> 2369 2370<p>Thus whether the second parameter is optional is not clear. </p> 2371<p><b>Proposed resolution:</b></p> 2372<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p> 2373<pre> template<class T> complex<T> polar(const T&, const T&);</pre> 2374 2375<p>to:</p> 2376<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> 2377<hr> 2378<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p> 2379<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2380<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for 2381class complex. This redundancy should be removed.</p> 2382<p><b>Proposed resolution:</b></p> 2383<p>Reduce redundancy according to the general style of the standard. </p> 2384<hr> 2385<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p> 2386<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2387<p>Many string member functions throw if size is getting or exceeding 2388npos. However, I wonder why they don't throw if size is getting or 2389exceeding max_size() instead of npos. May be npos is known at compile 2390time, while max_size() is known at runtime. However, what happens if 2391size exceeds max_size() but not npos, then? It seems the standard 2392lacks some clarifications here.</p> 2393<p><b>Proposed resolution:</b></p> 2394<p>After 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions 2395described in this clause...") add a new paragraph:</p> 2396 2397<blockquote> 2398 <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed 2399 <tt> max_size()</tt> then 2400 the operation throws <tt>length_error</tt>.</p> 2401</blockquote> 2402<p><b>Rationale:</b></p> 2403<p>The LWG believes length_error is the correct exception to throw.</p> 2404<hr> 2405<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p> 2406<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2407<p>The constructor from a range:</p> 2408 2409<pre>template<class InputIterator> 2410 basic_string(InputIterator begin, InputIterator end, 2411 const Allocator& a = Allocator());</pre> 2412 2413<p>lacks a throws clause. However, I would expect that it throws 2414according to the other constructors if the numbers of characters in 2415the range equals npos (or exceeds max_size(), see above). </p> 2416<p><b>Proposed resolution:</b></p> 2417<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for 2418constructors which say "Throws: length_error if n == 2419npos."</p> 2420<p><b>Rationale:</b></p> 2421<p>Throws clauses for length_error if n == npos are no longer needed 2422because they are subsumed by the general wording added by the 2423resolution for issue <a href="lwg-defects.html#83">83</a>.</p> 2424<hr> 2425<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p> 2426<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> 2427<p>The effect of operator >> for strings contain the following item:</p> 2428 2429<p> <tt>isspace(c,getloc())</tt> is true for the next available input 2430character c.</p> 2431 2432<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p> 2433<p><b>Proposed resolution:</b></p> 2434<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p> 2435 2436<blockquote> 2437 <p> 2438<tt>isspace(c,getloc())</tt> is true for the next available input character c.</p> 2439</blockquote> 2440 2441<p>with:</p> 2442 2443<blockquote> 2444 <p> 2445<tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p> 2446</blockquote> 2447<hr> 2448<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p> 2449<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> 2450<p>Set::iterator is described as implementation-defined with a 2451reference to the container requirement; the container requirement says 2452that const_iterator is an iterator pointing to const T and iterator an 2453iterator pointing to T.</p> 2454 2455<p>23.1.2 paragraph 2 implies that the keys should not be modified to 2456break the ordering of elements. But that is not clearly 2457specified. Especially considering that the current standard requires 2458that iterator for associative containers be different from 2459const_iterator. Set, for example, has the following: </p> 2460 2461<p><tt>typedef implementation defined iterator;<br> 2462 // See _lib.container.requirements_</tt></p> 2463 2464<p>23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing 2465to T (table 65). Disallowing user modification of keys by changing the 2466standard to require an iterator for associative container to be the 2467same as const_iterator would be overkill since that will unnecessarily 2468significantly restrict the usage of associative container. A class to 2469be used as elements of set, for example, can no longer be modified 2470easily without either redesigning the class (using mutable on fields 2471that have nothing to do with ordering), or using const_cast, which 2472defeats requiring iterator to be const_iterator. The proposed solution 2473goes in line with trusting user knows what he is doing. </p> 2474 2475<p> 2476<b>Other Options Evaluated:</b> </p> 2477 2478<p>Option A. In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after 2479first sentence, and before "In addition,...", add one line: 2480</p> 2481 2482<blockquote> 2483 <p>Modification of keys shall not change their strict weak ordering. </p> 2484</blockquote> 2485 2486<p>Option B. Add three new sentences to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p> 2487 2488<blockquote> 2489 <p>At the end of paragraph 5: "Keys in an associative container 2490 are immutable." At the end of paragraph 6: "For 2491 associative containers where the value type is the same as the key 2492 type, both <tt>iterator</tt> and <tt>const_iterator</tt> are 2493 constant iterators. It is unspecified whether or not 2494 <tt>iterator</tt> and <tt>const_iterator</tt> are the same 2495 type."</p> 2496</blockquote> 2497 2498<p>Option C. To 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which 2499currently reads:</p> 2500 2501<blockquote> 2502 <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the 2503 comparison and not the operator== on keys. That is, two keys k1 and k2 in the same 2504 container are considered to be equivalent if for the comparison object comp, comp(k1, k2) 2505 == false && comp(k2, k1) == false.</p> 2506</blockquote> 2507 2508<p> add the following:</p> 2509 2510<blockquote> 2511 <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same 2512 value whenever it is evaluated. [Note: If k2 is removed from the container and later 2513 reinserted, comp(k1, k2) must still return a consistent value but this value may be 2514 different than it was the first time k1 and k2 were in the same container. This is 2515 intended to allow usage like a string key that contains a filename, where comp compares 2516 file contents; if k2 is removed, the file is changed, and the same k2 (filename) is 2517 reinserted, comp(k1, k2) must again return a consistent value but this value may be 2518 different than it was the previous time k2 was in the container.]</p> 2519</blockquote> 2520<p><b>Proposed resolution:</b></p> 2521<p>Add the following to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at 2522the indicated location:</p> 2523 2524<blockquote> 2525 <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container, 2526 calling comp(k1, k2) shall always return the same 2527 value."</p> 2528 <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p> 2529 <p>At the end of paragraph 6: "For associative containers where the value type is the 2530 same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant 2531 iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> 2532 are the same type."</p> 2533</blockquote> 2534<p><b>Rationale:</b></p> 2535<p>Several arguments were advanced for and against allowing set elements to be 2536mutable as long as the ordering was not effected. The argument which swayed the 2537LWG was one of safety; if elements were mutable, there would be no compile-time 2538way to detect of a simple user oversight which caused ordering to be 2539modified. There was a report that this had actually happened in practice, 2540and had been painful to diagnose. If users need to modify elements, 2541it is possible to use mutable members or const_cast.</p> 2542 2543<p>Simply requiring that keys be immutable is not sufficient, because the comparison 2544object may indirectly (via pointers) operate on values outside of the keys.</p> 2545 2546<p> 2547The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted 2548to be different types to allow for potential future work in which some 2549member functions might be overloaded between the two types. No such 2550member functions exist now, and the LWG believes that user functionality 2551will not be impaired by permitting the two types to be the same. A 2552function that operates on both iterator types can be defined for 2553<tt>const_iterator</tt> alone, and can rely on the automatic 2554conversion from <tt>iterator</tt> to <tt>const_iterator</tt>. 2555</p> 2556 2557<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p> 2558<hr> 2559<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p> 2560<b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> 2561<p>This is the only place in the whole standard where the implementation has to document 2562something private.</p> 2563<p><b>Proposed resolution:</b></p> 2564<p> 2565Remove the comment which says "// remainder implementation defined" from: 2566</p> 2567 2568<ul> 2569 <li>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> 2570</li> 2571 <li>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> 2572</li> 2573 <li>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> 2574</li> 2575 <li>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> 2576</li> 2577</ul> 2578<hr> 2579<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p> 2580<b>Section:</b> 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> 2581<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of 2582exception::what() is left unspecified. This issue has implications 2583with exception safety of exception handling: some exceptions should 2584not throw bad_alloc.</p> 2585<p><b>Proposed resolution:</b></p> 2586<p>Add to 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes 2587clause) the sentence:</p> 2588 2589<blockquote> 2590 <p>The return value remains valid until the exception object from which it is obtained is 2591 destroyed or a non-const member function of the exception object is called.</p> 2592</blockquote> 2593<p><b>Rationale:</b></p> 2594<p>If an exception object has non-const members, they may be used 2595to set internal state that should affect the contents of the string 2596returned by <tt>what()</tt>. 2597</p> 2598<hr> 2599<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p> 2600<b>Section:</b> 20.3.6 <a href="lib-utilities.html#lib.binders"> [lib.binders]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p> 2601 2602<p>There are no versions of binders that apply to non-const elements 2603of a sequence. This makes examples like for_each() using bind2nd() on 2604page 521 of "The C++ Programming Language (3rd)" 2605non-conforming. Suitable versions of the binders need to be added.</p> 2606 2607<p>Further discussion from Nico:</p> 2608 2609<p>What is probably meant here is shown in the following example:</p> 2610 2611<pre>class Elem { 2612 public: 2613 void print (int i) const { } 2614 void modify (int i) { } 2615}; </pre> 2616<pre>int main() 2617{ 2618 vector<Elem> coll(2); 2619 for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK 2620 for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR 2621}</pre> 2622 2623<p>The error results from the fact that bind2nd() passes its first 2624argument (the argument of the sequence) as constant reference. See the 2625following typical implementation:</p> 2626 2627<blockquote> 2628 <pre>template <class Operation> 2629class binder2nd 2630 : public unary_function<typename Operation::first_argument_type, 2631 typename Operation::result_type> { 2632protected: 2633 Operation op; 2634 typename Operation::second_argument_type value; 2635public: 2636 binder2nd(const Operation& o, 2637 const typename Operation::second_argument_type& v) 2638 : op(o), value(v) {} </pre> 2639 <pre> typename Operation::result_type 2640 operator()(const typename Operation::first_argument_type& x) const { 2641 return op(x, value); 2642 } 2643};</pre> 2644</blockquote> 2645 2646<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p> 2647 2648<blockquote> 2649 <pre>template <class Operation> 2650class binder2nd 2651 : public unary_function<typename Operation::first_argument_type, 2652 typename Operation::result_type> { 2653protected: 2654 Operation op; 2655 typename Operation::second_argument_type value; 2656public: 2657 binder2nd(const Operation& o, 2658 const typename Operation::second_argument_type& v) 2659 : op(o), value(v) {} </pre> 2660 <pre> typename Operation::result_type 2661 operator()(const typename Operation::first_argument_type& x) const { 2662 return op(x, value); 2663 } 2664 typename Operation::result_type 2665 operator()(typename Operation::first_argument_type& x) const { 2666 return op(x, value); 2667 } 2668};</pre> 2669</blockquote> 2670<p><b>Proposed resolution:</b></p> 2671 2672<p> 2673<b>Howard believes there is a flaw</b> in this resolution. 2674See c++std-lib-9127. We may need to reopen this issue.</p> 2675 2676<p>In 20.3.6.1 <a href="lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p> 2677<blockquote> 2678 <p><tt>typename Operation::result_type<br> 2679 operator()(const typename Operation::second_argument_type& x) const;</tt></p> 2680</blockquote> 2681<p>insert:</p> 2682<blockquote> 2683 <p><tt>typename Operation::result_type<br> 2684 operator()(typename Operation::second_argument_type& x) const;</tt></p> 2685</blockquote> 2686<p>In 20.3.6.3 <a href="lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p> 2687<blockquote> 2688 <p><tt>typename Operation::result_type<br> 2689 operator()(const typename Operation::first_argument_type& x) const;</tt></p> 2690</blockquote> 2691<p>insert:</p> 2692<blockquote> 2693 <p><tt>typename Operation::result_type<br> 2694 operator()(typename Operation::first_argument_type& x) const;</tt></p> 2695</blockquote> 2696 2697<p><i>[Kona: The LWG discussed this at some length.It was agreed that 2698this is a mistake in the design, but there was no consensus on whether 2699it was a defect in the Standard. Straw vote: NAD - 5. Accept 2700proposed resolution - 3. Leave open - 6.]</i></p> 2701 2702<p><i>[Copenhagen: It was generally agreed that this was a defect. 2703Strap poll: NAD - 0. Accept proposed resolution - 10. 2704Leave open - 1.]</i></p> 2705 2706<hr> 2707<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p> 2708<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p> 2709<p>Member istreambuf_iterator<>::equal is not declared 2710"const", yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==, 2711which is const, calls it. This is contradictory. </p> 2712<p><b>Proposed resolution:</b></p> 2713<p>In 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also in 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>, 2714replace:</p> 2715 2716<blockquote> 2717 <pre>bool equal(istreambuf_iterator& b);</pre> 2718</blockquote> 2719 2720<p>with:</p> 2721 2722<blockquote> 2723 <pre>bool equal(const istreambuf_iterator& b) const;</pre> 2724</blockquote> 2725<hr> 2726<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p> 2727<b>Section:</b> 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p> 2728<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s 2729constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1) 2730reads "<i>s</i> is not null". However, <i>s</i> is a 2731reference, and references can't be null. </p> 2732<p><b>Proposed resolution:</b></p> 2733<p>In 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p> 2734 2735<p>Move the current paragraph 1, which reads "Requires: s is not 2736null.", from the first constructor to the second constructor.</p> 2737 2738<p>Insert a new paragraph 1 Requires clause for the first constructor 2739reading:</p> 2740 2741<blockquote> 2742 <p> 2743<b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p> 2744</blockquote> 2745<hr> 2746<a name="114"><h3>114. Placement forms example in error twice</h3></a><p> 2747<b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p> 2748<p>Section 18.4.1.3 contains the following example: </p> 2749 2750<pre>[Example: This can be useful for constructing an object at a known address: 2751 char place[sizeof(Something)]; 2752 Something* p = new (place) Something(); 2753 -end example]</pre> 2754 2755<p>First code line: "place" need not have any special alignment, and the 2756following constructor could fail due to misaligned data.</p> 2757 2758<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG 2759believes the () are correct.]</p> 2760 2761<p>Examples are not normative, but nevertheless should not show code that is invalid or 2762likely to fail.</p> 2763<p><b>Proposed resolution:</b></p> 2764<p>Replace the <u> first line of code</u> in the example in 276518.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with: 2766</p> 2767 2768<blockquote> 2769 <pre>void* place = operator new(sizeof(Something));</pre> 2770</blockquote> 2771<hr> 2772<a name="115"><h3>115. Typo in strstream constructors</h3></a><p> 2773<b>Section:</b> D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p> 2774<p>D.7.4.1 strstream constructors paragraph 2 says: </p> 2775 2776<blockquote> 2777 <p>Effects: Constructs an object of class strstream, initializing the base class with 2778 iostream(& sb) and initializing sb with one of the two constructors: </p> 2779 <p>- If mode&app==0, then s shall designate the first element of an array of n 2780 elements. The constructor is strstreambuf(s, n, s). </p> 2781 <p>- If mode&app==0, then s shall designate the first element of an array of n 2782 elements that contains an NTBS whose first element is designated by s. The constructor is 2783 strstreambuf(s, n, s+std::strlen(s)).</p> 2784</blockquote> 2785 2786<p>Notice the second condition is the same as the first. I think the second condition 2787should be "If mode&app==app", or "mode&app!=0", meaning that 2788the append bit is set.</p> 2789<p><b>Proposed resolution:</b></p> 2790<p>In D.7.3.1 <a href="future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> 2791paragraph 2, change the first condition to <tt>(mode&app)==0</tt> 2792and the second condition to <tt>(mode&app)!=0</tt>.</p> 2793<hr> 2794<a name="117"><h3>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p> 2795<b>Section:</b> 27.6.2.5.2 <a href="lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p> 2796<p>The <b>effects</b> clause for numeric inserters says that 2797insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>, 2798<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned 2799int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, 2800<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is 2801delegated to <tt>num_put</tt>, and that insertion is performed as if 2802through the following code fragment: </p> 2803 2804<pre>bool failed = use_facet< 2805 num_put<charT,ostreambuf_iterator<charT,traits> > 2806 >(getloc()).put(*this, *this, fill(), val). failed();</pre> 2807 2808<p>This doesn't work, because <tt>num_put<></tt>::put is only 2809overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned 2810long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const 2811void*</tt>. That is, the code fragment in the standard is incorrect 2812(it is diagnosed as ambiguous at compile time) for the types 2813<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned 2814int</tt>, and <tt>float</tt>. </p> 2815 2816<p>We must either add new member functions to <tt>num_put</tt>, or 2817else change the description in <tt>ostream</tt> so that it only calls 2818functions that are actually there. I prefer the latter. </p> 2819<p><b>Proposed resolution:</b></p> 2820<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p> 2821 2822<blockquote> 2823<p> 2824The classes num_get<> and num_put<> handle locale­dependent numeric 2825formatting and parsing. These inserter functions use the imbued 2826locale value to perform numeric formatting. When val is of type bool, 2827long, unsigned long, double, long double, or const void*, the 2828formatting conversion occurs as if it performed the following code 2829fragment: 2830</p> 2831 2832<pre> 2833bool failed = use_facet< 2834 num_put<charT,ostreambuf_iterator<charT,traits> > 2835 >(getloc()).put(*this, *this, fill(), val). failed(); 2836</pre> 2837 2838<p> 2839When val is of type short the formatting conversion occurs as if it 2840performed the following code fragment: 2841</p> 2842 2843<pre> 2844ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield; 2845bool failed = use_facet< 2846 num_put<charT,ostreambuf_iterator<charT,traits> > 2847 >(getloc()).put(*this, *this, fill(), 2848 baseflags == ios_base::oct || baseflags == ios_base::hex 2849 ? static_cast<long>(static_cast<unsigned short>(val)) 2850 : static_cast<long>(val)). failed(); 2851</pre> 2852 2853<p> 2854When val is of type int the formatting conversion occurs as if it performed 2855the following code fragment: 2856</p> 2857 2858<pre> 2859ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield; 2860bool failed = use_facet< 2861 num_put<charT,ostreambuf_iterator<charT,traits> > 2862 >(getloc()).put(*this, *this, fill(), 2863 baseflags == ios_base::oct || baseflags == ios_base::hex 2864 ? static_cast<long>(static_cast<unsigned int>(val)) 2865 : static_cast<long>(val)). failed(); 2866</pre> 2867 2868<p> 2869When val is of type unsigned short or unsigned int the formatting conversion 2870occurs as if it performed the following code fragment: 2871</p> 2872 2873<pre> 2874bool failed = use_facet< 2875 num_put<charT,ostreambuf_iterator<charT,traits> > 2876 >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)). 2877failed(); 2878</pre> 2879 2880<p> 2881When val is of type float the formatting conversion occurs as if it 2882performed the following code fragment: 2883</p> 2884 2885<pre> 2886bool failed = use_facet< 2887 num_put<charT,ostreambuf_iterator<charT,traits> > 2888 >(getloc()).put(*this, *this, fill(), static_cast<double>(val)). 2889failed(); 2890</pre> 2891 2892</blockquote> 2893 2894<p><i>[post-Toronto: This differs from the previous proposed 2895resolution; PJP provided the new wording. The differences are in 2896signed short and int output.]</i></p> 2897<p><b>Rationale:</b></p> 2898<p>The original proposed resolution was to cast int and short to long, 2899unsigned int and unsigned short to unsigned long, and float to double, 2900thus ensuring that we don't try to use nonexistent num_put<> 2901member functions. The current proposed resolution is more 2902complicated, but gives more expected results for hex and octal output 2903of signed short and signed int. (On a system with 16-bit short, for 2904example, printing short(-1) in hex format should yield 0xffff.)</p> 2905<hr> 2906<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p> 2907<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p> 2908<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, 2909<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>, 2910<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2, 2911formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p> 2912 2913<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; 2914iostate err = 0; 2915use_facet< numget >(loc).get(*this, 0, *this, err, val); 2916setstate(err);</pre> 2917 2918<p>According to section 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however, 2919<tt>num_get<>::get()</tt> is only overloaded for the types 2920<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned 2921int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>, 2922<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and 2923<tt>void*</tt>. Comparing the lists from the two sections, we find 2924that 27.6.1.2.2 is using a nonexistent function for types 2925<tt>short</tt> and <tt>int</tt>. </p> 2926<p><b>Proposed resolution:</b></p> 2927<p>In 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the 2928two lines (1st and 3rd) which read:</p> 2929<blockquote> 2930 <pre>operator>>(short& val); 2931... 2932operator>>(int& val);</pre> 2933</blockquote> 2934 2935<p>And add the following at the end of that section (27.6.1.2.2) :</p> 2936 2937<blockquote> 2938 <pre>operator>>(short& val);</pre> 2939 <p>The conversion occurs as if performed by the following code fragment (using 2940 the same notation as for the preceding code fragment):</p> 2941 <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; 2942 iostate err = 0; 2943 long lval; 2944 use_facet< numget >(loc).get(*this, 0, *this, err, lval); 2945 if (err == 0 2946 && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)) 2947 err = ios_base::failbit; 2948 setstate(err);</pre> 2949 <pre>operator>>(int& val);</pre> 2950 <p>The conversion occurs as if performed by the following code fragment (using 2951 the same notation as for the preceding code fragment):</p> 2952 <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; 2953 iostate err = 0; 2954 long lval; 2955 use_facet< numget >(loc).get(*this, 0, *this, err, lval); 2956 if (err == 0 2957 && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)) 2958 err = ios_base::failbit; 2959 setstate(err);</pre> 2960</blockquote> 2961 2962<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p> 2963<hr> 2964<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p> 2965<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> 2966<p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p> 2967 2968<p>"An implementation may strengthen the exception-specification 2969for a function by removing listed exceptions." </p> 2970 2971<p>The problem is that if an implementation is allowed to do this for 2972virtual functions, then a library user cannot write a class that 2973portably derives from that class. </p> 2974 2975<p>For example, this would not compile if ios_base::failure::~failure 2976had an empty exception specification: </p> 2977 2978<pre>#include <ios> 2979#include <string> 2980 2981class D : public std::ios_base::failure { 2982public: 2983 D(const std::string&); 2984 ~D(); // error - exception specification must be compatible with 2985 // overridden virtual function ios_base::failure::~failure() 2986};</pre> 2987<p><b>Proposed resolution:</b></p> 2988<p>Change Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p> 2989 2990<p> "may strengthen the 2991exception-specification for a function"</p> 2992 2993<p>to:</p> 2994 2995<p> "may strengthen the 2996exception-specification for a non-virtual function". </p> 2997<hr> 2998<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p> 2999<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> 3000<p>Section 27.5.2 describes the streambuf classes this way: </p> 3001 3002<blockquote> 3003 3004<p>The class streambuf is a specialization of the template class basic_streambuf 3005specialized for the type char. </p> 3006 3007<p>The class wstreambuf is a specialization of the template class basic_streambuf 3008specialized for the type wchar_t. </p> 3009 3010</blockquote> 3011 3012<p>This implies that these classes must be template specializations, not typedefs. </p> 3013 3014<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p> 3015<p><b>Proposed resolution:</b></p> 3016<p>Remove 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two 3017sentences). </p> 3018<p><b>Rationale:</b></p> 3019<p>The <tt>streambuf</tt> synopsis already has a declaration for the 3020typedefs and that is sufficient. </p> 3021<hr> 3022<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p> 3023<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> 3024<p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> 3025ctype_byname<charT>::do_scan_is() and do_scan_not() are declared 3026to return a const char* not a const charT*. </p> 3027<p><b>Proposed resolution:</b></p> 3028<p>Change Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and 3029<tt>do_scan_not()</tt> to return a <tt> const 3030charT*</tt>. </p> 3031<hr> 3032<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p> 3033<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> 3034<p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is 3035declared to return a valarray<T>, but in Section 26.3.2.5 <a href="lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The 3036latter appears to be correct. </p> 3037<p><b>Proposed resolution:</b></p> 3038<p>Change in Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of 3039<tt>operator!()</tt> so that the return type is 3040<tt>valarray<bool></tt>. </p> 3041<hr> 3042<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p> 3043<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> 3044<p>Typos in 22.2.1.1.2 need to be fixed.</p> 3045<p><b>Proposed resolution:</b></p> 3046<p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p> 3047 3048<pre> do_widen(do_narrow(c),0) == c</pre> 3049 3050<p>to:</p> 3051 3052<pre> do_widen(do_narrow(c,0)) == c</pre> 3053 3054<p>and change:</p> 3055 3056<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre> 3057 3058<p>to:</p> 3059 3060<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre> 3061<hr> 3062<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p> 3063<b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p> 3064<p>There are two problems with the current <tt>auto_ptr</tt> wording 3065in the standard: </p> 3066 3067<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested 3068because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to 3069<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by 3070Nathan Myers, with the same proposed resolution.</i> 3071</p> 3072 3073<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an 3074<tt>auto_ptr_ref</tt> argument. </p> 3075 3076<p>I have discussed these problems with my proposal coauthor, Bill 3077Gibbons, and with some compiler and library implementors, and we 3078believe that these problems are not desired or desirable implications 3079of the standard. </p> 3080 3081<p>25 Aug 1999: The proposed resolution now reflects changes suggested 3082by Dave Abrahams, with Greg Colvin's concurrence; 1) changed 3083"assignment operator" to "public assignment 3084operator", 2) changed effects to specify use of release(), 3) 3085made the conversion to auto_ptr_ref const. </p> 3086 3087<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue 3088states that the conversion from auto_ptr to auto_ptr_ref should 3089be const. This is not acceptable, because it would allow 3090initialization and assignment from _any_ const auto_ptr! It also 3091introduces an implementation difficulty in writing this conversion 3092function -- namely, somewhere along the line, a const_cast will be 3093necessary to remove that const so that release() may be called. This 3094may result in undefined behavior [7.1.5.1/4]. The conversion 3095operator does not have to be const, because a non-const implicit 3096object parameter may be bound to an rvalue [13.3.3.1.4/3] 3097[13.3.1/5]. </p> 3098 3099 <p>Tokyo: The LWG removed the following from the proposed resolution:</p> 3100 3101 <p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>, 3102 paragraph 2, make the conversion to auto_ptr_ref const:</p> 3103 <blockquote> 3104 <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre> 3105 </blockquote> 3106<p><b>Proposed resolution:</b></p> 3107<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move 3108the <tt>auto_ptr_ref</tt> definition to namespace scope.</p> 3109 3110<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add 3111a public assignment operator to the <tt>auto_ptr</tt> definition: </p> 3112 3113<blockquote> 3114 <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre> 3115</blockquote> 3116 3117<p>Also add the assignment operator to 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p> 3118 3119<blockquote> 3120 <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre> 3121 3122 <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr 3123 p</tt> that <tt>r</tt> holds a reference to.<br> 3124 <b>Returns: </b><tt>*this</tt>. 3125 3126</blockquote> 3127<hr> 3128<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p> 3129<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p> 3130<p>Currently, the standard does not specify how seekg() and seekp() 3131indicate failure. They are not required to set failbit, and they can't 3132return an error indication because they must return *this, i.e. the 3133stream. Hence, it is undefined what happens if they fail. And they 3134<i>can</i> fail, for instance, when a file stream is disconnected from the 3135underlying file (is_open()==false) or when a wide character file 3136stream must perform a state-dependent code conversion, etc. </p> 3137 3138<p>The stream functions seekg() and seekp() should set failbit in the 3139stream state in case of failure.</p> 3140<p><b>Proposed resolution:</b></p> 3141<p>Add to the Effects: clause of seekg() in 314227.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in 314327.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p> 3144 3145<blockquote> 3146 <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>). 3147 </p> 3148</blockquote> 3149<p><b>Rationale:</b></p> 3150<p>Setting failbit is the usual error reporting mechanism for streams</p> 3151<hr> 3152<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p> 3153<b>Section:</b> 23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> 3154<p>The description reads:</p> 3155 3156<p>-1- Effects:</p> 3157 3158<pre> if (sz > size()) 3159 insert(end(), sz-size(), c); 3160 else if (sz < size()) 3161 erase(begin()+sz, end()); 3162 else 3163 ; // do nothing</pre> 3164 3165<p>Obviously list::resize should not be specified in terms of random access iterators.</p> 3166<p><b>Proposed resolution:</b></p> 3167<p>Change 23.2.2.2 paragraph 1 to:</p> 3168 3169<p>Effects:</p> 3170 3171<pre> if (sz > size()) 3172 insert(end(), sz-size(), c); 3173 else if (sz < size()) 3174 { 3175 iterator i = begin(); 3176 advance(i, sz); 3177 erase(i, end()); 3178 }</pre> 3179 3180<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline 3181with David Abrahams. They had a discussion and believe there is 3182no issue of exception safety with the proposed resolution.]</i></p> 3183<hr> 3184<a name="133"><h3>133. map missing get_allocator()</h3></a><p> 3185<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> 3186<p>The title says it all.</p> 3187<p><b>Proposed resolution:</b></p> 3188<p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2, 3189after operator= in the map declaration:</p> 3190 3191<pre> allocator_type get_allocator() const;</pre> 3192<hr> 3193<a name="134"><h3>134. vector constructors over specified</h3></a><p> 3194<b>Section:</b> 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> 3195<p>The complexity description says: "It does at most 2N calls to the copy constructor 3196of T and logN reallocations if they are just input iterators ...".</p> 3197 3198<p>This appears to be overly restrictive, dictating the precise memory/performance 3199tradeoff for the implementor.</p> 3200<p><b>Proposed resolution:</b></p> 3201<p>Change 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p> 3202 3203<p>-1- Complexity: The constructor template <class 3204InputIterator> vector(InputIterator first, InputIterator last) 3205makes only N calls to the copy constructor of T (where N is the 3206distance between first and last) and no reallocations if iterators 3207first and last are of forward, bidirectional, or random access 3208categories. It makes order N calls to the copy constructor of T and 3209order logN reallocations if they are just input iterators. 3210</p> 3211<p><b>Rationale:</b></p> 3212<p>"at most 2N calls" is correct only if the growth factor 3213is greater than or equal to 2. 3214</p> 3215<hr> 3216<a name="136"><h3>136. seekp, seekg setting wrong streams?</h3></a><p> 3217<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> 3218<p>I may be misunderstanding the intent, but should not seekg set only 3219the input stream and seekp set only the output stream? The description 3220seems to say that each should set both input and output streams. If 3221that's really the intent, I withdraw this proposal.</p> 3222<p><b>Proposed resolution:</b></p> 3223<p>In section 27.6.1.3 change:</p> 3224 3225<pre>basic_istream<charT,traits>& seekg(pos_type pos); 3226Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre> 3227 3228<p>To:</p> 3229 3230<pre>basic_istream<charT,traits>& seekg(pos_type pos); 3231Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre> 3232 3233<p>In section 27.6.1.3 change:</p> 3234 3235<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir); 3236Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre> 3237 3238<p>To:</p> 3239 3240<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir); 3241Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre> 3242 3243<p>In section 27.6.2.4, paragraph 2 change:</p> 3244 3245<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre> 3246 3247<p>To:</p> 3248 3249<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre> 3250 3251<p>In section 27.6.2.4, paragraph 4 change:</p> 3252 3253<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre> 3254 3255<p>To:</p> 3256 3257<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre> 3258 3259<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would 3260like the opinion of more iostream experts before taking action.]</i></p> 3261 3262<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are 3263incorrect, his implementation already implements the Proposed 3264Resolution.]</i></p> 3265 3266<p><i>[Post-Tokyo: Matt Austern comments:<br> 3267Is it a problem with basic_istream and basic_ostream, or is it a problem 3268with basic_stringbuf? 3269We could resolve the issue either by changing basic_istream and 3270basic_ostream, or by changing basic_stringbuf. I prefer the latter 3271change (or maybe both changes): I don't see any reason for the standard to 3272require that std::stringbuf s(std::string("foo"), std::ios_base::in); 3273s.pubseekoff(0, std::ios_base::beg); must fail.<br> 3274This requirement is a bit weird. There's no similar requirement 3275for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or 3276basic_filebuf<>::seekpos.]</i></p> 3277<hr> 3278<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p> 3279<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p> 3280<p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p> 3281 3282<p>-4- In the call to use_facet<Facet>(loc), the type argument 3283chooses a facet, making available all members of the named type. If 3284Facet is not present in a locale (or, failing that, in the global 3285locale), it throws the standard exception bad_cast. A C++ program can 3286check if a locale implements a particular facet with the template 3287function has_facet<Facet>(). </p> 3288 3289<p>This contradicts the specification given in section 329022.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>: 3291<br><br> 3292template <class Facet> const Facet& use_facet(const 3293locale& loc); <br> 3294<br> 3295-1- Get a reference to a facet of a locale. <br> 3296-2- Returns: a reference to the corresponding facet of loc, if present. <br> 3297-3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br> 3298-4- Notes: The reference returned remains valid at least as long as any copy of loc exists 3299</p> 3300<p><b>Proposed resolution:</b></p> 3301<p>Remove the phrase "(or, failing that, in the global locale)" 3302from section 22.1.1. </p> 3303<p><b>Rationale:</b></p> 3304<p>Needed for consistency with the way locales are handled elsewhere 3305in the standard.</p> 3306<hr> 3307<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p> 3308<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p> 3309<p>The sentence introducing the Optional sequence operation table 3310(23.1.1 paragraph 12) has two problems:</p> 3311 3312<p>A. It says ``The operations in table 68 are provided only for the containers for which 3313they take constant time.''<br> 3314<br> 3315That could be interpreted in two ways, one of them being ``Even though table 68 shows 3316particular operations as being provided, implementations are free to omit them if they 3317cannot implement them in constant time.''<br> 3318<br> 3319B. That paragraph says nothing about amortized constant time, and it should. </p> 3320<p><b>Proposed resolution:</b></p> 3321<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..." 3322with:</p> 3323 3324<blockquote> 3325 <p>Table 68 lists sequence operations that are provided for some types of sequential 3326 containers but not others. An implementation shall provide these operations for all 3327 container types shown in the ``container'' column, and shall implement them so as to take 3328 amortized constant time.</p> 3329</blockquote> 3330<hr> 3331<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p> 3332<b>Section:</b> 21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p> 3333<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they 3334say:<br> 3335<br> 3336— <tt>xpos <= pos</tt> and <tt>pos < size();</tt> 3337</p> 3338 3339<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p> 3340 3341<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same 3342proposed resolution.]</i></p> 3343<p><b>Proposed resolution:</b></p> 3344<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br> 3345<br> 3346— <tt>xpos <= pos</tt> and <tt>pos < size();<br> 3347<br> 3348</tt>to:<br> 3349<tt><br> 3350</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt> 3351</p> 3352<hr> 3353<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p> 3354<b>Section:</b> 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p> 3355<p>The lexicographical_compare complexity is specified as:<br> 3356<br> 3357 "At most min((last1 - first1), (last2 - first2)) 3358applications of the corresponding comparison."<br> 3359<br> 3360The best I can do is twice that expensive.</p> 3361 3362<p>Nicolai Josuttis comments in lib-6862: You mean, to check for 3363equality you have to check both < and >? Yes, IMO you are 3364right! (and Matt states this complexity in his book)</p> 3365 3366<p><b>Proposed resolution:</b></p> 3367<p>Change 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p> 3368 <blockquote> 3369 At most <tt>2*min((last1 - first1), (last2 - first2))</tt> 3370 applications of the corresponding comparison. 3371 </blockquote> 3372 3373<p>Change the example at the end of paragraph 3 to read:</p> 3374 <blockquote> 3375 [Example:<br> 3376 <br> 3377 for ( ; first1 != last1 && first2 != last2 ; 3378 ++first1, ++first2) {<br> 3379 if (*first1 < *first2) return true;<br> 3380 if (*first2 < *first1) return false;<br> 3381 }<br> 3382 return first1 == last1 && first2 != last2;<br> 3383 <br> 3384 --end example] 3385 </blockquote> 3386<hr> 3387<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p> 3388<b>Section:</b> 23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p> 3389<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears 3390to have complexity requirements which are incorrect, and which contradict the 3391complexity requirements for insert(). I suspect that the text in question, 3392below, was taken from vector:</p> 3393<blockquote> 3394 <p>Complexity: If the iterators first and last are forward iterators, 3395 bidirectional iterators, or random access iterators the constructor makes only 3396 N calls to the copy constructor, and performs no reallocations, where N is 3397 last - first.</p> 3398</blockquote> 3399<p>The word "reallocations" does not really apply to deque. Further, 3400all of the following appears to be spurious:</p> 3401<blockquote> 3402 <p>It makes at most 2N calls to the copy constructor of T and log N 3403 reallocations if they are input iterators.1)</p> 3404 <p>1) The complexity is greater in the case of input iterators because each 3405 element must be added individually: it is impossible to determine the distance 3406 between first abd last before doing the copying.</p> 3407</blockquote> 3408<p>This makes perfect sense for vector, but not for deque. Why should deque gain 3409an efficiency advantage from knowing in advance the number of elements to 3410insert?</p> 3411<p><b>Proposed resolution:</b></p> 3412<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the 3413footnote, with the following text (which also corrects the "abd" 3414typo):</p> 3415<blockquote> 3416 <p>Complexity: Makes last - first calls to the copy constructor of T.</p> 3417</blockquote> 3418<hr> 3419<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p> 3420<b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p> 3421<p>The <u> extractor</u> for complex numbers is specified as: </p> 3422 3423<blockquote> 3424 3425<p> template<class T, class charT, class traits> <br> 3426 basic_istream<charT, traits>& <br> 3427 operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br> 3428 <br> 3429Effects: Extracts a complex number x of the form: u, (u), or (u,v), 3430where u is the real part and v is the imaginary part 3431(lib.istream.formatted). <br> 3432Requires: The input values be convertible to T. If bad input is 3433encountered, calls is.setstate(ios::failbit) (which may throw 3434ios::failure (lib.iostate.flags). <br> 3435Returns: is .</p> 3436 3437</blockquote> 3438<p>Is it intended that the extractor for complex numbers does not skip 3439whitespace, unlike all other extractors in the standard library do? 3440Shouldn't a sentry be used? <br> 3441<br> 3442The <u>inserter</u> for complex numbers is specified as:</p> 3443 3444<blockquote> 3445 3446<p> template<class T, class charT, class traits> <br> 3447 basic_ostream<charT, traits>& <br> 3448 operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br> 3449<br> 3450Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br> 3451<br> 3452 template<class T, class charT, class traits> <br> 3453 basic_ostream<charT, traits>& <br> 3454 operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br> 3455 { <br> 3456 basic_ostringstream<charT, traits> s; <br> 3457 s.flags(o.flags()); <br> 3458 s.imbue(o.getloc()); <br> 3459 s.precision(o.precision()); <br> 3460 s << '(' << x.real() << "," << x.imag() << ')'; <br> 3461 return o << s.str(); <br> 3462 }</p> 3463 3464</blockquote> 3465 3466<p>Is it intended that the inserter for complex numbers ignores the 3467field width and does not do any padding? If, with the suggested 3468implementation above, the field width were set in the stream then the 3469opening parentheses would be adjusted, but the rest not, because the 3470field width is reset to zero after each insertion.</p> 3471 3472<p>I think that both operations should use sentries, for sake of 3473consistency with the other inserters and extractors in the 3474library. Regarding the issue of padding in the inserter, I don't know 3475what the intent was. </p> 3476<p><b>Proposed resolution:</b></p> 3477<p>After 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a 3478Notes clause:</p> 3479 3480<blockquote> 3481 3482<p>Notes: This extraction is performed as a series of simpler 3483extractions. Therefore, the skipping of whitespace is specified to be the 3484same for each of the simpler extractions.</p> 3485 3486</blockquote> 3487<p><b>Rationale:</b></p> 3488<p>For extractors, the note is added to make it clear that skipping whitespace 3489follows an "all-or-none" rule.</p> 3490 3491<p>For inserters, the LWG believes there is no defect; the standard is correct 3492as written.</p> 3493<hr> 3494<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p> 3495<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p> 3496<p>The library had many global functions until 17.4.1.1 [lib.contents] 3497paragraph 2 was added: </p> 3498 3499<blockquote> 3500 3501<p>All library entities except macros, operator new and operator 3502delete are defined within the namespace std or namespaces nested 3503within namespace std. </p> 3504 3505</blockquote> 3506 3507<p>It appears "global function" was never updated in the following: </p> 3508 3509<blockquote> 3510 3511<p>17.4.4.3 - Global functions [lib.global.functions]<br> 3512<br> 3513-1- It is unspecified whether any global functions in the C++ Standard 3514Library are defined as inline (dcl.fct.spec).<br> 3515<br> 3516-2- A call to a global function signature described in Clauses 3517lib.language.support through lib.input.output behaves the same as if 3518the implementation declares no additional global function 3519signatures.*<br> 3520<br> 3521 [Footnote: A valid C++ program always calls the expected library 3522 global function. An implementation may also define additional 3523 global functions that would otherwise not be called by a valid C++ 3524 program. --- end footnote]<br> 3525<br> 3526-3- A global function cannot be declared by the implementation as 3527taking additional default arguments. <br> 3528<br> 352917.4.4.4 - Member functions [lib.member.functions]<br> 3530<br> 3531-2- An implementation can declare additional non-virtual member 3532function signatures within a class: </p> 3533 3534 <blockquote> 3535 3536<p>-- by adding arguments with default values to a member function 3537signature; The same latitude does not extend to the implementation of 3538virtual or global functions, however. </p> 3539 3540 </blockquote> 3541</blockquote> 3542<p><b>Proposed resolution:</b></p> 3543<p> Change "global" to "global or non-member" in:</p> 3544<blockquote> 3545 <p>17.4.4.3 [lib.global.functions] section title,<br> 3546 17.4.4.3 [lib.global.functions] para 1,<br> 3547 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 3548 places in the footnote,<br> 3549 17.4.4.3 [lib.global.functions] para 3,<br> 3550 17.4.4.4 [lib.member.functions] para 2</p> 3551</blockquote> 3552<p><b>Rationale:</b></p> 3553<p> 3554Because operator new and delete are global, the proposed resolution 3555was changed from "non-member" to "global or non-member. 3556</p> 3557<hr> 3558<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p> 3559<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p> 3560<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and 3561do_falsename() functions in the example facet BoolNames should be 3562const. The functions they are overriding in 3563numpunct_byname<char> are const. </p> 3564<p><b>Proposed resolution:</b></p> 3565<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in 3566two places:</p> 3567<blockquote> 3568 <p><tt>string do_truename() const { return "Oui Oui!"; }<br> 3569 string do_falsename() const { return "Mais Non!"; }</tt></p> 3570</blockquote> 3571<hr> 3572<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p> 3573<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p> 3574<p><b>Proposed resolution:</b></p> 3575<p>Change 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p> 3576 3577<blockquote> 3578<p>Returns: The first iterator i in the range [first1, last1) such 3579that for some <u>integer</u> j in the range [first2, last2) ...</p> 3580</blockquote> 3581 3582<p>to:</p> 3583 3584<blockquote> 3585<p>Returns: The first iterator i in the range [first1, last1) such 3586that for some iterator j in the range [first2, last2) ...</p> 3587</blockquote> 3588<hr> 3589<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p> 3590<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p> 3591<p>For both sequences and associative containers, a.clear() has the 3592semantics of erase(a.begin(),a.end()), which is undefined for an empty 3593container since erase(q1,q2) requires that q1 be dereferenceable 3594(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is 3595not dereferenceable.<br> 3596<br> 3597The requirement that q1 be unconditionally dereferenceable causes many 3598operations to be intuitively undefined, of which clearing an empty 3599container is probably the most dire.<br> 3600<br> 3601Since q1 and q2 are only referenced in the range [q1, q2), and [q1, 3602q2) is required to be a valid range, stating that q1 and q2 must be 3603iterators or certain kinds of iterators is unnecessary. 3604</p> 3605<p><b>Proposed resolution:</b></p> 3606<p>In 23.1.1, paragraph 3, change:</p> 3607<blockquote> 3608 <p>p and q2 denote valid iterators to a, q <u> and q1</u> denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p> 3609</blockquote> 3610<p>to:</p> 3611<blockquote> 3612 <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u> 3613 in a</u> 3614</p> 3615</blockquote> 3616<p>In 23.1.2, paragraph 7, change:</p> 3617<blockquote> 3618 <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable 3619 iterators to a, [q1, q2) is a valid range</p> 3620</blockquote> 3621<p>to</p> 3622<blockquote> 3623 <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range 3624 <u>into a</u> 3625</p> 3626</blockquote> 3627<hr> 3628<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p> 3629<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3630<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described 3631because there is no function <tt>is()</tt> which only takes a character as 3632argument. Also, in the effects clause (paragraph 3), the semantic is also kept 3633vague.</p> 3634<p><b>Proposed resolution:</b></p> 3635<p>In 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns 3636clause from:</p> 3637<blockquote> 3638 <p>"... such that <tt>is(*p)</tt> 3639would..."</p> 3640</blockquote> 3641<p>to: "... such that <tt>is(m, *p)</tt> 3642 would...."</p> 3643<hr> 3644<a name="153"><h3>153. Typo in <tt>narrow()</tt> semantics</h3></a><p> 3645<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3646<p>The description of the array version of <tt>narrow()</tt> (in 3647paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which 3648takes only three arguments because in addition to the range a default 3649character is needed.</p> 3650 3651<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have 3652two signatures followed by a <b>Returns</b> clause that only addresses 3653one of them.</p> 3654 3655<p><b>Proposed resolution:</b></p> 3656<p>Change the returns clause in 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> 3657paragraph 10 from:</p> 3658<p> Returns: do_widen(low, high, to).</p> 3659 3660<p>to:</p> 3661<p> Returns: do_widen(c) or do_widen(low, high, to), 3662respectively.</p> 3663 3664<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p> 3665<pre> char narrow(char c, char /*dfault*/) const; 3666 const char* narrow(const char* low, const char* high, 3667 char /*dfault*/, char* to) const;</pre> 3668<pre> Returns: do_narrow(low, high, to).</pre> 3669<p>to:</p> 3670<pre> char narrow(char c, char dfault) const; 3671 const char* narrow(const char* low, const char* high, 3672 char dfault, char* to) const;</pre> 3673<pre> Returns: do_narrow(c, dfault) or 3674 do_narrow(low, high, dfault, to), respectively.</pre> 3675 3676<p><i>[Kona: 1) the problem occurs in additional places, 2) a user 3677defined version could be different.]</i></p> 3678 3679<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of 3680the LWG. He could find no other places the problem occurred. He 3681asks for clarification of the Kona "a user defined 3682version..." comment above. Perhaps it was a circuitous way of 3683saying "dfault" needed to be uncommented?]</i></p> 3684 3685<p><i>[Post-Toronto: the issues list maintainer has merged in the 3686proposed resolution from issue <a href="lwg-closed.html#207">207</a>, which addresses the 3687same paragraphs.]</i></p> 3688<hr> 3689<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt> 3690</h3></a><p> 3691<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3692<p>The table in paragraph 7 for the length modifier does not list the length 3693modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the 3694standard asks the implementation to do undefined things when using <tt>scanf()</tt> 3695(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s 3696is actually a problem I found quite often in production code, too).</p> 3697<p><b>Proposed resolution:</b></p> 3698<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length 3699Modifier table to say that for <tt>double</tt> a length modifier 3700<tt>l</tt> is to be used.</p> 3701<p><b>Rationale:</b></p> 3702<p>The standard makes an embarrassing beginner's mistake.</p> 3703<hr> 3704<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt> 3705</h3></a><p> 3706<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3707<p>There are conflicting statements about where the class 3708<tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 3709it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p> 3710<p><b>Proposed resolution:</b></p> 3711<p>Change 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from 3712"<tt>basic_ios::Init"</tt> to 3713"<tt>ios_base::Init"</tt>.</p> 3714<p><b>Rationale:</b></p> 3715<p>Although not strictly wrong, the standard was misleading enough to warrant 3716the change.</p> 3717<hr> 3718<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p> 3719<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3720<p>There is a small discrepancy between the declarations of 3721<tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as 3722<tt>locale const&</tt> (correct), in 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it 3723is passed as <tt>locale const</tt> (wrong).</p> 3724<p><b>Proposed resolution:</b></p> 3725<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument 3726from "<tt>locale const" to "locale 3727const&".</tt> 3728</p> 3729<hr> 3730<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt> 3731</h3></a><p> 3732<b>Section:</b> 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3733<p>The default behavior of <tt>setbuf()</tt> is described only for the 3734situation that <tt>gptr() != 0 && gptr() != egptr()</tt>: 3735namely to do nothing. What has to be done in other situations 3736is not described although there is actually only one reasonable 3737approach, namely to do nothing, too.</p> 3738 3739<p>Since changing the buffer would almost certainly mess up most 3740buffer management of derived classes unless these classes do it 3741themselves, the default behavior of <tt>setbuf()</tt> should always be 3742to do nothing.</p> 3743<p><b>Proposed resolution:</b></p> 3744<p>Change 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior, 3745to: "Default behavior: Does nothing. Returns this."</p> 3746<hr> 3747<a name="159"><h3>159. Strange use of <tt>underflow()</tt> 3748</h3></a><p> 3749<b>Section:</b> 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3750<p>The description of the meaning of the result of 3751<tt>showmanyc()</tt> seems to be rather strange: It uses calls to 3752<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because 3753this function only reads the current character but does not extract 3754it, <tt>uflow()</tt> would extract the current character. This should 3755be fixed to use <tt>sbumpc()</tt> instead.</p> 3756<p><b>Proposed resolution:</b></p> 3757<p>Change 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1, 3758<tt>showmanyc()</tt>returns clause, by replacing the word 3759"supplied" with the words "extracted from the 3760stream".</p> 3761<hr> 3762<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt> 3763</h3></a><p> 3764<b>Section:</b> 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3765<p>The paragraph 4 refers to the function <tt>exception()</tt> which 3766is not defined. Probably, the referred function is 3767<tt>basic_ios<>::exceptions()</tt>.</p> 3768<p><b>Proposed resolution:</b></p> 3769<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1, 377027.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>, 3771paragraph 1, change "<tt>exception()" to 3772"exceptions()"</tt>.</p> 3773 3774<p><i>[Note to Editor: "exceptions" with an "s" 3775is the correct spelling.]</i></p> 3776<hr> 3777<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt> 3778</h3></a><p> 3779<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3780<p>The note in the second paragraph pretends that the first argument 3781is an object of type <tt>istream_iterator</tt>. This is wrong: It is 3782an object of type <tt>istreambuf_iterator</tt>.</p> 3783<p><b>Proposed resolution:</b></p> 3784<p>Change 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p> 3785<blockquote> 3786 <p>The first argument provides an object of the istream_iterator class...</p> 3787</blockquote> 3788<p>to</p> 3789<blockquote> 3790 <p>The first argument provides an object of the istreambuf_iterator class...</p> 3791</blockquote> 3792<hr> 3793<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p> 3794<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p> 3795<p>In 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified 3796as taking a fill character as an argument, but the description of the 3797function does not say whether the character is used at all and, if so, 3798in which way. The same holds for any format control parameters that 3799are accessible through the ios_base& argument, such as the 3800adjustment or the field width. Is strftime() supposed to use the fill 3801character in any way? In any case, the specification of 3802time_put.do_put() looks inconsistent to me.<br> <br> Is the 3803signature of do_put() wrong, or is the effects clause incomplete?</p> 3804<p><b>Proposed resolution:</b></p> 3805<p>Add the following note after 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> 3806paragraph 2:</p> 3807<blockquote> 3808 <p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default 3809 for this argument. --end Note]</p> 3810</blockquote> 3811<p><b>Rationale:</b></p> 3812<p>The LWG felt that while the normative text was correct, 3813users need some guidance on what to pass for the <tt>fill</tt> 3814argument since the standard doesn't say how it's used.</p> 3815<hr> 3816<a name="165"><h3>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p> 3817<b>Section:</b> 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3818<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt> 3819functions falling into one of the groups "formatted output functions" 3820and "unformatted output functions" calls any stream buffer function 3821which might call a virtual function other than <tt>overflow()</tt>. Basically 3822this is fine but this implies that <tt>sputn()</tt> (this function would call 3823the virtual function <tt>xsputn()</tt>) is never called by any of the standard 3824output functions. Is this really intended? At minimum it would be convenient to 3825call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt> 3826is the only virtual member of <tt>basic_streambuf</tt> called is in conflict 3827with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt> 3828and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed 3829under "unformatted output functions").</p> 3830<p>In addition, I guess that the sentence starting with "They may use other 3831public members of <tt>basic_ostream</tt> ..." probably was intended to 3832start with "They may use other public members of <tt>basic_streamuf</tt>..." 3833although the problem with the virtual members exists in both cases.</p> 3834<p>I see two obvious resolutions:</p> 3835<ol> 3836 <li>state in a footnote that this means that <tt>xsputn()</tt> will never be 3837 called by any ostream member and that this is intended.</li> 3838 <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>. 3839 Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li> 3840</ol> 3841<p><b>Proposed resolution:</b></p> 3842<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p> 3843<blockquote> 3844 <p>They may use other public members of basic_ostream except that they do not 3845 invoke any virtual members of rdbuf() except overflow().</p> 3846</blockquote> 3847<p>to:</p> 3848<blockquote> 3849 <p>They may use other public members of basic_ostream except that they shall 3850 not invoke any virtual members of rdbuf() except overflow(), xsputn(), and 3851 sync().</p> 3852</blockquote> 3853 3854<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or 3855PJP why the standard is written this way.]</i></p> 3856 3857<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the 3858LWG. He comments: The rules can be made a little bit more specific if 3859necessary be explicitly spelling out what virtuals are allowed to be 3860called from what functions and eg to state specifically that flush() 3861is allowed to call sync() while other functions are not.]</i></p> 3862<hr> 3863<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p> 3864<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3865<p>The first paragraph begins with a descriptions what has to be done 3866in <i>formatted</i> output functions. Probably this is a typo and the 3867paragraph really want to describe unformatted output functions...</p> 3868<p><b>Proposed resolution:</b></p> 3869<p>In 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last 3870sentences, change the word "formatted" to 3871"unformatted":</p> 3872<blockquote> 3873 <p>"Each <b>unformatted </b> output function begins ..."<br> 3874 "... value specified for the <b>unformatted </b> output 3875 function."</p> 3876</blockquote> 3877<hr> 3878<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p> 3879<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3880<p>Paragraph 8, Notes, of this section seems to mandate an extremely 3881inefficient way of buffer handling for <tt>basic_stringbuf</tt>, 3882especially in view of the restriction that <tt>basic_ostream</tt> 3883member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer 3884is to be created.</p> 3885<p>Of course, the resolution below requires some handling of 3886simultaneous input and output since it is no longer possible to update 3887<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible 3888solution is to handle this in <tt>underflow()</tt>.</p> 3889<p><b>Proposed resolution:</b></p> 3890<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words 3891"at least" as in the following:</p> 3892<blockquote> 3893 <p>To make a write position available, the function reallocates (or initially 3894 allocates) an array object with a sufficient number of elements to hold the 3895 current array object (if any), plus <b>at least</b> one additional write 3896 position.</p> 3897</blockquote> 3898<hr> 3899<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt> 3900</h3></a><p> 3901<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3902<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>), 3903<tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and 3904<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent 3905in their definition of the type <tt>traits_type</tt>: For 3906<tt>istringstream</tt>, this type is defined, for the other two it is 3907not. This should be consistent.</p> 3908<p><b>Proposed resolution:</b></p> 3909<p><b>Proposed resolution:</b></p> <p>To the declarations of 3910<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and 3911<tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p> 3912<blockquote> 3913<pre>typedef traits traits_type;</pre> 3914</blockquote> 3915<hr> 3916<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p> 3917<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> 3918<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and 3919output position is maintained by <tt>basic_filebuf</tt>. Still, the 3920description of <tt>seekpos()</tt> seems to talk about different file 3921positions. In particular, it is unclear (at least to me) what is 3922supposed to happen to the output buffer (if there is one) if only the 3923input position is changed. The standard seems to mandate that the 3924output buffer is kept and processed as if there was no positioning of 3925the output position (by changing the input position). Of course, this 3926can be exactly what you want if the flag <tt>ios_base::ate</tt> is 3927set. However, I think, the standard should say something like 3928this:</p> 3929<ul> 3930 <li>If <tt>(which & mode) == 0</tt> neither read nor write position is 3931 changed and the call fails. Otherwise, the joint read and write position is 3932 altered to correspond to <tt>sp</tt>.</li> 3933 <li>If there is an output buffer, the output sequences is updated and any 3934 unshift sequence is written before the position is altered.</li> 3935 <li>If there is an input buffer, the input sequence is updated after the 3936 position is altered.</li> 3937</ul> 3938<p>Plus the appropriate error handling, that is...</p> 3939<p><b>Proposed resolution:</b></p> 3940<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before 3941paragraph 14 from:</p> 3942<blockquote> 3943 <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | 3944 ios_base::out);</p> 3945 <p>Alters the file position, if possible, to correspond to the position stored 3946 in sp (as described below).</p> 3947 <p>- if (which&ios_base::in)!=0, set the file position to sp, then update 3948 the input sequence</p> 3949 <p>- if (which&ios_base::out)!=0, then update the output sequence, write 3950 any unshift sequence, and set the file position to sp.</p> 3951</blockquote> 3952<p>to:</p> 3953<blockquote> 3954 <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | 3955 ios_base::out);</p> 3956 <p>Alters the file position, if possible, to correspond to the position stored 3957 in sp (as described below). Altering the file position performs as follows:</p> 3958 <p>1. if (om & ios_base::out)!=0, then update the output sequence and 3959 write any unshift sequence;</p> 3960 <p>2. set the file position to sp;</p> 3961 <p>3. if (om & ios_base::in)!=0, then update the input sequence;</p> 3962 <p>where om is the open mode passed to the last call to open(). The operation 3963 fails if is_open() returns false.</p> 3964</blockquote> 3965 3966<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p> 3967<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p> 3968<hr> 3969<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt> 3970</h3></a><p> 3971<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> 3972<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function 3973<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first 3974argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> 3975paragraph 23 the first argument is of type <tt>int.</tt> 3976</p> 3977 3978<p>As far as I can see this is not really a contradiction because 3979everything is consistent if <tt>streamsize</tt> is typedef to be 3980<tt>int</tt>. However, this is almost certainly not what was 3981intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>, 3982as described in issue <a href="lwg-defects.html#173">173</a>.</p> 3983 3984<p>Darin Adler also 3985submitted this issue, commenting: Either 27.6.1.1 should be modified 3986to show a first parameter of type int, or 27.6.1.3 should be modified 3987to show a first parameter of type streamsize and use 3988numeric_limits<streamsize>::max.</p> 3989<p><b>Proposed resolution:</b></p> 3990<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses 3991of <tt>int</tt> in the description of <tt>ignore()</tt> to 3992<tt>streamsize</tt>.</p> 3993<hr> 3994<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt> 3995</h3></a><p> 3996<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> 3997 3998<p> 3999In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an 4000object of type <tt>streamsize</tt> as second argument. However, in 400127.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type 4002<tt>int</tt>. 4003</p> 4004 4005<p> 4006As far as I can see this is not really a contradiction because 4007everything is consistent if <tt>streamsize</tt> is typedef to be 4008<tt>int</tt>. However, this is almost certainly not what was 4009intended. The same thing happened to <tt>basic_istream::ignore()</tt>, 4010as described in issue <a href="lwg-defects.html#172">172</a>. 4011</p> 4012 4013<p><b>Proposed resolution:</b></p> 4014<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of 4015<tt>int</tt> in the description of <tt>setbuf()</tt> to 4016<tt>streamsize</tt>.</p> 4017<hr> 4018<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt> 4019</h3></a><p> 4020<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> 4021<p>According to paragraph 1 of this section, <tt>streampos</tt> is the 4022type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in 4023paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt> 4024</p> 4025<p><b>Proposed resolution:</b></p> 4026<p>Change D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef 4027OFF_T streampos;</tt>" to "<tt>typedef POS_T 4028streampos;</tt>"</p> 4029<hr> 4030<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p> 4031<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> 4032<p>According to paragraph 8 of this section, the methods 4033<tt>basic_streambuf::pubseekpos()</tt>, 4034<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt> 4035"may" be overloaded by a version of this function taking the 4036type <tt>ios_base::open_mode</tt> as last argument argument instead of 4037<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined 4038in this section to be an alias for one of the integral types). The 4039clause specifies, that the last argument has a default argument in 4040three cases. However, this generates an ambiguity with the overloaded 4041version because now the arguments are absolutely identical if the last 4042argument is not specified.</p> 4043<p><b>Proposed resolution:</b></p> 4044<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for 4045<tt>basic_streambuf::pubseekpos()</tt>, 4046<tt>basic_ifstream::open()</tt>, and 4047<tt>basic_ofstream::open().</tt> 4048</p> 4049<hr> 4050<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p> 4051<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p> 4052<p>The "overload" for the function <tt>exceptions()</tt> in 4053paragraph 8 gives the impression that there is another function of 4054this function defined in class <tt>ios_base</tt>. However, this is not 4055the case. Thus, it is hard to tell how the semantics (paragraph 9) can 4056be implemented: "Call the corresponding member function specified 4057in clause 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p> 4058<p><b>Proposed resolution:</b></p> 4059<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the 4060function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p> 4061<hr> 4062<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p> 4063<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p> 4064<p>The claim has surfaced in Usenet that expressions such as<br> 4065<br> 4066 <tt>make_pair("abc", 3)</tt><br> 4067<br> 4068are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template 4069parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br> 4070<br> 4071I doubt anyone intended that behavior... 4072</p> 4073<p><b>Proposed resolution:</b></p> 4074<p>In 20.2 <a href="lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following 4075declaration of make_pair():</p> 4076<blockquote> 4077 <pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre> 4078</blockquote> 4079<p>to:</p> 4080<blockquote> 4081 <pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre> 4082</blockquote> 4083<p> In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p> 4084<blockquote> 4085<pre>template <class T1, class T2> 4086pair<T1, T2> make_pair(const T1& x, const T2& y);</pre> 4087</blockquote> 4088<p>to:</p> 4089<blockquote> 4090<pre>template <class T1, class T2> 4091pair<T1, T2> make_pair(T1 x, T2 y);</pre> 4092</blockquote> 4093<p>and add the following footnote to the effects clause:</p> 4094<blockquote> 4095 <p> According to 12.8 [class.copy], an implementation is permitted 4096 to not perform a copy of an argument, thus avoiding unnecessary 4097 copies.</p> 4098</blockquote> 4099<p><b>Rationale:</b></p> 4100<p>Two potential fixes were suggested by Matt Austern and Dietmar 4101Kühl, respectively, 1) overloading with array arguments, and 2) use of 4102a reference_traits class with a specialization for arrays. Andy 4103Koenig suggested changing to pass by value. In discussion, it appeared 4104that this was a much smaller change to the standard that the other two 4105suggestions, and any efficiency concerns were more than offset by the 4106advantages of the solution. Two implementors reported that the 4107proposed resolution passed their test suites.</p> 4108<hr> 4109<a name="182"><h3>182. Ambiguous references to size_t</h3></a><p> 4110<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Al Stevens <b>Date:</b> 15 Aug 1999</p> 4111<p>Many references to <tt> size_t</tt> throughout the document 4112omit the <tt> std::</tt> namespace qualification.</p> <p>For 4113example, 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p> 4114<blockquote> 4115<pre>— operator new(size_t) 4116— operator new(size_t, const std::nothrow_t&) 4117— operator new[](size_t) 4118— operator new[](size_t, const std::nothrow_t&)</pre> 4119</blockquote> 4120<p><b>Proposed resolution:</b></p> 4121<p> In 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p> 4122<blockquote> 4123<p><tt> - operator new(size_t)<br> 4124 - operator new(size_t, const std::nothrow_t&)<br> 4125 - operator new[](size_t)<br> 4126 - operator new[](size_t, const std::nothrow_t&)</tt></p> 4127</blockquote> 4128<p> by:</p> 4129<blockquote> 4130<pre>- operator new(std::size_t) 4131- operator new(std::size_t, const std::nothrow_t&) 4132- operator new[](std::size_t) 4133- operator new[](std::size_t, const std::nothrow_t&)</pre> 4134</blockquote> 4135<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p> 4136<blockquote> 4137 <p>The typedef members pointer, const_pointer, size_type, and difference_type 4138 are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p> 4139</blockquote> 4140<p> by:</p> 4141<blockquote> 4142 <p>The typedef members pointer, const_pointer, size_type, and difference_type 4143 are required to be T*, T const*, std::size_t, and std::ptrdiff_t, 4144 respectively.</p> 4145</blockquote> 4146<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p> 4147<blockquote> 4148 <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p> 4149 <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it 4150 is unspecified when or how often this function is called. The use of hint is 4151 unspecified, but intended as an aid to locality if an implementation so 4152 desires.</p> 4153</blockquote> 4154<p>by:</p> 4155<blockquote> 4156 <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p> 4157 <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but 4158 it is unspecified when or how often this function is called. The use of hint 4159 is unspecified, but intended as an aid to locality if an implementation so 4160 desires.</p> 4161</blockquote> 4162<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p> 4163<blockquote> 4164 <p>In Table 37, X denotes a Traits class defining types and functions for the 4165 character container type CharT; c and d denote values of type CharT; p and q 4166 denote values of type const CharT*; s denotes a value of type CharT*; n, i and 4167 j denote values of type size_t; e and f denote values of type X::int_type; pos 4168 denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p> 4169</blockquote> 4170<p>by:</p> 4171<blockquote> 4172 <p>In Table 37, X denotes a Traits class defining types and functions for the 4173 character container type CharT; c and d denote values of type CharT; p and q 4174 denote values of type const CharT*; s denotes a value of type CharT*; n, i and 4175 j denote values of type std::size_t; e and f denote values of type X::int_type; 4176 pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p> 4177</blockquote> 4178<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of 4179X::length(p): "size_t" by "std::size_t".</p> 4180<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br> 4181 typedef ptrdiff_t difference_type;<br> 4182 by:<br> 4183 typedef std::ptrdiff_t difference_type;</p> 4184<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of template <class charT> class ctype.<br> 4185<br> 4186 In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br> 4187<br> 4188 template<class Iterator> struct iterator_traits<br> 4189 template<class T> struct iterator_traits<T*><br> 4190 template<class T> struct iterator_traits<const T*></p> 4191<p><b>Rationale:</b></p> 4192<p>The LWG believes correcting names like <tt>size_t</tt> and 4193<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt> 4194to be essentially editorial. There there can't be another size_t or 4195ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p> 4196 4197<blockquote> 4198For each type T from the Standard C library, the types ::T and std::T 4199are reserved to the implementation and, when defined, ::T shall be 4200identical to std::T. 4201</blockquote> 4202 4203<p>The issue is treated as a Defect Report to make explicit the Project 4204Editor's authority to make this change.</p> 4205 4206<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the 4207request of the LWG.]</i></p> 4208 4209<p><i>[Toronto: This is tangentially related to issue <a href="lwg-active.html#229">229</a>, but only tangentially: the intent of this issue is to 4210address use of the name <tt>size_t</tt> in contexts outside of 4211namespace std, such as in the description of <tt>::operator new</tt>. 4212The proposed changes should be reviewed to make sure they are 4213correct.]</i></p> 4214 4215<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes 4216them to be correct.]</i></p> 4217 4218<hr> 4219<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p> 4220<b>Section:</b> 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 7 Jul 1999</p> 4221<p>27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for 4222exposition):</p> 4223<blockquote> 4224<p>Returns: An object s of unspecified type such that if [1] out is an (instance 4225of) basic_ostream then the expression out<<s behaves as if f(s) were 4226called, and if [2] in is an (instance of) basic_istream then the expression 4227in>>s behaves as if f(s) were called. Where f can be defined as: ios_base& 4228f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags 4229str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression 4230out<<s has type ostream& and value out. [4] The expression in>>s 4231has type istream& and value in.</p> 4232</blockquote> 4233<p>Given the definitions [1] and [2] for out and in, surely [3] should read: 4234"The expression out << s has type basic_ostream& ..." and 4235[4] should read: "The expression in >> s has type basic_istream& 4236..."</p> 4237<p>If the wording in the standard is correct, I can see no way of implementing 4238any of the manipulators so that they will work with wide character streams.</p> 4239<p>e.g. wcout << setbase( 16 );</p> 4240<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which 4241doesn't).</p> 4242<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and 42438. In addition, Para 6 [setfill] has a similar error, but relates only to 4244ostreams.</p> 4245<p>I'd be happier if there was a better way of saying this, to make it clear 4246that the value of the expression is "the same specialization of 4247basic_ostream as out"&</p> 4248<p><b>Proposed resolution:</b></p> 4249<p>Replace section 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the 4250following:</p> 4251<blockquote> 4252<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each 4253function.<br> 4254<br> 4255<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br> 4256<br> 4257-3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves 4258as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if 4259f(s, mask) were called. The function f can be defined as:*<br> 4260<br> 4261[Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the 4262basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears 4263ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout << 4264noshowbase). --- end footnote]<br> 4265<br> 4266 <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br> 4267 {<br> 4268 // reset specified flags<br> 4269 str.setf(ios_base::fmtflags(0), mask);<br> 4270 return str;<br> 4271 }<br> 4272</tt><br> 4273The expression out<<s has type basic_ostream<charT,traits>& and value out. 4274The expression in>>s has type basic_istream<charT,traits>& and value in.<br> 4275<br> 4276 <tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br> 4277<br> 4278-4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves 4279as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, 4280mask) were called. The function f can be defined as:<br> 4281<br> 4282 <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br> 4283 {<br> 4284 // set specified flags<br> 4285 str.setf(mask);<br> 4286 return str;<br> 4287 }<br> 4288</tt><br> 4289The expression out<<s has type basic_ostream<charT,traits>& and value out. 4290The expression in>>s has type basic_istream<charT,traits>& and value in.<br> 4291<br> 4292<tt>smanip setbase(int base);</tt><br> 4293<br> 4294-5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves 4295as if f(s, base) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, 4296base) were called. The function f can be defined as:<br> 4297<br> 4298 <tt>ios_base& f(ios_base& str, int base)<br> 4299 {<br> 4300 // set basefield<br> 4301 str.setf(base == 8 ? ios_base::oct :<br> 4302 base == 10 ? ios_base::dec :<br> 4303 base == 16 ? ios_base::hex :<br> 4304 ios_base::fmtflags(0), ios_base::basefield);<br> 4305 return str;<br> 4306 }<br> 4307</tt><br> 4308The expression out<<s has type basic_ostream<charT,traits>& and value out. 4309The expression in>>s has type basic_istream<charT,traits>& and value in.<br> 4310<br> 4311<tt>smanip setfill(char_type c);<br> 4312</tt><br> 4313-6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream<charT,traits> and c has type charT then the 4314expression out<<s behaves as if f(s, c) were called. The function f can be 4315defined as:<br> 4316<br> 4317 <tt>template<class charT, class traits><br> 4318 basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br> 4319 {<br> 4320 // set fill character<br> 4321 str.fill(c);<br> 4322 return str;<br> 4323 }<br> 4324</tt><br> 4325The expression out<<s has type basic_ostream<charT,traits>& and value out.<br> 4326<br> 4327<tt>smanip setprecision(int n);</tt><br> 4328<br> 4329-7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves 4330as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) 4331were called. The function f can be defined as:<br> 4332<br> 4333 <tt>ios_base& f(ios_base& str, int n)<br> 4334 {<br> 4335 // set precision<br> 4336 str.precision(n);<br> 4337 return str;<br> 4338 }<br> 4339</tt><br> 4340The expression out<<s has type basic_ostream<charT,traits>& and value out. 4341The expression in>>s has type basic_istream<charT,traits>& and value in<br> 4342.<br> 4343<tt>smanip setw(int n);<br> 4344</tt><br> 4345-8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves 4346as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) 4347were called. The function f can be defined as:<br> 4348<br> 4349 <tt>ios_base& f(ios_base& str, int n)<br> 4350 {<br> 4351 // set width<br> 4352 str.width(n);<br> 4353 return str;<br> 4354 }<br> 4355</tt><br> 4356The expression out<<s has type 4357basic_ostream<charT,traits>& and value out. The expression 4358in>>s has type basic_istream<charT,traits>& and value 4359in. 4360</p> 4361</blockquote> 4362 4363<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of 4364the proposed resolution.]</i></p> 4365 4366<p><i>[Tokyo - The LWG noted that issue <a href="lwg-closed.html#216">216</a> involves 4367the same paragraphs.]</i></p> 4368 4369<p><i>[Post-Tokyo: The issues list maintainer combined the proposed 4370resolution of this issue with the proposed resolution for issue <a href="lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so 4371intertwined that dealing with them separately appear fraught with 4372error. The full text was supplied by Bill Plauger; it was cross 4373checked against changes supplied by Andy Sawyer. It should be further 4374checked by the LWG.]</i></p> 4375<hr> 4376<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p> 4377<b>Section:</b> 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p> 4378<p>bools are defined by the standard to be of integer types, as per 43793.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types" 4380seems to have a special meaning for the author of 18.2. The net effect 4381is an unclear and confusing specification for 4382numeric_limits<bool> as evidenced below.</p> 4383 4384<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer 4385types, the number of non-sign bits in the representation.</p> 4386 4387<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero 4388arithmetical value converts to true.</p> 4389 4390<p>I don't think it makes sense at all to require 4391numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to 4392be meaningful.</p> 4393 4394<p>The standard defines what constitutes a signed (resp. unsigned) integer 4395types. It doesn't categorize bool as being signed or unsigned. And the set of 4396values of bool type has only two elements.</p> 4397 4398<p>I don't think it makes sense to require numeric_limits<bool>::is_signed 4399to be meaningful.</p> 4400 4401<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p> 4402<blockquote> 4403 <p>For integer types, specifies the base of the representation.186)</p> 4404</blockquote> 4405 4406<p>This disposition is at best misleading and confusing for the standard 4407requires a "pure binary numeration system" for integer types as per 44083.9.1/7</p> 4409 4410<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g 4411BCD)." This also erroneous as the standard never defines any integer 4412types with base representation other than 2.</p> 4413 4414<p>Furthermore, numeric_limits<bool>::is_modulo and 4415numeric_limits<bool>::is_signed have similar problems.</p> 4416<p><b>Proposed resolution:</b></p> 4417<p>Append to the end of 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p> 4418<blockquote> 4419 <p>The specialization for bool shall be provided as follows:</p> 4420 <pre> namespace std { 4421 template<> class numeric_limits<bool> { 4422 public: 4423 static const bool is_specialized = true; 4424 static bool min() throw() { return false; } 4425 static bool max() throw() { return true; } 4426 4427 static const int digits = 1; 4428 static const int digits10 = 0; 4429 static const bool is_signed = false; 4430 static const bool is_integer = true; 4431 static const bool is_exact = true; 4432 static const int radix = 2; 4433 static bool epsilon() throw() { return 0; } 4434 static bool round_error() throw() { return 0; } 4435 4436 static const int min_exponent = 0; 4437 static const int min_exponent10 = 0; 4438 static const int max_exponent = 0; 4439 static const int max_exponent10 = 0; 4440 4441 static const bool has_infinity = false; 4442 static const bool has_quiet_NaN = false; 4443 static const bool has_signaling_NaN = false; 4444 static const float_denorm_style has_denorm = denorm_absent; 4445 static const bool has_denorm_loss = false; 4446 static bool infinity() throw() { return 0; } 4447 static bool quiet_NaN() throw() { return 0; } 4448 static bool signaling_NaN() throw() { return 0; } 4449 static bool denorm_min() throw() { return 0; } 4450 4451 static const bool is_iec559 = false; 4452 static const bool is_bounded = true; 4453 static const bool is_modulo = false; 4454 4455 static const bool traps = false; 4456 static const bool tinyness_before = false; 4457 static const float_round_style round_style = round_toward_zero; 4458 }; 4459 }</pre> 4460</blockquote> 4461 4462<p><i>[Tokyo: The LWG desires wording that specifies exact values 4463rather than more general wording in the original proposed 4464resolution.]</i></p> 4465 4466<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico 4467Josuttis provided the above wording.]</i></p> 4468<hr> 4469<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p> 4470<b>Section:</b> 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p> 4471<p>Paragraph 4 of 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p> 4472<blockquote> 4473 <p> [Example: To negate every element of a: transform(a.begin(), a.end(), 4474 a.begin(), negate<double>()); The corresponding functions will inline 4475 the addition and the negation. end example]</p> 4476</blockquote> 4477<p>(Note: The "addition" referred to in the above is in para 3) we can 4478find no other wording, except this (non-normative) example which suggests that 4479any "inlining" will take place in this case.</p> 4480<p>Indeed both:</p> 4481<blockquote> 4482 <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is 4483 unspecified whether any global functions in the C++ Standard Library 4484 are defined as inline (7.1.2).</p> 4485</blockquote> 4486<p>and</p> 4487<blockquote> 4488 <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is 4489 unspecified whether any member functions in the C++ Standard Library 4490 are defined as inline (7.1.2).</p> 4491</blockquote> 4492<p>take care to state that this may indeed NOT be the case.</p> 4493<p>Thus the example "mandates" behavior that is explicitly 4494not required elsewhere.</p> 4495<p><b>Proposed resolution:</b></p> 4496<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p> 4497<blockquote> 4498<p>They are important for the effective use of the library.</p> 4499</blockquote> 4500<p>Remove 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p> 4501<blockquote> 4502 <p> Using function objects together with function templates 4503 increases the expressive power of the library as well as making the 4504 resulting code much more efficient.</p> 4505</blockquote> 4506<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p> 4507<blockquote> 4508 <p>The corresponding functions will inline the addition and the 4509 negation.</p> 4510</blockquote> 4511 4512<p><i>[Kona: The LWG agreed there was a defect.]</i></p> 4513<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p> 4514<hr> 4515<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p> 4516<b>Section:</b> 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p> 4517<p>In section 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the 4518bitset::set operation to take a second parameter of type int. The 4519function tests whether this value is non-zero to determine whether to 4520set the bit to true or false. The type of this second parameter should 4521be bool. For one thing, the intent is to specify a Boolean value. For 4522another, the result type from test() is bool. In addition, it's 4523possible to slice an integer that's larger than an int. This can't 4524happen with bool, since conversion to bool has the semantic of 4525translating 0 to false and any non-zero value to true.</p> 4526<p><b>Proposed resolution:</b></p> 4527<p>In 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p> 4528<blockquote> 4529<pre>bitset<N>& set(size_t pos, int val = true ); </pre> 4530</blockquote> 4531<p>With:</p> 4532<blockquote> 4533 <pre>bitset<N>& set(size_t pos, bool val = true );</pre> 4534</blockquote> 4535<p>In 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p> 4536<blockquote> 4537 <pre>bitset<N>& set(size_t pos, int val = 1 );</pre> 4538</blockquote> 4539<p>With:</p> 4540<blockquote> 4541 <pre>bitset<N>& set(size_t pos, bool val = true );</pre> 4542</blockquote> 4543 4544<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work 4545on better P/R wording.]</i></p> 4546<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p> 4547<p><b>Rationale:</b></p> 4548<p> 4549<tt>bool</tt> is a better choice. It is believed that binary 4550compatibility is not an issue, because this member function is 4551usually implemented as <tt>inline</tt>, and because it is already 4552the case that users cannot rely on the type of a pointer to a 4553nonvirtual member of a standard library class.</p> 4554<hr> 4555<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p> 4556<b>Section:</b> 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p> 4557<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision, 4558and includes a parenthetical note saying that it is the number of 4559digits after the decimal point.<br> 4560<br> 4561This claim is not strictly correct. For example, in the default 4562floating-point output format, setprecision sets the number of 4563significant digits printed, not the number of digits after the decimal 4564point.<br> 4565<br> 4566I would like the committee to look at the definition carefully and 4567correct the statement in 27.4.2.2</p> 4568<p><b>Proposed resolution:</b></p> 4569<p>Remove from 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text 4570"(number of digits after the decimal point)".</p> 4571<hr> 4572<a name="193"><h3>193. Heap operations description incorrect</h3></a><p> 4573<b>Section:</b> 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p> 4574<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them 4575is<br> 4576<br> 4577 `"(1) *a is the largest element"<br> 4578<br> 4579I think this is incorrect and should be changed to the wording in the proposed 4580resolution.</p> 4581<p>Actually there are two independent changes:</p> 4582<blockquote> 4583 <p>A-"part of largest equivalence class" instead of "largest", cause 25.3 4584 [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p> 4585 <p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions could not be used for a 4586 priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects priority AND time).</p> 4587</blockquote> 4588<p><b>Proposed resolution:</b></p> 4589<p>Change 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p> 4590<blockquote> 4591 <p>(1) *a is the largest element</p> 4592</blockquote> 4593<p>to:</p> 4594<blockquote> 4595 <p>(1) There is no element greater than <tt>*a</tt> 4596</p> 4597</blockquote> 4598<hr> 4599<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p> 4600<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p> 4601<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero. 4602What should <tt>basic_istream<>::sentry</tt>'s constructor do if it 4603reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it 4604should set failbit. Should it set eofbit as well? The standard 4605doesn't seem to answer that question.</p> 4606 4607<p>On the one hand, nothing in 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that 4608<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the 4609other hand, 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if 4610extraction from a <tt>streambuf</tt> "returns 4611<tt>traits::eof()</tt>, then the input function, except as explicitly 4612noted otherwise, completes its actions and does 4613<tt>setstate(eofbit)"</tt>. So the question comes down to 4614whether <tt>basic_istream<>::sentry</tt>'s constructor is an 4615input function.</p> 4616 4617<p>Comments from Jerry Schwarz:</p> 4618<blockquote> 4619<p>It was always my intention that eofbit should be set any time that a 4620virtual returned something to indicate eof, no matter what reason 4621iostream code had for calling the virtual.</p> 4622<p> 4623The motivation for this is that I did not want to require streambufs 4624to behave consistently if their virtuals are called after they have 4625signaled eof.</p> 4626<p> 4627The classic case is a streambuf reading from a UNIX file. EOF isn't 4628really a state for UNIX file descriptors. The convention is that a 4629read on UNIX returns 0 bytes to indicate "EOF", but the file 4630descriptor isn't shut down in any way and future reads do not 4631necessarily also return 0 bytes. In particular, you can read from 4632tty's on UNIX even after they have signaled "EOF". (It 4633isn't always understood that a ^D on UNIX is not an EOF indicator, but 4634an EOL indicator. By typing a "line" consisting solely of 4635^D you cause a read to return 0 bytes, and by convention this is 4636interpreted as end of file.)</p> 4637</blockquote> 4638<p><b>Proposed resolution:</b></p> 4639<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p> 4640<blockquote> 4641<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt> 4642returns <tt>traits::eof()</tt>, the function calls 4643<tt>setstate(failbit | eofbit)</tt> (which may throw 4644<tt>ios_base::failure</tt>). 4645</p> 4646</blockquote> 4647<hr> 4648<a name="198"><h3>198. Validity of pointers and references unspecified after iterator destruction</h3></a><p> 4649<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Nov 1999</p> 4650<p> 4651Is a pointer or reference obtained from an iterator still valid after 4652destruction of the iterator? 4653</p> 4654<p> 4655Is a pointer or reference obtained from an iterator still valid after the value 4656of the iterator changes? 4657</p> 4658<blockquote> 4659<pre> 4660#include <iostream> 4661#include <vector> 4662#include <iterator> 4663 4664int main() 4665{ 4666 typedef std::vector<int> vec_t; 4667 vec_t v; 4668 v.push_back( 1 ); 4669 4670 // Is a pointer or reference obtained from an iterator still 4671 // valid after destruction of the iterator? 4672 int * p = &*v.begin(); 4673 std::cout << *p << '\n'; // OK? 4674 4675 // Is a pointer or reference obtained from an iterator still 4676 // valid after the value of the iterator changes? 4677 vec_t::iterator iter( v.begin() ); 4678 p = &*iter++; 4679 std::cout << *p << '\n'; // OK? 4680 4681 return 0; 4682} 4683</pre> 4684</blockquote> 4685 4686<p>The standard doesn't appear to directly address these 4687questions. The standard needs to be clarified. At least two real-world 4688cases have been reported where library implementors wasted 4689considerable effort because of the lack of clarity in the 4690standard. The question is important because requiring pointers and 4691references to remain valid has the effect for practical purposes of 4692prohibiting iterators from pointing to cached rather than actual 4693elements of containers.</p> 4694 4695<p>The standard itself assumes that pointers and references obtained 4696from an iterator are still valid after iterator destruction or 4697change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines 4698effects:</p> 4699 4700<blockquote> 4701 <pre>Iterator tmp = current; 4702return *--tmp;</pre> 4703</blockquote> 4704<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 <a href="lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p> 4705<blockquote> 4706 <pre>return &(operator*());</pre> 4707</blockquote> 4708 4709<p>Because the standard itself assumes pointers and references remain 4710valid after iterator destruction or change, the standard should say so 4711explicitly. This will also reduce the chance of user code breaking 4712unexpectedly when porting to a different standard library 4713implementation.</p> 4714<p><b>Proposed resolution:</b></p> 4715<p>Add a new paragraph to 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p> 4716<blockquote> 4717Destruction of an iterator may invalidate pointers and references 4718previously obtained from that iterator. 4719</blockquote> 4720 4721<p>Replace paragraph 1 of 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p> 4722 4723<blockquote> 4724<p><b>Effects:</b></p> 4725<pre> 4726 this->tmp = current; 4727 --this->tmp; 4728 return *this->tmp; 4729</pre> 4730 4731<p> 4732[<i>Note:</i> This operation must use an auxiliary member variable, 4733rather than a temporary variable, to avoid returning a reference that 4734persists beyond the lifetime of its associated iterator. (See 473524.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.) The name of this member variable is shown for 4736exposition only. <i>--end note</i>] 4737</p> 4738</blockquote> 4739 4740<p><i>[Post-Tokyo: The issue has been reformulated purely 4741in terms of iterators.]</i></p> 4742 4743<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation 4744assumption by reverse_iterator. The issue and proposed resolution was 4745reformulated yet again to reflect this reality.]</i></p> 4746 4747<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator 4748assumes its underlying iterator has persistent pointers and 4749references. Andy Koenig pointed out that it is possible to rewrite 4750reverse_iterator so that it no longer makes such an assupmption. 4751However, this issue is related to issue <a href="lwg-active.html#299">299</a>. If we 4752decide it is intentional that <tt>p[n]</tt> may return by value 4753instead of reference when <tt>p</tt> is a Random Access Iterator, 4754other changes in reverse_iterator will be necessary.]</i></p> 4755<p><b>Rationale:</b></p> 4756<p>This issue has been discussed extensively. Note that it is 4757<i>not</i> an issue about the behavior of predefined iterators. It is 4758asking whether or not user-defined iterators are permitted to have 4759transient pointers and references. Several people presented examples 4760of useful user-defined iterators that have such a property; examples 4761include a B-tree iterator, and an "iota iterator" that doesn't point 4762to memory. Library implementors already seem to be able to cope with 4763such iterators: they take pains to avoid forming references to memory 4764that gets iterated past. The only place where this is a problem is 4765<tt>reverse_iterator</tt>, so this issue changes 4766<tt>reverse_iterator</tt> to make it work.</p> 4767 4768<p>This resolution does not weaken any guarantees provided by 4769predefined iterators like <tt>list<int>::iterator</tt>. 4770Clause 23 should be reviewed to make sure that guarantees for 4771predefined iterators are as strong as users expect.</p> 4772 4773<hr> 4774<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p> 4775<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p> 4776<p> 4777Suppose that <tt>A</tt> is a class that conforms to the 4778Allocator requirements of Table 32, and <tt>a</tt> is an 4779object of class <tt>A</tt> What should be the return 4780value of <tt>a.allocate(0)</tt>? Three reasonable 4781possibilities: forbid the argument <tt>0</tt>, return 4782a null pointer, or require that the return value be a 4783unique non-null pointer. 4784</p> 4785<p><b>Proposed resolution:</b></p> 4786<p> 4787Add a note to the <tt>allocate</tt> row of Table 32: 4788"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p> 4789<p><b>Rationale:</b></p> 4790<p>A key to understanding this issue is that the ultimate use of 4791allocate() is to construct an iterator, and that iterator for zero 4792length sequences must be the container's past-the-end 4793representation. Since this already implies special case code, it 4794would be over-specification to mandate the return value. 4795</p> 4796<hr> 4797<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p> 4798<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p> 4799<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and 4800past-the-end values are always non-singular."</p> 4801<p>This places an unnecessary restriction on past-the-end iterators for 4802containers with forward iterators (for example, a singly-linked list). If the 4803past-the-end value on such a container was a well-known singular value, it would 4804still satisfy all forward iterator requirements.</p> 4805<p>Removing this restriction would allow, for example, a singly-linked list 4806without a "footer" node.</p> 4807<p>This would have an impact on existing code that expects past-the-end 4808iterators obtained from different (generic) containers being not equal.</p> 4809<p><b>Proposed resolution:</b></p> 4810<p>Change 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p> 4811<blockquote> 4812<p>Dereferenceable and past-the-end values are always non-singular.</p> 4813</blockquote> 4814<p>to:</p> 4815<blockquote> 4816<p>Dereferenceable values are always non-singular. </p> 4817</blockquote> 4818<p><b>Rationale:</b></p> 4819<p>For some kinds of containers, including singly linked lists and 4820zero-length vectors, null pointers are perfectly reasonable past-the-end 4821iterators. Null pointers are singular. 4822</p> 4823<hr> 4824<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p> 4825<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p> 4826<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function 4827declarations use a consistent style except for the following functions:</p> 4828<blockquote> 4829 <pre>void push_back(const charT); 4830basic_string& assign(const basic_string&); 4831void swap(basic_string<charT,traits,Allocator>&);</pre> 4832</blockquote> 4833<p>- push_back, assign, swap: missing argument name <br> 4834- push_back: use of const with charT (i.e. POD type passed by value 4835not by reference - should be charT or const charT& )<br> 4836- swap: redundant use of template parameters in argument 4837basic_string<charT,traits,Allocator>&</p> 4838<p><b>Proposed resolution:</b></p> 4839<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member 4840function declarations push_back, assign, and swap to:</p> 4841<blockquote> 4842 <pre>void push_back(charT c); 4843 4844basic_string& assign(const basic_string& str); 4845void swap(basic_string& str);</pre> 4846</blockquote> 4847<p><b>Rationale:</b></p> 4848<p>Although the standard is in general not consistent in declaration 4849style, the basic_string declarations are consistent other than the 4850above. The LWG felt that this was sufficient reason to merit the 4851change. 4852</p> 4853<hr> 4854<a name="210"><h3>210. distance first and last confused</h3></a><p> 4855<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p> 4856<p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p> 4857<blockquote> 4858 <p> In the description of the algorithms operators + and - are used 4859 for some of the iterator categories for which they do not have to 4860 be defined. In these cases the semantics of [...] a-b is the same 4861 as of<br> 4862 <br> 4863 <tt>return distance(a, b);</tt> 4864</p> 4865</blockquote> 4866<p><b>Proposed resolution:</b></p> 4867<p>On the last line of paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change 4868<tt>"a-b"</tt> to <tt>"b-a".</tt> 4869</p> 4870<p><b>Rationale:</b></p> 4871<p>There are two ways to fix the defect; change the description to b-a 4872or change the return to distance(b,a). The LWG preferred the 4873former for consistency.</p> 4874<hr> 4875<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p> 4876<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p> 4877<p>The description of the stream extraction operator for std::string (section 487821.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in 4879the case that the operator fails to extract any characters from the input 4880stream.</p> 4881<p>This implies that the typical construction</p> 4882<blockquote> 4883 <pre>std::istream is; 4884std::string str; 4885... 4886while (is >> str) ... ;</pre> 4887</blockquote> 4888<p>(which tests failbit) is not required to terminate at EOF.</p> 4889<p>Furthermore, this is inconsistent with other extraction operators, 4890which do include this requirement. (See sections 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this 4891requirement is present, either explicitly or implicitly, for the 4892extraction operators. It is also present explicitly in the description 4893of getline (istream&, string&, charT) in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p> 4894<p><b>Proposed resolution:</b></p> 4895<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p> 4896<blockquote> 4897 4898<p>If the function extracts no characters, it calls 4899is.setstate(ios::failbit) which may throw ios_base::failure 4900(27.4.4.3).</p> 4901</blockquote> 4902<hr> 4903<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p> 4904<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p> 4905<p>The standard doesn't specify what min_element() and max_element() shall 4906return if the range is empty (first equals last). The usual implementations 4907return last. This problem seems also apply to partition(), stable_partition(), 4908next_permutation(), and prev_permutation().</p> 4909<p><b>Proposed resolution:</b></p> 4910<p>In 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and 49119, append: Returns last if first==last.</p> 4912<p><b>Rationale:</b></p> 4913<p>The LWG looked in some detail at all of the above mentioned 4914algorithms, but believes that except for min_element() and 4915max_element() it is already clear that last is returned if first == 4916last.</p> 4917<hr> 4918<a name="214"><h3>214. set::find() missing const overload</h3></a><p> 4919<b>Section:</b> 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 28 Feb 2000</p> 4920<p>The specification for the associative container requirements in 4921Table 69 state that the find member function should "return 4922iterator; const_iterator for constant a". The map and multimap 4923container descriptions have two overloaded versions of find, but set 4924and multiset do not, all they have is:</p> 4925<blockquote> 4926 <pre>iterator find(const key_type & x) const;</pre> 4927</blockquote> 4928<p><b>Proposed resolution:</b></p> 4929<p>Change the prototypes for find(), lower_bound(), upper_bound(), and 4930equal_range() in section 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p> 4931<blockquote> 4932 <pre>iterator find(const key_type & x); 4933const_iterator find(const key_type & x) const;</pre> 4934 <pre>iterator lower_bound(const key_type & x); 4935const_iterator lower_bound(const key_type & x) const;</pre> 4936 <pre>iterator upper_bound(const key_type & x); 4937const_iterator upper_bound(const key_type & x) const;</pre> 4938 <pre>pair<iterator, iterator> equal_range(const key_type & x); 4939pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre> 4940</blockquote> 4941 4942<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording 4943extending the proposed resolution to lower_bound, upper_bound, and 4944equal_range.]</i></p> 4945<hr> 4946<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p> 4947<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p> 4948<p>The example in 22.2.8, paragraph 11 contains the following errors:</p> 4949<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function 4950must be const in order for it to be callable on a const object (a reference to 4951which which is what std::use_facet<>() returns).</p> 4952<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the 4953name of the namespace `My'.</p> 4954<p>3) In the definition of `loc' and subsequently in the call to use_facet<>() 4955in main(), the name of the facet is misspelled: it should read `My::JCtype' 4956rather than `My::JCType'.</p> 4957<p><b>Proposed resolution:</b></p> 4958<p>Replace the "Classifying Japanese characters" example in 22.2.8, 4959paragraph 11 with the following:</p> 4960<pre>#include <locale></pre> 4961<pre>namespace My { 4962 using namespace std; 4963 class JCtype : public locale::facet { 4964 public: 4965 static locale::id id; // required for use as a new locale facet 4966 bool is_kanji (wchar_t c) const; 4967 JCtype() {} 4968 protected: 4969 ~JCtype() {} 4970 }; 4971}</pre> 4972<pre>// file: filt.C 4973#include <iostream> 4974#include <locale> 4975#include "jctype" // above 4976std::locale::id My::JCtype::id; // the static JCtype member 4977declared above.</pre> 4978<pre>int main() 4979{ 4980 using namespace std; 4981 typedef ctype<wchar_t> wctype; 4982 locale loc(locale(""), // the user's preferred locale... 4983 new My::JCtype); // and a new feature ... 4984 wchar_t c = use_facet<wctype>(loc).widen('!'); 4985 if (!use_facet<My::JCtype>(loc).is_kanji(c)) 4986 cout << "no it isn't!" << endl; 4987 return 0; 4988}</pre> 4989<hr> 4990<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p> 4991<b>Section:</b> 27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p> 4992<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7 4993paragraph 2:</p> 4994<blockquote> 4995 <p>Effects: Destroys an object of class ios_base. Calls each registered 4996 callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such 4997 time that any ios_base member function called from within fn has well defined 4998 results.</p> 4999</blockquote> 5000<p>But what is not clear is: If no callback functions were ever registered, does 5001it matter whether the ios_base members were ever initialized?</p> 5002<p>For instance, does this program have defined behavior:</p> 5003<blockquote> 5004 <pre>#include <ios></pre> 5005 <pre>class D : public std::ios_base { };</pre> 5006 <pre>int main() { D d; }</pre> 5007</blockquote> 5008<p>It seems that registration of a callback function would surely affect the 5009state of an ios_base. That is, when you register a callback function with an 5010ios_base, the ios_base must record that fact somehow.</p> 5011<p>But if after construction the ios_base is in an indeterminate state, and that 5012state is not made determinate before the destructor is called, then how would 5013the destructor know if any callbacks had indeed been registered? And if the 5014number of callbacks that had been registered is indeterminate, then is not the 5015behavior of the destructor undefined?</p> 5016<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes 5017it explicit that destruction before initialization results in undefined 5018behavior.</p> 5019<p><b>Proposed resolution:</b></p> 5020<p>Modify 27.4.2.7 paragraph 1 from</p> 5021<blockquote> 5022 <p>Effects: Each ios_base member has an indeterminate value after 5023 construction.</p> 5024</blockquote> 5025<p>to</p> 5026<blockquote> 5027 <p>Effects: Each ios_base member has an indeterminate value after 5028 construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations 5029 have taken place, the behavior is undefined.</p> 5030</blockquote> 5031<hr> 5032<a name="221"><h3>221. num_get<>::do_get stage 2 processing broken</h3></a><p> 5033<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Mar 2000</p> 5034<p>Stage 2 processing of numeric conversion is broken.</p> 5035 5036<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral 5037conversion specifier is %i. A %i specifier determines a number's base 5038by its prefix (0 for octal, 0x for hex), so the intention is clearly 5039that a 0x prefix is allowed. Paragraph 8 in the same section, 5040however, describes very precisely how characters are processed. (It 5041must be done "as if" by a specified code fragment.) That 5042description does not allow a 0x prefix to be recognized.</p> 5043 5044<p>Very roughly, stage 2 processing reads a char_type ct. It converts 5045ct to a char, not by using narrow but by looking it up in a 5046translation table that was created by widening the string literal 5047"0123456789abcdefABCDEF+-". The character "x" is 5048not found in that table, so it can't be recognized by stage 2 5049processing.</p> 5050<p><b>Proposed resolution:</b></p> 5051<p>In 22.2.2.1.2 paragraph 8, replace the line:</p> 5052<blockquote> 5053 <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre> 5054</blockquote> 5055<p>with the line:</p> 5056<blockquote> 5057 <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre> 5058</blockquote> 5059<p><b>Rationale:</b></p> 5060<p>If we're using the technique of widening a string literal, the 5061string literal must contain every character we wish to recognize. 5062This technique has the consequence that alternate representations 5063of digits will not be recognized. This design decision was made 5064deliberately, with full knowledge of that limitation.</p> 5065<hr> 5066<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p> 5067<b>Section:</b> 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p> 5068<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p> 5069<blockquote> 5070 <pre>21.3.6.8 - basic_string::compare [lib.string::compare] 5071 5072int compare(size_type pos1, size_type n1, 5073 const basic_string<charT,traits,Allocator>& str , 5074 size_type pos2 , size_type n2 ) const; 5075 5076-4- Returns: 5077 5078 basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( 5079 basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre> 5080</blockquote> 5081<p>and the constructor that's implicitly called by the above is 5082defined to throw an out-of-range exception if pos > str.size(). See 5083section 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p> 5084 5085<p>On the other hand, the compare function descriptions themselves don't have 5086"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements 5087that do not apply to a function are omitted.</p> 5088<p>So it seems there is an inconsistency in the standard -- are the 5089"Effects" clauses correct, or are the "Throws" clauses 5090missing?</p> 5091<p><b>Proposed resolution:</b></p> 5092<p>In 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to 5093the sentence "Descriptions of function semantics contain the 5094following elements (as appropriate):", insert the word 5095"further" so that the foot note reads:</p> 5096<blockquote> 5097 <p>To save space, items that do not apply to a function are 5098 omitted. For example, if a function does not specify any further 5099 preconditions, there will be no "Requires" paragraph.</p> 5100</blockquote> 5101<p><b>Rationale:</b></p> 5102<p>The standard is somewhat inconsistent, but a failure to note a 5103throw condition in a throws clause does not grant permission not to 5104throw. The inconsistent wording is in a footnote, and thus 5105non-normative. The proposed resolution from the LWG clarifies the 5106footnote.</p> 5107<hr> 5108<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p> 5109<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p> 5110<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p> 5111<p><b>Proposed resolution:</b></p> 5112<p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p> 5113 <blockquote> 5114 Effects: For each non-negative integer i <= (last - first)/2, 5115 applies swap to all pairs of iterators first + i, (last - i) - 1. 5116 </blockquote> 5117<p>with:</p> 5118 <blockquote> 5119 Effects: For each non-negative integer i <= (last - first)/2, 5120 applies iter_swap to all pairs of iterators first + i, (last - i) - 1. 5121 </blockquote> 5122<hr> 5123<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p> 5124<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p> 5125<p>In the associative container requirements table in 23.1.2 paragraph 7, 5126a.clear() has complexity "log(size()) + N". However, the meaning of N 5127is not defined.</p> 5128<p><b>Proposed resolution:</b></p> 5129<p>In the associative container requirements table in 23.1.2 paragraph 51307, the complexity of a.clear(), change "log(size()) + N" to 5131"linear in <tt>size()</tt>".</p> 5132<p><b>Rationale:</b></p> 5133<p>It's the "log(size())", not the "N", that is in 5134error: there's no difference between <i>O(N)</i> and <i>O(N + 5135log(N))</i>. The text in the standard is probably an incorrect 5136cut-and-paste from the range version of <tt>erase</tt>.</p> 5137<hr> 5138<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p> 5139<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p> 5140<p>25.2.2 reads:</p> 5141<blockquote> 5142 <p> 5143<tt> template<class T> void swap(T& a, T& b);</tt><br> 5144 <br> 5145 Requires: Type T is Assignable (_lib.container.requirements_).<br> 5146 Effects: Exchanges values stored in two locations.</p> 5147</blockquote> 5148<p>The only reasonable** generic implementation of swap requires construction of a 5149 new temporary copy of one of its arguments:</p> 5150<blockquote> 5151<pre>template<class T> void swap(T& a, T& b); 5152 { 5153 T tmp(a); 5154 a = b; 5155 b = tmp; 5156 }</pre> 5157</blockquote> 5158<p>But a type which is only Assignable cannot be swapped by this implementation.</p> 5159<p>**Yes, there's also an unreasonable implementation which would require T to be 5160 DefaultConstructible instead of CopyConstructible. I don't think this is worthy 5161 of consideration:</p> 5162<blockquote> 5163<pre>template<class T> void swap(T& a, T& b); 5164{ 5165 T tmp; 5166 tmp = a; 5167 a = b; 5168 b = tmp; 5169}</pre> 5170</blockquote> 5171<p><b>Proposed resolution:</b></p> 5172<p>Change 25.2.2 paragraph 1 from:</p> 5173<blockquote> 5174<p> Requires: Type T is Assignable (23.1).</p> 5175</blockquote> 5176<p>to:</p> 5177<blockquote> 5178<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p> 5179</blockquote> 5180<hr> 5181<a name="228"><h3>228. Incorrect specification of "..._byname" facets</h3></a><p> 5182<b>Section:</b> 22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p> 5183<p>The sections 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>, 518422.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the 5185definitions of the "..._byname" classes by listing a bunch 5186of virtual functions. At the same time, no semantics of these 5187functions are defined. Real implementations do not define these 5188functions because the functional part of the facets is actually 5189implemented in the corresponding base classes and the constructor of 5190the "..._byname" version just provides suitable date used by 5191these implementations. For example, the 'numpunct' methods just return 5192values from a struct. The base class uses a statically initialized 5193struct while the derived version reads the contents of this struct 5194from a table. However, no virtual function is defined in 5195'numpunct_byname'.</p> 5196 5197<p>For most classes this does not impose a problem but specifically 5198for 'ctype' it does: The specialization for 'ctype_byname<char>' 5199is required because otherwise the semantics would change due to the 5200virtual functions defined in the general version for 'ctype_byname': 5201In 'ctype<char>' the method 'do_is()' is not virtual but it is 5202made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'. 5203Thus, a class derived from 'ctype_byname<char>' can tell whether 5204this class is specialized or not under the current specification: 5205Without the specialization, 'do_is()' is virtual while with 5206specialization it is not virtual.</p> 5207<p><b>Proposed resolution:</b></p> 5208<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p> 5209<pre> namespace std { 5210 template <class charT> 5211 class ctype_byname : public ctype<charT> { 5212 public: 5213 typedef ctype<charT>::mask mask; 5214 explicit ctype_byname(const char*, size_t refs = 0); 5215 protected: 5216 ~ctype_byname(); // virtual 5217 }; 5218 }</pre> 5219<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p> 5220<pre> namespace std { 5221 template <class internT, class externT, class stateT> 5222 class codecvt_byname : public codecvt<internT, externT, stateT> { 5223 public: 5224 explicit codecvt_byname(const char*, size_t refs = 0); 5225 protected: 5226 ~codecvt_byname(); // virtual 5227 }; 5228 } 5229</pre> 5230<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p> 5231<pre> namespace std { 5232 template <class charT> 5233 class numpunct_byname : public numpunct<charT> { 5234 // this class is specialized for char and wchar_t. 5235 public: 5236 typedef charT char_type; 5237 typedef basic_string<charT> string_type; 5238 explicit numpunct_byname(const char*, size_t refs = 0); 5239 protected: 5240 ~numpunct_byname(); // virtual 5241 }; 5242 }</pre> 5243<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p> 5244<pre> namespace std { 5245 template <class charT> 5246 class collate_byname : public collate<charT> { 5247 public: 5248 typedef basic_string<charT> string_type; 5249 explicit collate_byname(const char*, size_t refs = 0); 5250 protected: 5251 ~collate_byname(); // virtual 5252 }; 5253 }</pre> 5254<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p> 5255<pre> namespace std { 5256 template <class charT, class InputIterator = istreambuf_iterator<charT> > 5257 class time_get_byname : public time_get<charT, InputIterator> { 5258 public: 5259 typedef time_base::dateorder dateorder; 5260 typedef InputIterator iter_type</pre> 5261<pre> explicit time_get_byname(const char*, size_t refs = 0); 5262 protected: 5263 ~time_get_byname(); // virtual 5264 }; 5265 }</pre> 5266<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p> 5267<pre> namespace std { 5268 template <class charT, class OutputIterator = ostreambuf_iterator<charT> > 5269 class time_put_byname : public time_put<charT, OutputIterator> 5270 { 5271 public: 5272 typedef charT char_type; 5273 typedef OutputIterator iter_type;</pre> 5274<pre> explicit time_put_byname(const char*, size_t refs = 0); 5275 protected: 5276 ~time_put_byname(); // virtual 5277 }; 5278 }"</pre> 5279<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p> 5280<pre> namespace std { 5281 template <class charT, bool Intl = false> 5282 class moneypunct_byname : public moneypunct<charT, Intl> { 5283 public: 5284 typedef money_base::pattern pattern; 5285 typedef basic_string<charT> string_type;</pre> 5286<pre> explicit moneypunct_byname(const char*, size_t refs = 0); 5287 protected: 5288 ~moneypunct_byname(); // virtual 5289 }; 5290 }</pre> 5291<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p> 5292<pre> namespace std { 5293 template <class charT> 5294 class messages_byname : public messages<charT> { 5295 public: 5296 typedef messages_base::catalog catalog; 5297 typedef basic_string<charT> string_type;</pre> 5298<pre> explicit messages_byname(const char*, size_t refs = 0); 5299 protected: 5300 ~messages_byname(); // virtual 5301 }; 5302 }</pre> 5303<p>Remove section 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in 5304this case only those members are defined to be virtual which are 5305defined to be virtual in 'ctype<cT>'.)</p> 5306 5307<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of 5308the LWG to solve the underlying problems raised by issue <a href="lwg-closed.html#138">138</a>.]</i></p> 5309 5310<p><i>[Copenhagen: proposed resolution was revised slightly, to remove 5311three last virtual functions from <tt>messages_byname</tt>.]</i></p> 5312 5313<hr> 5314<a name="230"><h3>230. Assignable specified without also specifying CopyConstructible</h3></a><p> 5315<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 26 Apr 2000</p> 5316<p>Issue <a href="lwg-defects.html#227">227</a> identified an instance (std::swap) where 5317Assignable was specified without also specifying 5318CopyConstructible. The LWG asked that the standard be searched to 5319determine if the same defect existed elsewhere.</p> 5320 5321<p>There are a number of places (see proposed resolution below) where 5322Assignable is specified without also specifying 5323CopyConstructible. There are also several cases where both are 5324specified. For example, 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p> 5325<p><b>Proposed resolution:</b></p> 5326<p>In 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type: 5327change "T is Assignable" to "T is CopyConstructible and 5328Assignable" 5329</p> 5330 5331<p>In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change 5332"Key is Assignable" to "Key is 5333CopyConstructible and Assignable"<br> 5334</p> 5335 5336<p>In 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change: 5337</p> 5338<blockquote> 5339<p> A class or a built-in type X satisfies the requirements of an 5340output iterator if X is an Assignable type (23.1) and also the 5341following expressions are valid, as shown in Table 73: 5342</p> 5343</blockquote> 5344<p>to: 5345</p> 5346<blockquote> 5347<p> A class or a built-in type X satisfies the requirements of an 5348output iterator if X is a CopyConstructible (20.1.3) and Assignable 5349type (23.1) and also the following expressions are valid, as shown in 5350Table 73: 5351</p> 5352</blockquote> 5353 5354<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of 5355the LWG. He asks that the 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that 5356CopyConstructible is really a requirement and may be 5357overspecification.]</i></p> 5358<p><b>Rationale:</b></p> 5359<p>The original proposed resolution also included changes to input 5360iterator, fill, and replace. The LWG believes that those changes are 5361not necessary. The LWG considered some blanket statement, where an 5362Assignable type was also required to be Copy Constructible, but 5363decided against this because fill and replace really don't require the 5364Copy Constructible property.</p> 5365<hr> 5366<a name="232"><h3>232. "depends" poorly defined in 17.4.3.1</h3></a><p> 5367<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 18 Apr 2000</p> 5368<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed 5369specializations of standard templates to those that "depend on a 5370user-defined name of external linkage."</p> 5371<p>This term, however, is not adequately defined, making it possible to 5372construct a specialization that is, I believe, technically legal according to 537317.4.3.1/1, but that specializes a standard template for a built-in type such as 5374'int'.</p> 5375<p>The following code demonstrates the problem:</p> 5376<blockquote> 5377 <pre>#include <algorithm></pre> 5378 <pre>template<class T> struct X 5379{ 5380 typedef T type; 5381};</pre> 5382 <pre>namespace std 5383{ 5384 template<> void swap(::X<int>::type& i, ::X<int>::type& j); 5385}</pre> 5386</blockquote> 5387<p><b>Proposed resolution:</b></p> 5388<p>Change "user-defined name" to "user-defined 5389type".</p> 5390<p><b>Rationale:</b></p> 5391<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++ 5392Programming Language</i>. It disallows the example in the issue, 5393since the underlying type itself is not user-defined. The only 5394possible problem I can see is for non-type templates, but there's no 5395possible way for a user to come up with a specialization for bitset, 5396for example, that might not have already been specialized by the 5397implementor?</p> 5398 5399<p><i>[Toronto: this may be related to issue <a href="lwg-active.html#120">120</a>.]</i></p> 5400 5401<p><i>[post-Toronto: Judy provided the above proposed resolution and 5402rationale.]</i></p> 5403<hr> 5404<a name="234"><h3>234. Typos in allocator definition</h3></a><p> 5405<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> 5406<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and 5407<tt>destruct()</tt> are described as returns but the functions actually 5408return <tt>void</tt>.</p> 5409<p><b>Proposed resolution:</b></p> 5410<p>Substitute "Returns" by "Effect".</p> 5411<hr> 5412<a name="235"><h3>235. No specification of default ctor for reverse_iterator</h3></a><p> 5413<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> 5414<p>The declaration of <tt>reverse_iterator</tt> lists a default 5415constructor. However, no specification is given what this constructor 5416should do.</p> 5417<p><b>Proposed resolution:</b></p> 5418 <p>In section 24.4.1.3.1 <a href="lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following 5419 paragraph:</p> 5420 <blockquote> 5421 <p><tt>reverse_iterator()</tt></p> 5422 5423 <p>Default initializes <tt>current</tt>. Iterator operations 5424 applied to the resulting iterator have defined behavior if and 5425 only if the corresponding operations are defined on a default 5426 constructed iterator of type <tt>Iterator</tt>.</p> 5427 </blockquote> 5428 <p><i>[pre-Copenhagen: Dietmar provide wording for proposed 5429 resolution.]</i></p> 5430<hr> 5431<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p> 5432<b>Section:</b> 23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> 5433<p>The complexity specification in paragraph 6 says that the complexity 5434is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is 5435defined on iterators this term is in general undefined because it 5436would have to be <tt>last - first</tt>.</p> 5437<p><b>Proposed resolution:</b></p> 5438 <p>Change paragraph 6 from</p> 5439 <blockquote>Linear in <i>first - last</i>.</blockquote> 5440 <p>to become</p> 5441 <blockquote>Linear in <i>distance(first, last)</i>.</blockquote> 5442<hr> 5443<a name="238"><h3>238. Contradictory results of stringbuf initialization.</h3></a><p> 5444<b>Section:</b> 27.7.1.1 <a href="lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 11 May 2000</p> 5445<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of 5446'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine 5447that far but consider this code:</p> 5448 5449<pre> 5450 std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0)); 5451 std::cout << "'" << sbuf.str() << "'\n"; 5452</pre> 5453 5454<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither 5455the output sequence nor the input sequence is initialized and 5456paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either 5457returns the input or the output sequence. None of them is initialized, 5458ie. both are empty, in which case the return from <tt>str()</tt> is 5459defined to be <tt>basic_string<cT>()</tt>.</p> 5460 5461<p>However, probably only test cases in some testsuites will detect this 5462"problem"...</p> 5463<p><b>Proposed resolution:</b></p> 5464<p>Remove 27.7.1.1 paragraph 4.</p> 5465<p><b>Rationale:</b></p> 5466<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If 5467we fixed it, it would say just the same thing as text that's already 5468in the standard.</p> 5469<hr> 5470<a name="239"><h3>239. Complexity of unique() and/or unique_copy incorrect</h3></a><p> 5471<b>Section:</b> 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p> 5472<p>The complexity of unique and unique_copy are inconsistent with each 5473other and inconsistent with the implementations. The standard 5474specifies:</p> 5475 5476<p>for unique():</p> 5477 5478<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly 5479(last - first) - 1 applications of the corresponding predicate, otherwise 5480no applications of the predicate.</blockquote> 5481 5482<p>for unique_copy():</p> 5483 5484<blockquote>-7- Complexity: Exactly last - first applications of the corresponding 5485predicate.</blockquote> 5486 5487<p> 5488The implementations do it the other way round: unique() applies the 5489predicate last-first times and unique_copy() applies it last-first-1 5490times.</p> 5491 5492<p>As both algorithms use the predicate for pair-wise comparison of 5493sequence elements I don't see a justification for unique_copy() 5494applying the predicate last-first times, especially since it is not 5495specified to which pair in the sequence the predicate is applied 5496twice.</p> 5497<p><b>Proposed resolution:</b></p> 5498<p>Change both complexity sections in 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p> 5499 5500<blockquote>Complexity: For nonempty ranges, exactly last - first - 1 5501applications of the corresponding predicate.</blockquote> 5502 5503<hr> 5504<a name="240"><h3>240. Complexity of adjacent_find() is meaningless</h3></a><p> 5505<b>Section:</b> 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p> 5506<p>The complexity section of adjacent_find is defective:</p> 5507 5508<blockquote> 5509<pre> 5510template <class ForwardIterator> 5511ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last 5512 BinaryPredicate pred); 5513</pre> 5514 5515<p>-1- Returns: The first iterator i such that both i and i + 1 are in 5516the range [first, last) for which the following corresponding 5517conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns 5518last if no such iterator is found.</p> 5519 5520<p>-2- Complexity: Exactly find(first, last, value) - first applications 5521of the corresponding predicate. 5522</p> 5523</blockquote> 5524 5525<p>In the Complexity section, it is not defined what "value" 5526is supposed to mean. My best guess is that "value" means an 5527object for which one of the conditions pred(*i,value) or 5528pred(value,*i) is true, where i is the iterator defined in the Returns 5529section. However, the value type of the input sequence need not be 5530equality-comparable and for this reason the term find(first, last, 5531value) - first is meaningless.</p> 5532 5533<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or 5534find_if(first, last, bind1st(pred,*i)) - first might come closer to 5535the intended specification. Binders can only be applied to function 5536objects that have the function call operator declared const, which is 5537not required of predicates because they can have non-const data 5538members. For this reason, a specification using a binder could only be 5539an "as-if" specification.</p> 5540<p><b>Proposed resolution:</b></p> 5541<p>Change the complexity section in 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p> 5542<blockquote> 5543For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1, 5544(<i>last</i> - <i>first</i>) - 1)</tt> applications of the 5545corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s 5546return value. 5547</blockquote> 5548 5549<p><i>[Copenhagen: the original resolution specified an upper 5550bound. The LWG preferred an exact count.]</i></p> 5551 5552<hr> 5553<a name="242"><h3>242. Side effects of function objects</h3></a><p> 5554<b>Section:</b> 25.2.3 <a href="lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p> 5555<p>The algorithms transform(), accumulate(), inner_product(), 5556partial_sum(), and adjacent_difference() require that the function 5557object supplied to them shall not have any side effects.</p> 5558 5559<p>The standard defines a side effect in 1.9 <a href="intro.html#intro.execution"> [intro.execution]</a> as:</p> 5560<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval), 5561modifying an object, calling a library I/O function, or calling a function 5562that does any of those operations are all side effects, which are changes 5563in the state of the execution environment.</blockquote> 5564 5565<p>As a consequence, the function call operator of a function object supplied 5566to any of the algorithms listed above cannot modify data members, cannot 5567invoke any function that has a side effect, and cannot even create and 5568modify temporary objects. It is difficult to imagine a function object 5569that is still useful under these severe limitations. For instance, any 5570non-trivial transformator supplied to transform() might involve creation 5571and modification of temporaries, which is prohibited according to the current 5572wording of the standard.</p> 5573 5574<p>On the other hand, popular implementations of these algorithms exhibit 5575uniform and predictable behavior when invoked with a side-effect-producing 5576function objects. It looks like the strong requirement is not needed for 5577efficient implementation of these algorithms.</p> 5578 5579<p>The requirement of side-effect-free function objects could be 5580replaced by a more relaxed basic requirement (which would hold for all 5581function objects supplied to any algorithm in the standard library):</p> 5582<blockquote>A function objects supplied to an algorithm shall not invalidate 5583any iterator or sequence that is used by the algorithm. Invalidation of 5584the sequence includes destruction of the sorting order if the algorithm 5585relies on the sorting order (see section 25.3 - Sorting and related operations 5586[lib.alg.sorting]).</blockquote> 5587 5588<p>I can't judge whether it is intended that the function objects supplied 5589to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference() 5590shall not modify sequence elements through dereferenced iterators.</p> 5591 5592<p>It is debatable whether this issue is a defect or a change request. 5593Since the consequences for user-supplied function objects are drastic and 5594limit the usefulness of the algorithms significantly I would consider it 5595a defect.</p> 5596<p><b>Proposed resolution:</b></p> 5597 5598<p><i>Things to notice about these changes:</i></p> 5599 5600<ol> 5601<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges 5602 are intentional. we want to prevent side-effects from 5603 invalidating the end iterators.</i> 5604</li> 5605 5606<li> <i>That has the unintentional side-effect of prohibiting 5607 modification of the end element as a side-effect. This could 5608 conceivably be significant in some cases.</i> 5609</li> 5610 5611<li> <i>The wording also prevents side-effects from modifying elements 5612 of the output sequence. I can't imagine why anyone would want 5613 to do this, but it is arguably a restriction that implementors 5614 don't need to place on users.</i> 5615</li> 5616 5617<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible 5618 and simple, but would require more verbiage.</i> 5619</li> 5620</ol> 5621 5622<p>Change 25.2.3/2 from:</p> 5623 5624<blockquote> 5625 -2- Requires: op and binary_op shall not have any side effects. 5626</blockquote> 5627 5628<p>to:</p> 5629 5630<blockquote> 5631 -2- Requires: in the ranges [first1, last1], [first2, first2 + 5632 (last1 - first1)] and [result, result + (last1- first1)], op and 5633 binary_op shall neither modify elements nor invalidate iterators or 5634 subranges. 5635 [Footnote: The use of fully closed ranges is intentional --end footnote] 5636</blockquote> 5637 5638 5639<p>Change 25.2.3/2 from:</p> 5640 5641<blockquote> 5642 -2- Requires: op and binary_op shall not have any side effects. 5643</blockquote> 5644 5645<p>to:</p> 5646 5647<blockquote> 5648 -2- Requires: op and binary_op shall not invalidate iterators or 5649 subranges, or modify elements in the ranges [first1, last1], 5650 [first2, first2 + (last1 - first1)], and [result, result + (last1 5651 - first1)]. 5652 [Footnote: The use of fully closed ranges is intentional --end footnote] 5653</blockquote> 5654 5655 5656<p>Change 26.4.1/2 from:</p> 5657 5658<blockquote> 5659 -2- Requires: T must meet the requirements of CopyConstructible 5660 (lib.copyconstructible) and Assignable (lib.container.requirements) 5661 types. binary_op shall not cause side effects. 5662</blockquote> 5663 5664<p>to:</p> 5665 5666<blockquote> 5667 -2- Requires: T must meet the requirements of CopyConstructible 5668 (lib.copyconstructible) and Assignable 5669 (lib.container.requirements) types. In the range [first, last], 5670 binary_op shall neither modify elements nor invalidate iterators 5671 or subranges. 5672 [Footnote: The use of a fully closed range is intentional --end footnote] 5673</blockquote> 5674 5675<p>Change 26.4.2/2 from:</p> 5676 5677<blockquote> 5678 -2- Requires: T must meet the requirements of CopyConstructible 5679 (lib.copyconstructible) and Assignable (lib.container.requirements) 5680 types. binary_op1 and binary_op2 shall not cause side effects. 5681</blockquote> 5682 5683<p>to:</p> 5684 5685<blockquote> 5686 -2- Requires: T must meet the requirements of CopyConstructible 5687 (lib.copyconstructible) and Assignable (lib.container.requirements) 5688 types. In the ranges [first, last] and [first2, first2 + (last - 5689 first)], binary_op1 and binary_op2 shall neither modify elements 5690 nor invalidate iterators or subranges. 5691 [Footnote: The use of fully closed ranges is intentional --end footnote] 5692</blockquote> 5693 5694 5695<p>Change 26.4.3/4 from:</p> 5696 5697<blockquote> 5698 -4- Requires: binary_op is expected not to have any side effects. 5699</blockquote> 5700 5701<p>to:</p> 5702 5703<blockquote> 5704 -4- Requires: In the ranges [first, last] and [result, result + 5705 (last - first)], binary_op shall neither modify elements nor 5706 invalidate iterators or subranges. 5707 [Footnote: The use of fully closed ranges is intentional --end footnote] 5708</blockquote> 5709 5710<p>Change 26.4.4/2 from:</p> 5711 5712<blockquote> 5713 -2- Requires: binary_op shall not have any side effects. 5714</blockquote> 5715 5716<p>to:</p> 5717 5718<blockquote> 5719 -2- Requires: In the ranges [first, last] and [result, result + 5720 (last - first)], binary_op shall neither modify elements nor 5721 invalidate iterators or subranges. 5722 [Footnote: The use of fully closed ranges is intentional --end footnote] 5723</blockquote> 5724 5725<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p> 5726 5727<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt 5728added footnotes pointing out that the use of closed ranges was 5729intentional.]</i></p> 5730 5731<hr> 5732<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p> 5733<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p> 5734<p>basic_istream<>::get(), and basic_istream<>::getline(), 5735are unclear with respect to the behavior and side-effects of the named 5736functions in case of an error.</p> 5737 5738<p>27.6.1.3, p1 states that "... If the sentry object returns 5739true, when converted to a value of type bool, the function endeavors 5740to obtain the requested input..." It is not clear from this (or 5741the rest of the paragraph) what precisely the behavior should be when 5742the sentry ctor exits by throwing an exception or when the sentry 5743object returns false. In particular, what is the number of characters 5744extracted that gcount() returns supposed to be?</p> 5745 5746<p>27.6.1.3 p8 and p19 say about the effects of get() and getline(): 5747"... In any case, it then stores a null character (using 5748charT()) into the next successive location of the array." Is not 5749clear whether this sentence applies if either of the conditions above 5750holds (i.e., when sentry fails).</p> 5751<p><b>Proposed resolution:</b></p> 5752<p>Add to 27.6.1.3, p1 after the sentence</p> 5753 5754<blockquote> 5755"... If the sentry object returns true, when converted to a value of 5756type bool, the function endeavors to obtain the requested input." 5757</blockquote> 5758 5759<p>the following</p> 5760 5761 5762<blockquote> 5763"Otherwise, if the sentry constructor exits by throwing an exception or 5764if the sentry object returns false, when converted to a value of type 5765bool, the function returns without attempting to obtain any input. In 5766either case the number of extracted characters is set to 0; unformatted 5767input functions taking a character array of non-zero size as an argument 5768shall also store a null character (using charT()) in the first location 5769of the array." 5770</blockquote> 5771<p><b>Rationale:</b></p> 5772<p>Although the general philosophy of the input functions is that the 5773argument should not be modified upon failure, <tt>getline</tt> 5774historically added a terminating null unconditionally. Most 5775implementations still do that. Earlier versions of the draft standard 5776had language that made this an unambiguous requirement; those words 5777were moved to a place where their context made them less clear. See 5778Jerry Schwarz's message c++std-lib-7618.</p> 5779<hr> 5780<a name="248"><h3>248. time_get fails to set eofbit</h3></a><p> 5781<b>Section:</b> 22.2.5 <a href="lib-locales.html#lib.category.time"> [lib.category.time]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2000</p> 5782<p>There is no requirement that any of time_get member functions set 5783ios::eofbit when they reach the end iterator while parsing their input. 5784Since members of both the num_get and money_get facets are required to 5785do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members 5786should follow the same requirement for consistency.</p> 5787<p><b>Proposed resolution:</b></p> 5788<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p> 5789 5790<blockquote> 5791If the end iterator is reached during parsing by any of the get() 5792member functions, the member sets ios_base::eofbit in err. 5793</blockquote> 5794<p><b>Rationale:</b></p> 5795<p>Two alternative resolutions were proposed. The LWG chose this one 5796because it was more consistent with the way eof is described for other 5797input facets.</p> 5798<hr> 5799<a name="250"><h3>250. splicing invalidates iterators</h3></a><p> 5800<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p> 5801<p> 5802Section 23.2.2.4 [lib.list.ops] states that 5803</p> 5804<pre> 5805 void splice(iterator position, list<T, Allocator>& x); 5806</pre> 5807<p> 5808<i>invalidates</i> all iterators and references to list <tt>x</tt>. 5809</p> 5810 5811<p> 5812This is unnecessary and defeats an important feature of splice. In 5813fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid 5814after <tt>splice</tt>. 5815</p> 5816<p><b>Proposed resolution:</b></p> 5817 5818<p>Add a footnote to 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p> 5819<blockquote> 5820[<i>Footnote:</i> As specified in 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs 58214-5, the semantics described in this clause applies only to the case 5822where allocators compare equal. --end footnote] 5823</blockquote> 5824 5825<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p> 5826<blockquote> 5827Effects: Inserts the contents of x before position and x becomes 5828empty. Pointers and references to the moved elements of x now refer to 5829those same elements but as members of *this. Iterators referring to the 5830moved elements will continue to refer to their elements, but they now 5831behave as iterators into *this, not into x. 5832</blockquote> 5833 5834<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p> 5835<blockquote> 5836Effects: Inserts an element pointed to by i from list x before 5837position and removes the element from x. The result is unchanged if 5838position == i or position == ++i. Pointers and references to *i continue 5839to refer to this same element but as a member of *this. Iterators to *i 5840(including i itself) continue to refer to the same element, but now 5841behave as iterators into *this, not into x. 5842</blockquote> 5843 5844<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p> 5845<blockquote> 5846Requires: [first, last) is a valid range in x. The result is 5847undefined if position is an iterator in the range [first, last). 5848Pointers and references to the moved elements of x now refer to those 5849same elements but as members of *this. Iterators referring to the moved 5850elements will continue to refer to their elements, but they now behave as 5851iterators into *this, not into x. 5852</blockquote> 5853 5854<p><i>[pre-Copenhagen: Howard provided wording.]</i></p> 5855<p><b>Rationale:</b></p> 5856<p>The original proposed resolution said that iterators and references 5857would remain "valid". The new proposed resolution clarifies what that 5858means. Note that this only applies to the case of equal allocators. 5859From 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when 5860allocators compare nonequal is outside the scope of the standard.</p> 5861<hr> 5862<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p> 5863<b>Section:</b> 27.7.1 <a href="lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p> 5864<p>The synopsis for the template class <tt>basic_stringbuf</tt> 5865doesn't list a typedef for the template parameter 5866<tt>Allocator</tt>. This makes it impossible to determine the type of 5867the allocator at compile time. It's also inconsistent with all other 5868template classes in the library that do provide a typedef for the 5869<tt>Allocator</tt> parameter.</p> 5870<p><b>Proposed resolution:</b></p> 5871<p>Add to the synopses of the class templates basic_stringbuf (27.7.1), 5872basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and 5873basic_stringstream (27.7.4) the typedef:</p> 5874<pre> 5875 typedef Allocator allocator_type; 5876</pre> 5877<hr> 5878<a name="252"><h3>252. missing casts/C-style casts used in iostreams</h3></a><p> 5879<b>Section:</b> 27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p> 5880<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate 5881const_cast<> in the Returns clause for basic_istringstream<>::rdbuf(). 5882The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and 5883D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing 5884the cast altogether.</p> 5885 5886<p>C-style casts have not been deprecated, so the first part of this 5887issue is stylistic rather than a matter of correctness.</p> 5888<p><b>Proposed resolution:</b></p> 5889<p>In 27.7.2.2, p1 replace </p> 5890<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre> 5891 5892<p>with</p> 5893<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> 5894 5895 5896<p>In 27.7.3.2, p1 replace</p> 5897<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre> 5898 5899<p>with</p> 5900<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> 5901 5902<p>In 27.7.6, p1, replace</p> 5903<pre> -1- Returns: &sb</pre> 5904 5905<p>with</p> 5906<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> 5907 5908<p>In D.7.2.2, p1 replace</p> 5909<pre> -2- Returns: &sb. </pre> 5910 5911<p>with</p> 5912<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre> 5913<hr> 5914<a name="256"><h3>256. typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p> 5915<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 21 Aug 2000</p> 5916<p> 591727.4.4.2, p17 says 5918</p> 5919 5920<blockquote> 5921-17- Before copying any parts of rhs, calls each registered callback 5922pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but 5923exceptions() have been replaced, calls each callback pair that was 5924copied from rhs as (*fn)(copy_event,*this,index). 5925</blockquote> 5926 5927<p> 5928The name copy_event isn't defined anywhere. The intended name was 5929copyfmt_event. 5930</p> 5931<p><b>Proposed resolution:</b></p> 5932<p>Replace copy_event with copyfmt_event in the named paragraph.</p> 5933<hr> 5934<a name="259"><h3>259. <tt>basic_string::operator[]</tt> and const correctness</h3></a><p> 5935<b>Section:</b> 21.3.4 <a href="lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Chris Newton <b>Date:</b> 27 Aug 2000</p> 5936<p> 5937<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i> 5938</p> 5939 5940<p> 5941The standard's description of <tt>basic_string<>::operator[]</tt> 5942seems to violate const correctness. 5943</p> 5944 5945<p> 5946The standard (21.3.4/1) says that "If <tt>pos < size()</tt>, 5947returns <tt>data()[pos]</tt>." The types don't work. The 5948return value of <tt>data()</tt> is <tt>const charT*</tt>, but 5949<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>. 5950</p> 5951<p><b>Proposed resolution:</b></p> 5952<p> 5953In section 21.3.4, paragraph 1, change 5954"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() + 5955<i>pos</i>)</tt>". 5956</p> 5957<hr> 5958<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt> 5959</h3></a><p> 5960<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p> 5961<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows 5962it as returning the iterator by value. 24.5.1.2, p5 shows the same 5963operator as returning the iterator by reference. That's incorrect 5964given the Effects clause below (since a temporary is returned). The 5965`&' is probably just a typo.</p> 5966<p><b>Proposed resolution:</b></p> 5967<p>Change the declaration in 24.5.1.2, p5 from</p> 5968 <pre> 5969 istream_iterator<T,charT,traits,Distance>& operator++(int); 5970 </pre> 5971<p>to</p> 5972 <pre> 5973 istream_iterator<T,charT,traits,Distance> operator++(int); 5974 </pre> 5975<p>(that is, remove the `&').</p> 5976<hr> 5977<a name="261"><h3>261. Missing description of <tt>istream_iterator::operator!=</tt> 5978</h3></a><p> 5979<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p> 5980<p> 598124.5.1, p3 lists the synopsis for 5982</p> 5983 5984<pre> 5985 template <class T, class charT, class traits, class Distance> 5986 bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, 5987 const istream_iterator<T,charT,traits,Distance>& y); 5988</pre> 5989 5990<p> 5991but there is no description of what the operator does (i.e., no Effects 5992or Returns clause) in 24.5.1.2. 5993</p> 5994<p><b>Proposed resolution:</b></p> 5995<p> 5996Add paragraph 7 to the end of section 24.5.1.2 with the following text: 5997</p> 5998 5999<pre> 6000 template <class T, class charT, class traits, class Distance> 6001 bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, 6002 const istream_iterator<T,charT,traits,Distance>& y); 6003</pre> 6004 6005<p>-7- Returns: !(x == y).</p> 6006<hr> 6007<a name="262"><h3>262. Bitmask operator ~ specified incorrectly</h3></a><p> 6008<b>Section:</b> 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 03 Sep 2000</p> 6009<p> 6010The ~ operation should be applied after the cast to int_type. 6011</p> 6012<p><b>Proposed resolution:</b></p> 6013<p> 6014Change 17.3.2.1.2 [lib.bitmask.types] operator~ from: 6015</p> 6016 6017<pre> 6018 bitmask operator~ ( bitmask X ) 6019 { return static_cast< bitmask>(static_cast<int_type>(~ X)); } 6020</pre> 6021 6022<p> 6023to: 6024</p> 6025 6026<pre> 6027 bitmask operator~ ( bitmask X ) 6028 { return static_cast< bitmask>(~static_cast<int_type>(X)); } 6029</pre> 6030<hr> 6031<a name="263"><h3>263. Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p> 6032<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Kevlin Henney <b>Date:</b> 04 Sep 2000</p> 6033<p> 6034The note in paragraph 6 suggests that the invalidation rules for 6035references, pointers, and iterators in paragraph 5 permit a reference- 6036counted implementation (actually, according to paragraph 6, they permit 6037a "reference counted implementation", but this is a minor editorial fix). 6038</p> 6039 6040<p> 6041However, the last sub-bullet is so worded as to make a reference-counted 6042implementation unviable. In the following example none of the 6043conditions for iterator invalidation are satisfied: 6044</p> 6045 6046<pre> 6047 // first example: "*******************" should be printed twice 6048 string original = "some arbitrary text", copy = original; 6049 const string & alias = original; 6050 6051 string::const_iterator i = alias.begin(), e = alias.end(); 6052 for(string::iterator j = original.begin(); j != original.end(); ++j) 6053 *j = '*'; 6054 while(i != e) 6055 cout << *i++; 6056 cout << endl; 6057 cout << original << endl; 6058</pre> 6059 6060<p> 6061Similarly, in the following example: 6062</p> 6063 6064<pre> 6065 // second example: "some arbitrary text" should be printed out 6066 string original = "some arbitrary text", copy = original; 6067 const string & alias = original; 6068 6069 string::const_iterator i = alias.begin(); 6070 original.begin(); 6071 while(i != alias.end()) 6072 cout << *i++; 6073</pre> 6074 6075<p> 6076I have tested this on three string implementations, two of which were 6077reference counted. The reference-counted implementations gave 6078"surprising behavior" because they invalidated iterators on 6079the first call to non-const begin since construction. The current 6080wording does not permit such invalidation because it does not take 6081into account the first call since construction, only the first call 6082since various member and non-member function calls. 6083</p> 6084<p><b>Proposed resolution:</b></p> 6085<p> 6086Change the following sentence in 21.3 paragraph 5 from 6087</p> 6088 6089<blockquote> 6090 Subsequent to any of the above uses except the forms of insert() and 6091 erase() which return iterators, the first call to non-const member 6092 functions operator[](), at(), begin(), rbegin(), end(), or rend(). 6093</blockquote> 6094 6095<p>to</p> 6096 6097<blockquote> 6098 Following construction or any of the above uses, except the forms of 6099 insert() and erase() that return iterators, the first call to non- 6100 const member functions operator[](), at(), begin(), rbegin(), end(), 6101 or rend(). 6102</blockquote> 6103<hr> 6104<a name="264"><h3>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p> 6105<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John Potter <b>Date:</b> 07 Sep 2000</p> 6106<p> 6107Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient. 6108Consider inserting a sorted range of even integers into a set<int> containing the odd 6109integers in the same range. 6110</p> 6111 6112<p><i>Related issue: <a href="lwg-closed.html#102">102</a></i></p> 6113<p><b>Proposed resolution:</b></p> 6114<p> 6115In Table 69, in section 23.1.2, change the complexity clause for 6116insertion of a range from "N log(size() + N) (N is the distance 6117from i to j) in general; linear if [i, j) is sorted according to 6118value_comp()" to "N log(size() + N), where N is the distance 6119from i to j". 6120</p> 6121 6122<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced 6123parens in the revised wording.]</i></p> 6124 6125<p><b>Rationale:</b></p> 6126<p> 6127Testing for valid insertions could be less efficient than simply 6128inserting the elements when the range is not both sorted and between 6129two adjacent existing elements; this could be a QOI issue. 6130</p> 6131 6132<p> 6133The LWG considered two other options: (a) specifying that the 6134complexity was linear if [i, j) is sorted according to value_comp() 6135and between two adjacent existing elements; or (b) changing to 6136Klog(size() + N) + (N - K) (N is the distance from i to j and K is the 6137number of elements which do not insert immediately after the previous 6138element from [i, j) including the first). The LWG felt that, since 6139we can't guarantee linear time complexity whenever the range to be 6140inserted is sorted, it's more trouble than it's worth to say that it's 6141linear in some special cases. 6142</p> 6143<hr> 6144<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p> 6145<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 11 Sep 2000</p> 6146<p> 6147I don't see any requirements on the types of the elements of the 6148std::pair container in 20.2.2. From the descriptions of the member 6149functions it appears that they must at least satisfy the requirements of 615020.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in 6151the case of the [in]equality operators also the requirements of 20.1.1 6152[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable]. 6153</p> 6154 6155<p> 6156I believe that the the CopyConstructible requirement is unnecessary in 6157the case of 20.2.2, p2. 6158</p> 6159<p><b>Proposed resolution:</b></p> 6160<p>Change the Effects clause in 20.2.2, p2 from</p> 6161 6162<blockquote> 6163-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() : 6164first(T1()), second(T2()) {} </tt> 6165</blockquote> 6166 6167<p>to</p> 6168 6169<blockquote> 6170-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() : 6171first(), second() {} </tt> 6172</blockquote> 6173<p><b>Rationale:</b></p> 6174<p>The existing specification of pair's constructor appears to be a 6175historical artifact: there was concern that pair's members be properly 6176zero-initialized when they are built-in types. At one time there was 6177uncertainty about whether they would be zero-initialized if the 6178default constructor was written the obvious way. This has been 6179clarified by core issue 178, and there is no longer any doubt that 6180the straightforward implementation is correct.</p> 6181<hr> 6182<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p> 6183<b>Section:</b> 18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 24 Sep 2000</p> 6184<p> 6185The synopsis for std::bad_exception lists the function ~bad_exception() 6186but there is no description of what the function does (the Effects 6187clause is missing). 6188</p> 6189<p><b>Proposed resolution:</b></p> 6190<p> 6191Remove the destructor from the class synopses of 6192<tt>bad_alloc</tt> (18.4.2.1 <a href="lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>), 6193<tt>bad_cast</tt> (18.5.2 <a href="lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>), 6194<tt>bad_typeid</tt> (18.5.3 <a href="lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>), 6195and <tt>bad_exception</tt> (18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>). 6196</p> 6197<p><b>Rationale:</b></p> 6198<p> 6199This is a general problem with the exception classes in clause 18. 6200The proposed resolution is to remove the destructors from the class 6201synopses, rather than to document the destructors' behavior, because 6202removing them is more consistent with how exception classes are 6203described in clause 19. 6204</p> 6205<hr> 6206<a name="268"><h3>268. Typo in locale synopsis</h3></a><p> 6207<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p> 6208<p>The synopsis of the class std::locale in 22.1.1 contains two typos: 6209the semicolons after the declarations of the default ctor 6210locale::locale() and the copy ctor locale::locale(const locale&) 6211are missing.</p> 6212<p><b>Proposed resolution:</b></p> 6213<p>Add the missing semicolons, i.e., change</p> 6214 6215<pre> 6216 // construct/copy/destroy: 6217 locale() throw() 6218 locale(const locale& other) throw() 6219</pre> 6220 6221<p>in the synopsis in 22.1.1 to</p> 6222 6223<pre> 6224 // construct/copy/destroy: 6225 locale() throw(); 6226 locale(const locale& other) throw(); 6227</pre> 6228<hr> 6229<a name="270"><h3>270. Binary search requirements overly strict</h3></a><p> 6230<b>Section:</b> 25.3.3 <a href="lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Oct 2000</p> 6231<p> 6232Each of the four binary search algorithms (lower_bound, upper_bound, 6233equal_range, binary_search) has a form that allows the user to pass a 6234comparison function object. According to 25.3, paragraph 2, that 6235comparison function object has to be a strict weak ordering. 6236</p> 6237 6238<p> 6239This requirement is slightly too strict. Suppose we are searching 6240through a sequence containing objects of type X, where X is some 6241large record with an integer key. We might reasonably want to look 6242up a record by key, in which case we would want to write something 6243like this: 6244</p> 6245<pre> 6246 struct key_comp { 6247 bool operator()(const X& x, int n) const { 6248 return x.key() < n; 6249 } 6250 } 6251 6252 std::lower_bound(first, last, 47, key_comp()); 6253</pre> 6254 6255<p> 6256key_comp is not a strict weak ordering, but there is no reason to 6257prohibit its use in lower_bound. 6258</p> 6259 6260<p> 6261There's no difficulty in implementing lower_bound so that it allows 6262the use of something like key_comp. (It will probably work unless an 6263implementor takes special pains to forbid it.) What's difficult is 6264formulating language in the standard to specify what kind of 6265comparison function is acceptable. We need a notion that's slightly 6266more general than that of a strict weak ordering, one that can encompass 6267a comparison function that involves different types. Expressing that 6268notion may be complicated. 6269</p> 6270 6271<p><i>Additional questions raised at the Toronto meeting:</i></p> 6272<ul> 6273<li> Do we really want to specify what ordering the implementor must 6274 use when calling the function object? The standard gives 6275 specific expressions when describing these algorithms, but it also 6276 says that other expressions (with different argument order) are 6277 equivalent.</li> 6278<li> If we are specifying ordering, note that the standard uses both 6279 orderings when describing <tt>equal_range</tt>.</li> 6280<li> Are we talking about requiring these algorithms to work properly 6281 when passed a binary function object whose two argument types 6282 are not the same, or are we talking about requirements when 6283 they are passed a binary function object with several overloaded 6284 versions of <tt>operator()</tt>?</li> 6285<li> The definition of a strict weak ordering does not appear to give 6286 any guidance on issues of overloading; it only discusses expressions, 6287 and all of the values in these expressions are of the same type. 6288 Some clarification would seem to be in order.</li> 6289</ul> 6290 6291<p><i>Additional discussion from Copenhagen:</i></p> 6292<ul> 6293<li>It was generally agreed that there is a real defect here: if 6294the predicate is merely required to be a Strict Weak Ordering, then 6295it's possible to pass in a function object with an overloaded 6296operator(), where the version that's actually called does something 6297completely inappropriate. (Such as returning a random value.)</li> 6298 6299<li>An alternative formulation was presented in a paper distributed by 6300David Abrahams at the meeting, "Binary Search with Heterogeneous 6301Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the 6302predicate as a Strict Weak Ordering acting on a sorted sequence, view 6303the predicate/value pair as something that partitions a sequence. 6304This is almost equivalent to saying that we should view binary search 6305as if we are given a unary predicate and a sequence, such that f(*p) 6306is true for all p below a specific point and false for all p above it. 6307The proposed resolution is based on that alternative formulation.</li> 6308</ul> 6309<p><b>Proposed resolution:</b></p> 6310 6311<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p> 6312 6313<blockquote> 6314 3 For all algorithms that take Compare, there is a version that uses 6315 operator< instead. That is, comp(*i, *j) != false defaults to *i < 6316 *j != false. For the algorithms to work correctly, comp has to 6317 induce a strict weak ordering on the values. 6318</blockquote> 6319 6320<p>to:</p> 6321 6322<blockquote> 6323 3 For all algorithms that take Compare, there is a version that uses 6324 operator< instead. That is, comp(*i, *j) != false defaults to *i 6325 < *j != false. For algorithms other than those described in 6326 lib.alg.binary.search (25.3.3) to work correctly, comp has to induce 6327 a strict weak ordering on the values. 6328</blockquote> 6329 6330<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p> 6331 6332<blockquote> 6333 -6- A sequence [start, finish) is partitioned with respect to an 6334 expression f(e) if there exists an integer n such that 6335 for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if 6336 and only if i < n. 6337</blockquote> 6338 6339<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p> 6340 6341<blockquote> 6342 -1- All of the algorithms in this section are versions of binary 6343 search and assume that the sequence being searched is in order 6344 according to the implied or explicit comparison function. They work 6345 on non-random access iterators minimizing the number of 6346 comparisons, which will be logarithmic for all types of 6347 iterators. They are especially appropriate for random access 6348 iterators, because these algorithms do a logarithmic number of 6349 steps through the data structure. For non-random access iterators 6350 they execute a linear number of steps. 6351</blockquote> 6352 6353<p>to:</p> 6354 6355<blockquote> 6356 -1- All of the algorithms in this section are versions of binary 6357 search and assume that the sequence being searched is partitioned 6358 with respect to an expression formed by binding the search key to 6359 an argument of the implied or explicit comparison function. They 6360 work on non-random access iterators minimizing the number of 6361 comparisons, which will be logarithmic for all types of 6362 iterators. They are especially appropriate for random access 6363 iterators, because these algorithms do a logarithmic number of 6364 steps through the data structure. For non-random access iterators 6365 they execute a linear number of steps. 6366</blockquote> 6367 6368<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p> 6369 6370<blockquote> 6371 -1- Requires: Type T is LessThanComparable 6372 (lib.lessthancomparable). 6373</blockquote> 6374 6375<p>to:</p> 6376 6377<blockquote> 6378 -1- Requires: The elements e of [first, last) are partitioned with 6379 respect to the expression e < value or comp(e, value) 6380</blockquote> 6381 6382 6383<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p> 6384 6385<blockquote> 6386 -2- Effects: Finds the first position into which value can be 6387 inserted without violating the ordering. 6388</blockquote> 6389 6390<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p> 6391 6392<blockquote> 6393 -1- Requires: Type T is LessThanComparable (lib.lessthancomparable). 6394</blockquote> 6395 6396<p>to:</p> 6397 6398<blockquote> 6399 -1- Requires: The elements e of [first, last) are partitioned with 6400 respect to the expression !(value < e) or !comp(value, e) 6401</blockquote> 6402 6403<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p> 6404 6405<blockquote> 6406 -2- Effects: Finds the furthermost position into which value can be 6407 inserted without violating the ordering. 6408</blockquote> 6409 6410<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p> 6411 6412<blockquote> 6413 -1- Requires: Type T is LessThanComparable 6414 (lib.lessthancomparable). 6415</blockquote> 6416 6417<p>to:</p> 6418 6419<blockquote> 6420 -1- Requires: The elements e of [first, last) are partitioned with 6421 respect to the expressions e < value and !(value < e) or 6422 comp(e, value) and !comp(value, e). Also, for all elements e of 6423 [first, last), e < value implies !(value < e) or comp(e, 6424 value) implies !comp(value, e) 6425</blockquote> 6426 6427<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p> 6428 6429<blockquote> 6430 -2- Effects: Finds the largest subrange [i, j) such that the value 6431 can be inserted at any iterator k in it without violating the 6432 ordering. k satisfies the corresponding conditions: !(*k < value) 6433 && !(value < *k) or comp(*k, value) == false && comp(value, *k) == 6434 false. 6435</blockquote> 6436 6437<p>to:</p> 6438 6439<pre> 6440 -2- Returns: 6441 make_pair(lower_bound(first, last, value), 6442 upper_bound(first, last, value)) 6443 or 6444 make_pair(lower_bound(first, last, value, comp), 6445 upper_bound(first, last, value, comp)) 6446</pre> 6447 6448<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p> 6449 6450<blockquote> 6451 -1- Requires: Type T is LessThanComparable 6452 (lib.lessthancomparable). 6453</blockquote> 6454 6455<p>to:</p> 6456 6457<blockquote> 6458 -1- Requires: The elements e of [first, last) are partitioned with 6459 respect to the expressions e < value and !(value < e) or comp(e, 6460 value) and !comp(value, e). Also, for all elements e of [first, 6461 last), e < value implies !(value < e) or comp(e, value) implies 6462 !comp(value, e) 6463</blockquote> 6464 6465<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p> 6466 6467<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and 6468changed the "other than those described in" wording.) Also, the LWG 6469decided to accept the "optional" part.]</i></p> 6470 6471<p><b>Rationale:</b></p> 6472<p>The proposed resolution reinterprets binary search. Instead of 6473thinking about searching for a value in a sorted range, we view that 6474as an important special case of a more general algorithm: searching 6475for the partition point in a partitioned range.</p> 6476 6477<p>We also add a guarantee that the old wording did not: we ensure 6478that the upper bound is no earlier than the lower bound, that 6479the pair returned by equal_range is a valid range, and that the first 6480part of that pair is the lower bound.</p> 6481<hr> 6482<a name="271"><h3>271. basic_iostream missing typedefs</h3></a><p> 6483<b>Section:</b> 27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p> 6484<p> 6485Class template basic_iostream has no typedefs. The typedefs it 6486inherits from its base classes can't be used, since (for example) 6487basic_iostream<T>::traits_type is ambiguous. 6488</p> 6489<p><b>Proposed resolution:</b></p> 6490 6491<p>Add the following to basic_iostream's class synopsis in 649227.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p> 6493 6494<pre> 6495 // types: 6496 typedef charT char_type; 6497 typedef typename traits::int_type int_type; 6498 typedef typename traits::pos_type pos_type; 6499 typedef typename traits::off_type off_type; 6500 typedef traits traits_type; 6501</pre> 6502<hr> 6503<a name="272"><h3>272. Missing parentheses around subexpression</h3></a><p> 6504<b>Section:</b> 27.4.4.3 <a href="lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p> 6505<p> 650627.4.4.3, p4 says about the postcondition of the function: If 6507rdbuf()!=0 then state == rdstate(); otherwise 6508rdstate()==state|ios_base::badbit. 6509</p> 6510 6511<p> 6512The expression on the right-hand-side of the operator==() needs to be 6513parenthesized in order for the whole expression to ever evaluate to 6514anything but non-zero. 6515</p> 6516<p><b>Proposed resolution:</b></p> 6517<p> 6518Add parentheses like so: rdstate()==(state|ios_base::badbit). 6519</p> 6520<hr> 6521<a name="273"><h3>273. Missing ios_base qualification on members of a dependent class</h3></a><p> 6522<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p> 6523<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2, 652427.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification. 6525That's incorrect since the names are members of a dependent base 6526class (14.6.2 [temp.dep]) and thus not visible.</p> 6527<p><b>Proposed resolution:</b></p> 6528<p>Qualify the names with the name of the class of which they are 6529members, i.e., ios_base.</p> 6530<hr> 6531<a name="274"><h3>274. a missing/impossible allocator requirement</h3></a><p> 6532<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p> 6533<p> 6534I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of 6535any type. But the synopsis in 20.4.1 calls for allocator<>::address() to 6536be overloaded on reference and const_reference, which is ill-formed for 6537all T = const U. In other words, this won't work: 6538</p> 6539 6540<p> 6541template class std::allocator<const int>; 6542</p> 6543 6544<p> 6545The obvious solution is to disallow specializations of allocators on 6546const types. However, while containers' elements are required to be 6547assignable (which rules out specializations on const T's), I think that 6548allocators might perhaps be potentially useful for const values in other 6549contexts. So if allocators are to allow const types a partial 6550specialization of std::allocator<const T> would probably have to be 6551provided. 6552</p> 6553<p><b>Proposed resolution:</b></p> 6554<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p> 6555 6556 <blockquote> 6557 any type 6558 </blockquote> 6559 6560<p>to</p> 6561 <blockquote> 6562 any non-const, non-reference type 6563 </blockquote> 6564 6565<p><i>[Redmond: previous proposed resolution was "any non-const, 6566non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p> 6567 6568<p><b>Rationale:</b></p> 6569<p> 6570Two resolutions were originally proposed: one that partially 6571specialized std::allocator for const types, and one that said an 6572allocator's value type may not be const. The LWG chose the second. 6573The first wouldn't be appropriate, because allocators are intended for 6574use by containers, and const value types don't work in containers. 6575Encouraging the use of allocators with const value types would only 6576lead to unsafe code. 6577</p> 6578<p> 6579The original text for proposed resolution 2 was modified so that it 6580also forbids volatile types and reference types. 6581</p> 6582 6583<p><i>[Curaçao: LWG double checked and believes volatile is correctly 6584excluded from the PR.]</i></p> 6585 6586<hr> 6587<a name="275"><h3>275. Wrong type in num_get::get() overloads</h3></a><p> 6588<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 02 Nov 2000</p> 6589<p> 6590In 22.2.2.1.1, we have a list of overloads for num_get<>::get(). 6591There are eight overloads, all of which are identical except for the 6592last parameter. The overloads are: 6593</p> 6594<ul> 6595<li> long& </li> 6596<li> unsigned short& </li> 6597<li> unsigned int& </li> 6598<li> unsigned long& </li> 6599<li> short& </li> 6600<li> double& </li> 6601<li> long double& </li> 6602<li> void*& </li> 6603</ul> 6604 6605<p> 6606There is a similar list, in 22.2.2.1.2, of overloads for 6607num_get<>::do_get(). In this list, the last parameter has 6608the types: 6609</p> 6610<ul> 6611<li> long& </li> 6612<li> unsigned short& </li> 6613<li> unsigned int& </li> 6614<li> unsigned long& </li> 6615<li> float& </li> 6616<li> double& </li> 6617<li> long double& </li> 6618<li> void*& </li> 6619</ul> 6620 6621<p> 6622These two lists are not identical. They should be, since 6623<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly 6624the arguments it was given. 6625</p> 6626<p><b>Proposed resolution:</b></p> 6627<p>In 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p> 6628<pre> 6629 iter_type get(iter_type in, iter_type end, ios_base& str, 6630 ios_base::iostate& err, short& val) const; 6631</pre> 6632<p>to</p> 6633<pre> 6634 iter_type get(iter_type in, iter_type end, ios_base& str, 6635 ios_base::iostate& err, float& val) const; 6636</pre> 6637<hr> 6638<a name="276"><h3>276. Assignable requirement for container value type overly strict</h3></a><p> 6639<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 07 Nov 2000</p> 6640<p> 664123.1/3 states that the objects stored in a container must be 6642Assignable. 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2, 6643states that map satisfies all requirements for a container, while in 6644the same time defining value_type as pair<const Key, T> - a type 6645that is not Assignable. 6646</p> 6647 6648<p> 6649It should be noted that there exists a valid and non-contradictory 6650interpretation of the current text. The wording in 23.1/3 avoids 6651mentioning value_type, referring instead to "objects stored in a 6652container." One might argue that map does not store objects of 6653type map::value_type, but of map::mapped_type instead, and that the 6654Assignable requirement applies to map::mapped_type, not 6655map::value_type. 6656</p> 6657 6658<p> 6659However, this makes map a special case (other containers store objects of 6660type value_type) and the Assignable requirement is needlessly restrictive in 6661general. 6662</p> 6663 6664<p> 6665For example, the proposed resolution of active library issue 6666<a href="lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this 6667means that no set operations can exploit the fact that the stored 6668objects are Assignable. 6669</p> 6670 6671<p> 6672This is related to, but slightly broader than, closed issue 6673<a href="lwg-closed.html#140">140</a>. 6674</p> 6675<p><b>Proposed resolution:</b></p> 6676<p>23.1/3: Strike the trailing part of the sentence:</p> 6677 <blockquote> 6678 , and the additional requirements of Assignable types from 23.1/3 6679 </blockquote> 6680<p>so that it reads:</p> 6681 <blockquote> 6682 -3- The type of objects stored in these components must meet the 6683 requirements of CopyConstructible types (lib.copyconstructible). 6684 </blockquote> 6685 6686<p>23.1/4: Modify to make clear that this requirement is not for all 6687containers. Change to:</p> 6688 6689<blockquote> 6690-4- Table 64 defines the Assignable requirement. Some containers 6691require this property of the types to be stored in the container. T is 6692the type used to instantiate the container. t is a value of T, and u is 6693a value of (possibly const) T. 6694</blockquote> 6695 6696<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is 6697CopyConstructible".</p> 6698 6699<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p> 6700 6701<blockquote> 6702-2- A deque satisfies all of the requirements of a container and of a 6703reversible container (given in tables in lib.container.requirements) and 6704of a sequence, including the optional sequence requirements 6705(lib.sequence.reqmts). In addition to the requirements on the stored 6706object described in 23.1[lib.container.requirements], the stored object 6707must also meet the requirements of Assignable. Descriptions are 6708provided here only for operations on deque that are not described in one 6709of these tables or for operations where there is additional semantic 6710information. 6711</blockquote> 6712 6713<p>23.2.2/2: Add Assignable requirement to specific methods of list. 6714Change to:</p> 6715 6716<blockquote> 6717<p>-2- A list satisfies all of the requirements of a container and of a 6718reversible container (given in two tables in lib.container.requirements) 6719and of a sequence, including most of the the optional sequence 6720requirements (lib.sequence.reqmts). The exceptions are the operator[] 6721and at member functions, which are not provided. 6722 6723[Footnote: These member functions are only provided by containers whose 6724iterators are random access iterators. --- end foonote] 6725</p> 6726 6727<p>list does not require the stored type T to be Assignable unless the 6728following methods are instantiated: 6729 6730[Footnote: Implementors are permitted but not required to take advantage 6731of T's Assignable properties for these methods. -- end foonote] 6732</p> 6733<pre> 6734 list<T,Allocator>& operator=(const list<T,Allocator>& x ); 6735 template <class InputIterator> 6736 void assign(InputIterator first, InputIterator last); 6737 void assign(size_type n, const T& t); 6738</pre> 6739 6740 6741<p>Descriptions are provided here only for operations on list that are not 6742described in one of these tables or for operations where there is 6743additional semantic information.</p> 6744</blockquote> 6745 6746<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p> 6747 6748<blockquote> 6749-2- A vector satisfies all of the requirements of a container and of a 6750reversible container (given in two tables in lib.container.requirements) 6751and of a sequence, including most of the optional sequence requirements 6752(lib.sequence.reqmts). The exceptions are the push_front and pop_front 6753member functions, which are not provided. In addition to the 6754requirements on the stored object described in 675523.1[lib.container.requirements], the stored object must also meet the 6756requirements of Assignable. Descriptions are provided here only for 6757operations on vector that are not described in one of these tables or 6758for operations where there is additional semantic information. 6759</blockquote> 6760<p><b>Rationale:</b></p> 6761<p>list, set, multiset, map, multimap are able to store non-Assignables. 6762However, there is some concern about <tt>list<T></tt>: 6763although in general there's no reason for T to be Assignable, some 6764implementations of the member functions <tt>operator=</tt> and 6765<tt>assign</tt> do rely on that requirement. The LWG does not want 6766to forbid such implementations.</p> 6767 6768<p>Note that the type stored in a standard container must still satisfy 6769the requirements of the container's allocator; this rules out, for 6770example, such types as "const int". See issue <a href="lwg-defects.html#274">274</a> 6771for more details. 6772</p> 6773 6774<p>In principle we could also relax the "Assignable" requirement for 6775individual <tt>vector</tt> member functions, such as 6776<tt>push_back</tt>. However, the LWG did not see great value in such 6777selective relaxation. Doing so would remove implementors' freedom to 6778implement <tt>vector::push_back</tt> in terms of 6779<tt>vector::insert</tt>.</p> 6780 6781<hr> 6782<a name="281"><h3>281. std::min() and max() requirements overly restrictive</h3></a><p> 6783<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Dec 2000</p> 6784<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the 6785requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>) 6786and <tt>CopyConstructible</tt> (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>). 6787Since the functions take and return their arguments and result by 6788const reference, I believe the <tt>CopyConstructible</tt> requirement 6789is unnecessary. 6790</p> 6791<p><b>Proposed resolution:</b></p> 6792<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace 679325.3.7, p1 with</p> 6794<p> 6795<b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt> 6796(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>). 6797</p> 6798<p>and replace 25.3.7, p4 with</p> 6799<p> 6800<b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt> 6801(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>). 6802</p> 6803<hr> 6804<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p> 6805<b>Section:</b> 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 26 Dec 2000</p> 6806<p>The example in 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C 6807library function <tt>strcmp()</tt> with the function pointer adapter 6808<tt>ptr_fun()</tt>. But since it's unspecified whether the C library 6809functions have <tt>extern "C"</tt> or <tt>extern 6810"C++"</tt> linkage [17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since 6811function pointers with different the language linkage specifications 6812(7.5 <a href="dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is 6813well-formed is unspecified. 6814</p> 6815<p><b>Proposed resolution:</b></p> 6816<p>Change 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p> 6817<blockquote> 6818 <p>[<i>Example:</i> 6819</p> 6820 <pre> 6821 replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++"); 6822 </pre> 6823 <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p> 6824</blockquote> 6825 6826 6827<p>to:</p> 6828<blockquote> 6829 <p>[<i>Example:</i> 6830</p> 6831 <pre> 6832 int compare(const char*, const char*); 6833 replace_if(v.begin(), v.end(), 6834 not1(bind2nd(ptr_fun(compare), "abc")), "def"); 6835 </pre> 6836 <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p> 6837</blockquote> 6838 6839<p>Also, remove footnote 215 in that same paragraph.</p> 6840 6841<p><i>[Copenhagen: Minor change in the proposed resolution. Since this 6842issue deals in part with C and C++ linkage, it was believed to be too 6843confusing for the strings in the example to be "C" and "C++". 6844]</i></p> 6845 6846<p><i>[Redmond: More minor changes. Got rid of the footnote (which 6847seems to make a sweeping normative requirement, even though footnotes 6848aren't normative), and changed the sentence after the footnote so that 6849it corresponds to the new code fragment.]</i></p> 6850 6851<hr> 6852<a name="285"><h3>285. minor editorial errors in fstream ctors</h3></a><p> 6853<b>Section:</b> 27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 31 Dec 2000</p> 6854<p>27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and 685527.8.1.12 <a href="lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor: 6856</p> 6857 6858<p>... If that function returns a null pointer, calls 6859<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>). 6860</p> 6861 6862<p>The parenthetical note doesn't apply since the ctors cannot throw an 6863exception due to the requirement in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3 6864that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>. 6865</p> 6866<p><b>Proposed resolution:</b></p> 6867<p> 6868Strike the parenthetical note from the Effects clause in each of the 6869paragraphs mentioned above. 6870</p> 6871<hr> 6872<a name="286"><h3>286. <cstdlib> requirements missing size_t typedef</h3></a><p> 6873<b>Section:</b> 25.4 <a href="lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p> 6874<p> 6875The <cstdlib> header file contains prototypes for bsearch and 6876qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other 6877prototypes (C++ Standard section 21.4 paragraph 1 table 49) that 6878require the typedef size_t. Yet size_t is not listed in the 6879<cstdlib> synopsis table 78 in section 25.4. 6880</p> 6881<p><b>Proposed resolution:</b></p> 6882<p> 6883Add the type size_t to Table 78 (section 25.4) and add 6884the type size_t <cstdlib> to Table 97 (section C.2). 6885</p> 6886<p><b>Rationale:</b></p> 6887<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p> 6888<hr> 6889<a name="288"><h3>288. <cerrno> requirements missing macro EILSEQ</h3></a><p> 6890<b>Section:</b> 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p> 6891<p> 6892ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list 6893of macros defined in <errno.h> is adjusted to include a new 6894macro, EILSEQ" 6895</p> 6896 6897<p> 6898ISO/IEC 14882:1998(E) section 19.3 does not refer 6899to the above amendment. 6900</p> 6901 6902<p><b>Proposed resolution:</b></p> 6903<p> 6904Update Table 26 (section 19.3) "Header <cerrno> synopsis" 6905and Table 95 (section C.2) "Standard Macros" to include EILSEQ. 6906</p> 6907<hr> 6908<a name="292"><h3>292. effects of a.copyfmt (a)</h3></a><p> 6909<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jan 2001</p> 6910<p>The Effects clause of the member function <tt>copyfmt()</tt> in 691127.4.4.2, p15 doesn't consider the case where the left-hand side 6912argument is identical to the argument on the right-hand side, that is 6913<tt>(this == &rhs)</tt>. If the two arguments are identical there 6914is no need to copy any of the data members or call any callbacks 6915registered with <tt>register_callback()</tt>. Also, as Howard Hinnant 6916points out in message c++std-lib-8149 it appears to be incorrect to 6917allow the object to fire <tt>erase_event</tt> followed by 6918<tt>copyfmt_event</tt> since the callback handling the latter event 6919may inadvertently attempt to access memory freed by the former. 6920</p> 6921<p><b>Proposed resolution:</b></p> 6922<p>Change the Effects clause in 27.4.4.2, p15 from</p> 6923 6924<blockquote> 6925<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt> 6926the corresponding member objects of <tt>rhs</tt>, except that... 6927</blockquote> 6928 6929<p>to</p> 6930 6931<blockquote> 6932<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise 6933assigns to the member objects of <tt>*this</tt> the corresponding member 6934objects of <tt>rhs</tt>, except that... 6935</blockquote> 6936<hr> 6937<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p> 6938<b>Section:</b> 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p> 6939<p> 6940Table 80 lists the contents of the <cmath> header. It does not 6941list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added 6942signatures present in <cmath>, does say that several overloads 6943of <tt>abs()</tt> should be defined in <cmath>. 6944</p> 6945<p><b>Proposed resolution:</b></p> 6946<p> 6947Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list 6948of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>, 6949paragraph 1. 6950</p> 6951 6952<p><i>[Copenhagen: Modified proposed resolution so that it also gets 6953rid of that vestigial list of functions in paragraph 1.]</i></p> 6954 6955<p><b>Rationale:</b></p> 6956<p>All this DR does is fix a typo; it's uncontroversial. A 6957separate question is whether we're doing the right thing in 6958putting some overloads in <cmath> that we aren't also 6959putting in <cstdlib>. That's issue <a href="lwg-active.html#323">323</a>.</p> 6960<hr> 6961<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p> 6962<b>Section:</b> 20.3.8 <a href="lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Jan 2001</p> 6963<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and 6964<tt>const_mem_fun1_t</tt> 6965in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and 6966<tt>binary_function<T*, 6967A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and 6968<tt>first_argument_type</tt> 6969members, respectively, are both defined to be <tt>T*</tt> (non-const). 6970However, their function call member operator takes a <tt>const T*</tt> 6971argument. It is my opinion that <tt>argument_type</tt> should be <tt>const 6972T*</tt> instead, so that one can easily refer to it in generic code. The 6973example below derived from existing code fails to compile due to the 6974discrepancy: 6975</p> 6976 6977<p> 6978<tt>template <class T></tt> 6979<br><tt>void foo (typename T::argument_type arg) // #1</tt> 6980<br><tt>{</tt> 6981<br><tt> typename T::result_type (T::*pf) (typename 6982T::argument_type) 6983const = // #2</tt> 6984<br><tt> &T::operator();</tt> 6985<br><tt>}</tt> 6986</p> 6987 6988<p><tt>struct X { /* ... */ };</tt></p> 6989 6990<p> 6991<tt>int main ()</tt> 6992<br><tt>{</tt> 6993<br><tt> const X x;</tt> 6994<br><tt> foo<std::const_mem_fun_t<void, X> 6995>(&x); 6996// #3</tt> 6997<br><tt>}</tt> 6998</p> 6999 7000<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument 7001<br>#2 the type of the pointer is incompatible with the type of the member 7002function 7003<br>#3 the address of a constant being passed to a function taking a non-const 7004<tt>X*</tt> 7005</p> 7006<p><b>Proposed resolution:</b></p> 7007<p>Replace the top portion of the definition of the class template 7008const_mem_fun_t in 20.3.8, p8 7009</p> 7010<p> 7011<tt>template <class S, class T> class const_mem_fun_t</tt> 7012<br><tt> : public 7013unary_function<T*, S> {</tt> 7014</p> 7015<p>with</p> 7016<p> 7017<tt>template <class S, class T> class const_mem_fun_t</tt> 7018<br><tt> : public 7019unary_function<<b>const</b> T*, S> {</tt> 7020</p> 7021<p>Also replace the top portion of the definition of the class template 7022const_mem_fun1_t in 20.3.8, p9</p> 7023<p> 7024<tt>template <class S, class T, class A> class const_mem_fun1_t</tt> 7025<br><tt> : public 7026binary_function<T*, A, S> {</tt> 7027</p> 7028<p>with</p> 7029<p> 7030<tt>template <class S, class T, class A> class const_mem_fun1_t</tt> 7031<br><tt> : public 7032binary_function<<b>const</b> T*, A, S> {</tt> 7033</p> 7034<p><b>Rationale:</b></p> 7035<p>This is simply a contradiction: the <tt>argument_type</tt> typedef, 7036and the argument type itself, are not the same.</p> 7037<hr> 7038<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p> 7039<b>Section:</b> 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p> 7040<p> 7041The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 - 7042namely that for non-null value of <i>ptr</i>, the operator reclaims storage 7043allocated by the earlier call to the default <tt>operator new[]</tt> - is not 7044correct in all cases. Since the specified <tt>operator new[]</tt> default 7045behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be 7046replaced, along with <tt>operator delete</tt>, by the user, to implement their 7047own memory management, the specified default behavior of<tt> operator 7048delete[]</tt> must be to call <tt>operator delete</tt>. 7049</p> 7050<p><b>Proposed resolution:</b></p> 7051<p>Change 18.4.1.2, p12 from</p> 7052<blockquote> 7053<b>-12-</b> <b>Default behavior:</b> 7054<ul> 7055<li> 7056For a null value of <i><tt>ptr</tt></i> , does nothing. 7057</li> 7058<li> 7059Any other value of <i><tt>ptr</tt></i> shall be a value returned 7060earlier by a call to the default <tt>operator new[](std::size_t)</tt>. 7061[Footnote: The value must not have been invalidated by an intervening 7062call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>). 7063--- end footnote] 7064For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage 7065allocated by the earlier call to the default <tt>operator new[]</tt>. 7066</li> 7067</ul> 7068</blockquote> 7069 7070<p>to</p> 7071 7072<blockquote> 7073<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator 7074delete(</tt><i>ptr</i>) 7075or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively. 7076</blockquote> 7077<p>and expunge paragraph 13.</p> 7078<hr> 7079<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p> 7080<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p> 7081<p> 7082The effects clause for the basic_string template ctor in 21.3.1, p15 7083leaves out the third argument of type Allocator. I believe this to be 7084a mistake. 7085</p> 7086<p><b>Proposed resolution:</b></p> 7087<p>Replace</p> 7088 7089<blockquote> 7090 <p> 7091<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral 7092 type, equivalent to</p> 7093 7094 <blockquote><tt>basic_string(static_cast<size_type>(begin), 7095 static_cast<value_type>(end))</tt></blockquote> 7096</blockquote> 7097 7098<p>with</p> 7099 7100<blockquote> 7101 <p> 7102<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral 7103 type, equivalent to</p> 7104 7105 <blockquote><tt>basic_string(static_cast<size_type>(begin), 7106 static_cast<value_type>(end), <b>a</b>)</tt></blockquote> 7107</blockquote> 7108<hr> 7109<a name="303"><h3>303. Bitset input operator underspecified</h3></a><p> 7110<b>Section:</b> 23.3.5.3 <a href="lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Feb 2001</p> 7111<p> 7112In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator 7113"Extracts up to <i>N</i> (single-byte) characters from 7114<i>is</i>.", where <i>is</i> is a stream of type 7115<tt>basic_istream<charT, traits></tt>. 7116</p> 7117 7118<p> 7119The standard does not say what it means to extract single byte 7120characters from a stream whose character type, <tt>charT</tt>, is in 7121general not a single-byte character type. Existing implementations 7122differ. 7123</p> 7124 7125<p> 7126A reasonable solution will probably involve <tt>widen()</tt> and/or 7127<tt>narrow()</tt>, since they are the supplied mechanism for 7128converting a single character between <tt>char</tt> and 7129arbitrary <tt>charT</tt>. 7130</p> 7131 7132<p>Narrowing the input characters is not the same as widening the 7133literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some 7134locales in which more than one wide character maps to the narrow 7135character <tt>'0'</tt>. Narrowing means that alternate 7136representations may be used for bitset input, widening means that 7137they may not be.</p> 7138 7139<p>Note that for numeric input, <tt>num_get<></tt> 7140(22.2.2.1.2/8) compares input characters to widened version of narrow 7141character literals.</p> 7142 7143<p>From Pete Becker, in c++std-lib-8224:</p> 7144<blockquote> 7145<p> 7146Different writing systems can have different representations for the 7147digits that represent 0 and 1. For example, in the Unicode representation 7148of the Devanagari script (used in many of the Indic languages) the digit 0 7149is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those 7150into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and 71510x0031 for for the Latin representations of '0' and '1', as well as code 7152points for the same numeric values in several other scripts (Tamil has no 7153character for 0, but does have the digits 1-9), and any of these values 7154would also be narrowed to '0' and '1'. 7155</p> 7156 7157<p>...</p> 7158 7159<p> 7160It's fairly common to intermix both native and Latin 7161representations of numbers in a document. So I think the rule has to be 7162that if a wide character represents a digit whose value is 0 then the bit 7163should be cleared; if it represents a digit whose value is 1 then the bit 7164should be set; otherwise throw an exception. So in a Devanagari locale, 7165both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031 7166would set it. Widen can't do that. It would pick one of those two values, 7167and exclude the other one. 7168</p> 7169 7170</blockquote> 7171 7172<p>From Jens Maurer, in c++std-lib-8233:</p> 7173 7174<blockquote> 7175<p> 7176Whatever we decide, I would find it most surprising if 7177bitset conversion worked differently from int conversion 7178with regard to alternate local representations of 7179numbers. 7180</p> 7181 7182<p>Thus, I think the options are:</p> 7183<ul> 7184 <li> Have a new defect issue for 22.2.2.1.2/8 so that it will 7185require the use of narrow().</li> 7186 7187 <li> Have a defect issue for bitset() which describes clearly 7188that widen() is to be used.</li> 7189</ul> 7190</blockquote> 7191<p><b>Proposed resolution:</b></p> 7192 7193 <p>Replace the first two sentences of paragraph 5 with:</p> 7194 7195 <blockquote> 7196 Extracts up to <i>N</i> characters from <i>is</i>. Stores these 7197 characters in a temporary object <i>str</i> of type 7198 <tt>basic_string<charT, traits></tt>, then evaluates the 7199 expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>. 7200 </blockquote> 7201 7202 <p>Replace the third bullet item in paragraph 5 with:</p> 7203 <ul><li> 7204 the next input character is neither <tt><i>is</i>.widen(0)</tt> 7205 nor <tt><i>is</i>.widen(1)</tt> (in which case the input character 7206 is not extracted). 7207 </li></ul> 7208 7209<p><b>Rationale:</b></p> 7210<p>Input for <tt>bitset</tt> should work the same way as numeric 7211input. Using <tt>widen</tt> does mean that alternative digit 7212representations will not be recognized, but this was a known 7213consequence of the design choice.</p> 7214<hr> 7215<a name="306"><h3>306. offsetof macro and non-POD types</h3></a><p> 7216<b>Section:</b> 18.1 <a href="lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Feb 2001</p> 7217<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p> 7218 7219<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt> 7220accepts a restricted set of <i>type</i> arguments in this 7221International Standard. <i>type</i> shall be a POD structure or a POD 7222union (clause 9). The result of applying the offsetof macro to a field 7223that is a static data member or a function member is 7224undefined."</p> 7225 7226<p>For the POD requirement, it doesn't say "no diagnostic 7227required" or "undefined behavior". I read 1.4 <a href="intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required. 7228It's not clear whether this requirement was intended. While it's 7229possible to provide such a diagnostic, the extra complication doesn't 7230seem to add any value. 7231</p> 7232<p><b>Proposed resolution:</b></p> 7233<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD 7234structure or a POD union the results are undefined."</p> 7235 7236<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally 7237agreed that requiring a diagnostic was inadvertent, but some LWG 7238members thought that diagnostics should be required whenever 7239possible.]</i></p> 7240 7241<hr> 7242<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p> 7243<b>Section:</b> 23.2.3 <a href="lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p> 7244 7245<p>From reflector message c++std-lib-8330. See also lib-8317.</p> 7246 7247<p> 7248The standard is currently inconsistent in 23.2.3.2 <a href="lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> 7249paragraph 1 and 23.2.3.3 <a href="lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1. 725023.2.3.3/1, for example, says: 7251</p> 7252 7253<blockquote> 7254-1- Any sequence supporting operations back(), push_back() and pop_back() 7255can be used to instantiate stack. In particular, vector (lib.vector), list 7256(lib.list) and deque (lib.deque) can be used. 7257</blockquote> 7258 7259<p>But this is false: vector<bool> can not be used, because the 7260container adaptors return a T& rather than using the underlying 7261container's reference type.</p> 7262 7263<p>This is a contradiction that can be fixed by:</p> 7264 7265<ol> 7266<li>Modifying these paragraphs to say that vector<bool> 7267 is an exception.</li> 7268<li>Removing the vector<bool> specialization.</li> 7269<li>Changing the return types of stack and priority_queue to use 7270 reference typedef's.</li> 7271</ol> 7272 7273<p> 7274I propose 3. This does not preclude option 2 if we choose to do it 7275later (see issue <a href="lwg-active.html#96">96</a>); the issues are independent. Option 72763 offers a small step towards support for proxied containers. This 7277small step fixes a current contradiction, is easy for vendors to 7278implement, is already implemented in at least one popular lib, and 7279does not break any code. 7280</p> 7281 7282<p><b>Proposed resolution:</b></p> 7283<p>Summary: Add reference and const_reference typedefs to queue, 7284priority_queue and stack. Change return types of "value_type&" to 7285"reference". Change return types of "const value_type&" to 7286"const_reference". Details:</p> 7287 7288<p>Change 23.2.3.1/1 from:</p> 7289 7290<pre> 7291 namespace std { 7292 template <class T, class Container = deque<T> > 7293 class queue { 7294 public: 7295 typedef typename Container::value_type value_type; 7296 typedef typename Container::size_type size_type; 7297 typedef Container container_type; 7298 protected: 7299 Container c; 7300 7301 public: 7302 explicit queue(const Container& = Container()); 7303 7304 bool empty() const { return c.empty(); } 7305 size_type size() const { return c.size(); } 7306 value_type& front() { return c.front(); } 7307 const value_type& front() const { return c.front(); } 7308 value_type& back() { return c.back(); } 7309 const value_type& back() const { return c.back(); } 7310 void push(const value_type& x) { c.push_back(x); } 7311 void pop() { c.pop_front(); } 7312 }; 7313</pre> 7314 7315<p>to:</p> 7316 7317<pre> 7318 namespace std { 7319 template <class T, class Container = deque<T> > 7320 class queue { 7321 public: 7322 typedef typename Container::value_type value_type; 7323 typedef typename Container::reference reference; 7324 typedef typename Container::const_reference const_reference; 7325 typedef typename Container::value_type value_type; 7326 typedef typename Container::size_type size_type; 7327 typedef Container container_type; 7328 protected: 7329 Container c; 7330 7331 public: 7332 explicit queue(const Container& = Container()); 7333 7334 bool empty() const { return c.empty(); } 7335 size_type size() const { return c.size(); } 7336 reference front() { return c.front(); } 7337 const_reference front() const { return c.front(); } 7338 reference back() { return c.back(); } 7339 const_reference back() const { return c.back(); } 7340 void push(const value_type& x) { c.push_back(x); } 7341 void pop() { c.pop_front(); } 7342 }; 7343</pre> 7344 7345<p>Change 23.2.3.2/1 from:</p> 7346 7347<pre> 7348 namespace std { 7349 template <class T, class Container = vector<T>, 7350 class Compare = less<typename Container::value_type> > 7351 class priority_queue { 7352 public: 7353 typedef typename Container::value_type value_type; 7354 typedef typename Container::size_type size_type; 7355 typedef Container container_type; 7356 protected: 7357 Container c; 7358 Compare comp; 7359 7360 public: 7361 explicit priority_queue(const Compare& x = Compare(), 7362 const Container& = Container()); 7363 template <class InputIterator> 7364 priority_queue(InputIterator first, InputIterator last, 7365 const Compare& x = Compare(), 7366 const Container& = Container()); 7367 7368 bool empty() const { return c.empty(); } 7369 size_type size() const { return c.size(); } 7370 const value_type& top() const { return c.front(); } 7371 void push(const value_type& x); 7372 void pop(); 7373 }; 7374 // no equality is provided 7375 } 7376</pre> 7377 7378<p>to:</p> 7379 7380<pre> 7381 namespace std { 7382 template <class T, class Container = vector<T>, 7383 class Compare = less<typename Container::value_type> > 7384 class priority_queue { 7385 public: 7386 typedef typename Container::value_type value_type; 7387 typedef typename Container::reference reference; 7388 typedef typename Container::const_reference const_reference; 7389 typedef typename Container::size_type size_type; 7390 typedef Container container_type; 7391 protected: 7392 Container c; 7393 Compare comp; 7394 7395 public: 7396 explicit priority_queue(const Compare& x = Compare(), 7397 const Container& = Container()); 7398 template <class InputIterator> 7399 priority_queue(InputIterator first, InputIterator last, 7400 const Compare& x = Compare(), 7401 const Container& = Container()); 7402 7403 bool empty() const { return c.empty(); } 7404 size_type size() const { return c.size(); } 7405 const_reference top() const { return c.front(); } 7406 void push(const value_type& x); 7407 void pop(); 7408 }; 7409 // no equality is provided 7410 } 7411</pre> 7412 7413<p>And change 23.2.3.3/1 from:</p> 7414 7415<pre> 7416 namespace std { 7417 template <class T, class Container = deque<T> > 7418 class stack { 7419 public: 7420 typedef typename Container::value_type value_type; 7421 typedef typename Container::size_type size_type; 7422 typedef Container container_type; 7423 protected: 7424 Container c; 7425 7426 public: 7427 explicit stack(const Container& = Container()); 7428 7429 bool empty() const { return c.empty(); } 7430 size_type size() const { return c.size(); } 7431 value_type& top() { return c.back(); } 7432 const value_type& top() const { return c.back(); } 7433 void push(const value_type& x) { c.push_back(x); } 7434 void pop() { c.pop_back(); } 7435 }; 7436 7437 template <class T, class Container> 7438 bool operator==(const stack<T, Container>& x, 7439 const stack<T, Container>& y); 7440 template <class T, class Container> 7441 bool operator< (const stack<T, Container>& x, 7442 const stack<T, Container>& y); 7443 template <class T, class Container> 7444 bool operator!=(const stack<T, Container>& x, 7445 const stack<T, Container>& y); 7446 template <class T, class Container> 7447 bool operator> (const stack<T, Container>& x, 7448 const stack<T, Container>& y); 7449 template <class T, class Container> 7450 bool operator>=(const stack<T, Container>& x, 7451 const stack<T, Container>& y); 7452 template <class T, class Container> 7453 bool operator<=(const stack<T, Container>& x, 7454 const stack<T, Container>& y); 7455 } 7456</pre> 7457 7458<p>to:</p> 7459 7460<pre> 7461 namespace std { 7462 template <class T, class Container = deque<T> > 7463 class stack { 7464 public: 7465 typedef typename Container::value_type value_type; 7466 typedef typename Container::reference reference; 7467 typedef typename Container::const_reference const_reference; 7468 typedef typename Container::size_type size_type; 7469 typedef Container container_type; 7470 protected: 7471 Container c; 7472 7473 public: 7474 explicit stack(const Container& = Container()); 7475 7476 bool empty() const { return c.empty(); } 7477 size_type size() const { return c.size(); } 7478 reference top() { return c.back(); } 7479 const_reference top() const { return c.back(); } 7480 void push(const value_type& x) { c.push_back(x); } 7481 void pop() { c.pop_back(); } 7482 }; 7483 7484 template <class T, class Container> 7485 bool operator==(const stack<T, Container>& x, 7486 const stack<T, Container>& y); 7487 template <class T, class Container> 7488 bool operator< (const stack<T, Container>& x, 7489 const stack<T, Container>& y); 7490 template <class T, class Container> 7491 bool operator!=(const stack<T, Container>& x, 7492 const stack<T, Container>& y); 7493 template <class T, class Container> 7494 bool operator> (const stack<T, Container>& x, 7495 const stack<T, Container>& y); 7496 template <class T, class Container> 7497 bool operator>=(const stack<T, Container>& x, 7498 const stack<T, Container>& y); 7499 template <class T, class Container> 7500 bool operator<=(const stack<T, Container>& x, 7501 const stack<T, Container>& y); 7502 } 7503</pre> 7504 7505<p><i>[Copenhagen: This change was discussed before the IS was released 7506and it was deliberately not adopted. Nevertheless, the LWG believes 7507(straw poll: 10-2) that it is a genuine defect.]</i></p> 7508 7509<hr> 7510<a name="308"><h3>308. Table 82 mentions unrelated headers</h3></a><p> 7511<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Mar 2001</p> 7512<p> 7513Table 82 in section 27 mentions the header <cstdlib> for String 7514streams (27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers <cstdio> and 7515<cwchar> for File streams (27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear 7516why these headers are mentioned in this context since they do not 7517define any of the library entities described by the 7518subclauses. According to 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers 7519are to be listed in the summary. 7520</p> 7521<p><b>Proposed resolution:</b></p> 7522<p>Remove <cstdlib> and <cwchar> from 7523Table 82.</p> 7524 7525<p><i>[Copenhagen: changed the proposed resolution slightly. The 7526original proposed resolution also said to remove <cstdio> from 7527Table 82. However, <cstdio> is mentioned several times within 7528section 27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p> 7529 7530<hr> 7531<a name="310"><h3>310. Is errno a macro?</h3></a><p> 7532<b>Section:</b> 17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</p> 7533 <p> 7534 Exactly how should errno be declared in a conforming C++ header? 7535 </p> 7536 7537 <p> 7538 The C standard says in 7.1.4 that it is unspecified whether errno is a 7539 macro or an identifier with external linkage. In some implementations 7540 it can be either, depending on compile-time options. (E.g., on 7541 Solaris in multi-threading mode, errno is a macro that expands to a 7542 function call, but is an extern int otherwise. "Unspecified" allows 7543 such variability.) 7544 </p> 7545 7546 <p>The C++ standard:</p> 7547 <ul> 7548 <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li> 7549 <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 7550 name (true), and implies that it is an identifier.</li> 7551 <li>19.3 simply lists errno as a macro (by what reasoning?) and goes 7552 on to say that the contents of of C++ <errno.h> are the 7553 same as in C, begging the question.</li> 7554 <li>C.2, table 95 lists errno as a macro, without comment.</li> 7555 </ul> 7556 7557 <p>I find no other references to errno.</p> 7558 7559 <p>We should either explicitly say that errno must be a macro, even 7560 though it need not be a macro in C, or else explicitly leave it 7561 unspecified. We also need to say something about namespace std. 7562 A user who includes <cerrno> needs to know whether to write 7563 <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or 7564 else <cerrno> is useless.</p> 7565 7566 <p>Two acceptable fixes:</p> 7567 <ul> 7568 <li><p>errno must be a macro. This is trivially satisfied by adding<br> 7569 #define errno (::std::errno)<br> 7570 to the headers if errno is not already a macro. You then always 7571 write errno without any scope qualification, and it always expands 7572 to a correct reference. Since it is always a macro, you know to 7573 avoid using errno as a local identifer.</p></li> 7574 <li><p>errno is in the global namespace. This fix is inferior, because 7575 ::errno is not guaranteed to be well-formed.</p></li> 7576 </ul> 7577 7578 <p><i>[ 7579 This issue was first raised in 1999, but it slipped through 7580 the cracks. 7581 ]</i></p> 7582<p><b>Proposed resolution:</b></p> 7583 <p>Change the Note in section 17.4.1.2p5 from</p> 7584 7585 <blockquote> 7586 Note: the names defined as macros in C include the following: 7587 assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. 7588 </blockquote> 7589 7590 <p>to</p> 7591 7592 <blockquote> 7593 Note: the names defined as macros in C include the following: 7594 assert, offsetof, setjmp, va_arg, va_end, and va_start. 7595 </blockquote> 7596 7597 <p>In section 19.3, change paragraph 2 from</p> 7598 7599 <blockquote> 7600 The contents are the same as the Standard C library header 7601 <errno.h>. 7602 </blockquote> 7603 7604 <p>to</p> 7605 7606 <blockquote> 7607 The contents are the same as the Standard C library header 7608 <errno.h>, except that errno shall be defined as a macro. 7609 </blockquote> 7610<p><b>Rationale:</b></p> 7611<p>C++ must not leave it up to the implementation to decide whether or 7612not a name is a macro; it must explicitly specify exactly which names 7613are required to be macros. The only one that really works is for it 7614to be a macro.</p> 7615 7616<p><i>[Curaçao: additional rationale added.]</i></p> 7617 7618<hr> 7619<a name="311"><h3>311. Incorrect wording in basic_ostream class synopsis</h3></a><p> 7620<b>Section:</b> 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Mar 2001</p> 7621 7622<p>In 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p> 7623 7624<pre> 7625 // partial specializationss 7626 template<class traits> 7627 basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&, 7628 const char * ); 7629</pre> 7630 7631<p>Problems:</p> 7632<ul> 7633<li>Too many 's's at the end of "specializationss" </li> 7634<li>This is an overload, not a partial specialization</li> 7635</ul> 7636 7637<p><b>Proposed resolution:</b></p> 7638<p>In the synopsis in 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the 7639<i>// partial specializationss</i> comment. Also remove the same 7640comment (correctly spelled, but still incorrect) from the synopsis in 764127.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>. 7642</p> 7643 7644<p><i>[ 7645Pre-Redmond: added 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's 7646comment in c++std-lib-8939. 7647]</i></p> 7648 7649<hr> 7650<a name="312"><h3>312. Table 27 is missing headers</h3></a><p> 7651<b>Section:</b> 20 <a href="lib-utilities.html#lib.utilities"> [lib.utilities]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Mar 2001</p> 7652<p>Table 27 in section 20 lists the header <memory> (only) for 7653Memory (lib.memory) but neglects to mention the headers 7654<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p> 7655<p><b>Proposed resolution:</b></p> 7656<p>Add <cstdlib> and <cstring> to Table 27, in the same row 7657as <memory>.</p> 7658<hr> 7659<a name="315"><h3>315. Bad "range" in list::unique complexity</h3></a><p> 7660<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p> 7661<p> 766223.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of 7663list::unique as: "If the range (last - first) is not empty, exactly 7664(last - first) -1 applications of the corresponding predicate, 7665otherwise no applications of the predicate)". 7666</p> 7667 7668<p> 7669"(last - first)" is not a range. 7670</p> 7671<p><b>Proposed resolution:</b></p> 7672<p> 7673Change the "range" from (last - first) to [first, last). 7674</p> 7675<hr> 7676<a name="316"><h3>316. Vague text in Table 69</h3></a><p> 7677<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p> 7678<p>Table 69 says this about a_uniq.insert(t):</p> 7679 7680<blockquote> 7681inserts t if and only if there is no element in the container with key 7682equivalent to the key of t. The bool component of the returned pair 7683indicates whether the insertion takes place and the iterator component of the 7684pair points to the element with key equivalent to the key of t. 7685</blockquote> 7686 7687<p>The description should be more specific about exactly how the bool component 7688indicates whether the insertion takes place.</p> 7689<p><b>Proposed resolution:</b></p> 7690<p>Change the text in question to</p> 7691 7692<blockquote> 7693...The bool component of the returned pair is true if and only if the insertion 7694takes place... 7695</blockquote> 7696<hr> 7697<a name="317"><h3>317. Instantiation vs. specialization of facets</h3></a><p> 7698<b>Section:</b> 22 <a href="lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p> 7699<p> 7700The localization section of the standard refers to specializations of 7701the facet templates as instantiations even though the required facets 7702are typically specialized rather than explicitly (or implicitly) 7703instantiated. In the case of ctype<char> and 7704ctype_byname<char> (and the wchar_t versions), these facets are 7705actually required to be specialized. The terminology should be 7706corrected to make it clear that the standard doesn't mandate explicit 7707instantiation (the term specialization encompasses both explicit 7708instantiations and specializations). 7709</p> 7710<p><b>Proposed resolution:</b></p> 7711<p> 7712In the following paragraphs, replace all occurrences of the word 7713instantiation or instantiations with specialization or specializations, 7714respectively: 7715</p> 7716 7717<blockquote> 771822.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5, 771922.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 772022.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and 7721Footnote 242. 7722</blockquote> 7723 7724<p>And change the text in 22.1.1.1.1, p4 from</p> 7725 7726<blockquote> 7727 An implementation is required to provide those instantiations 7728 for facet templates identified as members of a category, and 7729 for those shown in Table 52: 7730</blockquote> 7731 7732<p>to</p> 7733 7734<blockquote> 7735 An implementation is required to provide those specializations... 7736</blockquote> 7737 7738<p><i>[Nathan will review these changes, and will look for places where 7739explicit specialization is necessary.]</i></p> 7740 7741<p><b>Rationale:</b></p> 7742<p>This is a simple matter of outdated language. The language to 7743describe templates was clarified during the standardization process, 7744but the wording in clause 22 was never updated to reflect that 7745change.</p> 7746<hr> 7747<a name="318"><h3>318. Misleading comment in definition of numpunct_byname</h3></a><p> 7748<b>Section:</b> 22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 May 2001</p> 7749<p>The definition of the numpunct_byname template contains the following 7750comment:</p> 7751 7752<pre> 7753 namespace std { 7754 template <class charT> 7755 class numpunct_byname : public numpunct<charT> { 7756 // this class is specialized for char and wchar_t. 7757 ... 7758</pre> 7759 7760<p>There is no documentation of the specializations and it seems 7761conceivable that an implementation will not explicitly specialize the 7762template at all, but simply provide the primary template.</p> 7763<p><b>Proposed resolution:</b></p> 7764<p>Remove the comment from the text in 22.2.3.2 and from the proposed 7765resolution of library issue <a href="lwg-defects.html#228">228</a>.</p> 7766<hr> 7767<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p> 7768<b>Section:</b> 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p> 7769<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required 7770behavior" elements describe "the semantics of a function definition 7771provided by either the implementation or a C++ program."</p> 7772 7773<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires" 7774elements describe "the preconditions for calling the function."</p> 7775 7776<p>In the sections noted below, the current wording specifies 7777"Required Behavior" for what are actually preconditions, and thus 7778should be specified as "Requires".</p> 7779 7780<p><b>Proposed resolution:</b></p> 7781 7782<p>In 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p> 7783<blockquote> 7784 <p>Required behavior: accept a value of ptr that is null or that was 7785 returned by an earlier call ...</p> 7786</blockquote> 7787<p>to:</p> 7788<blockquote> 7789 <p>Requires: the value of ptr is null or the value returned by an 7790 earlier call ...</p> 7791</blockquote> 7792 7793<p>In 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p> 7794<blockquote> 7795 <p>Required behavior: accept a value of ptr that is null or that was 7796 returned by an earlier call ...</p> 7797</blockquote> 7798<p>to:</p> 7799<blockquote> 7800 <p>Requires: the value of ptr is null or the value returned by an 7801 earlier call ...</p> 7802</blockquote> 7803 7804<hr> 7805<a name="321"><h3>321. Typo in num_get</h3></a><p> 7806<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Kevin Djang <b>Date:</b> 17 May 2001</p> 7807<p> 7808Section 22.2.2.1.2 at p7 states that "A length specifier is added to 7809the conversion function, if needed, as indicated in Table 56." 7810However, Table 56 uses the term "length modifier", not "length 7811specifier". 7812</p> 7813<p><b>Proposed resolution:</b></p> 7814<p> 7815In 22.2.2.1.2 at p7, change the text "A length specifier is added ..." 7816to be "A length modifier is added ..." 7817</p> 7818<p><b>Rationale:</b></p> 7819<p>C uses the term "length modifier". We should be consistent.</p> 7820<hr> 7821<a name="322"><h3>322. iterator and const_iterator should have the same value type</h3></a><p> 7822<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 17 May 2001</p> 7823<p> 7824It's widely assumed that, if X is a container, 7825iterator_traits<X::iterator>::value_type and 7826iterator_traits<X::const_iterator>::value_type should both be 7827X::value_type. However, this is nowhere stated. The language in 7828Table 65 is not precise about the iterators' value types (it predates 7829iterator_traits), and could even be interpreted as saying that 7830iterator_traits<X::const_iterator>::value_type should be "const 7831X::value_type". 7832</p> 7833 7834<p>Related issue: <a href="lwg-closed.html#279">279</a>.</p> 7835<p><b>Proposed resolution:</b></p> 7836<p>In Table 65 ("Container Requirements"), change the return type for 7837X::iterator to "iterator type whose value type is T". Change the 7838return type for X::const_iterator to "constant iterator type whose 7839value type is T".</p> 7840<p><b>Rationale:</b></p> 7841<p> 7842This belongs as a container requirement, rather than an iterator 7843requirement, because the whole notion of iterator/const_iterator 7844pairs is specific to containers' iterator. 7845</p> 7846<p> 7847It is existing practice that (for example) 7848iterator_traits<list<int>::const_iterator>::value_type 7849is "int", rather than "const int". This is consistent with 7850the way that const pointers are handled: the standard already 7851requires that iterator_traits<const int*>::value_type is int. 7852</p> 7853<hr> 7854<a name="327"><h3>327. Typo in time_get facet in table 52</h3></a><p> 7855<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Tiki Wan <b>Date:</b> 06 Jul 2001</p> 7856<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and 7857<tt>time_get_byname</tt> are listed incorrectly in table 52, 7858required instantiations. In both cases the second template 7859parameter is given as OutputIterator. It should instead be 7860InputIterator, since these are input facets.</p> 7861<p><b>Proposed resolution:</b></p> 7862<p> 7863In table 52, required instantiations, in 786422.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p> 7865<pre> 7866 time_get<wchar_t, OutputIterator> 7867 time_get_byname<wchar_t, OutputIterator> 7868</pre> 7869<p>to</p> 7870<pre> 7871 time_get<wchar_t, InputIterator> 7872 time_get_byname<wchar_t, InputIterator> 7873</pre> 7874 7875<p><i>[Redmond: Very minor change in proposed resolution. Original had 7876a typo, wchart instead of wchar_t.]</i></p> 7877 7878<hr> 7879<a name="328"><h3>328. Bad sprintf format modifier in money_put<>::do_put()</h3></a><p> 7880<b>Section:</b> 22.2.6.2.2 <a href="lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 07 Jul 2001</p> 7881<p>The sprintf format string , "%.01f" (that's the digit one), in the 7882description of the do_put() member functions of the money_put facet in 788322.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong 7884for values of type long double, and second, the precision of 01 7885doesn't seem to make sense. What was most likely intended was 7886"%.0Lf"., that is a precision of zero followed by the L length 7887modifier.</p> 7888<p><b>Proposed resolution:</b></p> 7889<p>Change the format string to "%.0Lf".</p> 7890<p><b>Rationale:</b></p> 7891<p>Fixes an obvious typo</p> 7892<hr> 7893<a name="331"><h3>331. bad declaration of destructor for ios_base::failure</h3></a><p> 7894<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 23 Aug 2001</p> 7895<p> 7896With the change in 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state 7897 "An implementation may strengthen the exception-specification for a 7898 non-virtual function by removing listed exceptions." 7899(issue <a href="lwg-defects.html#119">119</a>) 7900and the following declaration of ~failure() in ios_base::failure 7901</p> 7902<pre> 7903 namespace std { 7904 class ios_base::failure : public exception { 7905 public: 7906 ... 7907 virtual ~failure(); 7908 ... 7909 }; 7910 } 7911</pre> 7912<p>the class failure cannot be implemented since in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty 7913exception specification:</p> 7914<pre> 7915 namespace std { 7916 class exception { 7917 public: 7918 ... 7919 virtual ~exception() throw(); 7920 ... 7921 }; 7922 } 7923</pre> 7924<p><b>Proposed resolution:</b></p> 7925<p>Remove the declaration of ~failure().</p> 7926<p><b>Rationale:</b></p> 7927<p>The proposed resolution is consistent with the way that destructors 7928of other classes derived from <tt>exception</tt> are handled.</p> 7929<hr> 7930<a name="335"><h3>335. minor issue with char_traits, table 37</h3></a><p> 7931<b>Section:</b> 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 06 Sep 2001</p> 7932<p> 7933Table 37, in 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign 7934as: 7935</p> 7936<pre> 7937 X::assign(c,d) assigns c = d. 7938</pre> 7939 7940<p>And para 1 says:</p> 7941 7942<blockquote> 7943 [...] c and d denote values of type CharT [...] 7944</blockquote> 7945 7946<p> 7947Naturally, if c and d are <i>values</i>, then the assignment is 7948(effectively) meaningless. It's clearly intended that (in the case of 7949assign, at least), 'c' is intended to be a reference type. 7950</p> 7951 7952<p>I did a quick survey of the four implementations I happened to have 7953lying around, and sure enough they all have signatures:</p> 7954<pre> 7955 assign( charT&, const charT& ); 7956</pre> 7957 7958<p>(or the equivalent). It's also described this way in Nico's book. 7959(Not to mention the synopses of char_traits<char> in 21.1.3.1 7960and char_traits<wchar_t> in 21.1.3.2...) 7961</p> 7962<p><b>Proposed resolution:</b></p> 7963<p>Add the following to 21.1.1 para 1:</p> 7964<blockquote> 7965 r denotes an lvalue of CharT 7966</blockquote> 7967 7968<p>and change the description of assign in the table to:</p> 7969<pre> 7970 X::assign(r,d) assigns r = d 7971</pre> 7972<hr> 7973<a name="337"><h3>337. replace_copy_if's template parameter should be InputIterator</h3></a><p> 7974<b>Section:</b> 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 07 Sep 2001</p> 7975<p>From c++std-edit-876:</p> 7976 7977<p> 7978In section 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first 7979parameter of template replace_copy_if should be "InputIterator" 7980instead of "Iterator". According to 17.3.2.1 <a href="lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the 7981parameter name conveys real normative meaning. 7982</p> 7983<p><b>Proposed resolution:</b></p> 7984<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p> 7985<hr> 7986<a name="345"><h3>345. type tm in <cwchar></h3></a><p> 7987<b>Section:</b> 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Clark Nelson <b>Date:</b> 19 Oct 2001</p> 7988<p> 7989C99, and presumably amendment 1 to C90, specify that <wchar.h> 7990declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in 7991<cwchar>. Is this omission intentional or accidental? 7992</p> 7993<p><b>Proposed resolution:</b></p> 7994<p>In section 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p> 7995<hr> 7996<a name="346"><h3>346. Some iterator member functions should be const</h3></a><p> 7997<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 20 Oct 2001</p> 7998<p>Iterator member functions and operators that do not change the state 7999of the iterator should be defined as const member functions or as 8000functions that take iterators either by const reference or by 8001value. The standard does not explicitly state which functions should 8002be const. Since this a fairly common mistake, the following changes 8003are suggested to make this explicit.</p> 8004 8005<p>The tables almost indicate constness properly through naming: r 8006for non-const and a,b for const iterators. The following changes 8007make this more explicit and also fix a couple problems.</p> 8008<p><b>Proposed resolution:</b></p> 8009<p>In 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from 8010"In the following sections, a and b denote values of X..." to 8011"In the following sections, a and b denote values of type const X...".</p> 8012 8013<p>In Table 73, change</p> 8014<pre> 8015 a->m U& ... 8016</pre> 8017 8018<p>to</p> 8019 8020<pre> 8021 a->m const U& ... 8022 r->m U& ... 8023</pre> 8024 8025<p>In Table 73 expression column, change</p> 8026 8027<pre> 8028 *a = t 8029</pre> 8030 8031<p>to</p> 8032 8033<pre> 8034 *r = t 8035</pre> 8036 8037<p><i>[Redmond: The container requirements should be reviewed to see if 8038the same problem appears there.]</i></p> 8039 8040<p>----- End of document -----</p> 8041</body> 8042</html> 8043