+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
-<html>
-<head><title>C++ Standard Library Defect Report List</title></head>
-<body bgcolor="#ffffff" text="#000000">
-<table>
-<tr>
-<td align="left">Doc. no.</td>
-<td align="left">J16/02-0049 = WG21 N1391</td>
-</tr>
-<tr>
-<td align="left">Date:</td>
-<td align="left">10 Sep 2002</td>
-</tr>
-<tr>
-<td align="left">Project:</td>
-<td align="left">Programming Language C++</td>
-</tr>
-<tr>
-<td align="left">Reply to:</td>
-<td align="left">Matt Austern <austern@apple.com></td>
-</tr>
-</table>
-<h1>C++ Standard Library Defect Report List (Revision 23)</h1>
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
- <p>Also see:</p>
- <ul>
- <li>
-<a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
- <li>
-<a href="lwg-index.html">Index by Section</a> for all library issues.</li>
- <li>
-<a href="lwg-status.html">Index by Status</a> for all library issues.</li>
- <li><a href="lwg-active.html">Library Active Issues List</a></li>
- <li><a href="lwg-closed.html">Library Closed Issues List</a></li>
- </ul>
- <p>This document contains only library issues which have been closed
- by the Library Working Group (LWG) after being found to be defects
- 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
- <a href="lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the
- <a href="lwg-active.html">Library Active Issues List</a> for active issues and more information. The
- introductory material in that document also applies to this
- document.</p>
-<h2>Revision History</h2>
-<ul>
-<li>R23:
-Pre-Santa Cruz mailing. Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
-Moved issues in the TC to TC status.
-</li>
-<li>R22:
-Post-Curaçao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
-</li>
-<li>R21:
-Pre-Curaçao mailing. Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>.
-</li>
-<li>R20:
-Post-Redmond mailing; reflects actions taken in Redmond. Added
-new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues
-<a href="lwg-active.html#347">347</a>-<a href="lwg-active.html#350">350</a> were added since Redmond, hence
-not discussed at the meeting.
-
-All Ready issues were moved to DR status, with the exception of issues
-<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>.
-
-Noteworthy issues discussed at Redmond include
-<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>,
-<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>.
-</li>
-<li>R19:
-Pre-Redmond mailing. Added new issues
-<a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
-</li>
-<li>R18:
-Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
-new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
-
-Changed status of issues
-<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>
-<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>
-<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>
-<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>
-<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>
-<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>
-<a href="lwg-defects.html#268">268</a>
-to DR.
-
-Changed status of issues
-<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>
-<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>
-<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>
-<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>
-<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>
-<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>
-<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>
-<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>
-<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
-to Ready.
-
-Closed issues
-<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>
-<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>
-<a href="lwg-closed.html#314">314</a>
-as NAD.
-
-</li>
-<li>R17:
-Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions 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>.
-Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
-</li>
-<li>R16:
-post-Toronto mailing; reflects actions taken in Toronto. Added new
-issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>. Changed status of issues
-<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>,
-<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
-<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
-<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
-<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
-<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
-<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
-<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
-<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
-<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
-<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
-<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
-<a href="lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
-issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
-<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
-issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
-appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
-the bug in enough places.
-</li>
-<li>R15:
-pre-Toronto mailing. Added issues
-<a href="lwg-active.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
-changes so that we pass Weblint tests.
-</li>
-<li>R14:
-post-Tokyo II mailing; reflects committee actions taken in
-Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
-</li>
-<li>R13:
-pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
-</li>
-<li>R12:
-pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
-<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
-of issue <a href="lwg-defects.html#29">29</a>. Add further rationale to issue
-<a href="lwg-closed.html#178">178</a>.
-</li>
-<li>R11:
-post-Kona mailing: Updated to reflect LWG and full committee actions
-in Kona (99-0048/N1224). Note changed resolution of issues
-<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>
-to <a href="lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
-"closed" documents. Changed the proposed resolution of issue
-<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
-of issue <a href="lwg-defects.html#38">38</a>.
-</li>
-<li>R10:
-pre-Kona updated. Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
-<a href="lwg-defects.html#86">86</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
-<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
-<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
-</li>
-<li>R9:
-pre-Kona mailing. Added issues <a href="lwg-closed.html#140">140</a> to
-<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and
-"closed" documents. (99-0030/N1206, 25 Aug 99)
-</li>
-<li>R8:
-post-Dublin mailing. Updated to reflect LWG and full committee actions
-in Dublin. (99-0016/N1193, 21 Apr 99)
-</li>
-<li>R7:
-pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
-<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
-<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
-<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
-</li>
-<li>R6:
-pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
-and <a href="lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
-</li>
-<li>R5:
-update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
-<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
-for making list public. (30 Dec 98)
-</li>
-<li>R4:
-post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
-<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
-issues corrected. (22 Oct 98)
-</li>
-<li>R3:
-post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
-added, many issues updated to reflect LWG consensus (12 Oct 98)
-</li>
-<li>R2:
-pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
-issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
-</li>
-<li>R1:
-Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
-format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
-</li>
-</ul>
-<h2>Defect Reports</h2>
-<hr>
-<a name="1"><h3>1. C library linkage editing oversight</h3></a><p>
-<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>
-<p>The change specified in the proposed resolution below did not make
-it into the Standard. This change was accepted in principle at the
-London meeting, and the exact wording below was accepted at the
-Morristown meeting.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
-from:</p>
-
-<blockquote>
- <p>It is unspecified whether a name from the Standard C library
- declared with external linkage has either extern "C" or
- extern "C++" linkage.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>Whether a name from the Standard C library declared with external
- linkage has extern "C" or extern "C++" linkage
- is implementation defined. It is recommended that an implementation
- use extern "C++" linkage for this purpose.</p>
-</blockquote>
-<hr>
-<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p>
-<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>
-<p>We appear not to have covered all the possibilities of
- exit processing with respect to
-atexit registration. <br>
-<br>
-Example 1: (C and C++)</p>
-
-<pre> #include <stdlib.h>
- void f1() { }
- void f2() { atexit(f1); }
-
- int main()
- {
- atexit(f2); // the only use of f2
- return 0; // for C compatibility
- }</pre>
-
-<p>At program exit, f2 gets called due to its registration in
-main. Running f2 causes f1 to be newly registered during the exit
-processing. Is this a valid program? If so, what are its
-semantics?</p>
-
-<p>
-Interestingly, neither the C standard, nor the C++ draft standard nor
-the forthcoming C9X Committee Draft says directly whether you can
-register a function with atexit during exit processing.</p>
-
-<p>
-All 3 standards say that functions are run in reverse order of their
-registration. Since f1 is registered last, it ought to be run first,
-but by the time it is registered, it is too late to be first.</p>
-
-<p>If the program is valid, the standards are self-contradictory about
-its semantics.</p>
-
-<p>Example 2: (C++ only)</p>
-
-<pre>
- void F() { static T t; } // type T has a destructor
-
- int main()
- {
- atexit(F); // the only use of F
- }
-</pre>
-
-<p>Function F registered with atexit has a local static variable t,
-and F is called for the first time during exit processing. A local
-static object is initialized the first time control flow passes
-through its definition, and all static objects are destroyed during
-exit processing. Is the code valid? If so, what are its semantics?</p>
-
-<p>
-Section 18.3 "Start and termination" says that if a function
-F is registered with atexit before a static object t is initialized, F
-will not be called until after t's destructor completes.</p>
-
-<p>
-In example 2, function F is registered with atexit before its local
-static object O could possibly be initialized. On that basis, it must
-not be called by exit processing until after O's destructor
-completes. But the destructor cannot be run until after F is called,
-since otherwise the object could not be constructed in the first
-place.</p>
-
-<p>If the program is valid, the standard is self-contradictory about
-its semantics.</p>
-
-<p>I plan to submit Example 1 as a public comment on the C9X CD, with
-a recommendation that the results be undefined. (Alternative: make it
-unspecified. I don't think it is worthwhile to specify the case where
-f1 itself registers additional functions, each of which registers
-still more functions.)</p>
-
-<p>I think we should resolve the situation in the whatever way the C
-committee decides. </p>
-
-<p>For Example 2, I recommend we declare the results undefined.</p>
-
-<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Change section 18.3/8 from:</p>
-<blockquote>
- First, objects with static storage duration are destroyed and
- functions registered by calling atexit are called. Objects with
- static storage duration are destroyed in the reverse order of the
- completion of their constructor. (Automatic objects are not
- destroyed as a result of calling exit().) Functions registered with
- atexit are called in the reverse order of their registration. A
- function registered with atexit before an object obj1 of static
- storage duration is initialized will not be called until obj1's
- destruction has completed. A function registered with atexit after
- an object obj2 of static storage duration is initialized will be
- called before obj2's destruction starts.
-</blockquote>
-<p>to:</p>
-<blockquote>
- First, objects with static storage duration are destroyed and
- functions registered by calling atexit are called. Non-local objects
- with static storage duration are destroyed in the reverse order of
- the completion of their constructor. (Automatic objects are not
- destroyed as a result of calling exit().) Functions registered with
- atexit are called in the reverse order of their registration, except
- that a function is called after any previously registered functions
- that had already been called at the time it was registered. A
- function registered with atexit before a non-local object obj1 of
- static storage duration is initialized will not be called until
- obj1's destruction has completed. A function registered with atexit
- after a non-local object obj2 of static storage duration is
- initialized will be called before obj2's destruction starts. A local
- static object obj3 is destroyed at the same time it would be if a
- function calling the obj3 destructor were registered with atexit at
- the completion of the obj3 constructor.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
-supporting to the proposed resolution.</p>
-<hr>
-<a name="5"><h3>5. String::compare specification questionable</h3></a><p>
-<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>
-<p>At the very end of the basic_string class definition is the signature: int
-compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
-following text this is defined as: returns
-basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
-basic_string<charT,traits,Allocator>(s,n2); </p>
-
-<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a
-= Allocator()) clearly requires that s != NULL and n < npos and further states that it
-throws length_error if n == npos, it appears the compare() signature above should always
-throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
-null terminated character array. </p>
-
-<p>This appears to be a typo since the obvious intent is to allow either the call above or
-something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
-
-<p>This would imply that what was really intended was two signatures int compare(size_type
-pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
-charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the compare signature in 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
-(at the very end of the basic_string synopsis) which reads:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos1, size_type n1,<br>
- const charT* s,
- size_type n2 = npos) const;</tt></p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos1, size_type n1,<br>
- const charT* s) const;<br>
- int compare(size_type pos1, size_type n1,<br>
- const charT* s,
- size_type n2) const;</tt></p>
-</blockquote>
-
-<p>Replace the portion of 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
-paragraphs 5 and 6 which read:</p>
-
-<blockquote>
- <p>
-<tt>int compare(size_type pos, size_type n1,<br>
- charT * s, size_type n2
- = npos) const;<br>
- </tt>Returns:<tt><br>
- basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
-
- basic_string<charT,traits,Allocator>( s, n2))</tt>
-</p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p>
-<tt>int compare(size_type pos, size_type n1,<br>
- const charT * s) const;<br>
- </tt>Returns:<tt><br>
- basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
-
- basic_string<charT,traits,Allocator>( s ))<br>
- <br>
- int compare(size_type pos, size_type n1,<br>
- const charT * s,
- size_type n2) const;<br>
- </tt>Returns:<tt><br>
- basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
-
- basic_string<charT,traits,Allocator>( s, n2))</tt>
-</p>
-</blockquote>
-
-<p>Editors please note that in addition to splitting the signature, the third argument
-becomes const, matching the existing synopsis.</p>
-<p><b>Rationale:</b></p>
-<p>While the LWG dislikes adding signatures, this is a clear defect in
-the Standard which must be fixed. The same problem was also
-identified in issues 7 (item 5) and 87.</p>
-<hr>
-<a name="7"><h3>7. String clause minor problems</h3></a><p>
-<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>
-<p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
-<class InputIterator> insert(iterator, InputIterator,
-InputIterator) makes no sense. It refers to a member function that
-doesn't exist. It also talks about the return value of a void
-function. </p>
-
-<p>(2) Several versions of basic_string::replace don't appear in the
-class synopsis. </p>
-
-<p>(3) basic_string::push_back appears in the synopsis, but is never
-described elsewhere. In the synopsis its argument is const charT,
-which doesn't makes much sense; it should probably be charT, or
-possible const charT&. </p>
-
-<p>(4) basic_string::pop_back is missing. </p>
-
-<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
-= npos) make no sense. First, it's const charT* in the synopsis and
-charT* in the description. Second, given what it says in RETURNS,
-leaving out the final argument will always result in an exception
-getting thrown. This is paragraphs 5 and 6 of
-21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
-</p>
-
-<p>(6) In table 37, in section 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
-there's a note for X::move(s, p, n). It says "Copies correctly
-even where p is in [s, s+n)". This is correct as far as it goes,
-but it doesn't go far enough; it should also guarantee that the copy
-is correct even where s in in [p, p+n). These are two orthogonal
-guarantees, and neither one follows from the other. Both guarantees
-are necessary if X::move is supposed to have the same sort of
-semantics as memmove (which was clearly the intent), and both
-guarantees are necessary if X::move is actually supposed to be
-useful. </p>
-<p><b>Proposed resolution:</b></p>
-<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
-<br>
- EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
-<br>
-ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in
-the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
-<br>
-ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
-[lib.basic.string]) from:</p>
-
-<p> void push_back(const charT)<br>
-<br>
-to<br>
-<br>
- void push_back(charT)<br>
-<br>
-Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
-<br>
- void basic_string::push_back(charT c);<br>
- EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br>
-<br>
-ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
-<br>
-ITEM 5: Duplicate; see issue 5 (and 87).<br>
-<br>
-ITEM 6: In table 37, Replace:<br>
-<br>
- "Copies correctly even where p is in [s, s+n)."<br>
-<br>
-with:<br>
-<br>
- "Copies correctly even where the ranges [p, p+n) and [s,
-s+n) overlap."</p>
-<hr>
-<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p>
-<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>
-<p>It appears there's an important guarantee missing from clause
-22. We're told that invoking locale::global(L) sets the C locale if L
-has a name. However, we're not told whether or not invoking
-setlocale(s) sets the global C++ locale. </p>
-
-<p>The intent, I think, is that it should not, but I can't find any
-such words anywhere. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add a sentence at the end of 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
-paragraph 2: </p>
-
-<blockquote>
- <p>No library function other than <tt>locale::global()</tt> shall affect
- the value returned by <tt>locale()</tt>. </p>
-
-</blockquote>
-<hr>
-<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p>
-<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>
-<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
-section 3.7.3.1 of CD2 seems to allow for the possibility that all
-calls to operator new(0) yield the same pointer, an implementation
-technique specifically prohibited by ARM 5.3.3.Was this prohibition
-really lifted? Does the FDIS agree with CD2 in the regard? [Issues
-list maintainer's note: the IS is the same.]</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the last paragraph of 3.7.3 from:</p>
-<blockquote>
- <p>Any allocation and/or deallocation functions defined in a C++ program shall
- conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Any allocation and/or deallocation functions defined in a C++ program,
- including the default versions in the library, shall conform to the semantics
- specified in 3.7.3.1 and 3.7.3.2.</p>
-</blockquote>
-<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
-<blockquote>
- <p>If the size of the space requested is zero, the value returned shall not be
- a null pointer value (4.10).</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Even if the size of the space requested is zero, the request can fail. If
- the request succeeds, the value returned shall be a non-null pointer value
- (4.10) p0 different from any previously returned value p1, unless that value
- p1 was since passed to an operator delete.</p>
-</blockquote>
-<p>5.3.4/7 currently reads:</p>
-<blockquote>
- <p>When the value of the expression in a direct-new-declarator is zero, the
- allocation function is called to allocate an array with no elements. The
- pointer returned by the new-expression is non-null. [Note: If the library
- allocation function is called, the pointer returned is distinct from the
- pointer to any other object.]</p>
-</blockquote>
-<p>Retain the first sentence, and delete the remainder.</p>
-<p>18.4.1 currently has no text. Add the following:</p>
-<blockquote>
- <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
- library versions of operator new and operator delete.</p>
-</blockquote>
-<p>To 18.4.1.3, add the following text:</p>
-<blockquote>
- <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
- operator new and operator delete.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
-supporting to the proposed resolution.</p>
-<hr>
-<a name="11"><h3>11. Bitset minor problems</h3></a><p>
-<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>
-<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
-not documented in 23.3.5.2. </p>
-
-<p>(2) The class synopsis only gives a single signature for bitset<>::operator[],
-reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
-on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
-
-<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
-trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
-go in the Effects clause.</p>
-<p><b>Proposed resolution:</b></p>
-<p>ITEMS 1 AND 2:<br>
-<br>
-In the bitset synopsis (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
-replace the member function <br>
-<br>
-<tt> reference operator[](size_t pos);<br>
-</tt><br>
-with the two member functions<br>
-<br>
-<tt> bool operator[](size_t pos) const; <br>
- reference operator[](size_t pos); <br>
-</tt><br>
-Add the following text at the end of 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
-immediately after paragraph 45:</p>
-
-<blockquote>
- <p>
-<tt>bool operator[](size_t pos) const;</tt><br>
- Requires: pos is valid<br>
- Throws: nothing<br>
- Returns: <tt>test(pos)</tt><br>
- <br>
- <tt>bitset<N>::reference operator[](size_t pos);</tt> <br>
- Requires: pos is valid<br>
- Throws: nothing<br>
- Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos]
- == this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos,
- val);</tt>
-</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG believes Item 3 is not a defect. "Formatted
-input" implies the desired semantics. See 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
-</p>
-<hr>
-<a name="13"><h3>13. Eos refuses to die</h3></a><p>
-<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>
-<p>In 27.6.1.2.3, there is a reference to "eos", which is
-the only one in the whole draft (at least using Acrobat search), so
-it's undefined. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
-"charT()"</p>
-<hr>
-<a name="14"><h3>14. Locale::combine should be const</h3></a><p>
-<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>
-<p>locale::combine is the only member function of locale (other than constructors and
-destructor) that is not const. There is no reason for it not to be const, and good reasons
-why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
-paragraph 6: "An instance of a locale is immutable." </p>
-
-<p>History: this member function originally was a constructor. it happened that the
-interface it specified had no corresponding language syntax, so it was changed to a member
-function. As constructors are never const, there was no "const" in the interface
-which was transformed into member "combine". It should have been added at that
-time, but the omission was not noticed. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-"const" to the declaration of member combine: </p>
-<blockquote>
- <pre>template <class Facet> locale combine(const locale& other) const; </pre>
-</blockquote>
-<hr>
-<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p>
-<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>
-<p>locale::name() is described as returning a string that can be passed to a locale
-constructor, but there is no matching constructor. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
-"<tt>locale(name())</tt>" with
-"<tt>locale(name().c_str())</tt>".
-</p>
-<hr>
-<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p>
-<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>
-<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
-edited in properly. Instead, the member do_widen appears four times, with wrong argument
-lists. </p>
-<p><b>Proposed resolution:</b></p>
-<p>The correct declarations for the overloaded members
-<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
-from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
-<hr>
-<a name="17"><h3>17. Bad bool parsing</h3></a><p>
-<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>
-<p>This section describes the process of parsing a text boolean value from the input
-stream. It does not say it recognizes either of the sequences "true" or
-"false" and returns the corresponding bool value; instead, it says it recognizes
-only one of those sequences, and chooses which according to the received value of a
-reference argument intended for returning the result, and reports an error if the other
-sequence is found. (!) Furthermore, it claims to get the names from the ctype<>
-facet rather than the numpunct<> facet, and it examines the "boolalpha"
-flag wrongly; it doesn't define the value "loc"; and finally, it computes
-wrongly whether to use numeric or "alpha" parsing.<br>
-<br>
-I believe the correct algorithm is "as if": </p>
-
-<pre> // in, err, val, and str are arguments.
- err = 0;
- const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
- const string_type t = np.truename(), f = np.falsename();
- bool tm = true, fm = true;
- size_t pos = 0;
- while (tm && pos < t.size() || fm && pos < f.size()) {
- if (in == end) { err = str.eofbit; }
- bool matched = false;
- if (tm && pos < t.size()) {
- if (!err && t[pos] == *in) matched = true;
- else tm = false;
- }
- if (fm && pos < f.size()) {
- if (!err && f[pos] == *in) matched = true;
- else fm = false;
- }
- if (matched) { ++in; ++pos; }
- if (pos > t.size()) tm = false;
- if (pos > f.size()) fm = false;
- }
- if (tm == fm || pos == 0) { err |= str.failbit; }
- else { val = tm; }
- return in;</pre>
-
-<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
-when one is a substring of the other. The proposed text below captures the logic of the
-code above.</p>
-<p><b>Proposed resolution:</b></p>
-<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,
-change "&&" to "&".</p>
-
-<p>Then, replace paragraphs 15 and 16 as follows:</p>
-
-<blockquote>
-
- <p>Otherwise target sequences are determined "as if" by
- calling the members <tt>falsename()</tt> and
- <tt>truename()</tt> of the facet obtained by
- <tt>use_facet<numpunct<charT> >(str.getloc())</tt>.
- Successive characters in the range <tt>[in,end)</tt> (see
- [lib.sequence.reqmts]) are obtained and matched against
- corresponding positions in the target sequences only as necessary to
- identify a unique match. The input iterator <tt>in</tt> is
- compared to <tt>end</tt> only when necessary to obtain a
- character. If and only if a target sequence is uniquely matched,
- <tt>val</tt> is set to the corresponding value.</p>
-
-</blockquote>
-
-<blockquote>
- <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
- successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
- <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
- <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
- <tt>(str.failbit|str.eofbit)</tt>if
- the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
- <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
- <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
- <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
- <tt>true</tt>:"1"
- and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
- and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
- <tt>err==str.failbit</tt>. --end example]</p>
-</blockquote>
-<hr>
-<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p>
-<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>
-<p>In the list of num_get<> non-virtual members on page 22-23, the member
-that parses bool values was omitted from the list of definitions of non-virtual
-members, though it is listed in the class definition and the corresponding
-virtual is listed everywhere appropriate. </p>
-<p><b>Proposed resolution:</b></p>
-<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>
-another get member for bool&, copied from the entry in
-22.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
-<hr>
-<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p>
-<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>
-<p>
-In the definitions of codecvt<>::do_out and do_in, they are
-specified to return noconv if "no conversion is
-needed". This definition is too vague, and does not say
-normatively what is done with the buffers.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the entry for noconv in the table under paragraph 4 in section
-22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
-</p>
-<blockquote>
- <p>
-<tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
- and input sequence is identical to converted sequence.</p>
-</blockquote>
-<p>Change the Note in paragraph 2 to normative text as follows:</p>
-<blockquote>
- <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
- same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
- <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
- unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
-</blockquote>
-<hr>
-<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p>
-<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>
-<p>The synopsis for numpunct<>::do_thousands_sep, and the
-definition of numpunct<>::thousands_sep which calls it, specify
-that it returns a value of type char_type. Here it is erroneously
-described as returning a "string_type". </p>
-<p><b>Proposed resolution:</b></p>
-<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
-"string_type" to "char_type". </p>
-<hr>
-<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p>
-<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>
-<p>In the second table in the section, captioned "Required
-instantiations", the instantiations for codecvt_byname<>
-have been omitted. These are necessary to allow users to construct a
-locale by name from facets. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add in 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
-"Required instantiations", in the category "ctype"
-the lines </p>
-
-<blockquote>
- <pre>codecvt_byname<char,char,mbstate_t>,
-codecvt_byname<wchar_t,char,mbstate_t> </pre>
-</blockquote>
-<hr>
-<a name="22"><h3>22. Member open vs. flags</h3></a><p>
-<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>
-<p>The description of basic_istream<>::open leaves unanswered questions about how it
-responds to or changes flags in the error status for the stream. A strict reading
-indicates that it ignores the bits and does not change them, which confuses users who do
-not expect eofbit and failbit to remain set after a successful open. There are three
-reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
-and eofbit on call to open(). </p>
-<p><b>Proposed resolution:</b></p>
-<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:
-</p>
-
-<blockquote>
- <p>A successful open does not change the error state.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>This may seem surprising to some users, but it's just an instance
-of a general rule: error flags are never cleared by the
-implementation. The only way error flags are are ever cleared is if
-the user explicitly clears them by hand.</p>
-
-<p>The LWG believed that preserving this general rule was
-important enough so that an exception shouldn't be made just for this
-one case. The resolution of this issue clarifies what the LWG
-believes to have been the original intent.</p>
-
-<hr>
-<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p>
-<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>
-<p>The description of codecvt<>::do_out and do_in mentions a
-symbol "do_convert" which is not defined in the
-standard. This is a leftover from an edit, and should be "do_in
-and do_out". </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
-"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
-or do_out". </p>
-<hr>
-<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p>
-<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>
-<p>In the description of operator<< applied to strings, the standard says that uses
-the smaller of os.width() and str.size(), to pad "as described in stage 3"
-elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 4 from:<br>
-<br>
- "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
-..."<br>
-<br>
-to: <br>
-<br>
- "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
-..."</p>
-<hr>
-<a name="26"><h3>26. Bad sentry example</h3></a><p>
-<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>
-<p>In paragraph 6, the code in the example: </p>
-
-<pre> template <class charT, class traits = char_traits<charT> >
- basic_istream<charT,traits>::sentry(
- basic_istream<charT,traits>& is, bool noskipws = false) {
- ...
- int_type c;
- typedef ctype<charT> ctype_type;
- const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
- while ((c = is.rdbuf()->snextc()) != traits::eof()) {
- if (ctype.is(ctype.space,c)==0) {
- is.rdbuf()->sputbackc (c);
- break;
- }
- }
- ...
- }</pre>
-
-<p>fails to demonstrate correct use of the facilities described. In
-particular, it fails to use traits operators, and specifies incorrect
-semantics. (E.g. it specifies skipping over the first character in the
-sequence without examining it.) </p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the example above from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
-paragraph 6.</p>
-<p><b>Rationale:</b></p>
-<p>The originally proposed replacement code for the example was not
-correct. The LWG tried in Kona and again in Tokyo to correct it
-without success. In Tokyo, an implementor reported that actual working
-code ran over one page in length and was quite complicated. The LWG
-decided that it would be counter-productive to include such a lengthy
-example, which might well still contain errors.</p>
-<hr>
-<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p>
-<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>
-<p>The string::erase(iterator first, iterator last) is specified to return an element one
-place beyond the next element after the last one erased. E.g. for the string
-"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
-while 'd' has not been erased. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
-
-<blockquote>
- <p>Returns: an iterator which points to the element immediately following _last_ prior to
- the element being erased. </p>
-</blockquote>
-
-<p>to read </p>
-
-<blockquote>
- <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
- other elements being erased. </p>
-</blockquote>
-<hr>
-<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p>
-<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>
-<p>The description of the vector form of ctype<char>::is can be interpreted to mean
-something very different from what was intended. Paragraph 4 says </p>
-
-<blockquote>
- <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
- table()[(unsigned char)*p]. </p>
-</blockquote>
-
-<p>This is intended to copy the value indexed from table()[] into the place identified in
-vec[]. </p>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<blockquote>
- <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
- the value table()[(unsigned char)*p]. </p>
-</blockquote>
-<hr>
-<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p>
-<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>
-<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
-a function ios_base::init, which is not defined. Probably they mean
-basic_ios<>::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
-paragraph 3. </p>
-<p><b>Proposed resolution:</b></p>
-<p>[R12: modified to include paragraph 5.]</p>
-
-<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>
-
-<blockquote>
- <p>ios_base::init </p>
-</blockquote>
-
-<p>to </p>
-
-<blockquote>
- <p>basic_ios<char>::init </p>
-</blockquote>
-
-<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
-should read </p>
-
-<blockquote>
- <p>basic_ios<wchar_t>::init </p>
-</blockquote>
-<hr>
-<a name="30"><h3>30. Wrong header for LC_*</h3></a><p>
-<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>
-<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
-where they are in fact defined elsewhere to appear in <clocale>. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
-"<cctype>" to read "<clocale>". </p>
-<hr>
-<a name="31"><h3>31. Immutable locale values</h3></a><p>
-<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>
-<p>Paragraph 6, says "An instance of <tt>locale</tt> is
-<i>immutable</i>; once a facet reference is obtained from it,
-...". This has caused some confusion, because locale variables
-are manifestly assignable. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
-
-<blockquote>
- <p>An instance of <tt>locale</tt> is immutable; once a facet
- reference is obtained from it, that reference remains usable as long
- as the locale value itself exists.</p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>Once a facet reference is obtained from a locale object by
- calling use_facet<>, that reference remains usable, and the
- results from member functions of it may be cached and re-used, as
- long as some locale object refers to that facet.</p>
-</blockquote>
-<hr>
-<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p>
-<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>
-<p>The description of the required state before calling virtual member
-basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
-described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
-Specifically, the latter says it calls pbackfail if: </p>
-
-<p> traits::eq(c,gptr()[-1]) is false </p>
-
-<p>where pbackfail claims to require: </p>
-
-<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
-
-<p>It appears that the pbackfail description is wrong. </p>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<blockquote>
- <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
-</blockquote>
-
-<p>to </p>
-
-<blockquote>
- <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
- </p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Note deliberate reordering of arguments for clarity in addition to the correction of
-the argument value.</p>
-<hr>
-<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p>
-<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>
-<p>In the table defining the results from do_out and do_in, the specification for the
-result <i>error</i> says </p>
-
-<blockquote>
- <p>encountered a from_type character it could not convert </p>
-</blockquote>
-
-<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
-an internT for do_out. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-in the table for the case of _error_ with </p>
-
-<blockquote>
- <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
-</blockquote>
-<hr>
-<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p>
-<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>
-<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
-ctype<charT>, but it has no such members. Note that this is also a problem in
-22.2.2.1.2, addressed in (4). </p>
-<p><b>Proposed resolution:</b></p>
-<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:
-clause for member put(...., bool), replace the initialization of the
-string_type value s as follows: </p>
-
-<blockquote>
- <pre>const numpunct& np = use_facet<numpunct<charT> >(loc);
-string_type s = val ? np.truename() : np.falsename(); </pre>
-</blockquote>
-<hr>
-<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p>
-<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>
-<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
-named "unitbuf". Unlike other manipulators, it's not listed
-in synopsis. Similarly for "nounitbuf". </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add to the synopsis for <ios> in 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
-the entry for "nouppercase", the prototypes: </p>
-
-<blockquote>
- <pre>ios_base& unitbuf(ios_base& str);
-ios_base& nounitbuf(ios_base& str); </pre>
-</blockquote>
-<hr>
-<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p>
-<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>
-<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
-specified badly, so that an implementation which only keeps the last value stored appears
-to conform. In particular, it says: </p>
-
-<p>The reference returned may become invalid after another call to the object's iword
-member with a different index ... </p>
-
-<p>This is not idle speculation; at least one implementation was done this way. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-paragraph 4, replace the sentence: </p>
-
-<blockquote>
- <p>The reference returned may become invalid after another call to the object's iword
- [pword] member with a different index, after a call to its copyfmt member, or when the
- object is destroyed. </p>
-</blockquote>
-
-<p>with: </p>
-
-<blockquote>
- <p>The reference returned is invalid after any other operations on the object. However,
- the value of the storage referred to is retained, so that until the next call to copyfmt,
- calling iword [pword] with the same index yields another reference to the same value. </p>
-</blockquote>
-
-<p>substituting "iword" or "pword" as appropriate. </p>
-<hr>
-<a name="37"><h3>37. Leftover "global" reference</h3></a><p>
-<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>
-<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
-
-<blockquote>
- <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
- the standard exception bad_cast. </p>
-</blockquote>
-
-<p>This is not supported by the definition of use_facet<>, and represents semantics
-from an old draft. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
-expression </p>
-
-<blockquote>
- <p>(or, failing that, in the global locale) </p>
-</blockquote>
-<hr>
-<a name="38"><h3>38. Facet definition incomplete</h3></a><p>
-<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>
-<p>It has been noticed by Esa Pulkkinen that the definition of
-"facet" is incomplete. In particular, a class derived from
-another facet, but which does not define a member <i>id</i>, cannot
-safely serve as the argument <i>F</i> to use_facet<F>(loc),
-because there is no guarantee that a reference to the facet instance
-stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which
-reads: </p>
-
-<blockquote>
- <p>Get a reference to a facet of a locale. </p>
-</blockquote>
-
-<p>with: </p>
-
-<blockquote>
- <p>Requires: <tt>Facet</tt> is a facet class whose definition
- 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>
-</blockquote>
-
-<p><i>[
-Kona: strike as overspecification the text "(not inherits)"
-from the original resolution, which read "... whose definition
-contains (not inherits) the public static member
-<tt>id</tt>..."
-]</i></p>
-
-<hr>
-<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p>
-<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>
-<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
-3, the standard contains three lines of garbage text left over from a previous edit. </p>
-
-<blockquote>
- <pre>istreambuf_iterator<charT,traits> tmp = *this;
-sbuf_->sbumpc();
-return(tmp); </pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<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
-end of paragraph 3. </p>
-<hr>
-<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p>
-<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>
-<p>Paragraph 3 of the locale examples is a description of part of an
-implementation technique that has lost its referent, and doesn't mean
-anything. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Delete 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
-initialization/identification system depends...", or (at the
-editor's option) replace it with a place-holder to keep the paragraph
-numbering the same. </p>
-<hr>
-<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p>
-<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>
-<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,
-which may throw an exception". However, ios_base offers no
-interface to set or to test badbit; those interfaces are defined in
-basic_ios<>. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the description in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
-paragraph 2, and also in paragraph 4, as follows. Replace</p>
-
-<blockquote>
- <p>If the function fails it sets badbit, which may throw an exception.</p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>If the function fails, and <tt>*this</tt> is a base sub-object of
- a <tt>basic_ios<></tt> object or sub-object, the effect is
- equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt>
- on the derived object (which may throw <tt>failure</tt>).</p>
-</blockquote>
-
-<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
-setstate(badbit).]</i></p>
-
-<hr>
-<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p>
-<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>
-<p>The basic_string<> copy constructor: </p>
-
-<pre>basic_string(const basic_string& str, size_type pos = 0,
- size_type n = npos, const Allocator& a = Allocator()); </pre>
-
-<p>specifies an Allocator argument default value that is
-counter-intuitive. The natural choice for a the allocator to copy from
-is str.get_allocator(). Though this cannot be expressed in
-default-argument notation, overloading suffices. </p>
-
-<p>Alternatively, the other containers in Clause 23 (deque, list,
-vector) do not have this form of constructor, so it is inconsistent,
-and an evident source of confusion, for basic_string<> to have
-it, so it might better be removed. </p>
-<p><b>Proposed resolution:</b></p>
-<p> In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
-constructor as follows: </p>
-
-<blockquote>
- <pre>basic_string(const basic_string& str);
-basic_string(const basic_string& str, size_type pos, size_type n = npos,
- const Allocator& a = Allocator());</pre>
-</blockquote>
-
-<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
-as above. Add to paragraph 5, Effects:</p>
-
-<blockquote>
- <p>In the first form, the Allocator value used is copied from
- <tt>str.get_allocator()</tt>.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG believes the constructor is actually broken, rather than
-just an unfortunate design choice.</p>
-
-<p>The LWG considered two other possible resolutions:</p>
-
-<p>A. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
-constructor as follows:</p>
-
-<blockquote>
- <pre>basic_string(const basic_string& str, size_type pos = 0,
- size_type n = npos);
-basic_string(const basic_string& str, size_type pos,
- size_type n, const Allocator& a); </pre>
-</blockquote>
-
-<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
-as above. Add to paragraph 5, Effects: </p>
-
-<blockquote>
- <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
- value <tt>str.get_allocator()</tt>. </p>
-</blockquote>
-
-<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
-the declaration of the copy constructor as follows: </p>
-
-<blockquote>
- <pre>basic_string(const basic_string& str, size_type pos = 0,
- size_type n = npos); </pre>
-</blockquote>
-
-<p>The proposed resolution reflects the original intent of the LWG. It
-was also noted by Pete Becker that this fix "will cause
-a small amount of existing code to now work correctly."</p>
-
-<p><i>[
-Kona: issue editing snafu fixed - the proposed resolution now correctly
-reflects the LWG consensus.
-]</i></p>
-<hr>
-<a name="46"><h3>46. Minor Annex D errors</h3></a><p>
-<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>
-<p>See lib-6522 and edit-814.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
-basic_streambuf<char>) from:</p>
-
-<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
-
-<p>to:</p>
-
-<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
-
-<p>In D.7.4 <a href="future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
-int_type:</p>
-
-<pre> namespace std {
- class strstream
- : public basic_iostream<char> {
- public:
- // Types
- typedef char char_type;
- typedef typename char_traits<char>::int_type int_type
- typedef typename char_traits<char>::pos_type pos_type;</pre>
-<hr>
-<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p>
-<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>
-<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
-section has two RETURNS clauses, and they make no sense as
-stated. They make perfect sense, though, if you swap them. Am I
-correct in thinking that paragraphs 2 and 4 just got mixed up by
-accident?</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-<hr>
-<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p>
-<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>
-<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
-base class, exception, with exception(msg). Class exception (see
-18.6.1) has no such constructor.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
-
-<blockquote>
- <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
-</blockquote>
-<hr>
-<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p>
-<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>
-<p>Two problems</p>
-
-<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
-returns. Does it return f, or does it return the previous
-synchronization state? My guess is the latter, but the standard
-doesn't say so.</p>
-
-<p>(2) 27.4.2.4 doesn't say what it means for streams to be
-synchronized with stdio. Again, of course, I can make some
-guesses. (And I'm unhappy about the performance implications of those
-guesses, but that's another matter.)</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the following sentence in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
-returns clause from:</p>
-
-<blockquote>
- <p>
-<tt>true</tt> if the standard iostream objects (27.3) are
- synchronized and otherwise returns <tt>false</tt>.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>
-<tt>true</tt> if the previous state of the standard iostream
- objects (27.3) was synchronized and otherwise returns
- <tt>false</tt>.</p>
-</blockquote>
-
-<p>Add the following immediately after 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
-paragraph 2:</p>
-
-<blockquote>
-<p>When a standard iostream object str is <i>synchronized</i> with a
-standard stdio stream f, the effect of inserting a character c by</p>
-<pre>
- fputc(f, c);
-</pre>
-
-<p>is the same as the effect of</p>
-<pre>
- str.rdbuf()->sputc(c);
-</pre>
-
-<p>for any sequence of characters; the effect of extracting a
-character c by</p>
-<pre>
- c = fgetc(f);
-</pre>
-
-<p>is the same as the effect of:</p>
-<pre>
- c = str.rdbuf()->sbumpc(c);
-</pre>
-
-<p>for any sequences of characters; and the effect of pushing
-back a character c by</p>
-<pre>
- ungetc(c, f);
-</pre>
-
-<p>is the same as the effect of</p>
-<pre>
- str.rdbuf()->sputbackc(c);
-</pre>
-
-<p>for any sequence of characters. [<i>Footnote</i>: This implies
-that operations on a standard iostream object can be mixed arbitrarily
-with operations on the corresponding stdio stream. In practical
-terms, synchronization usually means that a standard iostream object
-and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
-</blockquote>
-
-<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
-of "synchronization"]</i></p>
-
-<p><i>[post-Copenhagen: proposed resolution was revised slightly:
-text was added in the non-normative footnote to say that operations
-on the two streams can be mixed arbitrarily.]</i></p>
-<hr>
-<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p>
-<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>
-<p>As written, ios_base has a copy constructor and an assignment
-operator. (Nothing in the standard says it doesn't have one, and all
-classes have copy constructors and assignment operators unless you
-take specific steps to avoid them.) However, nothing in 27.4.2 says
-what the copy constructor and assignment operator do. </p>
-
-<p>My guess is that this was an oversight, that ios_base is, like
-basic_ios, not supposed to have a copy constructor or an assignment
-operator.</p>
-
-<p>
-Jerry Schwarz comments: Yes, its an oversight, but in the opposite
-sense to what you're suggesting. At one point there was a definite
-intention that you could copy ios_base. It's an easy way to save the
-entire state of a stream for future use. As you note, to carry out
-that intention would have required a explicit description of the
-semantics (e.g. what happens to the iarray and parray stuff).
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
-constructor and operator= members as being private.</p>
-<p><b>Rationale:</b></p>
-<p>The LWG believes the difficulty of specifying correct semantics
-outweighs any benefit of allowing ios_base objects to be copyable.</p>
-<hr>
-<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p>
-<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>
-<p>The std::sort algorithm can in general only sort a given sequence
-by moving around values. The list<>::sort() member on the other
-hand could move around values or just update internal pointers. Either
-method can leave iterators into the list<> dereferencable, but
-they would point to different things. </p>
-
-<p>Does the FDIS mandate anywhere which method should be used for
-list<>::sort()?</p>
-
-<p>Matt Austern comments:</p>
-
-<p>I think you've found an omission in the standard. </p>
-
-<p>The library working group discussed this point, and there was
-supposed to be a general requirement saying that list, set, map,
-multiset, and multimap may not invalidate iterators, or change the
-values that iterators point to, except when an operation does it
-explicitly. So, for example, insert() doesn't invalidate any iterators
-and erase() and remove() only invalidate iterators pointing to the
-elements that are being erased. </p>
-
-<p>I looked for that general requirement in the FDIS, and, while I
-found a limited form of it for the sorted associative containers, I
-didn't find it for list. It looks like it just got omitted. </p>
-
-<p>The intention, though, is that list<>::sort does not
-invalidate any iterators and does not change the values that any
-iterator points to. There would be no reason to have the member
-function otherwise.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph at the end of 23.1:</p>
-
-<blockquote>
- <p>Unless otherwise specified (either explicitly or by defining a function in terms of
- other functions), invoking a container member function or passing a container as an
- argument to a library function shall not invalidate iterators to, or change the values of,
- objects within that container. </p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>This was US issue CD2-23-011; it was accepted in London but the
-change was not made due to an editing oversight. The wording in the
-proposed resolution below is somewhat updated from CD2-23-011,
-particularly the addition of the phrase "or change the values
-of"</p>
-<hr>
-<a name="52"><h3>52. Small I/O problems</h3></a><p>
-<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>
-<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:
-it should be titled "basic_ios<>() effects", not
-"ios_base() effects". </p>
-
-<p>[The second item is a duplicate; see issue <a href="lwg-closed.html#6">6</a> for
-resolution.]</p>
-
-<p>Second, 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
-different things wrong with it, some of which I've already discussed
-with Jerry, but the most obvious mechanical sort of error is that it
-uses expressions like P(i) and p(i), without ever defining what sort
-of thing "i" is.
-</p>
-
-<p>(The other problem is that it requires support for streampos
-arithmetic. This is impossible on some systems, i.e. ones where file
-position is a complicated structure rather than just a number. Jerry
-tells me that the intention was to require syntactic support for
-streampos arithmetic, but that it wasn't actually supposed to do
-anything meaningful except on platforms, like Unix, where genuine
-arithmetic is possible.) </p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
-"ios_base() effects" to "basic_ios<>()
-effects". </p>
-<hr>
-<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p>
-<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>
-<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
-The important question is whether basic_ios::~basic_ios() destroys
-rdbuf().</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add after 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
-
-<blockquote>
- <p><tt>virtual ~basic_ios();</tt></p>
- <p>
-<b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG reviewed the additional question of whether or not
-<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
-clearly 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
-by the LWG, which removed from the original proposed resolution a
-footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
-<tt>badbit</tt>".</p>
-<hr>
-<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p>
-<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>
-<p>The class synopsis for basic_streambuf shows a (virtual)
-destructor, but the standard doesn't say what that destructor does. My
-assumption is that it does nothing, but the standard should say so
-explicitly. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Add after 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
-
-<blockquote>
- <p><tt>virtual ~basic_streambuf();</tt></p>
- <p>
-<b>Effects</b>: None.</p>
-</blockquote>
-<hr>
-<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p>
-<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>
-<p>Several member functions in clause 27 are defined in certain
-circumstances to return an "invalid stream position", a term
-that is defined nowhere in the standard. Two places (27.5.2.4.2,
-paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
-a definition in _lib.iostreams.definitions_, a nonexistent
-section. </p>
-
-<p>I suspect that the invalid stream position is just supposed to be
-pos_type(-1). Probably best to say explicitly in (for example)
-27.5.2.4.2 that the return value is pos_type(-1), rather than to use
-the term "invalid stream position", define that term
-somewhere, and then put in a cross-reference. </p>
-
-<p>The phrase "invalid stream position" appears ten times in
-the C++ Standard. In seven places it refers to a return value, and it
-should be changed. In three places it refers to an argument, and it
-should not be changed. Here are the three places where "invalid
-stream position" should not be changed:</p>
-
-<blockquote>
- <p>27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
- 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
- D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
- </p>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<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
-object of class pos_type that stores an invalid stream position
-(_lib.iostreams.definitions_)" to "Returns
-<tt>pos_type(off_type(-1))</tt>".
-</p>
-
-<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
-an object of class pos_type that stores an invalid stream
-position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
-
-<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>". </p>
-
-<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
-invalid stream position (27.4.3)" to "returns
-<tt>pos_type(off_type(-1))</tt>" </p>
-
-<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
-returns an invalid stream position (_lib.iostreams.definitions_)"
-to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
-</p>
-
-<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>" </p>
-
-<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>"</p>
-<hr>
-<a name="56"><h3>56. Showmanyc's return type</h3></a><p>
-<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>
-<p>The class summary for basic_streambuf<>, in 27.5.2, says that
-showmanyc has return type int. However, 27.5.2.4.3 says that its
-return type is streamsize. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>showmanyc</tt>'s return type in the
-27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
-<hr>
-<a name="57"><h3>57. Mistake in char_traits</h3></a><p>
-<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>
-<p>21.1.3.2, paragraph 3, says "The types streampos and
-wstreampos may be different if the implementation supports no shift
-encoding in narrow-oriented iostreams but supports one or more shift
-encodings in wide-oriented streams". </p>
-
-<p>That's wrong: the two are the same type. The <iosfwd> summary
-in 27.2 says that streampos and wstreampos are, respectively, synonyms
-for fpos<char_traits<char>::state_type> and
-fpos<char_traits<wchar_t>::state_type>, and, flipping back
-to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
-char_traits<char>::state_type and
-char_traits<wchar_t>::state_type must both be mbstate_t. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-begins "The types streampos and wstreampos may be
-different..." . </p>
-<hr>
-<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p>
-<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>
-<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
-next pointer for the input sequence by n." </p>
-
-<p>The straightforward interpretation is that it is just gptr() +=
-n. An alternative interpretation, though, is that it behaves as if it
-calls sbumpc n times. (The issue, of course, is whether it might ever
-call underflow.) There is a similar ambiguity in the case of
-pbump. </p>
-
-<p>(The "classic" AT&T implementation used the
-former interpretation.)</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<blockquote>
- <p>Effects: Advances the next pointer for the input sequence by n.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
-</blockquote>
-
-<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
-effects.</p>
-<hr>
-<a name="60"><h3>60. What is a formatted input function?</h3></a><p>
-<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>
-<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
-formatted input functions. Some of the functions defined in section
-27.6.1.2 explicitly say that those requirements apply ("Behaves
-like a formatted input member (as described in 27.6.1.2.1)"), but
-others don't. The question: is 27.6.1.2.1 supposed to apply to
-everything in 27.6.1.2, or only to those member functions that
-explicitly say "behaves like a formatted input member"? Or
-to put it differently: are we to assume that everything that appears
-in a section called "Formatted input functions" really is a
-formatted input function? I assume that 27.6.1.2.1 is intended to
-apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
-is not intended to apply to extractors like </p>
-
-<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre>
-
-<p>and </p>
-
-<pre> basic_istream& operator>>(basic_streammbuf*);</pre>
-
-<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
-output. </p>
-
-<p>Comments from Judy Ward: It seems like the problem is that the
-basic_istream and basic_ostream operator <<()'s that are used
-for the manipulators and streambuf* are in the wrong section and
-should have their own separate section or be modified to make it clear
-that the "Common requirements" listed in section 27.6.1.2.1
-(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
-apply to them. </p>
-
-<p>Additional comments from Dietmar Kühl: It appears to be somewhat
-nonsensical 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
-function" but since these functions are defined in a section
-labeled "Formatted input functions" it is unclear to me
-whether these operators are considered formatted input functions which
-have 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
-just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
-set (... but setting <tt>noskipws</tt> using the manipulator syntax
-would also skip whitespace :-)</p> <p>It is not clear which functions
-are to be considered unformatted input functions. As written, it seems
-that all functions in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
-functions. However, it does not really make much sense to construct a
-sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
-unclear what happens to the <tt>gcount()</tt> if
-eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
-<tt>sync()</tt> is called: These functions don't extract characters,
-some of them even "unextract" a character. Should this still
-be reflected in <tt>gcount()</tt>? Of course, it could be read as if
-after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
-(the last unformatted input function, <tt>gcount()</tt>, didn't
-extract any character) and after a call to <tt>putback()</tt>
-<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
-function <tt>putback()</tt> did "extract" back into the
-stream). Correspondingly for <tt>unget()</tt>. Is this what is
-intended? If so, this should be clarified. Otherwise, a corresponding
-clarification should be used.</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
-Change the beginning of the second sentence from "The conversion
-occurs" to "These extractors behave as formatted input functions (as
-described in 27.6.1.2.1). After a sentry object is constructed,
-the conversion occurs"
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
-Add an effects clause. "Effects: None. This extractor does
-not behave as a formatted input function (as described in
-27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
-effects clause to "Effects: Calls pf(*this). This extractor does not
-behave as a formatted input function (as described in 27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
-effects clause to "Effects: Calls pf(*this). This extractor does not
-behave as a formatted input function (as described in 27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
-first two sentences from "If sb is null, calls setstate(failbit),
-which may throw ios_base::failure (27.4.4.3). Extracts characters
-from *this..." to "Behaves as a formatted input function (as described
-in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
-throw ios_base::failure (27.4.4.3). After a sentry object is
-constructed, extracts characters from *this...".
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
-effects clause. "Effects: none. This member function does not behave
-as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
-beginning of the first sentence of the effects clause from "Extracts a
-character" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
-character"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
-beginning of the first sentence of the effects clause from "Extracts a
-character" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
-character"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 10, because it refers to paragraph 7.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 15.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 23.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
-Effects clause: "Effects: Behaves as an unformatted input function (as
-described in 27.6.1.3, paragraph 1). After constructing a sentry
-object, reads but does not extract the current input character."
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
-first sentence of the Effects clause from "If !good() calls" to
-Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
-first sentence of the Effects clause from "If !good() calls" to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
-first sentence of the Effects clause from "If !good() calls..." to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good()
-calls..." Add a new sentence to the end of the Effects clause:
-"[Note: this function extracts no characters, so the value returned
-by the next call to gcount() is 0.]"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
-first sentence of the Effects clause from "If !good() calls" to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls".
-Add a new sentence to the end of the Effects clause: "[Note: this
-function extracts no characters, so the value returned by the next
-call to gcount() is 0.]"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
-first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if rdbuf() is"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
-Effects clause: "Effects: Behaves as an unformatted input function (as
-described in 27.6.1.3, paragraph 1), except that it does not count the
-number of characters extracted and does not affect the value returned
-by subsequent calls to gcount()." Change the first sentence of
-paragraph 37 from "if fail()" to "after constructing a sentry object,
-if fail()".
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
-first sentence of the Effects clause from "If fail()" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if fail()
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
-first sentence of the Effects clause from "If fail()" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if fail()
-</p>
-
-<p>
-In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
-the beginning of the third sentence from "The formatting conversion"
-to "These extractors behave as formatted output functions (as
-described in 27.6.2.5.1). After the sentry object is constructed, the
-conversion occurs".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
-effects clause: "Effects: None. Does not behave as a formatted output
-function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
-effects clause to "Effects: calls pf(*this). This extractor does not
-behave as a formatted output function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
-effects clause to "Effects: calls pf(*this). This extractor does not
-behave as a formatted output function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
-sentence from "If sb" to "Behaves as a formatted output function (as
-described in 27.6.2.5.1). After the sentry object is constructed, if
-sb".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
-sentence from "Inserts the character" to "Behaves as an unformatted
-output function (as described in 27.6.2.6, paragraph 1). After
-constructing a sentry object, inserts the character".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
-sentence from "Obtains characters" to "Behaves as an unformatted
-output function (as described in 27.6.2.6, paragraph 1). After
-constructing a sentry object, obtains characters".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
-sentence at the end of the paragraph: "Does not behave as an
-unformatted output function (as described in 27.6.2.6, paragraph 1)."
-</p>
-<p><b>Rationale:</b></p>
-<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
-by Judy Ward and Matt Austern. This proposed resolution is section
-VI of that paper.</p>
-<hr>
-<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p>
-<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>
-<p>The introduction to the section on unformatted input (27.6.1.3)
-says that every unformatted input function catches all exceptions that
-were thrown during input, sets badbit, and then conditionally rethrows
-the exception. That seems clear enough. Several of the specific
-functions, however, such as get() and read(), are documented in some
-circumstances as setting eofbit and/or failbit. (The standard notes,
-correctly, that setting eofbit or failbit can sometimes result in an
-exception being thrown.) The question: if one of these functions
-throws an exception triggered by setting failbit, is this an exception
-"thrown during input" and hence covered by 27.6.1.3, or does
-27.6.1.3 only refer to a limited class of exceptions? Just to make
-this concrete, suppose you have the following snippet. </p>
-
-<pre>
- char buffer[N];
- istream is;
- ...
- is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
- is.read(buffer, N);</pre>
-
-<p>Now suppose we reach EOF before we've read N characters. What
-iostate bits can we expect to be set, and what exception (if any) will
-be thrown? </p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.1.3, paragraph 1, after the sentence that begins
-"If an exception is thrown...", add the following
-parenthetical comment: "(Exceptions thrown from
-<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)"
-</p>
-<p><b>Rationale:</b></p>
-<p>The LWG looked to two alternative wordings, and choose the proposed
-resolution as better standardese.</p>
-<hr>
-<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p>
-<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>
-<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
-"calls rdbuf()->pubsync() and, if that function returns -1
-... returns traits::eof()." </p>
-
-<p>That looks suspicious, because traits::eof() is of type
-traits::int_type while the return type of sync() is int. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
-<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
-</p>
-<hr>
-<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p>
-<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>
-<p>Clause 27 details an exception-handling policy for formatted input,
-unformatted input, and formatted output. It says nothing for
-unformatted output (27.6.2.6). 27.6.2.6 should either include the same
-kind of exception-handling policy as in the other three places, or
-else it should have a footnote saying that the omission is
-deliberate. </p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.2.6, paragraph 1, replace the last sentence ("In any
-case, the unformatted output function ends by destroying the sentry
-object, then returning the value specified for the formatted output
-function.") with the following text:
-</p>
-<blockquote>
-If an exception is thrown during output, then <tt>ios::badbit</tt> is
-turned on [Footnote: without causing an <tt>ios::failure</tt> to be
-thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &
-badbit) != 0</tt> then the exception is rethrown. In any case, the
-unformatted output function ends by destroying the sentry object,
-then, if no exception was thrown, returning the value specified for
-the formatted output function.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>
-This exception-handling policy is consistent with that of formatted
-input, unformatted input, and formatted output.
-</p>
-<hr>
-<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt>
-</h3></a><p>
-<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>
-<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
-different ways, depending on whether the second sentence is read as an
-elaboration of the first. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
-"If the function inserts no characters ..." with:</p>
-
-<blockquote>
- <p>If the function inserts no characters, it calls
- <tt>setstate(failbit)</tt>, which may throw
- <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
- because it caught an exception thrown while extracting characters
- from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
- (27.4.4.3), then the caught exception is rethrown. </p>
-</blockquote>
-<hr>
-<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p>
-<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>
-<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
-"Performs an operation that is defined separately for each class
-derived from strstreambuf". This is obviously an incorrect
-cut-and-paste from basic_streambuf. There are no classes derived from
-strstreambuf. </p>
-<p><b>Proposed resolution:</b></p>
-<p>D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
-clause which currently says "Performs an operation that is
-defined separately for each class derived from strstreambuf"
-with:</p>
-
-<blockquote>
- <p>
-<b>Effects</b>: implementation defined, except that
- <tt>setbuf(0,0)</tt> has no effect.</p>
-</blockquote>
-<hr>
-<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p>
-<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>
-<p>Extractors for char* (27.6.1.2.3) do not store a null character
-after the extracted character sequence whereas the unformatted
-functions like get() do. Why is this?</p>
-
-<p>Comment from Jerry Schwarz: There is apparently an editing
-glitch. You'll notice that the last item of the list of what stops
-extraction doesn't make any sense. It was supposed to be the line that
-said a null is stored.</p>
-<p><b>Proposed resolution:</b></p>
-<p>27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
-item from:</p>
-
-<blockquote>
- A null byte (<tt>charT()</tt>) in the next position, which may be
- the first position if no characters were extracted.
-</blockquote>
-
-<p>to become a new paragraph which reads:</p>
-
-<blockquote>
- Operator>> then stores a null byte (<tt>charT()</tt>) in the
- next position, which may be the first position if no characters were
- extracted.
-</blockquote>
-<hr>
-<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p>
-<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>
-<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
-
-<p>(Please note that this is entirely separate from the question of
-whether a vector iterator is required to be a pointer; the answer to
-that question is clearly "no," as it would rule out
-debugging implementations)</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>,
-paragraph 1. </p>
-
-<blockquote>
- <p>The elements of a vector are stored contiguously, meaning that if
- v is a <tt>vector<T, Allocator></tt> where T is some type
- other than <tt>bool</tt>, then it obeys the identity <tt>&v[n]
- == &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG feels that as a practical matter the answer is clearly
-"yes". There was considerable discussion as to the best way
-to express the concept of "contiguous", which is not
-directly defined in the standard. Discussion included:</p>
-
-<ul>
- <li>An operational definition similar to the above proposed resolution is
- already used for valarray (26.3.2.3 <a href="lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
- <li>There is no need to explicitly consider a user-defined operator&
- because elements must be copyconstructible (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
- and copyconstructible (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
- requirements for operator&.</li>
- <li>There is no issue of one-past-the-end because of language rules.</li>
-</ul>
-<hr>
-<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p>
-<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>
-<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
-
-<p>uncaught_exception() doesn't have a throw specification.</p>
-
-<p>It is intentional ? Does it means that one should be prepared to
-handle exceptions thrown from uncaught_exception() ?</p>
-
-<p>uncaught_exception() is called in exception handling contexts where
-exception safety is very important.</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-<hr>
-<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p>
-<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>
-<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
-is 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,
-consistent with do_get_weekday and with its specified use by member
-get_monthname. However, in the synopsis, it is specified instead with
-four arguments. The missing argument is the "end" iterator
-value.</p>
-<p><b>Proposed resolution:</b></p>
-<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
-the declaration of member do_monthname as follows:</p>
-
-<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
- ios_base::iostate& err, tm* t) const;</pre>
-<hr>
-<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt>
-</h3></a><p>
-<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>
-<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
-clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
-parentheses and a spurious <b>n</b>.</p>
-<p><b>Proposed resolution:</b></p>
-<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
-following:</p>
-
-<blockquote>
- <b>Returns</b>: The maximum value that
- <tt>do_length(state, from, from_end, 1)</tt> can return for any
- valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
- <tt>state</tt>. The specialization <tt>codecvt<char, char,
- mbstate_t>::do_max_length()</tt> returns 1.
-</blockquote>
-<hr>
-<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p>
-<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
-Austern <b>Date:</b> 18 Sep 1998</p>
-<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
-and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
-parameter of the member functions <tt>length</tt> and
-<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member
-function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
-paragraph 9) say that the type is <tt>stateT&</tt>. Either the
-synopsis or the summary must be changed. </p>
-
-<p>If (as I believe) the member function descriptions are correct,
-then we must also add text saying how <tt>do_length</tt> changes its
-<tt>stateT</tt> argument. </p>
-<p><b>Proposed resolution:</b></p>
-<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>,
-change the <tt>stateT</tt> argument type on both member
-<tt>length()</tt> and member <tt>do_length()</tt> from </p>
-
-<blockquote>
- <p><tt>const stateT&</tt></p>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
- <p><tt>stateT&</tt></p>
-</blockquote>
-
-<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
-<tt>do_length</tt> a paragraph:</p>
-
-<blockquote>
- <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
- it called <tt>do_in(state, from, from_end, from, to, to+max,
- to)</tt> for <tt>to</tt> pointing to a buffer of at least
- <tt>max</tt> elements.</p>
-</blockquote>
-<hr>
-<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p>
-<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>
-<p>This issue concerns the requirements on classes derived from
-<tt>codecvt</tt>, including user-defined classes. What are the
-restrictions on the conversion from external characters
-(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
-Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
-the I/O library make? </p>
-
-<p>The question is whether it's possible to convert from internal
-characters to external characters one internal character at a time,
-and whether, given a valid sequence of external characters, it's
-possible to pick off internal characters one at a time. Or, to put it
-differently: given a sequence of external characters and the
-corresponding sequence of internal characters, does a position in the
-internal sequence correspond to some position in the external
-sequence? </p>
-
-<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
-sequence of <i>M</i> external characters and that <tt>[ifirst,
-ilast)</tt> is the corresponding sequence of <i>N</i> internal
-characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>,
-applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
-ilast)</tt>. Now the question: does there necessarily exist a
-subsequence of external characters, <tt>[first, last_1)</tt>, such
-that the corresponding sequence of internal characters is the single
-character <tt>*ifirst</tt>?
-</p>
-
-<p>(What a "no" answer would mean is that
-<tt>my_encoding</tt> translates sequences only as blocks. There's a
-sequence of <i>M</i> external characters that maps to a sequence of
-<i>N</i> internal characters, but that external sequence has no
-subsequence that maps to <i>N-1</i> internal characters.) </p>
-
-<p>Some of the wording in the standard, such as the description of
-<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>,
-paragraph 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
-possible to pick off internal characters one at a time from a sequence
-of external characters. However, this is never explicitly stated one
-way or the other. </p>
-
-<p>This issue seems (and is) quite technical, but it is important if
-we expect users to provide their own encoding facets. This is an area
-where the standard library calls user-supplied code, so a well-defined
-set of requirements for the user-supplied code is crucial. Users must
-be aware of the assumptions that the library makes. This issue affects
-positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
-and several of <tt>codecvt</tt>'s member functions. </p>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<blockquote>
-<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
-(27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
-<pre>
- do_out(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
-<pre>
- do_out(state, from, from + 1, from_next, to, to_end, to_next)
-</pre>
-must also return <tt>ok</tt>, and that if
-<pre>
- do_in(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
-<pre>
- do_in(state, from, from_end, from_next, to, to + 1, to_next)
-</pre>
-<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this
-means that <tt>basic_filebuf</tt> assumes that the mapping from
-internal to external characters is 1 to N: a <tt>codecvt</tt> that is
-used by <tt>basic_filebuf</tt> must be able to translate characters
-one internal character at a time. <i>--End Footnote</i>]</p>
-</blockquote>
-
-<p><i>[Redmond: Minor change in proposed resolution. Original
-proposed resolution talked about "success", with a parenthetical
-comment that success meant returning <tt>ok</tt>. New wording
-removes all talk about "success", and just talks about the
-return value.]</i></p>
-
-<p><b>Rationale:</b></p>
-
- <p>The proposed resoluion says that conversions can be performed one
- internal character at a time. This rules out some encodings that
- would otherwise be legal. The alternative answer would mean there
- would be some internal positions that do not correspond to any
- external file position.</p>
- <p>
- An example of an encoding that this rules out is one where the
- <tt>internT</tt> and <tt>externT</tt> are of the same type, and
- where the internal sequence <tt>c1 c2</tt> corresponds to the
- external sequence <tt>c2 c1</tt>.
- </p>
- <p>It was generally agreed that <tt>basic_filebuf</tt> relies
- on this property: it was designed under the assumption that
- the external-to-internal mapping is N-to-1, and it is not clear
- that <tt>basic_filebuf</tt> is implementable without that
- restriction.
- </p>
- <p>
- The proposed resolution is expressed as a restriction on
- <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
- than a blanket restriction on all <tt>codecvt</tt> facets,
- because <tt>basic_filebuf</tt> is the only other part of the
- library that uses <tt>codecvt</tt>. If a user wants to define
- a <tt>codecvt</tt> facet that implements a more general N-to-M
- mapping, there is no reason to prohibit it, so long as the user
- does not expect <tt>basic_filebuf</tt> to be able to use it.
- </p>
-<hr>
-<a name="78"><h3>78. Typo: event_call_back</h3></a><p>
-<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>
-<p>typo: event_call_back should be event_callback </p>
-<p><b>Proposed resolution:</b></p>
-<p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
-"event_call_back" to "event_callback". </p>
-<hr>
-<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p>
-<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>
-<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
-<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
-
-<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>
-<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
-
-<p>Thus whether the second parameter is optional is not clear. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
-<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
-
-<p>to:</p>
-<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
-<hr>
-<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p>
-<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>
-<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
-class complex. This redundancy should be removed.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Reduce redundancy according to the general style of the standard. </p>
-<hr>
-<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p>
-<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>
-<p>Many string member functions throw if size is getting or exceeding
-npos. However, I wonder why they don't throw if size is getting or
-exceeding max_size() instead of npos. May be npos is known at compile
-time, while max_size() is known at runtime. However, what happens if
-size exceeds max_size() but not npos, then? It seems the standard
-lacks some clarifications here.</p>
-<p><b>Proposed resolution:</b></p>
-<p>After 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
-described in this clause...") add a new paragraph:</p>
-
-<blockquote>
- <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
- <tt> max_size()</tt> then
- the operation throws <tt>length_error</tt>.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG believes length_error is the correct exception to throw.</p>
-<hr>
-<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p>
-<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>
-<p>The constructor from a range:</p>
-
-<pre>template<class InputIterator>
- basic_string(InputIterator begin, InputIterator end,
- const Allocator& a = Allocator());</pre>
-
-<p>lacks a throws clause. However, I would expect that it throws
-according to the other constructors if the numbers of characters in
-the range equals npos (or exceeds max_size(), see above). </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
-constructors which say "Throws: length_error if n ==
-npos."</p>
-<p><b>Rationale:</b></p>
-<p>Throws clauses for length_error if n == npos are no longer needed
-because they are subsumed by the general wording added by the
-resolution for issue <a href="lwg-defects.html#83">83</a>.</p>
-<hr>
-<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p>
-<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>
-<p>The effect of operator >> for strings contain the following item:</p>
-
-<p> <tt>isspace(c,getloc())</tt> is true for the next available input
-character c.</p>
-
-<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
-
-<blockquote>
- <p>
-<tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p>
-<tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
-</blockquote>
-<hr>
-<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p>
-<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>
-<p>Set::iterator is described as implementation-defined with a
-reference to the container requirement; the container requirement says
-that const_iterator is an iterator pointing to const T and iterator an
-iterator pointing to T.</p>
-
-<p>23.1.2 paragraph 2 implies that the keys should not be modified to
-break the ordering of elements. But that is not clearly
-specified. Especially considering that the current standard requires
-that iterator for associative containers be different from
-const_iterator. Set, for example, has the following: </p>
-
-<p><tt>typedef implementation defined iterator;<br>
- // See _lib.container.requirements_</tt></p>
-
-<p>23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
-to T (table 65). Disallowing user modification of keys by changing the
-standard to require an iterator for associative container to be the
-same as const_iterator would be overkill since that will unnecessarily
-significantly restrict the usage of associative container. A class to
-be used as elements of set, for example, can no longer be modified
-easily without either redesigning the class (using mutable on fields
-that have nothing to do with ordering), or using const_cast, which
-defeats requiring iterator to be const_iterator. The proposed solution
-goes in line with trusting user knows what he is doing. </p>
-
-<p>
-<b>Other Options Evaluated:</b> </p>
-
-<p>Option A. In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
-first sentence, and before "In addition,...", add one line:
-</p>
-
-<blockquote>
- <p>Modification of keys shall not change their strict weak ordering. </p>
-</blockquote>
-
-<p>Option B. Add three new sentences to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
-
-<blockquote>
- <p>At the end of paragraph 5: "Keys in an associative container
- are immutable." At the end of paragraph 6: "For
- associative containers where the value type is the same as the key
- type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
- constant iterators. It is unspecified whether or not
- <tt>iterator</tt> and <tt>const_iterator</tt> are the same
- type."</p>
-</blockquote>
-
-<p>Option C. To 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
-currently reads:</p>
-
-<blockquote>
- <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
- comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
- container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
- == false && comp(k2, k1) == false.</p>
-</blockquote>
-
-<p> add the following:</p>
-
-<blockquote>
- <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
- value whenever it is evaluated. [Note: If k2 is removed from the container and later
- reinserted, comp(k1, k2) must still return a consistent value but this value may be
- different than it was the first time k1 and k2 were in the same container. This is
- intended to allow usage like a string key that contains a filename, where comp compares
- file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
- reinserted, comp(k1, k2) must again return a consistent value but this value may be
- different than it was the previous time k2 was in the container.]</p>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
-the indicated location:</p>
-
-<blockquote>
- <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
- calling comp(k1, k2) shall always return the same
- value."</p>
- <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
- <p>At the end of paragraph 6: "For associative containers where the value type is the
- same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
- iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
- are the same type."</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Several arguments were advanced for and against allowing set elements to be
-mutable as long as the ordering was not effected. The argument which swayed the
-LWG was one of safety; if elements were mutable, there would be no compile-time
-way to detect of a simple user oversight which caused ordering to be
-modified. There was a report that this had actually happened in practice,
-and had been painful to diagnose. If users need to modify elements,
-it is possible to use mutable members or const_cast.</p>
-
-<p>Simply requiring that keys be immutable is not sufficient, because the comparison
-object may indirectly (via pointers) operate on values outside of the keys.</p>
-
-<p>
-The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
-to be different types to allow for potential future work in which some
-member functions might be overloaded between the two types. No such
-member functions exist now, and the LWG believes that user functionality
-will not be impaired by permitting the two types to be the same. A
-function that operates on both iterator types can be defined for
-<tt>const_iterator</tt> alone, and can rely on the automatic
-conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
-</p>
-
-<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
-<hr>
-<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p>
-<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>
-<p>This is the only place in the whole standard where the implementation has to document
-something private.</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the comment which says "// remainder implementation defined" from:
-</p>
-
-<ul>
- <li>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
-</li>
- <li>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
-</li>
- <li>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
-</li>
- <li>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
-</li>
-</ul>
-<hr>
-<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p>
-<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>
-<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
-exception::what() is left unspecified. This issue has implications
-with exception safety of exception handling: some exceptions should
-not throw bad_alloc.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add to 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
-clause) the sentence:</p>
-
-<blockquote>
- <p>The return value remains valid until the exception object from which it is obtained is
- destroyed or a non-const member function of the exception object is called.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>If an exception object has non-const members, they may be used
-to set internal state that should affect the contents of the string
-returned by <tt>what()</tt>.
-</p>
-<hr>
-<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p>
-<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>
-
-<p>There are no versions of binders that apply to non-const elements
-of a sequence. This makes examples like for_each() using bind2nd() on
-page 521 of "The C++ Programming Language (3rd)"
-non-conforming. Suitable versions of the binders need to be added.</p>
-
-<p>Further discussion from Nico:</p>
-
-<p>What is probably meant here is shown in the following example:</p>
-
-<pre>class Elem {
- public:
- void print (int i) const { }
- void modify (int i) { }
-}; </pre>
-<pre>int main()
-{
- vector<Elem> coll(2);
- for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK
- for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR
-}</pre>
-
-<p>The error results from the fact that bind2nd() passes its first
-argument (the argument of the sequence) as constant reference. See the
-following typical implementation:</p>
-
-<blockquote>
- <pre>template <class Operation>
-class binder2nd
- : public unary_function<typename Operation::first_argument_type,
- typename Operation::result_type> {
-protected:
- Operation op;
- typename Operation::second_argument_type value;
-public:
- binder2nd(const Operation& o,
- const typename Operation::second_argument_type& v)
- : op(o), value(v) {} </pre>
- <pre> typename Operation::result_type
- operator()(const typename Operation::first_argument_type& x) const {
- return op(x, value);
- }
-};</pre>
-</blockquote>
-
-<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
-
-<blockquote>
- <pre>template <class Operation>
-class binder2nd
- : public unary_function<typename Operation::first_argument_type,
- typename Operation::result_type> {
-protected:
- Operation op;
- typename Operation::second_argument_type value;
-public:
- binder2nd(const Operation& o,
- const typename Operation::second_argument_type& v)
- : op(o), value(v) {} </pre>
- <pre> typename Operation::result_type
- operator()(const typename Operation::first_argument_type& x) const {
- return op(x, value);
- }
- typename Operation::result_type
- operator()(typename Operation::first_argument_type& x) const {
- return op(x, value);
- }
-};</pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-
-<p>
-<b>Howard believes there is a flaw</b> in this resolution.
-See c++std-lib-9127. We may need to reopen this issue.</p>
-
-<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>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- operator()(const typename Operation::second_argument_type& x) const;</tt></p>
-</blockquote>
-<p>insert:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- operator()(typename Operation::second_argument_type& x) const;</tt></p>
-</blockquote>
-<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>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- operator()(const typename Operation::first_argument_type& x) const;</tt></p>
-</blockquote>
-<p>insert:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- operator()(typename Operation::first_argument_type& x) const;</tt></p>
-</blockquote>
-
-<p><i>[Kona: The LWG discussed this at some length.It was agreed that
-this is a mistake in the design, but there was no consensus on whether
-it was a defect in the Standard. Straw vote: NAD - 5. Accept
-proposed resolution - 3. Leave open - 6.]</i></p>
-
-<p><i>[Copenhagen: It was generally agreed that this was a defect.
-Strap poll: NAD - 0. Accept proposed resolution - 10.
-Leave open - 1.]</i></p>
-
-<hr>
-<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p>
-<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>
-<p>Member istreambuf_iterator<>::equal is not declared
-"const", yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
-which is const, calls it. This is contradictory. </p>
-<p><b>Proposed resolution:</b></p>
-<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>,
-replace:</p>
-
-<blockquote>
- <pre>bool equal(istreambuf_iterator& b);</pre>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <pre>bool equal(const istreambuf_iterator& b) const;</pre>
-</blockquote>
-<hr>
-<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
-<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>
-<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
-constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
-reads "<i>s</i> is not null". However, <i>s</i> is a
-reference, and references can't be null. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
-
-<p>Move the current paragraph 1, which reads "Requires: s is not
-null.", from the first constructor to the second constructor.</p>
-
-<p>Insert a new paragraph 1 Requires clause for the first constructor
-reading:</p>
-
-<blockquote>
- <p>
-<b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
-</blockquote>
-<hr>
-<a name="114"><h3>114. Placement forms example in error twice</h3></a><p>
-<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>
-<p>Section 18.4.1.3 contains the following example: </p>
-
-<pre>[Example: This can be useful for constructing an object at a known address:
- char place[sizeof(Something)];
- Something* p = new (place) Something();
- -end example]</pre>
-
-<p>First code line: "place" need not have any special alignment, and the
-following constructor could fail due to misaligned data.</p>
-
-<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG
-believes the () are correct.]</p>
-
-<p>Examples are not normative, but nevertheless should not show code that is invalid or
-likely to fail.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the <u> first line of code</u> in the example in
-18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
-</p>
-
-<blockquote>
- <pre>void* place = operator new(sizeof(Something));</pre>
-</blockquote>
-<hr>
-<a name="115"><h3>115. Typo in strstream constructors</h3></a><p>
-<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>
-<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
-
-<blockquote>
- <p>Effects: Constructs an object of class strstream, initializing the base class with
- iostream(& sb) and initializing sb with one of the two constructors: </p>
- <p>- If mode&app==0, then s shall designate the first element of an array of n
- elements. The constructor is strstreambuf(s, n, s). </p>
- <p>- If mode&app==0, then s shall designate the first element of an array of n
- elements that contains an NTBS whose first element is designated by s. The constructor is
- strstreambuf(s, n, s+std::strlen(s)).</p>
-</blockquote>
-
-<p>Notice the second condition is the same as the first. I think the second condition
-should be "If mode&app==app", or "mode&app!=0", meaning that
-the append bit is set.</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
-and the second condition to <tt>(mode&app)!=0</tt>.</p>
-<hr>
-<a name="117"><h3>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p>
-<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>
-<p>The <b>effects</b> clause for numeric inserters says that
-insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
-<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
-int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
-<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
-delegated to <tt>num_put</tt>, and that insertion is performed as if
-through the following code fragment: </p>
-
-<pre>bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(), val). failed();</pre>
-
-<p>This doesn't work, because <tt>num_put<></tt>::put is only
-overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
-long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
-void*</tt>. That is, the code fragment in the standard is incorrect
-(it is diagnosed as ambiguous at compile time) for the types
-<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
-int</tt>, and <tt>float</tt>. </p>
-
-<p>We must either add new member functions to <tt>num_put</tt>, or
-else change the description in <tt>ostream</tt> so that it only calls
-functions that are actually there. I prefer the latter. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
-
-<blockquote>
-<p>
-The classes num_get<> and num_put<> handle locale­dependent numeric
-formatting and parsing. These inserter functions use the imbued
-locale value to perform numeric formatting. When val is of type bool,
-long, unsigned long, double, long double, or const void*, the
-formatting conversion occurs as if it performed the following code
-fragment:
-</p>
-
-<pre>
-bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(), val). failed();
-</pre>
-
-<p>
-When val is of type short the formatting conversion occurs as if it
-performed the following code fragment:
-</p>
-
-<pre>
-ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
-bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(),
- baseflags == ios_base::oct || baseflags == ios_base::hex
- ? static_cast<long>(static_cast<unsigned short>(val))
- : static_cast<long>(val)). failed();
-</pre>
-
-<p>
-When val is of type int the formatting conversion occurs as if it performed
-the following code fragment:
-</p>
-
-<pre>
-ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
-bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(),
- baseflags == ios_base::oct || baseflags == ios_base::hex
- ? static_cast<long>(static_cast<unsigned int>(val))
- : static_cast<long>(val)). failed();
-</pre>
-
-<p>
-When val is of type unsigned short or unsigned int the formatting conversion
-occurs as if it performed the following code fragment:
-</p>
-
-<pre>
-bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
-failed();
-</pre>
-
-<p>
-When val is of type float the formatting conversion occurs as if it
-performed the following code fragment:
-</p>
-
-<pre>
-bool failed = use_facet<
- num_put<charT,ostreambuf_iterator<charT,traits> >
- >(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
-failed();
-</pre>
-
-</blockquote>
-
-<p><i>[post-Toronto: This differs from the previous proposed
-resolution; PJP provided the new wording. The differences are in
-signed short and int output.]</i></p>
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution was to cast int and short to long,
-unsigned int and unsigned short to unsigned long, and float to double,
-thus ensuring that we don't try to use nonexistent num_put<>
-member functions. The current proposed resolution is more
-complicated, but gives more expected results for hex and octal output
-of signed short and signed int. (On a system with 16-bit short, for
-example, printing short(-1) in hex format should yield 0xffff.)</p>
-<hr>
-<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p>
-<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>
-<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
-<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
-<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
-formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
-
-<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-use_facet< numget >(loc).get(*this, 0, *this, err, val);
-setstate(err);</pre>
-
-<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,
-<tt>num_get<>::get()</tt> is only overloaded for the types
-<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
-int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
-<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
-<tt>void*</tt>. Comparing the lists from the two sections, we find
-that 27.6.1.2.2 is using a nonexistent function for types
-<tt>short</tt> and <tt>int</tt>. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-two lines (1st and 3rd) which read:</p>
-<blockquote>
- <pre>operator>>(short& val);
-...
-operator>>(int& val);</pre>
-</blockquote>
-
-<p>And add the following at the end of that section (27.6.1.2.2) :</p>
-
-<blockquote>
- <pre>operator>>(short& val);</pre>
- <p>The conversion occurs as if performed by the following code fragment (using
- the same notation as for the preceding code fragment):</p>
- <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
- iostate err = 0;
- long lval;
- use_facet< numget >(loc).get(*this, 0, *this, err, lval);
- if (err == 0
- && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
- err = ios_base::failbit;
- setstate(err);</pre>
- <pre>operator>>(int& val);</pre>
- <p>The conversion occurs as if performed by the following code fragment (using
- the same notation as for the preceding code fragment):</p>
- <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
- iostate err = 0;
- long lval;
- use_facet< numget >(loc).get(*this, 0, *this, err, lval);
- if (err == 0
- && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
- err = ios_base::failbit;
- setstate(err);</pre>
-</blockquote>
-
-<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
-<hr>
-<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
-<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>
-<p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
-
-<p>"An implementation may strengthen the exception-specification
-for a function by removing listed exceptions." </p>
-
-<p>The problem is that if an implementation is allowed to do this for
-virtual functions, then a library user cannot write a class that
-portably derives from that class. </p>
-
-<p>For example, this would not compile if ios_base::failure::~failure
-had an empty exception specification: </p>
-
-<pre>#include <ios>
-#include <string>
-
-class D : public std::ios_base::failure {
-public:
- D(const std::string&);
- ~D(); // error - exception specification must be compatible with
- // overridden virtual function ios_base::failure::~failure()
-};</pre>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<p> "may strengthen the
-exception-specification for a function"</p>
-
-<p>to:</p>
-
-<p> "may strengthen the
-exception-specification for a non-virtual function". </p>
-<hr>
-<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p>
-<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>
-<p>Section 27.5.2 describes the streambuf classes this way: </p>
-
-<blockquote>
-
-<p>The class streambuf is a specialization of the template class basic_streambuf
-specialized for the type char. </p>
-
-<p>The class wstreambuf is a specialization of the template class basic_streambuf
-specialized for the type wchar_t. </p>
-
-</blockquote>
-
-<p>This implies that these classes must be template specializations, not typedefs. </p>
-
-<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
-sentences). </p>
-<p><b>Rationale:</b></p>
-<p>The <tt>streambuf</tt> synopsis already has a declaration for the
-typedefs and that is sufficient. </p>
-<hr>
-<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p>
-<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>
-<p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
-ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
-to return a const char* not a const charT*. </p>
-<p><b>Proposed resolution:</b></p>
-<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
-<tt>do_scan_not()</tt> to return a <tt> const
-charT*</tt>. </p>
-<hr>
-<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p>
-<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>
-<p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
-declared 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
-latter appears to be correct. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Change in Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
-<tt>operator!()</tt> so that the return type is
-<tt>valarray<bool></tt>. </p>
-<hr>
-<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p>
-<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>
-<p>Typos in 22.2.1.1.2 need to be fixed.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
-
-<pre> do_widen(do_narrow(c),0) == c</pre>
-
-<p>to:</p>
-
-<pre> do_widen(do_narrow(c,0)) == c</pre>
-
-<p>and change:</p>
-
-<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
-
-<p>to:</p>
-
-<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
-<hr>
-<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p>
-<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>
-<p>There are two problems with the current <tt>auto_ptr</tt> wording
-in the standard: </p>
-
-<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
-because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to
-<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by
-Nathan Myers, with the same proposed resolution.</i>
-</p>
-
-<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
-<tt>auto_ptr_ref</tt> argument. </p>
-
-<p>I have discussed these problems with my proposal coauthor, Bill
-Gibbons, and with some compiler and library implementors, and we
-believe that these problems are not desired or desirable implications
-of the standard. </p>
-
-<p>25 Aug 1999: The proposed resolution now reflects changes suggested
-by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
-"assignment operator" to "public assignment
-operator", 2) changed effects to specify use of release(), 3)
-made the conversion to auto_ptr_ref const. </p>
-
-<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
-states that the conversion from auto_ptr to auto_ptr_ref should
-be const. This is not acceptable, because it would allow
-initialization and assignment from _any_ const auto_ptr! It also
-introduces an implementation difficulty in writing this conversion
-function -- namely, somewhere along the line, a const_cast will be
-necessary to remove that const so that release() may be called. This
-may result in undefined behavior [7.1.5.1/4]. The conversion
-operator does not have to be const, because a non-const implicit
-object parameter may be bound to an rvalue [13.3.3.1.4/3]
-[13.3.1/5]. </p>
-
- <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
-
- <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>,
- paragraph 2, make the conversion to auto_ptr_ref const:</p>
- <blockquote>
- <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
- </blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
-the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
-
-<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
-a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
-
-<blockquote>
- <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
-</blockquote>
-
-<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>
-
-<blockquote>
- <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
-
- <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
- p</tt> that <tt>r</tt> holds a reference to.<br>
- <b>Returns: </b><tt>*this</tt>.
-
-</blockquote>
-<hr>
-<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p>
-<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>
-<p>Currently, the standard does not specify how seekg() and seekp()
-indicate failure. They are not required to set failbit, and they can't
-return an error indication because they must return *this, i.e. the
-stream. Hence, it is undefined what happens if they fail. And they
-<i>can</i> fail, for instance, when a file stream is disconnected from the
-underlying file (is_open()==false) or when a wide character file
-stream must perform a state-dependent code conversion, etc. </p>
-
-<p>The stream functions seekg() and seekp() should set failbit in the
-stream state in case of failure.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add to the Effects: clause of seekg() in
-27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
-27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
-
-<blockquote>
- <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
- </p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Setting failbit is the usual error reporting mechanism for streams</p>
-<hr>
-<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p>
-<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>
-<p>The description reads:</p>
-
-<p>-1- Effects:</p>
-
-<pre> if (sz > size())
- insert(end(), sz-size(), c);
- else if (sz < size())
- erase(begin()+sz, end());
- else
- ; // do nothing</pre>
-
-<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.2.2 paragraph 1 to:</p>
-
-<p>Effects:</p>
-
-<pre> if (sz > size())
- insert(end(), sz-size(), c);
- else if (sz < size())
- {
- iterator i = begin();
- advance(i, sz);
- erase(i, end());
- }</pre>
-
-<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
-with David Abrahams. They had a discussion and believe there is
-no issue of exception safety with the proposed resolution.]</i></p>
-<hr>
-<a name="133"><h3>133. map missing get_allocator()</h3></a><p>
-<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>
-<p>The title says it all.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
-after operator= in the map declaration:</p>
-
-<pre> allocator_type get_allocator() const;</pre>
-<hr>
-<a name="134"><h3>134. vector constructors over specified</h3></a><p>
-<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>
-<p>The complexity description says: "It does at most 2N calls to the copy constructor
-of T and logN reallocations if they are just input iterators ...".</p>
-
-<p>This appears to be overly restrictive, dictating the precise memory/performance
-tradeoff for the implementor.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
-
-<p>-1- Complexity: The constructor template <class
-InputIterator> vector(InputIterator first, InputIterator last)
-makes only N calls to the copy constructor of T (where N is the
-distance between first and last) and no reallocations if iterators
-first and last are of forward, bidirectional, or random access
-categories. It makes order N calls to the copy constructor of T and
-order logN reallocations if they are just input iterators.
-</p>
-<p><b>Rationale:</b></p>
-<p>"at most 2N calls" is correct only if the growth factor
-is greater than or equal to 2.
-</p>
-<hr>
-<a name="136"><h3>136. seekp, seekg setting wrong streams?</h3></a><p>
-<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>
-<p>I may be misunderstanding the intent, but should not seekg set only
-the input stream and seekp set only the output stream? The description
-seems to say that each should set both input and output streams. If
-that's really the intent, I withdraw this proposal.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In section 27.6.1.3 change:</p>
-
-<pre>basic_istream<charT,traits>& seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
-
-<p>To:</p>
-
-<pre>basic_istream<charT,traits>& seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre>
-
-<p>In section 27.6.1.3 change:</p>
-
-<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
-
-<p>To:</p>
-
-<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre>
-
-<p>In section 27.6.2.4, paragraph 2 change:</p>
-
-<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
-
-<p>To:</p>
-
-<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre>
-
-<p>In section 27.6.2.4, paragraph 4 change:</p>
-
-<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
-
-<p>To:</p>
-
-<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre>
-
-<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
-like the opinion of more iostream experts before taking action.]</i></p>
-
-<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
-incorrect, his implementation already implements the Proposed
-Resolution.]</i></p>
-
-<p><i>[Post-Tokyo: Matt Austern comments:<br>
-Is it a problem with basic_istream and basic_ostream, or is it a problem
-with basic_stringbuf?
-We could resolve the issue either by changing basic_istream and
-basic_ostream, or by changing basic_stringbuf. I prefer the latter
-change (or maybe both changes): I don't see any reason for the standard to
-require that std::stringbuf s(std::string("foo"), std::ios_base::in);
-s.pubseekoff(0, std::ios_base::beg); must fail.<br>
-This requirement is a bit weird. There's no similar requirement
-for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or
-basic_filebuf<>::seekpos.]</i></p>
-<hr>
-<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p>
-<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>
-<p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
-
-<p>-4- In the call to use_facet<Facet>(loc), the type argument
-chooses a facet, making available all members of the named type. If
-Facet is not present in a locale (or, failing that, in the global
-locale), it throws the standard exception bad_cast. A C++ program can
-check if a locale implements a particular facet with the template
-function has_facet<Facet>(). </p>
-
-<p>This contradicts the specification given in section
-22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
-<br><br>
-template <class Facet> const Facet& use_facet(const
-locale& loc); <br>
-<br>
--1- Get a reference to a facet of a locale. <br>
--2- Returns: a reference to the corresponding facet of loc, if present. <br>
--3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br>
--4- Notes: The reference returned remains valid at least as long as any copy of loc exists
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the phrase "(or, failing that, in the global locale)"
-from section 22.1.1. </p>
-<p><b>Rationale:</b></p>
-<p>Needed for consistency with the way locales are handled elsewhere
-in the standard.</p>
-<hr>
-<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p>
-<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>
-<p>The sentence introducing the Optional sequence operation table
-(23.1.1 paragraph 12) has two problems:</p>
-
-<p>A. It says ``The operations in table 68 are provided only for the containers for which
-they take constant time.''<br>
-<br>
-That could be interpreted in two ways, one of them being ``Even though table 68 shows
-particular operations as being provided, implementations are free to omit them if they
-cannot implement them in constant time.''<br>
-<br>
-B. That paragraph says nothing about amortized constant time, and it should. </p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..."
-with:</p>
-
-<blockquote>
- <p>Table 68 lists sequence operations that are provided for some types of sequential
- containers but not others. An implementation shall provide these operations for all
- container types shown in the ``container'' column, and shall implement them so as to take
- amortized constant time.</p>
-</blockquote>
-<hr>
-<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
-<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>
-<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
-say:<br>
-<br>
-— <tt>xpos <= pos</tt> and <tt>pos < size();</tt>
-</p>
-
-<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p>
-
-<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
-proposed resolution.]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
-<br>
-— <tt>xpos <= pos</tt> and <tt>pos < size();<br>
-<br>
-</tt>to:<br>
-<tt><br>
-</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt>
-</p>
-<hr>
-<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p>
-<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>
-<p>The lexicographical_compare complexity is specified as:<br>
-<br>
- "At most min((last1 - first1), (last2 - first2))
-applications of the corresponding comparison."<br>
-<br>
-The best I can do is twice that expensive.</p>
-
-<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
-equality you have to check both < and >? Yes, IMO you are
-right! (and Matt states this complexity in his book)</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
- <blockquote>
- At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
- applications of the corresponding comparison.
- </blockquote>
-
-<p>Change the example at the end of paragraph 3 to read:</p>
- <blockquote>
- [Example:<br>
- <br>
- for ( ; first1 != last1 && first2 != last2 ;
- ++first1, ++first2) {<br>
- if (*first1 < *first2) return true;<br>
- if (*first2 < *first1) return false;<br>
- }<br>
- return first1 == last1 && first2 != last2;<br>
- <br>
- --end example]
- </blockquote>
-<hr>
-<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p>
-<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>
-<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
-to have complexity requirements which are incorrect, and which contradict the
-complexity requirements for insert(). I suspect that the text in question,
-below, was taken from vector:</p>
-<blockquote>
- <p>Complexity: If the iterators first and last are forward iterators,
- bidirectional iterators, or random access iterators the constructor makes only
- N calls to the copy constructor, and performs no reallocations, where N is
- last - first.</p>
-</blockquote>
-<p>The word "reallocations" does not really apply to deque. Further,
-all of the following appears to be spurious:</p>
-<blockquote>
- <p>It makes at most 2N calls to the copy constructor of T and log N
- reallocations if they are input iterators.1)</p>
- <p>1) The complexity is greater in the case of input iterators because each
- element must be added individually: it is impossible to determine the distance
- between first abd last before doing the copying.</p>
-</blockquote>
-<p>This makes perfect sense for vector, but not for deque. Why should deque gain
-an efficiency advantage from knowing in advance the number of elements to
-insert?</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
-footnote, with the following text (which also corrects the "abd"
-typo):</p>
-<blockquote>
- <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
-</blockquote>
-<hr>
-<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p>
-<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>
-<p>The <u> extractor</u> for complex numbers is specified as: </p>
-
-<blockquote>
-
-<p> template<class T, class charT, class traits> <br>
- basic_istream<charT, traits>& <br>
- operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br>
- <br>
-Effects: Extracts a complex number x of the form: u, (u), or (u,v),
-where u is the real part and v is the imaginary part
-(lib.istream.formatted). <br>
-Requires: The input values be convertible to T. If bad input is
-encountered, calls is.setstate(ios::failbit) (which may throw
-ios::failure (lib.iostate.flags). <br>
-Returns: is .</p>
-
-</blockquote>
-<p>Is it intended that the extractor for complex numbers does not skip
-whitespace, unlike all other extractors in the standard library do?
-Shouldn't a sentry be used? <br>
-<br>
-The <u>inserter</u> for complex numbers is specified as:</p>
-
-<blockquote>
-
-<p> template<class T, class charT, class traits> <br>
- basic_ostream<charT, traits>& <br>
- operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br>
-<br>
-Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
-<br>
- template<class T, class charT, class traits> <br>
- basic_ostream<charT, traits>& <br>
- operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br>
- { <br>
- basic_ostringstream<charT, traits> s; <br>
- s.flags(o.flags()); <br>
- s.imbue(o.getloc()); <br>
- s.precision(o.precision()); <br>
- s << '(' << x.real() << "," << x.imag() << ')'; <br>
- return o << s.str(); <br>
- }</p>
-
-</blockquote>
-
-<p>Is it intended that the inserter for complex numbers ignores the
-field width and does not do any padding? If, with the suggested
-implementation above, the field width were set in the stream then the
-opening parentheses would be adjusted, but the rest not, because the
-field width is reset to zero after each insertion.</p>
-
-<p>I think that both operations should use sentries, for sake of
-consistency with the other inserters and extractors in the
-library. Regarding the issue of padding in the inserter, I don't know
-what the intent was. </p>
-<p><b>Proposed resolution:</b></p>
-<p>After 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a
-Notes clause:</p>
-
-<blockquote>
-
-<p>Notes: This extraction is performed as a series of simpler
-extractions. Therefore, the skipping of whitespace is specified to be the
-same for each of the simpler extractions.</p>
-
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>For extractors, the note is added to make it clear that skipping whitespace
-follows an "all-or-none" rule.</p>
-
-<p>For inserters, the LWG believes there is no defect; the standard is correct
-as written.</p>
-<hr>
-<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p>
-<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>
-<p>The library had many global functions until 17.4.1.1 [lib.contents]
-paragraph 2 was added: </p>
-
-<blockquote>
-
-<p>All library entities except macros, operator new and operator
-delete are defined within the namespace std or namespaces nested
-within namespace std. </p>
-
-</blockquote>
-
-<p>It appears "global function" was never updated in the following: </p>
-
-<blockquote>
-
-<p>17.4.4.3 - Global functions [lib.global.functions]<br>
-<br>
--1- It is unspecified whether any global functions in the C++ Standard
-Library are defined as inline (dcl.fct.spec).<br>
-<br>
--2- A call to a global function signature described in Clauses
-lib.language.support through lib.input.output behaves the same as if
-the implementation declares no additional global function
-signatures.*<br>
-<br>
- [Footnote: A valid C++ program always calls the expected library
- global function. An implementation may also define additional
- global functions that would otherwise not be called by a valid C++
- program. --- end footnote]<br>
-<br>
--3- A global function cannot be declared by the implementation as
-taking additional default arguments. <br>
-<br>
-17.4.4.4 - Member functions [lib.member.functions]<br>
-<br>
--2- An implementation can declare additional non-virtual member
-function signatures within a class: </p>
-
- <blockquote>
-
-<p>-- by adding arguments with default values to a member function
-signature; The same latitude does not extend to the implementation of
-virtual or global functions, however. </p>
-
- </blockquote>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p> Change "global" to "global or non-member" in:</p>
-<blockquote>
- <p>17.4.4.3 [lib.global.functions] section title,<br>
- 17.4.4.3 [lib.global.functions] para 1,<br>
- 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
- places in the footnote,<br>
- 17.4.4.3 [lib.global.functions] para 3,<br>
- 17.4.4.4 [lib.member.functions] para 2</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>
-Because operator new and delete are global, the proposed resolution
-was changed from "non-member" to "global or non-member.
-</p>
-<hr>
-<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p>
-<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>
-<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
-do_falsename() functions in the example facet BoolNames should be
-const. The functions they are overriding in
-numpunct_byname<char> are const. </p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
-two places:</p>
-<blockquote>
- <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
- string do_falsename() const { return "Mais Non!"; }</tt></p>
-</blockquote>
-<hr>
-<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p>
-<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>
-<p><b>Proposed resolution:</b></p>
-<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>
-
-<blockquote>
-<p>Returns: The first iterator i in the range [first1, last1) such
-that for some <u>integer</u> j in the range [first2, last2) ...</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>Returns: The first iterator i in the range [first1, last1) such
-that for some iterator j in the range [first2, last2) ...</p>
-</blockquote>
-<hr>
-<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p>
-<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>
-<p>For both sequences and associative containers, a.clear() has the
-semantics of erase(a.begin(),a.end()), which is undefined for an empty
-container since erase(q1,q2) requires that q1 be dereferenceable
-(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
-not dereferenceable.<br>
-<br>
-The requirement that q1 be unconditionally dereferenceable causes many
-operations to be intuitively undefined, of which clearing an empty
-container is probably the most dire.<br>
-<br>
-Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
-q2) is required to be a valid range, stating that q1 and q2 must be
-iterators or certain kinds of iterators is unnecessary.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1.1, paragraph 3, change:</p>
-<blockquote>
- <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>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
- in a</u>
-</p>
-</blockquote>
-<p>In 23.1.2, paragraph 7, change:</p>
-<blockquote>
- <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
- iterators to a, [q1, q2) is a valid range</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
- <u>into a</u>
-</p>
-</blockquote>
-<hr>
-<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p>
-<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>
-<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
-because there is no function <tt>is()</tt> which only takes a character as
-argument. Also, in the effects clause (paragraph 3), the semantic is also kept
-vague.</p>
-<p><b>Proposed resolution:</b></p>
-<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
-clause from:</p>
-<blockquote>
- <p>"... such that <tt>is(*p)</tt>
-would..."</p>
-</blockquote>
-<p>to: "... such that <tt>is(m, *p)</tt>
- would...."</p>
-<hr>
-<a name="153"><h3>153. Typo in <tt>narrow()</tt> semantics</h3></a><p>
-<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>
-<p>The description of the array version of <tt>narrow()</tt> (in
-paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
-takes only three arguments because in addition to the range a default
-character is needed.</p>
-
-<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
-two signatures followed by a <b>Returns</b> clause that only addresses
-one of them.</p>
-
-<p><b>Proposed resolution:</b></p>
-<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>
-paragraph 10 from:</p>
-<p> Returns: do_widen(low, high, to).</p>
-
-<p>to:</p>
-<p> Returns: do_widen(c) or do_widen(low, high, to),
-respectively.</p>
-
-<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>
-<pre> char narrow(char c, char /*dfault*/) const;
- const char* narrow(const char* low, const char* high,
- char /*dfault*/, char* to) const;</pre>
-<pre> Returns: do_narrow(low, high, to).</pre>
-<p>to:</p>
-<pre> char narrow(char c, char dfault) const;
- const char* narrow(const char* low, const char* high,
- char dfault, char* to) const;</pre>
-<pre> Returns: do_narrow(c, dfault) or
- do_narrow(low, high, dfault, to), respectively.</pre>
-
-<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
-defined version could be different.]</i></p>
-
-<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
-the LWG. He could find no other places the problem occurred. He
-asks for clarification of the Kona "a user defined
-version..." comment above. Perhaps it was a circuitous way of
-saying "dfault" needed to be uncommented?]</i></p>
-
-<p><i>[Post-Toronto: the issues list maintainer has merged in the
-proposed resolution from issue <a href="lwg-closed.html#207">207</a>, which addresses the
-same paragraphs.]</i></p>
-<hr>
-<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt>
-</h3></a><p>
-<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>
-<p>The table in paragraph 7 for the length modifier does not list the length
-modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
-standard asks the implementation to do undefined things when using <tt>scanf()</tt>
-(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
-is actually a problem I found quite often in production code, too).</p>
-<p><b>Proposed resolution:</b></p>
-<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
-Modifier table to say that for <tt>double</tt> a length modifier
-<tt>l</tt> is to be used.</p>
-<p><b>Rationale:</b></p>
-<p>The standard makes an embarrassing beginner's mistake.</p>
-<hr>
-<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt>
-</h3></a><p>
-<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>
-<p>There are conflicting statements about where the class
-<tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
-it 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>
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
-"<tt>basic_ios::Init"</tt> to
-"<tt>ios_base::Init"</tt>.</p>
-<p><b>Rationale:</b></p>
-<p>Although not strictly wrong, the standard was misleading enough to warrant
-the change.</p>
-<hr>
-<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p>
-<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>
-<p>There is a small discrepancy between the declarations of
-<tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
-<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
-is passed as <tt>locale const</tt> (wrong).</p>
-<p><b>Proposed resolution:</b></p>
-<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
-from "<tt>locale const" to "locale
-const&".</tt>
-</p>
-<hr>
-<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt>
-</h3></a><p>
-<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>
-<p>The default behavior of <tt>setbuf()</tt> is described only for the
-situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
-namely to do nothing. What has to be done in other situations
-is not described although there is actually only one reasonable
-approach, namely to do nothing, too.</p>
-
-<p>Since changing the buffer would almost certainly mess up most
-buffer management of derived classes unless these classes do it
-themselves, the default behavior of <tt>setbuf()</tt> should always be
-to do nothing.</p>
-<p><b>Proposed resolution:</b></p>
-<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,
-to: "Default behavior: Does nothing. Returns this."</p>
-<hr>
-<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
-</h3></a><p>
-<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>
-<p>The description of the meaning of the result of
-<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
-<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
-this function only reads the current character but does not extract
-it, <tt>uflow()</tt> would extract the current character. This should
-be fixed to use <tt>sbumpc()</tt> instead.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
-<tt>showmanyc()</tt>returns clause, by replacing the word
-"supplied" with the words "extracted from the
-stream".</p>
-<hr>
-<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
-</h3></a><p>
-<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>
-<p>The paragraph 4 refers to the function <tt>exception()</tt> which
-is not defined. Probably, the referred function is
-<tt>basic_ios<>::exceptions()</tt>.</p>
-<p><b>Proposed resolution:</b></p>
-<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,
-27.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>,
-paragraph 1, change "<tt>exception()" to
-"exceptions()"</tt>.</p>
-
-<p><i>[Note to Editor: "exceptions" with an "s"
-is the correct spelling.]</i></p>
-<hr>
-<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
-</h3></a><p>
-<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>
-<p>The note in the second paragraph pretends that the first argument
-is an object of type <tt>istream_iterator</tt>. This is wrong: It is
-an object of type <tt>istreambuf_iterator</tt>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
-<blockquote>
- <p>The first argument provides an object of the istream_iterator class...</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>The first argument provides an object of the istreambuf_iterator class...</p>
-</blockquote>
-<hr>
-<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p>
-<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>
-<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
-as taking a fill character as an argument, but the description of the
-function does not say whether the character is used at all and, if so,
-in which way. The same holds for any format control parameters that
-are accessible through the ios_base& argument, such as the
-adjustment or the field width. Is strftime() supposed to use the fill
-character in any way? In any case, the specification of
-time_put.do_put() looks inconsistent to me.<br> <br> Is the
-signature of do_put() wrong, or is the effects clause incomplete?</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-paragraph 2:</p>
-<blockquote>
- <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
- for this argument. --end Note]</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The LWG felt that while the normative text was correct,
-users need some guidance on what to pass for the <tt>fill</tt>
-argument since the standard doesn't say how it's used.</p>
-<hr>
-<a name="165"><h3>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p>
-<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>
-<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
-functions falling into one of the groups "formatted output functions"
-and "unformatted output functions" calls any stream buffer function
-which might call a virtual function other than <tt>overflow()</tt>. Basically
-this is fine but this implies that <tt>sputn()</tt> (this function would call
-the virtual function <tt>xsputn()</tt>) is never called by any of the standard
-output functions. Is this really intended? At minimum it would be convenient to
-call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
-is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
-with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt>
-and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
-under "unformatted output functions").</p>
-<p>In addition, I guess that the sentence starting with "They may use other
-public members of <tt>basic_ostream</tt> ..." probably was intended to
-start with "They may use other public members of <tt>basic_streamuf</tt>..."
-although the problem with the virtual members exists in both cases.</p>
-<p>I see two obvious resolutions:</p>
-<ol>
- <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
- called by any ostream member and that this is intended.</li>
- <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
- Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
-</ol>
-<p><b>Proposed resolution:</b></p>
-<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
-<blockquote>
- <p>They may use other public members of basic_ostream except that they do not
- invoke any virtual members of rdbuf() except overflow().</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>They may use other public members of basic_ostream except that they shall
- not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
- sync().</p>
-</blockquote>
-
-<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
-PJP why the standard is written this way.]</i></p>
-
-<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
-LWG. He comments: The rules can be made a little bit more specific if
-necessary be explicitly spelling out what virtuals are allowed to be
-called from what functions and eg to state specifically that flush()
-is allowed to call sync() while other functions are not.]</i></p>
-<hr>
-<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p>
-<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>
-<p>The first paragraph begins with a descriptions what has to be done
-in <i>formatted</i> output functions. Probably this is a typo and the
-paragraph really want to describe unformatted output functions...</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
-sentences, change the word "formatted" to
-"unformatted":</p>
-<blockquote>
- <p>"Each <b>unformatted </b> output function begins ..."<br>
- "... value specified for the <b>unformatted </b> output
- function."</p>
-</blockquote>
-<hr>
-<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
-<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>
-<p>Paragraph 8, Notes, of this section seems to mandate an extremely
-inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
-especially in view of the restriction that <tt>basic_ostream</tt>
-member 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
-is to be created.</p>
-<p>Of course, the resolution below requires some handling of
-simultaneous input and output since it is no longer possible to update
-<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
-solution is to handle this in <tt>underflow()</tt>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
-"at least" as in the following:</p>
-<blockquote>
- <p>To make a write position available, the function reallocates (or initially
- allocates) an array object with a sufficient number of elements to hold the
- current array object (if any), plus <b>at least</b> one additional write
- position.</p>
-</blockquote>
-<hr>
-<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
-</h3></a><p>
-<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>
-<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
-<tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
-<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
-in their definition of the type <tt>traits_type</tt>: For
-<tt>istringstream</tt>, this type is defined, for the other two it is
-not. This should be consistent.</p>
-<p><b>Proposed resolution:</b></p>
-<p><b>Proposed resolution:</b></p> <p>To the declarations of
-<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
-<tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
-<blockquote>
-<pre>typedef traits traits_type;</pre>
-</blockquote>
-<hr>
-<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p>
-<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>
-<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
-output position is maintained by <tt>basic_filebuf</tt>. Still, the
-description of <tt>seekpos()</tt> seems to talk about different file
-positions. In particular, it is unclear (at least to me) what is
-supposed to happen to the output buffer (if there is one) if only the
-input position is changed. The standard seems to mandate that the
-output buffer is kept and processed as if there was no positioning of
-the output position (by changing the input position). Of course, this
-can be exactly what you want if the flag <tt>ios_base::ate</tt> is
-set. However, I think, the standard should say something like
-this:</p>
-<ul>
- <li>If <tt>(which & mode) == 0</tt> neither read nor write position is
- changed and the call fails. Otherwise, the joint read and write position is
- altered to correspond to <tt>sp</tt>.</li>
- <li>If there is an output buffer, the output sequences is updated and any
- unshift sequence is written before the position is altered.</li>
- <li>If there is an input buffer, the input sequence is updated after the
- position is altered.</li>
-</ul>
-<p>Plus the appropriate error handling, that is...</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
-paragraph 14 from:</p>
-<blockquote>
- <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
- ios_base::out);</p>
- <p>Alters the file position, if possible, to correspond to the position stored
- in sp (as described below).</p>
- <p>- if (which&ios_base::in)!=0, set the file position to sp, then update
- the input sequence</p>
- <p>- if (which&ios_base::out)!=0, then update the output sequence, write
- any unshift sequence, and set the file position to sp.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
- ios_base::out);</p>
- <p>Alters the file position, if possible, to correspond to the position stored
- in sp (as described below). Altering the file position performs as follows:</p>
- <p>1. if (om & ios_base::out)!=0, then update the output sequence and
- write any unshift sequence;</p>
- <p>2. set the file position to sp;</p>
- <p>3. if (om & ios_base::in)!=0, then update the input sequence;</p>
- <p>where om is the open mode passed to the last call to open(). The operation
- fails if is_open() returns false.</p>
-</blockquote>
-
-<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
-<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
-<hr>
-<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
-</h3></a><p>
-<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>
-<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
-<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
-argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
-paragraph 23 the first argument is of type <tt>int.</tt>
-</p>
-
-<p>As far as I can see this is not really a contradiction because
-everything is consistent if <tt>streamsize</tt> is typedef to be
-<tt>int</tt>. However, this is almost certainly not what was
-intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
-as described in issue <a href="lwg-defects.html#173">173</a>.</p>
-
-<p>Darin Adler also
-submitted this issue, commenting: Either 27.6.1.1 should be modified
-to show a first parameter of type int, or 27.6.1.3 should be modified
-to show a first parameter of type streamsize and use
-numeric_limits<streamsize>::max.</p>
-<p><b>Proposed resolution:</b></p>
-<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
-of <tt>int</tt> in the description of <tt>ignore()</tt> to
-<tt>streamsize</tt>.</p>
-<hr>
-<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
-</h3></a><p>
-<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>
-
-<p>
-In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
-object of type <tt>streamsize</tt> as second argument. However, in
-27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
-<tt>int</tt>.
-</p>
-
-<p>
-As far as I can see this is not really a contradiction because
-everything is consistent if <tt>streamsize</tt> is typedef to be
-<tt>int</tt>. However, this is almost certainly not what was
-intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
-as described in issue <a href="lwg-defects.html#172">172</a>.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
-<tt>int</tt> in the description of <tt>setbuf()</tt> to
-<tt>streamsize</tt>.</p>
-<hr>
-<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
-</h3></a><p>
-<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>
-<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
-type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
-paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
-OFF_T streampos;</tt>" to "<tt>typedef POS_T
-streampos;</tt>"</p>
-<hr>
-<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
-<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>
-<p>According to paragraph 8 of this section, the methods
-<tt>basic_streambuf::pubseekpos()</tt>,
-<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
-"may" be overloaded by a version of this function taking the
-type <tt>ios_base::open_mode</tt> as last argument argument instead of
-<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
-in this section to be an alias for one of the integral types). The
-clause specifies, that the last argument has a default argument in
-three cases. However, this generates an ambiguity with the overloaded
-version because now the arguments are absolutely identical if the last
-argument is not specified.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
-<tt>basic_streambuf::pubseekpos()</tt>,
-<tt>basic_ifstream::open()</tt>, and
-<tt>basic_ofstream::open().</tt>
-</p>
-<hr>
-<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
-<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>
-<p>The "overload" for the function <tt>exceptions()</tt> in
-paragraph 8 gives the impression that there is another function of
-this function defined in class <tt>ios_base</tt>. However, this is not
-the case. Thus, it is hard to tell how the semantics (paragraph 9) can
-be implemented: "Call the corresponding member function specified
-in clause 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
-<p><b>Proposed resolution:</b></p>
-<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
-function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
-<hr>
-<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p>
-<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>
-<p>The claim has surfaced in Usenet that expressions such as<br>
-<br>
- <tt>make_pair("abc", 3)</tt><br>
-<br>
-are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
-parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br>
-<br>
-I doubt anyone intended that behavior...
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 20.2 <a href="lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
-declaration of make_pair():</p>
-<blockquote>
- <pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
-</blockquote>
-<p> In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
-<blockquote>
-<pre>template <class T1, class T2>
-pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<pre>template <class T1, class T2>
-pair<T1, T2> make_pair(T1 x, T2 y);</pre>
-</blockquote>
-<p>and add the following footnote to the effects clause:</p>
-<blockquote>
- <p> According to 12.8 [class.copy], an implementation is permitted
- to not perform a copy of an argument, thus avoiding unnecessary
- copies.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Two potential fixes were suggested by Matt Austern and Dietmar
-Kühl, respectively, 1) overloading with array arguments, and 2) use of
-a reference_traits class with a specialization for arrays. Andy
-Koenig suggested changing to pass by value. In discussion, it appeared
-that this was a much smaller change to the standard that the other two
-suggestions, and any efficiency concerns were more than offset by the
-advantages of the solution. Two implementors reported that the
-proposed resolution passed their test suites.</p>
-<hr>
-<a name="182"><h3>182. Ambiguous references to size_t</h3></a><p>
-<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>
-<p>Many references to <tt> size_t</tt> throughout the document
-omit the <tt> std::</tt> namespace qualification.</p> <p>For
-example, 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
-<blockquote>
-<pre>— operator new(size_t)
-— operator new(size_t, const std::nothrow_t&)
-— operator new[](size_t)
-— operator new[](size_t, const std::nothrow_t&)</pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p> In 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
-<blockquote>
-<p><tt> - operator new(size_t)<br>
- - operator new(size_t, const std::nothrow_t&)<br>
- - operator new[](size_t)<br>
- - operator new[](size_t, const std::nothrow_t&)</tt></p>
-</blockquote>
-<p> by:</p>
-<blockquote>
-<pre>- operator new(std::size_t)
-- operator new(std::size_t, const std::nothrow_t&)
-- operator new[](std::size_t)
-- operator new[](std::size_t, const std::nothrow_t&)</pre>
-</blockquote>
-<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
-<blockquote>
- <p>The typedef members pointer, const_pointer, size_type, and difference_type
- are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
-</blockquote>
-<p> by:</p>
-<blockquote>
- <p>The typedef members pointer, const_pointer, size_type, and difference_type
- are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
- respectively.</p>
-</blockquote>
-<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
-<blockquote>
- <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
- <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
- is unspecified when or how often this function is called. The use of hint is
- unspecified, but intended as an aid to locality if an implementation so
- desires.</p>
-</blockquote>
-<p>by:</p>
-<blockquote>
- <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
- <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
- it is unspecified when or how often this function is called. The use of hint
- is unspecified, but intended as an aid to locality if an implementation so
- desires.</p>
-</blockquote>
-<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
-<blockquote>
- <p>In Table 37, X denotes a Traits class defining types and functions for the
- character container type CharT; c and d denote values of type CharT; p and q
- denote values of type const CharT*; s denotes a value of type CharT*; n, i and
- j denote values of type size_t; e and f denote values of type X::int_type; pos
- denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
-</blockquote>
-<p>by:</p>
-<blockquote>
- <p>In Table 37, X denotes a Traits class defining types and functions for the
- character container type CharT; c and d denote values of type CharT; p and q
- denote values of type const CharT*; s denotes a value of type CharT*; n, i and
- j denote values of type std::size_t; e and f denote values of type X::int_type;
- pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
-</blockquote>
-<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
-X::length(p): "size_t" by "std::size_t".</p>
-<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
- typedef ptrdiff_t difference_type;<br>
- by:<br>
- typedef std::ptrdiff_t difference_type;</p>
-<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of template <class charT> class ctype.<br>
-<br>
- In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
-<br>
- template<class Iterator> struct iterator_traits<br>
- template<class T> struct iterator_traits<T*><br>
- template<class T> struct iterator_traits<const T*></p>
-<p><b>Rationale:</b></p>
-<p>The LWG believes correcting names like <tt>size_t</tt> and
-<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
-to be essentially editorial. There there can't be another size_t or
-ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
-
-<blockquote>
-For each type T from the Standard C library, the types ::T and std::T
-are reserved to the implementation and, when defined, ::T shall be
-identical to std::T.
-</blockquote>
-
-<p>The issue is treated as a Defect Report to make explicit the Project
-Editor's authority to make this change.</p>
-
-<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
-request of the LWG.]</i></p>
-
-<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
-address use of the name <tt>size_t</tt> in contexts outside of
-namespace std, such as in the description of <tt>::operator new</tt>.
-The proposed changes should be reviewed to make sure they are
-correct.]</i></p>
-
-<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
-them to be correct.]</i></p>
-
-<hr>
-<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p>
-<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>
-<p>27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
-exposition):</p>
-<blockquote>
-<p>Returns: An object s of unspecified type such that if [1] out is an (instance
-of) basic_ostream then the expression out<<s behaves as if f(s) were
-called, and if [2] in is an (instance of) basic_istream then the expression
-in>>s behaves as if f(s) were called. Where f can be defined as: ios_base&
-f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags
-str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
-out<<s has type ostream& and value out. [4] The expression in>>s
-has type istream& and value in.</p>
-</blockquote>
-<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
-"The expression out << s has type basic_ostream& ..." and
-[4] should read: "The expression in >> s has type basic_istream&
-..."</p>
-<p>If the wording in the standard is correct, I can see no way of implementing
-any of the manipulators so that they will work with wide character streams.</p>
-<p>e.g. wcout << setbase( 16 );</p>
-<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which
-doesn't).</p>
-<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
-8. In addition, Para 6 [setfill] has a similar error, but relates only to
-ostreams.</p>
-<p>I'd be happier if there was a better way of saying this, to make it clear
-that the value of the expression is "the same specialization of
-basic_ostream as out"&</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace section 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
-following:</p>
-<blockquote>
-<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
-function.<br>
-<br>
-<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
-<br>
--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
-as 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, mask) were called. The function f can be defined as:*<br>
-<br>
-[Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the
-basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears
-ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout <<
-noshowbase). --- end footnote]<br>
-<br>
- <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
- {<br>
- // reset specified flags<br>
- str.setf(ios_base::fmtflags(0), mask);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type basic_ostream<charT,traits>& and value out.
-The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
-<br>
- <tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
-<br>
--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
-as 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,
-mask) were called. The function f can be defined as:<br>
-<br>
- <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
- {<br>
- // set specified flags<br>
- str.setf(mask);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type basic_ostream<charT,traits>& and value out.
-The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
-<br>
-<tt>smanip setbase(int base);</tt><br>
-<br>
--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
-as 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,
-base) were called. The function f can be defined as:<br>
-<br>
- <tt>ios_base& f(ios_base& str, int base)<br>
- {<br>
- // set basefield<br>
- str.setf(base == 8 ? ios_base::oct :<br>
- base == 10 ? ios_base::dec :<br>
- base == 16 ? ios_base::hex :<br>
- ios_base::fmtflags(0), ios_base::basefield);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type basic_ostream<charT,traits>& and value out.
-The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
-<br>
-<tt>smanip setfill(char_type c);<br>
-</tt><br>
--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
-expression out<<s behaves as if f(s, c) were called. The function f can be
-defined as:<br>
-<br>
- <tt>template<class charT, class traits><br>
- basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br>
- {<br>
- // set fill character<br>
- str.fill(c);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type basic_ostream<charT,traits>& and value out.<br>
-<br>
-<tt>smanip setprecision(int n);</tt><br>
-<br>
--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
-as 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)
-were called. The function f can be defined as:<br>
-<br>
- <tt>ios_base& f(ios_base& str, int n)<br>
- {<br>
- // set precision<br>
- str.precision(n);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type basic_ostream<charT,traits>& and value out.
-The expression in>>s has type basic_istream<charT,traits>& and value in<br>
-.<br>
-<tt>smanip setw(int n);<br>
-</tt><br>
--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
-as 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)
-were called. The function f can be defined as:<br>
-<br>
- <tt>ios_base& f(ios_base& str, int n)<br>
- {<br>
- // set width<br>
- str.width(n);<br>
- return str;<br>
- }<br>
-</tt><br>
-The expression out<<s has type
-basic_ostream<charT,traits>& and value out. The expression
-in>>s has type basic_istream<charT,traits>& and value
-in.
-</p>
-</blockquote>
-
-<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
-the proposed resolution.]</i></p>
-
-<p><i>[Tokyo - The LWG noted that issue <a href="lwg-closed.html#216">216</a> involves
-the same paragraphs.]</i></p>
-
-<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
-resolution 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
-intertwined that dealing with them separately appear fraught with
-error. The full text was supplied by Bill Plauger; it was cross
-checked against changes supplied by Andy Sawyer. It should be further
-checked by the LWG.]</i></p>
-<hr>
-<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p>
-<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>
-<p>bools are defined by the standard to be of integer types, as per
-3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types"
-seems to have a special meaning for the author of 18.2. The net effect
-is an unclear and confusing specification for
-numeric_limits<bool> as evidenced below.</p>
-
-<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer
-types, the number of non-sign bits in the representation.</p>
-
-<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
-arithmetical value converts to true.</p>
-
-<p>I don't think it makes sense at all to require
-numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to
-be meaningful.</p>
-
-<p>The standard defines what constitutes a signed (resp. unsigned) integer
-types. It doesn't categorize bool as being signed or unsigned. And the set of
-values of bool type has only two elements.</p>
-
-<p>I don't think it makes sense to require numeric_limits<bool>::is_signed
-to be meaningful.</p>
-
-<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p>
-<blockquote>
- <p>For integer types, specifies the base of the representation.186)</p>
-</blockquote>
-
-<p>This disposition is at best misleading and confusing for the standard
-requires a "pure binary numeration system" for integer types as per
-3.9.1/7</p>
-
-<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
-BCD)." This also erroneous as the standard never defines any integer
-types with base representation other than 2.</p>
-
-<p>Furthermore, numeric_limits<bool>::is_modulo and
-numeric_limits<bool>::is_signed have similar problems.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Append to the end of 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
-<blockquote>
- <p>The specialization for bool shall be provided as follows:</p>
- <pre> namespace std {
- template<> class numeric_limits<bool> {
- public:
- static const bool is_specialized = true;
- static bool min() throw() { return false; }
- static bool max() throw() { return true; }
-
- static const int digits = 1;
- static const int digits10 = 0;
- static const bool is_signed = false;
- static const bool is_integer = true;
- static const bool is_exact = true;
- static const int radix = 2;
- static bool epsilon() throw() { return 0; }
- static bool round_error() throw() { return 0; }
-
- static const int min_exponent = 0;
- static const int min_exponent10 = 0;
- static const int max_exponent = 0;
- static const int max_exponent10 = 0;
-
- static const bool has_infinity = false;
- static const bool has_quiet_NaN = false;
- static const bool has_signaling_NaN = false;
- static const float_denorm_style has_denorm = denorm_absent;
- static const bool has_denorm_loss = false;
- static bool infinity() throw() { return 0; }
- static bool quiet_NaN() throw() { return 0; }
- static bool signaling_NaN() throw() { return 0; }
- static bool denorm_min() throw() { return 0; }
-
- static const bool is_iec559 = false;
- static const bool is_bounded = true;
- static const bool is_modulo = false;
-
- static const bool traps = false;
- static const bool tinyness_before = false;
- static const float_round_style round_style = round_toward_zero;
- };
- }</pre>
-</blockquote>
-
-<p><i>[Tokyo: The LWG desires wording that specifies exact values
-rather than more general wording in the original proposed
-resolution.]</i></p>
-
-<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico
-Josuttis provided the above wording.]</i></p>
-<hr>
-<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p>
-<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>
-<p>Paragraph 4 of 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
-<blockquote>
- <p> [Example: To negate every element of a: transform(a.begin(), a.end(),
- a.begin(), negate<double>()); The corresponding functions will inline
- the addition and the negation. end example]</p>
-</blockquote>
-<p>(Note: The "addition" referred to in the above is in para 3) we can
-find no other wording, except this (non-normative) example which suggests that
-any "inlining" will take place in this case.</p>
-<p>Indeed both:</p>
-<blockquote>
- <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
- unspecified whether any global functions in the C++ Standard Library
- are defined as inline (7.1.2).</p>
-</blockquote>
-<p>and</p>
-<blockquote>
- <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
- unspecified whether any member functions in the C++ Standard Library
- are defined as inline (7.1.2).</p>
-</blockquote>
-<p>take care to state that this may indeed NOT be the case.</p>
-<p>Thus the example "mandates" behavior that is explicitly
-not required elsewhere.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
-<blockquote>
-<p>They are important for the effective use of the library.</p>
-</blockquote>
-<p>Remove 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
-<blockquote>
- <p> Using function objects together with function templates
- increases the expressive power of the library as well as making the
- resulting code much more efficient.</p>
-</blockquote>
-<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
-<blockquote>
- <p>The corresponding functions will inline the addition and the
- negation.</p>
-</blockquote>
-
-<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
-<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
-<hr>
-<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p>
-<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>
-<p>In section 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
-bitset::set operation to take a second parameter of type int. The
-function tests whether this value is non-zero to determine whether to
-set the bit to true or false. The type of this second parameter should
-be bool. For one thing, the intent is to specify a Boolean value. For
-another, the result type from test() is bool. In addition, it's
-possible to slice an integer that's larger than an int. This can't
-happen with bool, since conversion to bool has the semantic of
-translating 0 to false and any non-zero value to true.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
-<blockquote>
-<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
-</blockquote>
-<p>With:</p>
-<blockquote>
- <pre>bitset<N>& set(size_t pos, bool val = true );</pre>
-</blockquote>
-<p>In 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
-<blockquote>
- <pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
-</blockquote>
-<p>With:</p>
-<blockquote>
- <pre>bitset<N>& set(size_t pos, bool val = true );</pre>
-</blockquote>
-
-<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work
-on better P/R wording.]</i></p>
-<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
-<p><b>Rationale:</b></p>
-<p>
-<tt>bool</tt> is a better choice. It is believed that binary
-compatibility is not an issue, because this member function is
-usually implemented as <tt>inline</tt>, and because it is already
-the case that users cannot rely on the type of a pointer to a
-nonvirtual member of a standard library class.</p>
-<hr>
-<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p>
-<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>
-<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
-and includes a parenthetical note saying that it is the number of
-digits after the decimal point.<br>
-<br>
-This claim is not strictly correct. For example, in the default
-floating-point output format, setprecision sets the number of
-significant digits printed, not the number of digits after the decimal
-point.<br>
-<br>
-I would like the committee to look at the definition carefully and
-correct the statement in 27.4.2.2</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove from 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
-"(number of digits after the decimal point)".</p>
-<hr>
-<a name="193"><h3>193. Heap operations description incorrect</h3></a><p>
-<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>
-<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
-is<br>
-<br>
- `"(1) *a is the largest element"<br>
-<br>
-I think this is incorrect and should be changed to the wording in the proposed
-resolution.</p>
-<p>Actually there are two independent changes:</p>
-<blockquote>
- <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
- [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
- <p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions could not be used for a
- 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>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
-<blockquote>
- <p>(1) *a is the largest element</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>(1) There is no element greater than <tt>*a</tt>
-</p>
-</blockquote>
-<hr>
-<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
-<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>
-<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
-What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
-reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
-should set failbit. Should it set eofbit as well? The standard
-doesn't seem to answer that question.</p>
-
-<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
-<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
-other hand, 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
-extraction from a <tt>streambuf</tt> "returns
-<tt>traits::eof()</tt>, then the input function, except as explicitly
-noted otherwise, completes its actions and does
-<tt>setstate(eofbit)"</tt>. So the question comes down to
-whether <tt>basic_istream<>::sentry</tt>'s constructor is an
-input function.</p>
-
-<p>Comments from Jerry Schwarz:</p>
-<blockquote>
-<p>It was always my intention that eofbit should be set any time that a
-virtual returned something to indicate eof, no matter what reason
-iostream code had for calling the virtual.</p>
-<p>
-The motivation for this is that I did not want to require streambufs
-to behave consistently if their virtuals are called after they have
-signaled eof.</p>
-<p>
-The classic case is a streambuf reading from a UNIX file. EOF isn't
-really a state for UNIX file descriptors. The convention is that a
-read on UNIX returns 0 bytes to indicate "EOF", but the file
-descriptor isn't shut down in any way and future reads do not
-necessarily also return 0 bytes. In particular, you can read from
-tty's on UNIX even after they have signaled "EOF". (It
-isn't always understood that a ^D on UNIX is not an EOF indicator, but
-an EOL indicator. By typing a "line" consisting solely of
-^D you cause a read to return 0 bytes, and by convention this is
-interpreted as end of file.)</p>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
-<blockquote>
-<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt>
-returns <tt>traits::eof()</tt>, the function calls
-<tt>setstate(failbit | eofbit)</tt> (which may throw
-<tt>ios_base::failure</tt>).
-</p>
-</blockquote>
-<hr>
-<a name="198"><h3>198. Validity of pointers and references unspecified after iterator destruction</h3></a><p>
-<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>
-<p>
-Is a pointer or reference obtained from an iterator still valid after
-destruction of the iterator?
-</p>
-<p>
-Is a pointer or reference obtained from an iterator still valid after the value
-of the iterator changes?
-</p>
-<blockquote>
-<pre>
-#include <iostream>
-#include <vector>
-#include <iterator>
-
-int main()
-{
- typedef std::vector<int> vec_t;
- vec_t v;
- v.push_back( 1 );
-
- // Is a pointer or reference obtained from an iterator still
- // valid after destruction of the iterator?
- int * p = &*v.begin();
- std::cout << *p << '\n'; // OK?
-
- // Is a pointer or reference obtained from an iterator still
- // valid after the value of the iterator changes?
- vec_t::iterator iter( v.begin() );
- p = &*iter++;
- std::cout << *p << '\n'; // OK?
-
- return 0;
-}
-</pre>
-</blockquote>
-
-<p>The standard doesn't appear to directly address these
-questions. The standard needs to be clarified. At least two real-world
-cases have been reported where library implementors wasted
-considerable effort because of the lack of clarity in the
-standard. The question is important because requiring pointers and
-references to remain valid has the effect for practical purposes of
-prohibiting iterators from pointing to cached rather than actual
-elements of containers.</p>
-
-<p>The standard itself assumes that pointers and references obtained
-from an iterator are still valid after iterator destruction or
-change. 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
-effects:</p>
-
-<blockquote>
- <pre>Iterator tmp = current;
-return *--tmp;</pre>
-</blockquote>
-<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>
-<blockquote>
- <pre>return &(operator*());</pre>
-</blockquote>
-
-<p>Because the standard itself assumes pointers and references remain
-valid after iterator destruction or change, the standard should say so
-explicitly. This will also reduce the chance of user code breaking
-unexpectedly when porting to a different standard library
-implementation.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph to 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
-<blockquote>
-Destruction of an iterator may invalidate pointers and references
-previously obtained from that iterator.
-</blockquote>
-
-<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>
-
-<blockquote>
-<p><b>Effects:</b></p>
-<pre>
- this->tmp = current;
- --this->tmp;
- return *this->tmp;
-</pre>
-
-<p>
-[<i>Note:</i> This operation must use an auxiliary member variable,
-rather than a temporary variable, to avoid returning a reference that
-persists beyond the lifetime of its associated iterator. (See
-24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.) The name of this member variable is shown for
-exposition only. <i>--end note</i>]
-</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: The issue has been reformulated purely
-in terms of iterators.]</i></p>
-
-<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
-assumption by reverse_iterator. The issue and proposed resolution was
-reformulated yet again to reflect this reality.]</i></p>
-
-<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
-assumes its underlying iterator has persistent pointers and
-references. Andy Koenig pointed out that it is possible to rewrite
-reverse_iterator so that it no longer makes such an assupmption.
-However, this issue is related to issue <a href="lwg-active.html#299">299</a>. If we
-decide it is intentional that <tt>p[n]</tt> may return by value
-instead of reference when <tt>p</tt> is a Random Access Iterator,
-other changes in reverse_iterator will be necessary.]</i></p>
-<p><b>Rationale:</b></p>
-<p>This issue has been discussed extensively. Note that it is
-<i>not</i> an issue about the behavior of predefined iterators. It is
-asking whether or not user-defined iterators are permitted to have
-transient pointers and references. Several people presented examples
-of useful user-defined iterators that have such a property; examples
-include a B-tree iterator, and an "iota iterator" that doesn't point
-to memory. Library implementors already seem to be able to cope with
-such iterators: they take pains to avoid forming references to memory
-that gets iterated past. The only place where this is a problem is
-<tt>reverse_iterator</tt>, so this issue changes
-<tt>reverse_iterator</tt> to make it work.</p>
-
-<p>This resolution does not weaken any guarantees provided by
-predefined iterators like <tt>list<int>::iterator</tt>.
-Clause 23 should be reviewed to make sure that guarantees for
-predefined iterators are as strong as users expect.</p>
-
-<hr>
-<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p>
-<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>
-<p>
-Suppose that <tt>A</tt> is a class that conforms to the
-Allocator requirements of Table 32, and <tt>a</tt> is an
-object of class <tt>A</tt> What should be the return
-value of <tt>a.allocate(0)</tt>? Three reasonable
-possibilities: forbid the argument <tt>0</tt>, return
-a null pointer, or require that the return value be a
-unique non-null pointer.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a note to the <tt>allocate</tt> row of Table 32:
-"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
-<p><b>Rationale:</b></p>
-<p>A key to understanding this issue is that the ultimate use of
-allocate() is to construct an iterator, and that iterator for zero
-length sequences must be the container's past-the-end
-representation. Since this already implies special case code, it
-would be over-specification to mandate the return value.
-</p>
-<hr>
-<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p>
-<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>
-<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
-past-the-end values are always non-singular."</p>
-<p>This places an unnecessary restriction on past-the-end iterators for
-containers with forward iterators (for example, a singly-linked list). If the
-past-the-end value on such a container was a well-known singular value, it would
-still satisfy all forward iterator requirements.</p>
-<p>Removing this restriction would allow, for example, a singly-linked list
-without a "footer" node.</p>
-<p>This would have an impact on existing code that expects past-the-end
-iterators obtained from different (generic) containers being not equal.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
-<blockquote>
-<p>Dereferenceable and past-the-end values are always non-singular.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<p>Dereferenceable values are always non-singular. </p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>For some kinds of containers, including singly linked lists and
-zero-length vectors, null pointers are perfectly reasonable past-the-end
-iterators. Null pointers are singular.
-</p>
-<hr>
-<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p>
-<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>
-<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
-declarations use a consistent style except for the following functions:</p>
-<blockquote>
- <pre>void push_back(const charT);
-basic_string& assign(const basic_string&);
-void swap(basic_string<charT,traits,Allocator>&);</pre>
-</blockquote>
-<p>- push_back, assign, swap: missing argument name <br>
-- push_back: use of const with charT (i.e. POD type passed by value
-not by reference - should be charT or const charT& )<br>
-- swap: redundant use of template parameters in argument
-basic_string<charT,traits,Allocator>&</p>
-<p><b>Proposed resolution:</b></p>
-<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
-function declarations push_back, assign, and swap to:</p>
-<blockquote>
- <pre>void push_back(charT c);
-
-basic_string& assign(const basic_string& str);
-void swap(basic_string& str);</pre>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Although the standard is in general not consistent in declaration
-style, the basic_string declarations are consistent other than the
-above. The LWG felt that this was sufficient reason to merit the
-change.
-</p>
-<hr>
-<a name="210"><h3>210. distance first and last confused</h3></a><p>
-<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>
-<p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
-<blockquote>
- <p> In the description of the algorithms operators + and - are used
- for some of the iterator categories for which they do not have to
- be defined. In these cases the semantics of [...] a-b is the same
- as of<br>
- <br>
- <tt>return distance(a, b);</tt>
-</p>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>On the last line of paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
-<tt>"a-b"</tt> to <tt>"b-a".</tt>
-</p>
-<p><b>Rationale:</b></p>
-<p>There are two ways to fix the defect; change the description to b-a
-or change the return to distance(b,a). The LWG preferred the
-former for consistency.</p>
-<hr>
-<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p>
-<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>
-<p>The description of the stream extraction operator for std::string (section
-21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
-the case that the operator fails to extract any characters from the input
-stream.</p>
-<p>This implies that the typical construction</p>
-<blockquote>
- <pre>std::istream is;
-std::string str;
-...
-while (is >> str) ... ;</pre>
-</blockquote>
-<p>(which tests failbit) is not required to terminate at EOF.</p>
-<p>Furthermore, this is inconsistent with other extraction operators,
-which 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
-requirement is present, either explicitly or implicitly, for the
-extraction operators. It is also present explicitly in the description
-of 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>
-<p><b>Proposed resolution:</b></p>
-<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>
-<blockquote>
-
-<p>If the function extracts no characters, it calls
-is.setstate(ios::failbit) which may throw ios_base::failure
-(27.4.4.3).</p>
-</blockquote>
-<hr>
-<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p>
-<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>
-<p>The standard doesn't specify what min_element() and max_element() shall
-return if the range is empty (first equals last). The usual implementations
-return last. This problem seems also apply to partition(), stable_partition(),
-next_permutation(), and prev_permutation().</p>
-<p><b>Proposed resolution:</b></p>
-<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
-9, append: Returns last if first==last.</p>
-<p><b>Rationale:</b></p>
-<p>The LWG looked in some detail at all of the above mentioned
-algorithms, but believes that except for min_element() and
-max_element() it is already clear that last is returned if first ==
-last.</p>
-<hr>
-<a name="214"><h3>214. set::find() missing const overload</h3></a><p>
-<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>
-<p>The specification for the associative container requirements in
-Table 69 state that the find member function should "return
-iterator; const_iterator for constant a". The map and multimap
-container descriptions have two overloaded versions of find, but set
-and multiset do not, all they have is:</p>
-<blockquote>
- <pre>iterator find(const key_type & x) const;</pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
-equal_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>
-<blockquote>
- <pre>iterator find(const key_type & x);
-const_iterator find(const key_type & x) const;</pre>
- <pre>iterator lower_bound(const key_type & x);
-const_iterator lower_bound(const key_type & x) const;</pre>
- <pre>iterator upper_bound(const key_type & x);
-const_iterator upper_bound(const key_type & x) const;</pre>
- <pre>pair<iterator, iterator> equal_range(const key_type & x);
-pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre>
-</blockquote>
-
-<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
-extending the proposed resolution to lower_bound, upper_bound, and
-equal_range.]</i></p>
-<hr>
-<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p>
-<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>
-<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
-<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
-must be const in order for it to be callable on a const object (a reference to
-which which is what std::use_facet<>() returns).</p>
-<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
-name of the namespace `My'.</p>
-<p>3) In the definition of `loc' and subsequently in the call to use_facet<>()
-in main(), the name of the facet is misspelled: it should read `My::JCtype'
-rather than `My::JCType'.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the "Classifying Japanese characters" example in 22.2.8,
-paragraph 11 with the following:</p>
-<pre>#include <locale></pre>
-<pre>namespace My {
- using namespace std;
- class JCtype : public locale::facet {
- public:
- static locale::id id; // required for use as a new locale facet
- bool is_kanji (wchar_t c) const;
- JCtype() {}
- protected:
- ~JCtype() {}
- };
-}</pre>
-<pre>// file: filt.C
-#include <iostream>
-#include <locale>
-#include "jctype" // above
-std::locale::id My::JCtype::id; // the static JCtype member
-declared above.</pre>
-<pre>int main()
-{
- using namespace std;
- typedef ctype<wchar_t> wctype;
- locale loc(locale(""), // the user's preferred locale...
- new My::JCtype); // and a new feature ...
- wchar_t c = use_facet<wctype>(loc).widen('!');
- if (!use_facet<My::JCtype>(loc).is_kanji(c))
- cout << "no it isn't!" << endl;
- return 0;
-}</pre>
-<hr>
-<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p>
-<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>
-<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
-paragraph 2:</p>
-<blockquote>
- <p>Effects: Destroys an object of class ios_base. Calls each registered
- callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
- time that any ios_base member function called from within fn has well defined
- results.</p>
-</blockquote>
-<p>But what is not clear is: If no callback functions were ever registered, does
-it matter whether the ios_base members were ever initialized?</p>
-<p>For instance, does this program have defined behavior:</p>
-<blockquote>
- <pre>#include <ios></pre>
- <pre>class D : public std::ios_base { };</pre>
- <pre>int main() { D d; }</pre>
-</blockquote>
-<p>It seems that registration of a callback function would surely affect the
-state of an ios_base. That is, when you register a callback function with an
-ios_base, the ios_base must record that fact somehow.</p>
-<p>But if after construction the ios_base is in an indeterminate state, and that
-state is not made determinate before the destructor is called, then how would
-the destructor know if any callbacks had indeed been registered? And if the
-number of callbacks that had been registered is indeterminate, then is not the
-behavior of the destructor undefined?</p>
-<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
-it explicit that destruction before initialization results in undefined
-behavior.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Modify 27.4.2.7 paragraph 1 from</p>
-<blockquote>
- <p>Effects: Each ios_base member has an indeterminate value after
- construction.</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>Effects: Each ios_base member has an indeterminate value after
- construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
- have taken place, the behavior is undefined.</p>
-</blockquote>
-<hr>
-<a name="221"><h3>221. num_get<>::do_get stage 2 processing broken</h3></a><p>
-<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>
-<p>Stage 2 processing of numeric conversion is broken.</p>
-
-<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
-conversion specifier is %i. A %i specifier determines a number's base
-by its prefix (0 for octal, 0x for hex), so the intention is clearly
-that a 0x prefix is allowed. Paragraph 8 in the same section,
-however, describes very precisely how characters are processed. (It
-must be done "as if" by a specified code fragment.) That
-description does not allow a 0x prefix to be recognized.</p>
-
-<p>Very roughly, stage 2 processing reads a char_type ct. It converts
-ct to a char, not by using narrow but by looking it up in a
-translation table that was created by widening the string literal
-"0123456789abcdefABCDEF+-". The character "x" is
-not found in that table, so it can't be recognized by stage 2
-processing.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
-<blockquote>
- <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
-</blockquote>
-<p>with the line:</p>
-<blockquote>
- <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>If we're using the technique of widening a string literal, the
-string literal must contain every character we wish to recognize.
-This technique has the consequence that alternate representations
-of digits will not be recognized. This design decision was made
-deliberately, with full knowledge of that limitation.</p>
-<hr>
-<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
-<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>
-<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
-<blockquote>
- <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
-
-int compare(size_type pos1, size_type n1,
- const basic_string<charT,traits,Allocator>& str ,
- size_type pos2 , size_type n2 ) const;
-
--4- Returns:
-
- basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
- basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre>
-</blockquote>
-<p>and the constructor that's implicitly called by the above is
-defined to throw an out-of-range exception if pos > str.size(). See
-section 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
-
-<p>On the other hand, the compare function descriptions themselves don't have
-"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
-that do not apply to a function are omitted.</p>
-<p>So it seems there is an inconsistency in the standard -- are the
-"Effects" clauses correct, or are the "Throws" clauses
-missing?</p>
-<p><b>Proposed resolution:</b></p>
-<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
-the sentence "Descriptions of function semantics contain the
-following elements (as appropriate):", insert the word
-"further" so that the foot note reads:</p>
-<blockquote>
- <p>To save space, items that do not apply to a function are
- omitted. For example, if a function does not specify any further
- preconditions, there will be no "Requires" paragraph.</p>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The standard is somewhat inconsistent, but a failure to note a
-throw condition in a throws clause does not grant permission not to
-throw. The inconsistent wording is in a footnote, and thus
-non-normative. The proposed resolution from the LWG clarifies the
-footnote.</p>
-<hr>
-<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p>
-<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>
-<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
- <blockquote>
- Effects: For each non-negative integer i <= (last - first)/2,
- applies swap to all pairs of iterators first + i, (last - i) - 1.
- </blockquote>
-<p>with:</p>
- <blockquote>
- Effects: For each non-negative integer i <= (last - first)/2,
- applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
- </blockquote>
-<hr>
-<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p>
-<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>
-<p>In the associative container requirements table in 23.1.2 paragraph 7,
-a.clear() has complexity "log(size()) + N". However, the meaning of N
-is not defined.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In the associative container requirements table in 23.1.2 paragraph
-7, the complexity of a.clear(), change "log(size()) + N" to
-"linear in <tt>size()</tt>".</p>
-<p><b>Rationale:</b></p>
-<p>It's the "log(size())", not the "N", that is in
-error: there's no difference between <i>O(N)</i> and <i>O(N +
-log(N))</i>. The text in the standard is probably an incorrect
-cut-and-paste from the range version of <tt>erase</tt>.</p>
-<hr>
-<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
-<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>
-<p>25.2.2 reads:</p>
-<blockquote>
- <p>
-<tt> template<class T> void swap(T& a, T& b);</tt><br>
- <br>
- Requires: Type T is Assignable (_lib.container.requirements_).<br>
- Effects: Exchanges values stored in two locations.</p>
-</blockquote>
-<p>The only reasonable** generic implementation of swap requires construction of a
- new temporary copy of one of its arguments:</p>
-<blockquote>
-<pre>template<class T> void swap(T& a, T& b);
- {
- T tmp(a);
- a = b;
- b = tmp;
- }</pre>
-</blockquote>
-<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
-<p>**Yes, there's also an unreasonable implementation which would require T to be
- DefaultConstructible instead of CopyConstructible. I don't think this is worthy
- of consideration:</p>
-<blockquote>
-<pre>template<class T> void swap(T& a, T& b);
-{
- T tmp;
- tmp = a;
- a = b;
- b = tmp;
-}</pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.2.2 paragraph 1 from:</p>
-<blockquote>
-<p> Requires: Type T is Assignable (23.1).</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
-</blockquote>
-<hr>
-<a name="228"><h3>228. Incorrect specification of "..._byname" facets</h3></a><p>
-<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>
-<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>,
-22.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
-definitions of the "..._byname" classes by listing a bunch
-of virtual functions. At the same time, no semantics of these
-functions are defined. Real implementations do not define these
-functions because the functional part of the facets is actually
-implemented in the corresponding base classes and the constructor of
-the "..._byname" version just provides suitable date used by
-these implementations. For example, the 'numpunct' methods just return
-values from a struct. The base class uses a statically initialized
-struct while the derived version reads the contents of this struct
-from a table. However, no virtual function is defined in
-'numpunct_byname'.</p>
-
-<p>For most classes this does not impose a problem but specifically
-for 'ctype' it does: The specialization for 'ctype_byname<char>'
-is required because otherwise the semantics would change due to the
-virtual functions defined in the general version for 'ctype_byname':
-In 'ctype<char>' the method 'do_is()' is not virtual but it is
-made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'.
-Thus, a class derived from 'ctype_byname<char>' can tell whether
-this class is specialized or not under the current specification:
-Without the specialization, 'do_is()' is virtual while with
-specialization it is not virtual.</p>
-<p><b>Proposed resolution:</b></p>
-<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
-<pre> namespace std {
- template <class charT>
- class ctype_byname : public ctype<charT> {
- public:
- typedef ctype<charT>::mask mask;
- explicit ctype_byname(const char*, size_t refs = 0);
- protected:
- ~ctype_byname(); // virtual
- };
- }</pre>
-<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
-<pre> namespace std {
- template <class internT, class externT, class stateT>
- class codecvt_byname : public codecvt<internT, externT, stateT> {
- public:
- explicit codecvt_byname(const char*, size_t refs = 0);
- protected:
- ~codecvt_byname(); // virtual
- };
- }
-</pre>
-<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
-<pre> namespace std {
- template <class charT>
- class numpunct_byname : public numpunct<charT> {
- // this class is specialized for char and wchar_t.
- public:
- typedef charT char_type;
- typedef basic_string<charT> string_type;
- explicit numpunct_byname(const char*, size_t refs = 0);
- protected:
- ~numpunct_byname(); // virtual
- };
- }</pre>
-<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
-<pre> namespace std {
- template <class charT>
- class collate_byname : public collate<charT> {
- public:
- typedef basic_string<charT> string_type;
- explicit collate_byname(const char*, size_t refs = 0);
- protected:
- ~collate_byname(); // virtual
- };
- }</pre>
-<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
-<pre> namespace std {
- template <class charT, class InputIterator = istreambuf_iterator<charT> >
- class time_get_byname : public time_get<charT, InputIterator> {
- public:
- typedef time_base::dateorder dateorder;
- typedef InputIterator iter_type</pre>
-<pre> explicit time_get_byname(const char*, size_t refs = 0);
- protected:
- ~time_get_byname(); // virtual
- };
- }</pre>
-<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
-<pre> namespace std {
- template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
- class time_put_byname : public time_put<charT, OutputIterator>
- {
- public:
- typedef charT char_type;
- typedef OutputIterator iter_type;</pre>
-<pre> explicit time_put_byname(const char*, size_t refs = 0);
- protected:
- ~time_put_byname(); // virtual
- };
- }"</pre>
-<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
-<pre> namespace std {
- template <class charT, bool Intl = false>
- class moneypunct_byname : public moneypunct<charT, Intl> {
- public:
- typedef money_base::pattern pattern;
- typedef basic_string<charT> string_type;</pre>
-<pre> explicit moneypunct_byname(const char*, size_t refs = 0);
- protected:
- ~moneypunct_byname(); // virtual
- };
- }</pre>
-<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
-<pre> namespace std {
- template <class charT>
- class messages_byname : public messages<charT> {
- public:
- typedef messages_base::catalog catalog;
- typedef basic_string<charT> string_type;</pre>
-<pre> explicit messages_byname(const char*, size_t refs = 0);
- protected:
- ~messages_byname(); // virtual
- };
- }</pre>
-<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
-this case only those members are defined to be virtual which are
-defined to be virtual in 'ctype<cT>'.)</p>
-
-<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
-the LWG to solve the underlying problems raised by issue <a href="lwg-closed.html#138">138</a>.]</i></p>
-
-<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
-three last virtual functions from <tt>messages_byname</tt>.]</i></p>
-
-<hr>
-<a name="230"><h3>230. Assignable specified without also specifying CopyConstructible</h3></a><p>
-<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>
-<p>Issue <a href="lwg-defects.html#227">227</a> identified an instance (std::swap) where
-Assignable was specified without also specifying
-CopyConstructible. The LWG asked that the standard be searched to
-determine if the same defect existed elsewhere.</p>
-
-<p>There are a number of places (see proposed resolution below) where
-Assignable is specified without also specifying
-CopyConstructible. There are also several cases where both are
-specified. For example, 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
-change "T is Assignable" to "T is CopyConstructible and
-Assignable"
-</p>
-
-<p>In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
-"Key is Assignable" to "Key is
-CopyConstructible and Assignable"<br>
-</p>
-
-<p>In 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
-</p>
-<blockquote>
-<p> A class or a built-in type X satisfies the requirements of an
-output iterator if X is an Assignable type (23.1) and also the
-following expressions are valid, as shown in Table 73:
-</p>
-</blockquote>
-<p>to:
-</p>
-<blockquote>
-<p> A class or a built-in type X satisfies the requirements of an
-output iterator if X is a CopyConstructible (20.1.3) and Assignable
-type (23.1) and also the following expressions are valid, as shown in
-Table 73:
-</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
-the 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
-CopyConstructible is really a requirement and may be
-overspecification.]</i></p>
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution also included changes to input
-iterator, fill, and replace. The LWG believes that those changes are
-not necessary. The LWG considered some blanket statement, where an
-Assignable type was also required to be Copy Constructible, but
-decided against this because fill and replace really don't require the
-Copy Constructible property.</p>
-<hr>
-<a name="232"><h3>232. "depends" poorly defined in 17.4.3.1</h3></a><p>
-<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>
-<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
-specializations of standard templates to those that "depend on a
-user-defined name of external linkage."</p>
-<p>This term, however, is not adequately defined, making it possible to
-construct a specialization that is, I believe, technically legal according to
-17.4.3.1/1, but that specializes a standard template for a built-in type such as
-'int'.</p>
-<p>The following code demonstrates the problem:</p>
-<blockquote>
- <pre>#include <algorithm></pre>
- <pre>template<class T> struct X
-{
- typedef T type;
-};</pre>
- <pre>namespace std
-{
- template<> void swap(::X<int>::type& i, ::X<int>::type& j);
-}</pre>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>Change "user-defined name" to "user-defined
-type".</p>
-<p><b>Rationale:</b></p>
-<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
-Programming Language</i>. It disallows the example in the issue,
-since the underlying type itself is not user-defined. The only
-possible problem I can see is for non-type templates, but there's no
-possible way for a user to come up with a specialization for bitset,
-for example, that might not have already been specialized by the
-implementor?</p>
-
-<p><i>[Toronto: this may be related to issue <a href="lwg-active.html#120">120</a>.]</i></p>
-
-<p><i>[post-Toronto: Judy provided the above proposed resolution and
-rationale.]</i></p>
-<hr>
-<a name="234"><h3>234. Typos in allocator definition</h3></a><p>
-<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>
-<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
-<tt>destruct()</tt> are described as returns but the functions actually
-return <tt>void</tt>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Substitute "Returns" by "Effect".</p>
-<hr>
-<a name="235"><h3>235. No specification of default ctor for reverse_iterator</h3></a><p>
-<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>
-<p>The declaration of <tt>reverse_iterator</tt> lists a default
-constructor. However, no specification is given what this constructor
-should do.</p>
-<p><b>Proposed resolution:</b></p>
- <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
- paragraph:</p>
- <blockquote>
- <p><tt>reverse_iterator()</tt></p>
-
- <p>Default initializes <tt>current</tt>. Iterator operations
- applied to the resulting iterator have defined behavior if and
- only if the corresponding operations are defined on a default
- constructed iterator of type <tt>Iterator</tt>.</p>
- </blockquote>
- <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
- resolution.]</i></p>
-<hr>
-<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p>
-<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>
-<p>The complexity specification in paragraph 6 says that the complexity
-is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
-defined on iterators this term is in general undefined because it
-would have to be <tt>last - first</tt>.</p>
-<p><b>Proposed resolution:</b></p>
- <p>Change paragraph 6 from</p>
- <blockquote>Linear in <i>first - last</i>.</blockquote>
- <p>to become</p>
- <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
-<hr>
-<a name="238"><h3>238. Contradictory results of stringbuf initialization.</h3></a><p>
-<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>
-<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
-'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
-that far but consider this code:</p>
-
-<pre>
- std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
- std::cout << "'" << sbuf.str() << "'\n";
-</pre>
-
-<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
-the output sequence nor the input sequence is initialized and
-paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
-returns the input or the output sequence. None of them is initialized,
-ie. both are empty, in which case the return from <tt>str()</tt> is
-defined to be <tt>basic_string<cT>()</tt>.</p>
-
-<p>However, probably only test cases in some testsuites will detect this
-"problem"...</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove 27.7.1.1 paragraph 4.</p>
-<p><b>Rationale:</b></p>
-<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
-we fixed it, it would say just the same thing as text that's already
-in the standard.</p>
-<hr>
-<a name="239"><h3>239. Complexity of unique() and/or unique_copy incorrect</h3></a><p>
-<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>
-<p>The complexity of unique and unique_copy are inconsistent with each
-other and inconsistent with the implementations. The standard
-specifies:</p>
-
-<p>for unique():</p>
-
-<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
-(last - first) - 1 applications of the corresponding predicate, otherwise
-no applications of the predicate.</blockquote>
-
-<p>for unique_copy():</p>
-
-<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
-predicate.</blockquote>
-
-<p>
-The implementations do it the other way round: unique() applies the
-predicate last-first times and unique_copy() applies it last-first-1
-times.</p>
-
-<p>As both algorithms use the predicate for pair-wise comparison of
-sequence elements I don't see a justification for unique_copy()
-applying the predicate last-first times, especially since it is not
-specified to which pair in the sequence the predicate is applied
-twice.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change both complexity sections in 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
-
-<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
-applications of the corresponding predicate.</blockquote>
-
-<hr>
-<a name="240"><h3>240. Complexity of adjacent_find() is meaningless</h3></a><p>
-<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>
-<p>The complexity section of adjacent_find is defective:</p>
-
-<blockquote>
-<pre>
-template <class ForwardIterator>
-ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
- BinaryPredicate pred);
-</pre>
-
-<p>-1- Returns: The first iterator i such that both i and i + 1 are in
-the range [first, last) for which the following corresponding
-conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
-last if no such iterator is found.</p>
-
-<p>-2- Complexity: Exactly find(first, last, value) - first applications
-of the corresponding predicate.
-</p>
-</blockquote>
-
-<p>In the Complexity section, it is not defined what "value"
-is supposed to mean. My best guess is that "value" means an
-object for which one of the conditions pred(*i,value) or
-pred(value,*i) is true, where i is the iterator defined in the Returns
-section. However, the value type of the input sequence need not be
-equality-comparable and for this reason the term find(first, last,
-value) - first is meaningless.</p>
-
-<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
-find_if(first, last, bind1st(pred,*i)) - first might come closer to
-the intended specification. Binders can only be applied to function
-objects that have the function call operator declared const, which is
-not required of predicates because they can have non-const data
-members. For this reason, a specification using a binder could only be
-an "as-if" specification.</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-<blockquote>
-For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
-(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
-corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
-return value.
-</blockquote>
-
-<p><i>[Copenhagen: the original resolution specified an upper
-bound. The LWG preferred an exact count.]</i></p>
-
-<hr>
-<a name="242"><h3>242. Side effects of function objects</h3></a><p>
-<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>
-<p>The algorithms transform(), accumulate(), inner_product(),
-partial_sum(), and adjacent_difference() require that the function
-object supplied to them shall not have any side effects.</p>
-
-<p>The standard defines a side effect in 1.9 <a href="intro.html#intro.execution"> [intro.execution]</a> as:</p>
-<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
-modifying an object, calling a library I/O function, or calling a function
-that does any of those operations are all side effects, which are changes
-in the state of the execution environment.</blockquote>
-
-<p>As a consequence, the function call operator of a function object supplied
-to any of the algorithms listed above cannot modify data members, cannot
-invoke any function that has a side effect, and cannot even create and
-modify temporary objects. It is difficult to imagine a function object
-that is still useful under these severe limitations. For instance, any
-non-trivial transformator supplied to transform() might involve creation
-and modification of temporaries, which is prohibited according to the current
-wording of the standard.</p>
-
-<p>On the other hand, popular implementations of these algorithms exhibit
-uniform and predictable behavior when invoked with a side-effect-producing
-function objects. It looks like the strong requirement is not needed for
-efficient implementation of these algorithms.</p>
-
-<p>The requirement of side-effect-free function objects could be
-replaced by a more relaxed basic requirement (which would hold for all
-function objects supplied to any algorithm in the standard library):</p>
-<blockquote>A function objects supplied to an algorithm shall not invalidate
-any iterator or sequence that is used by the algorithm. Invalidation of
-the sequence includes destruction of the sorting order if the algorithm
-relies on the sorting order (see section 25.3 - Sorting and related operations
-[lib.alg.sorting]).</blockquote>
-
-<p>I can't judge whether it is intended that the function objects supplied
-to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
-shall not modify sequence elements through dereferenced iterators.</p>
-
-<p>It is debatable whether this issue is a defect or a change request.
-Since the consequences for user-supplied function objects are drastic and
-limit the usefulness of the algorithms significantly I would consider it
-a defect.</p>
-<p><b>Proposed resolution:</b></p>
-
-<p><i>Things to notice about these changes:</i></p>
-
-<ol>
-<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
- are intentional. we want to prevent side-effects from
- invalidating the end iterators.</i>
-</li>
-
-<li> <i>That has the unintentional side-effect of prohibiting
- modification of the end element as a side-effect. This could
- conceivably be significant in some cases.</i>
-</li>
-
-<li> <i>The wording also prevents side-effects from modifying elements
- of the output sequence. I can't imagine why anyone would want
- to do this, but it is arguably a restriction that implementors
- don't need to place on users.</i>
-</li>
-
-<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
- and simple, but would require more verbiage.</i>
-</li>
-</ol>
-
-<p>Change 25.2.3/2 from:</p>
-
-<blockquote>
- -2- Requires: op and binary_op shall not have any side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -2- Requires: in the ranges [first1, last1], [first2, first2 +
- (last1 - first1)] and [result, result + (last1- first1)], op and
- binary_op shall neither modify elements nor invalidate iterators or
- subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</blockquote>
-
-
-<p>Change 25.2.3/2 from:</p>
-
-<blockquote>
- -2- Requires: op and binary_op shall not have any side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -2- Requires: op and binary_op shall not invalidate iterators or
- subranges, or modify elements in the ranges [first1, last1],
- [first2, first2 + (last1 - first1)], and [result, result + (last1
- - first1)].
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</blockquote>
-
-
-<p>Change 26.4.1/2 from:</p>
-
-<blockquote>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. binary_op shall not cause side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable
- (lib.container.requirements) types. In the range [first, last],
- binary_op shall neither modify elements nor invalidate iterators
- or subranges.
- [Footnote: The use of a fully closed range is intentional --end footnote]
-</blockquote>
-
-<p>Change 26.4.2/2 from:</p>
-
-<blockquote>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. binary_op1 and binary_op2 shall not cause side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. In the ranges [first, last] and [first2, first2 + (last -
- first)], binary_op1 and binary_op2 shall neither modify elements
- nor invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</blockquote>
-
-
-<p>Change 26.4.3/4 from:</p>
-
-<blockquote>
- -4- Requires: binary_op is expected not to have any side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -4- Requires: In the ranges [first, last] and [result, result +
- (last - first)], binary_op shall neither modify elements nor
- invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</blockquote>
-
-<p>Change 26.4.4/2 from:</p>
-
-<blockquote>
- -2- Requires: binary_op shall not have any side effects.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -2- Requires: In the ranges [first, last] and [result, result +
- (last - first)], binary_op shall neither modify elements nor
- invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</blockquote>
-
-<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
-
-<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
-added footnotes pointing out that the use of closed ranges was
-intentional.]</i></p>
-
-<hr>
-<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
-<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>
-<p>basic_istream<>::get(), and basic_istream<>::getline(),
-are unclear with respect to the behavior and side-effects of the named
-functions in case of an error.</p>
-
-<p>27.6.1.3, p1 states that "... If the sentry object returns
-true, when converted to a value of type bool, the function endeavors
-to obtain the requested input..." It is not clear from this (or
-the rest of the paragraph) what precisely the behavior should be when
-the sentry ctor exits by throwing an exception or when the sentry
-object returns false. In particular, what is the number of characters
-extracted that gcount() returns supposed to be?</p>
-
-<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
-"... In any case, it then stores a null character (using
-charT()) into the next successive location of the array." Is not
-clear whether this sentence applies if either of the conditions above
-holds (i.e., when sentry fails).</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add to 27.6.1.3, p1 after the sentence</p>
-
-<blockquote>
-"... If the sentry object returns true, when converted to a value of
-type bool, the function endeavors to obtain the requested input."
-</blockquote>
-
-<p>the following</p>
-
-
-<blockquote>
-"Otherwise, if the sentry constructor exits by throwing an exception or
-if the sentry object returns false, when converted to a value of type
-bool, the function returns without attempting to obtain any input. In
-either case the number of extracted characters is set to 0; unformatted
-input functions taking a character array of non-zero size as an argument
-shall also store a null character (using charT()) in the first location
-of the array."
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Although the general philosophy of the input functions is that the
-argument should not be modified upon failure, <tt>getline</tt>
-historically added a terminating null unconditionally. Most
-implementations still do that. Earlier versions of the draft standard
-had language that made this an unambiguous requirement; those words
-were moved to a place where their context made them less clear. See
-Jerry Schwarz's message c++std-lib-7618.</p>
-<hr>
-<a name="248"><h3>248. time_get fails to set eofbit</h3></a><p>
-<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>
-<p>There is no requirement that any of time_get member functions set
-ios::eofbit when they reach the end iterator while parsing their input.
-Since members of both the num_get and money_get facets are required to
-do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
-should follow the same requirement for consistency.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
-
-<blockquote>
-If the end iterator is reached during parsing by any of the get()
-member functions, the member sets ios_base::eofbit in err.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>Two alternative resolutions were proposed. The LWG chose this one
-because it was more consistent with the way eof is described for other
-input facets.</p>
-<hr>
-<a name="250"><h3>250. splicing invalidates iterators</h3></a><p>
-<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>
-<p>
-Section 23.2.2.4 [lib.list.ops] states that
-</p>
-<pre>
- void splice(iterator position, list<T, Allocator>& x);
-</pre>
-<p>
-<i>invalidates</i> all iterators and references to list <tt>x</tt>.
-</p>
-
-<p>
-This is unnecessary and defeats an important feature of splice. In
-fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
-after <tt>splice</tt>.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-<p>Add a footnote to 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
-<blockquote>
-[<i>Footnote:</i> As specified in 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
-4-5, the semantics described in this clause applies only to the case
-where allocators compare equal. --end footnote]
-</blockquote>
-
-<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
-<blockquote>
-Effects: Inserts the contents of x before position and x becomes
-empty. Pointers and references to the moved elements of x now refer to
-those same elements but as members of *this. Iterators referring to the
-moved elements will continue to refer to their elements, but they now
-behave as iterators into *this, not into x.
-</blockquote>
-
-<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
-<blockquote>
-Effects: Inserts an element pointed to by i from list x before
-position and removes the element from x. The result is unchanged if
-position == i or position == ++i. Pointers and references to *i continue
-to refer to this same element but as a member of *this. Iterators to *i
-(including i itself) continue to refer to the same element, but now
-behave as iterators into *this, not into x.
-</blockquote>
-
-<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
-<blockquote>
-Requires: [first, last) is a valid range in x. The result is
-undefined if position is an iterator in the range [first, last).
-Pointers and references to the moved elements of x now refer to those
-same elements but as members of *this. Iterators referring to the moved
-elements will continue to refer to their elements, but they now behave as
-iterators into *this, not into x.
-</blockquote>
-
-<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution said that iterators and references
-would remain "valid". The new proposed resolution clarifies what that
-means. Note that this only applies to the case of equal allocators.
-From 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
-allocators compare nonequal is outside the scope of the standard.</p>
-<hr>
-<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p>
-<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>
-<p>The synopsis for the template class <tt>basic_stringbuf</tt>
-doesn't list a typedef for the template parameter
-<tt>Allocator</tt>. This makes it impossible to determine the type of
-the allocator at compile time. It's also inconsistent with all other
-template classes in the library that do provide a typedef for the
-<tt>Allocator</tt> parameter.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
-basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
-basic_stringstream (27.7.4) the typedef:</p>
-<pre>
- typedef Allocator allocator_type;
-</pre>
-<hr>
-<a name="252"><h3>252. missing casts/C-style casts used in iostreams</h3></a><p>
-<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>
-<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
-const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
-The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
-D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
-the cast altogether.</p>
-
-<p>C-style casts have not been deprecated, so the first part of this
-issue is stylistic rather than a matter of correctness.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 27.7.2.2, p1 replace </p>
-<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
-
-
-<p>In 27.7.3.2, p1 replace</p>
-<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
-
-<p>In 27.7.6, p1, replace</p>
-<pre> -1- Returns: &sb</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
-
-<p>In D.7.2.2, p1 replace</p>
-<pre> -2- Returns: &sb. </pre>
-
-<p>with</p>
-<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre>
-<hr>
-<a name="256"><h3>256. typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p>
-<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>
-<p>
-27.4.4.2, p17 says
-</p>
-
-<blockquote>
--17- Before copying any parts of rhs, calls each registered callback
-pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
-exceptions() have been replaced, calls each callback pair that was
-copied from rhs as (*fn)(copy_event,*this,index).
-</blockquote>
-
-<p>
-The name copy_event isn't defined anywhere. The intended name was
-copyfmt_event.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
-<hr>
-<a name="259"><h3>259. <tt>basic_string::operator[]</tt> and const correctness</h3></a><p>
-<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>
-<p>
-<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
-</p>
-
-<p>
-The standard's description of <tt>basic_string<>::operator[]</tt>
-seems to violate const correctness.
-</p>
-
-<p>
-The standard (21.3.4/1) says that "If <tt>pos < size()</tt>,
-returns <tt>data()[pos]</tt>." The types don't work. The
-return value of <tt>data()</tt> is <tt>const charT*</tt>, but
-<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In section 21.3.4, paragraph 1, change
-"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
-<i>pos</i>)</tt>".
-</p>
-<hr>
-<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
-</h3></a><p>
-<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>
-<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
-it as returning the iterator by value. 24.5.1.2, p5 shows the same
-operator as returning the iterator by reference. That's incorrect
-given the Effects clause below (since a temporary is returned). The
-`&' is probably just a typo.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the declaration in 24.5.1.2, p5 from</p>
- <pre>
- istream_iterator<T,charT,traits,Distance>& operator++(int);
- </pre>
-<p>to</p>
- <pre>
- istream_iterator<T,charT,traits,Distance> operator++(int);
- </pre>
-<p>(that is, remove the `&').</p>
-<hr>
-<a name="261"><h3>261. Missing description of <tt>istream_iterator::operator!=</tt>
-</h3></a><p>
-<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>
-<p>
-24.5.1, p3 lists the synopsis for
-</p>
-
-<pre>
- template <class T, class charT, class traits, class Distance>
- bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
- const istream_iterator<T,charT,traits,Distance>& y);
-</pre>
-
-<p>
-but there is no description of what the operator does (i.e., no Effects
-or Returns clause) in 24.5.1.2.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add paragraph 7 to the end of section 24.5.1.2 with the following text:
-</p>
-
-<pre>
- template <class T, class charT, class traits, class Distance>
- bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
- const istream_iterator<T,charT,traits,Distance>& y);
-</pre>
-
-<p>-7- Returns: !(x == y).</p>
-<hr>
-<a name="262"><h3>262. Bitmask operator ~ specified incorrectly</h3></a><p>
-<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>
-<p>
-The ~ operation should be applied after the cast to int_type.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
-</p>
-
-<pre>
- bitmask operator~ ( bitmask X )
- { return static_cast< bitmask>(static_cast<int_type>(~ X)); }
-</pre>
-
-<p>
-to:
-</p>
-
-<pre>
- bitmask operator~ ( bitmask X )
- { return static_cast< bitmask>(~static_cast<int_type>(X)); }
-</pre>
-<hr>
-<a name="263"><h3>263. Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p>
-<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>
-<p>
-The note in paragraph 6 suggests that the invalidation rules for
-references, pointers, and iterators in paragraph 5 permit a reference-
-counted implementation (actually, according to paragraph 6, they permit
-a "reference counted implementation", but this is a minor editorial fix).
-</p>
-
-<p>
-However, the last sub-bullet is so worded as to make a reference-counted
-implementation unviable. In the following example none of the
-conditions for iterator invalidation are satisfied:
-</p>
-
-<pre>
- // first example: "*******************" should be printed twice
- string original = "some arbitrary text", copy = original;
- const string & alias = original;
-
- string::const_iterator i = alias.begin(), e = alias.end();
- for(string::iterator j = original.begin(); j != original.end(); ++j)
- *j = '*';
- while(i != e)
- cout << *i++;
- cout << endl;
- cout << original << endl;
-</pre>
-
-<p>
-Similarly, in the following example:
-</p>
-
-<pre>
- // second example: "some arbitrary text" should be printed out
- string original = "some arbitrary text", copy = original;
- const string & alias = original;
-
- string::const_iterator i = alias.begin();
- original.begin();
- while(i != alias.end())
- cout << *i++;
-</pre>
-
-<p>
-I have tested this on three string implementations, two of which were
-reference counted. The reference-counted implementations gave
-"surprising behavior" because they invalidated iterators on
-the first call to non-const begin since construction. The current
-wording does not permit such invalidation because it does not take
-into account the first call since construction, only the first call
-since various member and non-member function calls.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the following sentence in 21.3 paragraph 5 from
-</p>
-
-<blockquote>
- Subsequent to any of the above uses except the forms of insert() and
- erase() which return iterators, the first call to non-const member
- functions operator[](), at(), begin(), rbegin(), end(), or rend().
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
- Following construction or any of the above uses, except the forms of
- insert() and erase() that return iterators, the first call to non-
- const member functions operator[](), at(), begin(), rbegin(), end(),
- or rend().
-</blockquote>
-<hr>
-<a name="264"><h3>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p>
-<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>
-<p>
-Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
-Consider inserting a sorted range of even integers into a set<int> containing the odd
-integers in the same range.
-</p>
-
-<p><i>Related issue: <a href="lwg-closed.html#102">102</a></i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In Table 69, in section 23.1.2, change the complexity clause for
-insertion of a range from "N log(size() + N) (N is the distance
-from i to j) in general; linear if [i, j) is sorted according to
-value_comp()" to "N log(size() + N), where N is the distance
-from i to j".
-</p>
-
-<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
-parens in the revised wording.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>
-Testing for valid insertions could be less efficient than simply
-inserting the elements when the range is not both sorted and between
-two adjacent existing elements; this could be a QOI issue.
-</p>
-
-<p>
-The LWG considered two other options: (a) specifying that the
-complexity was linear if [i, j) is sorted according to value_comp()
-and between two adjacent existing elements; or (b) changing to
-Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
-number of elements which do not insert immediately after the previous
-element from [i, j) including the first). The LWG felt that, since
-we can't guarantee linear time complexity whenever the range to be
-inserted is sorted, it's more trouble than it's worth to say that it's
-linear in some special cases.
-</p>
-<hr>
-<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p>
-<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>
-<p>
-I don't see any requirements on the types of the elements of the
-std::pair container in 20.2.2. From the descriptions of the member
-functions it appears that they must at least satisfy the requirements of
-20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
-the case of the [in]equality operators also the requirements of 20.1.1
-[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
-</p>
-
-<p>
-I believe that the the CopyConstructible requirement is unnecessary in
-the case of 20.2.2, p2.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the Effects clause in 20.2.2, p2 from</p>
-
-<blockquote>
--2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
-first(T1()), second(T2()) {} </tt>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
--2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
-first(), second() {} </tt>
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>The existing specification of pair's constructor appears to be a
-historical artifact: there was concern that pair's members be properly
-zero-initialized when they are built-in types. At one time there was
-uncertainty about whether they would be zero-initialized if the
-default constructor was written the obvious way. This has been
-clarified by core issue 178, and there is no longer any doubt that
-the straightforward implementation is correct.</p>
-<hr>
-<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p>
-<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>
-<p>
-The synopsis for std::bad_exception lists the function ~bad_exception()
-but there is no description of what the function does (the Effects
-clause is missing).
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the destructor from the class synopses of
-<tt>bad_alloc</tt> (18.4.2.1 <a href="lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
-<tt>bad_cast</tt> (18.5.2 <a href="lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
-<tt>bad_typeid</tt> (18.5.3 <a href="lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
-and <tt>bad_exception</tt> (18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
-</p>
-<p><b>Rationale:</b></p>
-<p>
-This is a general problem with the exception classes in clause 18.
-The proposed resolution is to remove the destructors from the class
-synopses, rather than to document the destructors' behavior, because
-removing them is more consistent with how exception classes are
-described in clause 19.
-</p>
-<hr>
-<a name="268"><h3>268. Typo in locale synopsis</h3></a><p>
-<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>
-<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
-the semicolons after the declarations of the default ctor
-locale::locale() and the copy ctor locale::locale(const locale&)
-are missing.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the missing semicolons, i.e., change</p>
-
-<pre>
- // construct/copy/destroy:
- locale() throw()
- locale(const locale& other) throw()
-</pre>
-
-<p>in the synopsis in 22.1.1 to</p>
-
-<pre>
- // construct/copy/destroy:
- locale() throw();
- locale(const locale& other) throw();
-</pre>
-<hr>
-<a name="270"><h3>270. Binary search requirements overly strict</h3></a><p>
-<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>
-<p>
-Each of the four binary search algorithms (lower_bound, upper_bound,
-equal_range, binary_search) has a form that allows the user to pass a
-comparison function object. According to 25.3, paragraph 2, that
-comparison function object has to be a strict weak ordering.
-</p>
-
-<p>
-This requirement is slightly too strict. Suppose we are searching
-through a sequence containing objects of type X, where X is some
-large record with an integer key. We might reasonably want to look
-up a record by key, in which case we would want to write something
-like this:
-</p>
-<pre>
- struct key_comp {
- bool operator()(const X& x, int n) const {
- return x.key() < n;
- }
- }
-
- std::lower_bound(first, last, 47, key_comp());
-</pre>
-
-<p>
-key_comp is not a strict weak ordering, but there is no reason to
-prohibit its use in lower_bound.
-</p>
-
-<p>
-There's no difficulty in implementing lower_bound so that it allows
-the use of something like key_comp. (It will probably work unless an
-implementor takes special pains to forbid it.) What's difficult is
-formulating language in the standard to specify what kind of
-comparison function is acceptable. We need a notion that's slightly
-more general than that of a strict weak ordering, one that can encompass
-a comparison function that involves different types. Expressing that
-notion may be complicated.
-</p>
-
-<p><i>Additional questions raised at the Toronto meeting:</i></p>
-<ul>
-<li> Do we really want to specify what ordering the implementor must
- use when calling the function object? The standard gives
- specific expressions when describing these algorithms, but it also
- says that other expressions (with different argument order) are
- equivalent.</li>
-<li> If we are specifying ordering, note that the standard uses both
- orderings when describing <tt>equal_range</tt>.</li>
-<li> Are we talking about requiring these algorithms to work properly
- when passed a binary function object whose two argument types
- are not the same, or are we talking about requirements when
- they are passed a binary function object with several overloaded
- versions of <tt>operator()</tt>?</li>
-<li> The definition of a strict weak ordering does not appear to give
- any guidance on issues of overloading; it only discusses expressions,
- and all of the values in these expressions are of the same type.
- Some clarification would seem to be in order.</li>
-</ul>
-
-<p><i>Additional discussion from Copenhagen:</i></p>
-<ul>
-<li>It was generally agreed that there is a real defect here: if
-the predicate is merely required to be a Strict Weak Ordering, then
-it's possible to pass in a function object with an overloaded
-operator(), where the version that's actually called does something
-completely inappropriate. (Such as returning a random value.)</li>
-
-<li>An alternative formulation was presented in a paper distributed by
-David Abrahams at the meeting, "Binary Search with Heterogeneous
-Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
-predicate as a Strict Weak Ordering acting on a sorted sequence, view
-the predicate/value pair as something that partitions a sequence.
-This is almost equivalent to saying that we should view binary search
-as if we are given a unary predicate and a sequence, such that f(*p)
-is true for all p below a specific point and false for all p above it.
-The proposed resolution is based on that alternative formulation.</li>
-</ul>
-<p><b>Proposed resolution:</b></p>
-
-<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
-
-<blockquote>
- 3 For all algorithms that take Compare, there is a version that uses
- operator< instead. That is, comp(*i, *j) != false defaults to *i <
- *j != false. For the algorithms to work correctly, comp has to
- induce a strict weak ordering on the values.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- 3 For all algorithms that take Compare, there is a version that uses
- operator< instead. That is, comp(*i, *j) != false defaults to *i
- < *j != false. For algorithms other than those described in
- lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
- a strict weak ordering on the values.
-</blockquote>
-
-<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
-
-<blockquote>
- -6- A sequence [start, finish) is partitioned with respect to an
- expression f(e) if there exists an integer n such that
- for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
- and only if i < n.
-</blockquote>
-
-<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
-
-<blockquote>
- -1- All of the algorithms in this section are versions of binary
- search and assume that the sequence being searched is in order
- according to the implied or explicit comparison function. They work
- on non-random access iterators minimizing the number of
- comparisons, which will be logarithmic for all types of
- iterators. They are especially appropriate for random access
- iterators, because these algorithms do a logarithmic number of
- steps through the data structure. For non-random access iterators
- they execute a linear number of steps.
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -1- All of the algorithms in this section are versions of binary
- search and assume that the sequence being searched is partitioned
- with respect to an expression formed by binding the search key to
- an argument of the implied or explicit comparison function. They
- work on non-random access iterators minimizing the number of
- comparisons, which will be logarithmic for all types of
- iterators. They are especially appropriate for random access
- iterators, because these algorithms do a logarithmic number of
- steps through the data structure. For non-random access iterators
- they execute a linear number of steps.
-</blockquote>
-
-<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
-
-<blockquote>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expression e < value or comp(e, value)
-</blockquote>
-
-
-<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
-
-<blockquote>
- -2- Effects: Finds the first position into which value can be
- inserted without violating the ordering.
-</blockquote>
-
-<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
-
-<blockquote>
- -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expression !(value < e) or !comp(value, e)
-</blockquote>
-
-<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
-
-<blockquote>
- -2- Effects: Finds the furthermost position into which value can be
- inserted without violating the ordering.
-</blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
-
-<blockquote>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expressions e < value and !(value < e) or
- comp(e, value) and !comp(value, e). Also, for all elements e of
- [first, last), e < value implies !(value < e) or comp(e,
- value) implies !comp(value, e)
-</blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
-
-<blockquote>
- -2- Effects: Finds the largest subrange [i, j) such that the value
- can be inserted at any iterator k in it without violating the
- ordering. k satisfies the corresponding conditions: !(*k < value)
- && !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
- false.
-</blockquote>
-
-<p>to:</p>
-
-<pre>
- -2- Returns:
- make_pair(lower_bound(first, last, value),
- upper_bound(first, last, value))
- or
- make_pair(lower_bound(first, last, value, comp),
- upper_bound(first, last, value, comp))
-</pre>
-
-<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
-
-<blockquote>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expressions e < value and !(value < e) or comp(e,
- value) and !comp(value, e). Also, for all elements e of [first,
- last), e < value implies !(value < e) or comp(e, value) implies
- !comp(value, e)
-</blockquote>
-
-<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
-
-<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and
-changed the "other than those described in" wording.) Also, the LWG
-decided to accept the "optional" part.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>The proposed resolution reinterprets binary search. Instead of
-thinking about searching for a value in a sorted range, we view that
-as an important special case of a more general algorithm: searching
-for the partition point in a partitioned range.</p>
-
-<p>We also add a guarantee that the old wording did not: we ensure
-that the upper bound is no earlier than the lower bound, that
-the pair returned by equal_range is a valid range, and that the first
-part of that pair is the lower bound.</p>
-<hr>
-<a name="271"><h3>271. basic_iostream missing typedefs</h3></a><p>
-<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>
-<p>
-Class template basic_iostream has no typedefs. The typedefs it
-inherits from its base classes can't be used, since (for example)
-basic_iostream<T>::traits_type is ambiguous.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following to basic_iostream's class synopsis in
-27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
-
-<pre>
- // types:
- typedef charT char_type;
- typedef typename traits::int_type int_type;
- typedef typename traits::pos_type pos_type;
- typedef typename traits::off_type off_type;
- typedef traits traits_type;
-</pre>
-<hr>
-<a name="272"><h3>272. Missing parentheses around subexpression</h3></a><p>
-<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>
-<p>
-27.4.4.3, p4 says about the postcondition of the function: If
-rdbuf()!=0 then state == rdstate(); otherwise
-rdstate()==state|ios_base::badbit.
-</p>
-
-<p>
-The expression on the right-hand-side of the operator==() needs to be
-parenthesized in order for the whole expression to ever evaluate to
-anything but non-zero.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add parentheses like so: rdstate()==(state|ios_base::badbit).
-</p>
-<hr>
-<a name="273"><h3>273. Missing ios_base qualification on members of a dependent class</h3></a><p>
-<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>
-<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
-27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
-That's incorrect since the names are members of a dependent base
-class (14.6.2 [temp.dep]) and thus not visible.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Qualify the names with the name of the class of which they are
-members, i.e., ios_base.</p>
-<hr>
-<a name="274"><h3>274. a missing/impossible allocator requirement</h3></a><p>
-<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>
-<p>
-I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
-any type. But the synopsis in 20.4.1 calls for allocator<>::address() to
-be overloaded on reference and const_reference, which is ill-formed for
-all T = const U. In other words, this won't work:
-</p>
-
-<p>
-template class std::allocator<const int>;
-</p>
-
-<p>
-The obvious solution is to disallow specializations of allocators on
-const types. However, while containers' elements are required to be
-assignable (which rules out specializations on const T's), I think that
-allocators might perhaps be potentially useful for const values in other
-contexts. So if allocators are to allow const types a partial
-specialization of std::allocator<const T> would probably have to be
-provided.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
-
- <blockquote>
- any type
- </blockquote>
-
-<p>to</p>
- <blockquote>
- any non-const, non-reference type
- </blockquote>
-
-<p><i>[Redmond: previous proposed resolution was "any non-const,
-non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>
-Two resolutions were originally proposed: one that partially
-specialized std::allocator for const types, and one that said an
-allocator's value type may not be const. The LWG chose the second.
-The first wouldn't be appropriate, because allocators are intended for
-use by containers, and const value types don't work in containers.
-Encouraging the use of allocators with const value types would only
-lead to unsafe code.
-</p>
-<p>
-The original text for proposed resolution 2 was modified so that it
-also forbids volatile types and reference types.
-</p>
-
-<p><i>[Curaçao: LWG double checked and believes volatile is correctly
-excluded from the PR.]</i></p>
-
-<hr>
-<a name="275"><h3>275. Wrong type in num_get::get() overloads</h3></a><p>
-<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>
-<p>
-In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
-There are eight overloads, all of which are identical except for the
-last parameter. The overloads are:
-</p>
-<ul>
-<li> long& </li>
-<li> unsigned short& </li>
-<li> unsigned int& </li>
-<li> unsigned long& </li>
-<li> short& </li>
-<li> double& </li>
-<li> long double& </li>
-<li> void*& </li>
-</ul>
-
-<p>
-There is a similar list, in 22.2.2.1.2, of overloads for
-num_get<>::do_get(). In this list, the last parameter has
-the types:
-</p>
-<ul>
-<li> long& </li>
-<li> unsigned short& </li>
-<li> unsigned int& </li>
-<li> unsigned long& </li>
-<li> float& </li>
-<li> double& </li>
-<li> long double& </li>
-<li> void*& </li>
-</ul>
-
-<p>
-These two lists are not identical. They should be, since
-<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
-the arguments it was given.
-</p>
-<p><b>Proposed resolution:</b></p>
-<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>
-<pre>
- iter_type get(iter_type in, iter_type end, ios_base& str,
- ios_base::iostate& err, short& val) const;
-</pre>
-<p>to</p>
-<pre>
- iter_type get(iter_type in, iter_type end, ios_base& str,
- ios_base::iostate& err, float& val) const;
-</pre>
-<hr>
-<a name="276"><h3>276. Assignable requirement for container value type overly strict</h3></a><p>
-<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>
-<p>
-23.1/3 states that the objects stored in a container must be
-Assignable. 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
-states that map satisfies all requirements for a container, while in
-the same time defining value_type as pair<const Key, T> - a type
-that is not Assignable.
-</p>
-
-<p>
-It should be noted that there exists a valid and non-contradictory
-interpretation of the current text. The wording in 23.1/3 avoids
-mentioning value_type, referring instead to "objects stored in a
-container." One might argue that map does not store objects of
-type map::value_type, but of map::mapped_type instead, and that the
-Assignable requirement applies to map::mapped_type, not
-map::value_type.
-</p>
-
-<p>
-However, this makes map a special case (other containers store objects of
-type value_type) and the Assignable requirement is needlessly restrictive in
-general.
-</p>
-
-<p>
-For example, the proposed resolution of active library issue
-<a href="lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
-means that no set operations can exploit the fact that the stored
-objects are Assignable.
-</p>
-
-<p>
-This is related to, but slightly broader than, closed issue
-<a href="lwg-closed.html#140">140</a>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>23.1/3: Strike the trailing part of the sentence:</p>
- <blockquote>
- , and the additional requirements of Assignable types from 23.1/3
- </blockquote>
-<p>so that it reads:</p>
- <blockquote>
- -3- The type of objects stored in these components must meet the
- requirements of CopyConstructible types (lib.copyconstructible).
- </blockquote>
-
-<p>23.1/4: Modify to make clear that this requirement is not for all
-containers. Change to:</p>
-
-<blockquote>
--4- Table 64 defines the Assignable requirement. Some containers
-require this property of the types to be stored in the container. T is
-the type used to instantiate the container. t is a value of T, and u is
-a value of (possibly const) T.
-</blockquote>
-
-<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
-CopyConstructible".</p>
-
-<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p>
-
-<blockquote>
--2- A deque satisfies all of the requirements of a container and of a
-reversible container (given in tables in lib.container.requirements) and
-of a sequence, including the optional sequence requirements
-(lib.sequence.reqmts). In addition to the requirements on the stored
-object described in 23.1[lib.container.requirements], the stored object
-must also meet the requirements of Assignable. Descriptions are
-provided here only for operations on deque that are not described in one
-of these tables or for operations where there is additional semantic
-information.
-</blockquote>
-
-<p>23.2.2/2: Add Assignable requirement to specific methods of list.
-Change to:</p>
-
-<blockquote>
-<p>-2- A list satisfies all of the requirements of a container and of a
-reversible container (given in two tables in lib.container.requirements)
-and of a sequence, including most of the the optional sequence
-requirements (lib.sequence.reqmts). The exceptions are the operator[]
-and at member functions, which are not provided.
-
-[Footnote: These member functions are only provided by containers whose
-iterators are random access iterators. --- end foonote]
-</p>
-
-<p>list does not require the stored type T to be Assignable unless the
-following methods are instantiated:
-
-[Footnote: Implementors are permitted but not required to take advantage
-of T's Assignable properties for these methods. -- end foonote]
-</p>
-<pre>
- list<T,Allocator>& operator=(const list<T,Allocator>& x );
- template <class InputIterator>
- void assign(InputIterator first, InputIterator last);
- void assign(size_type n, const T& t);
-</pre>
-
-
-<p>Descriptions are provided here only for operations on list that are not
-described in one of these tables or for operations where there is
-additional semantic information.</p>
-</blockquote>
-
-<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p>
-
-<blockquote>
--2- A vector satisfies all of the requirements of a container and of a
-reversible container (given in two tables in lib.container.requirements)
-and of a sequence, including most of the optional sequence requirements
-(lib.sequence.reqmts). The exceptions are the push_front and pop_front
-member functions, which are not provided. In addition to the
-requirements on the stored object described in
-23.1[lib.container.requirements], the stored object must also meet the
-requirements of Assignable. Descriptions are provided here only for
-operations on vector that are not described in one of these tables or
-for operations where there is additional semantic information.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>list, set, multiset, map, multimap are able to store non-Assignables.
-However, there is some concern about <tt>list<T></tt>:
-although in general there's no reason for T to be Assignable, some
-implementations of the member functions <tt>operator=</tt> and
-<tt>assign</tt> do rely on that requirement. The LWG does not want
-to forbid such implementations.</p>
-
-<p>Note that the type stored in a standard container must still satisfy
-the requirements of the container's allocator; this rules out, for
-example, such types as "const int". See issue <a href="lwg-defects.html#274">274</a>
-for more details.
-</p>
-
-<p>In principle we could also relax the "Assignable" requirement for
-individual <tt>vector</tt> member functions, such as
-<tt>push_back</tt>. However, the LWG did not see great value in such
-selective relaxation. Doing so would remove implementors' freedom to
-implement <tt>vector::push_back</tt> in terms of
-<tt>vector::insert</tt>.</p>
-
-<hr>
-<a name="281"><h3>281. std::min() and max() requirements overly restrictive</h3></a><p>
-<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>
-<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
-requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
-and <tt>CopyConstructible</tt> (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
-Since the functions take and return their arguments and result by
-const reference, I believe the <tt>CopyConstructible</tt> requirement
-is unnecessary.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
-25.3.7, p1 with</p>
-<p>
-<b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
-(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
-</p>
-<p>and replace 25.3.7, p4 with</p>
-<p>
-<b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
-(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
-</p>
-<hr>
-<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p>
-<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>
-<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
-library function <tt>strcmp()</tt> with the function pointer adapter
-<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
-functions have <tt>extern "C"</tt> or <tt>extern
-"C++"</tt> linkage [17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
-function pointers with different the language linkage specifications
-(7.5 <a href="dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
-well-formed is unspecified.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
-<blockquote>
- <p>[<i>Example:</i>
-</p>
- <pre>
- replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
- </pre>
- <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-
-<p>to:</p>
-<blockquote>
- <p>[<i>Example:</i>
-</p>
- <pre>
- int compare(const char*, const char*);
- replace_if(v.begin(), v.end(),
- not1(bind2nd(ptr_fun(compare), "abc")), "def");
- </pre>
- <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-<p>Also, remove footnote 215 in that same paragraph.</p>
-
-<p><i>[Copenhagen: Minor change in the proposed resolution. Since this
-issue deals in part with C and C++ linkage, it was believed to be too
-confusing for the strings in the example to be "C" and "C++".
-]</i></p>
-
-<p><i>[Redmond: More minor changes. Got rid of the footnote (which
-seems to make a sweeping normative requirement, even though footnotes
-aren't normative), and changed the sentence after the footnote so that
-it corresponds to the new code fragment.]</i></p>
-
-<hr>
-<a name="285"><h3>285. minor editorial errors in fstream ctors</h3></a><p>
-<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>
-<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
-27.8.1.12 <a href="lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
-</p>
-
-<p>... If that function returns a null pointer, calls
-<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
-</p>
-
-<p>The parenthetical note doesn't apply since the ctors cannot throw an
-exception due to the requirement in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
-that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Strike the parenthetical note from the Effects clause in each of the
-paragraphs mentioned above.
-</p>
-<hr>
-<a name="286"><h3>286. <cstdlib> requirements missing size_t typedef</h3></a><p>
-<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>
-<p>
-The <cstdlib> header file contains prototypes for bsearch and
-qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
-prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
-require the typedef size_t. Yet size_t is not listed in the
-<cstdlib> synopsis table 78 in section 25.4.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the type size_t to Table 78 (section 25.4) and add
-the type size_t <cstdlib> to Table 97 (section C.2).
-</p>
-<p><b>Rationale:</b></p>
-<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p>
-<hr>
-<a name="288"><h3>288. <cerrno> requirements missing macro EILSEQ</h3></a><p>
-<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>
-<p>
-ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
-of macros defined in <errno.h> is adjusted to include a new
-macro, EILSEQ"
-</p>
-
-<p>
-ISO/IEC 14882:1998(E) section 19.3 does not refer
-to the above amendment.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Update Table 26 (section 19.3) "Header <cerrno> synopsis"
-and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
-</p>
-<hr>
-<a name="292"><h3>292. effects of a.copyfmt (a)</h3></a><p>
-<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>
-<p>The Effects clause of the member function <tt>copyfmt()</tt> in
-27.4.4.2, p15 doesn't consider the case where the left-hand side
-argument is identical to the argument on the right-hand side, that is
-<tt>(this == &rhs)</tt>. If the two arguments are identical there
-is no need to copy any of the data members or call any callbacks
-registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
-points out in message c++std-lib-8149 it appears to be incorrect to
-allow the object to fire <tt>erase_event</tt> followed by
-<tt>copyfmt_event</tt> since the callback handling the latter event
-may inadvertently attempt to access memory freed by the former.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the Effects clause in 27.4.4.2, p15 from</p>
-
-<blockquote>
-<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
-the corresponding member objects of <tt>rhs</tt>, except that...
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise
-assigns to the member objects of <tt>*this</tt> the corresponding member
-objects of <tt>rhs</tt>, except that...
-</blockquote>
-<hr>
-<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p>
-<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>
-<p>
-Table 80 lists the contents of the <cmath> header. It does not
-list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
-signatures present in <cmath>, does say that several overloads
-of <tt>abs()</tt> should be defined in <cmath>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
-of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
-paragraph 1.
-</p>
-
-<p><i>[Copenhagen: Modified proposed resolution so that it also gets
-rid of that vestigial list of functions in paragraph 1.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>All this DR does is fix a typo; it's uncontroversial. A
-separate question is whether we're doing the right thing in
-putting some overloads in <cmath> that we aren't also
-putting in <cstdlib>. That's issue <a href="lwg-active.html#323">323</a>.</p>
-<hr>
-<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p>
-<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>
-<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
-<tt>const_mem_fun1_t</tt>
-in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and
-<tt>binary_function<T*,
-A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and
-<tt>first_argument_type</tt>
-members, respectively, are both defined to be <tt>T*</tt> (non-const).
-However, their function call member operator takes a <tt>const T*</tt>
-argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
-T*</tt> instead, so that one can easily refer to it in generic code. The
-example below derived from existing code fails to compile due to the
-discrepancy:
-</p>
-
-<p>
-<tt>template <class T></tt>
-<br><tt>void foo (typename T::argument_type arg) // #1</tt>
-<br><tt>{</tt>
-<br><tt> typename T::result_type (T::*pf) (typename
-T::argument_type)
-const = // #2</tt>
-<br><tt> &T::operator();</tt>
-<br><tt>}</tt>
-</p>
-
-<p><tt>struct X { /* ... */ };</tt></p>
-
-<p>
-<tt>int main ()</tt>
-<br><tt>{</tt>
-<br><tt> const X x;</tt>
-<br><tt> foo<std::const_mem_fun_t<void, X>
->(&x);
-// #3</tt>
-<br><tt>}</tt>
-</p>
-
-<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
-<br>#2 the type of the pointer is incompatible with the type of the member
-function
-<br>#3 the address of a constant being passed to a function taking a non-const
-<tt>X*</tt>
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the top portion of the definition of the class template
-const_mem_fun_t in 20.3.8, p8
-</p>
-<p>
-<tt>template <class S, class T> class const_mem_fun_t</tt>
-<br><tt> : public
-unary_function<T*, S> {</tt>
-</p>
-<p>with</p>
-<p>
-<tt>template <class S, class T> class const_mem_fun_t</tt>
-<br><tt> : public
-unary_function<<b>const</b> T*, S> {</tt>
-</p>
-<p>Also replace the top portion of the definition of the class template
-const_mem_fun1_t in 20.3.8, p9</p>
-<p>
-<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
-<br><tt> : public
-binary_function<T*, A, S> {</tt>
-</p>
-<p>with</p>
-<p>
-<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
-<br><tt> : public
-binary_function<<b>const</b> T*, A, S> {</tt>
-</p>
-<p><b>Rationale:</b></p>
-<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
-and the argument type itself, are not the same.</p>
-<hr>
-<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p>
-<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>
-<p>
-The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
-namely that for non-null value of <i>ptr</i>, the operator reclaims storage
-allocated by the earlier call to the default <tt>operator new[]</tt> - is not
-correct in all cases. Since the specified <tt>operator new[]</tt> default
-behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
-replaced, along with <tt>operator delete</tt>, by the user, to implement their
-own memory management, the specified default behavior of<tt> operator
-delete[]</tt> must be to call <tt>operator delete</tt>.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 18.4.1.2, p12 from</p>
-<blockquote>
-<b>-12-</b> <b>Default behavior:</b>
-<ul>
-<li>
-For a null value of <i><tt>ptr</tt></i> , does nothing.
-</li>
-<li>
-Any other value of <i><tt>ptr</tt></i> shall be a value returned
-earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
-[Footnote: The value must not have been invalidated by an intervening
-call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
---- end footnote]
-For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
-allocated by the earlier call to the default <tt>operator new[]</tt>.
-</li>
-</ul>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
-delete(</tt><i>ptr</i>)
-or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
-</blockquote>
-<p>and expunge paragraph 13.</p>
-<hr>
-<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p>
-<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>
-<p>
-The effects clause for the basic_string template ctor in 21.3.1, p15
-leaves out the third argument of type Allocator. I believe this to be
-a mistake.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace</p>
-
-<blockquote>
- <p>
-<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
- type, equivalent to</p>
-
- <blockquote><tt>basic_string(static_cast<size_type>(begin),
- static_cast<value_type>(end))</tt></blockquote>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>
-<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
- type, equivalent to</p>
-
- <blockquote><tt>basic_string(static_cast<size_type>(begin),
- static_cast<value_type>(end), <b>a</b>)</tt></blockquote>
-</blockquote>
-<hr>
-<a name="303"><h3>303. Bitset input operator underspecified</h3></a><p>
-<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>
-<p>
-In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
-"Extracts up to <i>N</i> (single-byte) characters from
-<i>is</i>.", where <i>is</i> is a stream of type
-<tt>basic_istream<charT, traits></tt>.
-</p>
-
-<p>
-The standard does not say what it means to extract single byte
-characters from a stream whose character type, <tt>charT</tt>, is in
-general not a single-byte character type. Existing implementations
-differ.
-</p>
-
-<p>
-A reasonable solution will probably involve <tt>widen()</tt> and/or
-<tt>narrow()</tt>, since they are the supplied mechanism for
-converting a single character between <tt>char</tt> and
-arbitrary <tt>charT</tt>.
-</p>
-
-<p>Narrowing the input characters is not the same as widening the
-literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
-locales in which more than one wide character maps to the narrow
-character <tt>'0'</tt>. Narrowing means that alternate
-representations may be used for bitset input, widening means that
-they may not be.</p>
-
-<p>Note that for numeric input, <tt>num_get<></tt>
-(22.2.2.1.2/8) compares input characters to widened version of narrow
-character literals.</p>
-
-<p>From Pete Becker, in c++std-lib-8224:</p>
-<blockquote>
-<p>
-Different writing systems can have different representations for the
-digits that represent 0 and 1. For example, in the Unicode representation
-of the Devanagari script (used in many of the Indic languages) the digit 0
-is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
-into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
-0x0031 for for the Latin representations of '0' and '1', as well as code
-points for the same numeric values in several other scripts (Tamil has no
-character for 0, but does have the digits 1-9), and any of these values
-would also be narrowed to '0' and '1'.
-</p>
-
-<p>...</p>
-
-<p>
-It's fairly common to intermix both native and Latin
-representations of numbers in a document. So I think the rule has to be
-that if a wide character represents a digit whose value is 0 then the bit
-should be cleared; if it represents a digit whose value is 1 then the bit
-should be set; otherwise throw an exception. So in a Devanagari locale,
-both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
-would set it. Widen can't do that. It would pick one of those two values,
-and exclude the other one.
-</p>
-
-</blockquote>
-
-<p>From Jens Maurer, in c++std-lib-8233:</p>
-
-<blockquote>
-<p>
-Whatever we decide, I would find it most surprising if
-bitset conversion worked differently from int conversion
-with regard to alternate local representations of
-numbers.
-</p>
-
-<p>Thus, I think the options are:</p>
-<ul>
- <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
-require the use of narrow().</li>
-
- <li> Have a defect issue for bitset() which describes clearly
-that widen() is to be used.</li>
-</ul>
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-
- <p>Replace the first two sentences of paragraph 5 with:</p>
-
- <blockquote>
- Extracts up to <i>N</i> characters from <i>is</i>. Stores these
- characters in a temporary object <i>str</i> of type
- <tt>basic_string<charT, traits></tt>, then evaluates the
- expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>.
- </blockquote>
-
- <p>Replace the third bullet item in paragraph 5 with:</p>
- <ul><li>
- the next input character is neither <tt><i>is</i>.widen(0)</tt>
- nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
- is not extracted).
- </li></ul>
-
-<p><b>Rationale:</b></p>
-<p>Input for <tt>bitset</tt> should work the same way as numeric
-input. Using <tt>widen</tt> does mean that alternative digit
-representations will not be recognized, but this was a known
-consequence of the design choice.</p>
-<hr>
-<a name="306"><h3>306. offsetof macro and non-POD types</h3></a><p>
-<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>
-<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
-
-<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
-accepts a restricted set of <i>type</i> arguments in this
-International Standard. <i>type</i> shall be a POD structure or a POD
-union (clause 9). The result of applying the offsetof macro to a field
-that is a static data member or a function member is
-undefined."</p>
-
-<p>For the POD requirement, it doesn't say "no diagnostic
-required" 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.
-It's not clear whether this requirement was intended. While it's
-possible to provide such a diagnostic, the extra complication doesn't
-seem to add any value.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
-structure or a POD union the results are undefined."</p>
-
-<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
-agreed that requiring a diagnostic was inadvertent, but some LWG
-members thought that diagnostics should be required whenever
-possible.]</i></p>
-
-<hr>
-<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p>
-<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>
-
-<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
-
-<p>
-The standard is currently inconsistent in 23.2.3.2 <a href="lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
-paragraph 1 and 23.2.3.3 <a href="lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
-23.2.3.3/1, for example, says:
-</p>
-
-<blockquote>
--1- Any sequence supporting operations back(), push_back() and pop_back()
-can be used to instantiate stack. In particular, vector (lib.vector), list
-(lib.list) and deque (lib.deque) can be used.
-</blockquote>
-
-<p>But this is false: vector<bool> can not be used, because the
-container adaptors return a T& rather than using the underlying
-container's reference type.</p>
-
-<p>This is a contradiction that can be fixed by:</p>
-
-<ol>
-<li>Modifying these paragraphs to say that vector<bool>
- is an exception.</li>
-<li>Removing the vector<bool> specialization.</li>
-<li>Changing the return types of stack and priority_queue to use
- reference typedef's.</li>
-</ol>
-
-<p>
-I propose 3. This does not preclude option 2 if we choose to do it
-later (see issue <a href="lwg-active.html#96">96</a>); the issues are independent. Option
-3 offers a small step towards support for proxied containers. This
-small step fixes a current contradiction, is easy for vendors to
-implement, is already implemented in at least one popular lib, and
-does not break any code.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Summary: Add reference and const_reference typedefs to queue,
-priority_queue and stack. Change return types of "value_type&" to
-"reference". Change return types of "const value_type&" to
-"const_reference". Details:</p>
-
-<p>Change 23.2.3.1/1 from:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = deque<T> >
- class queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit queue(const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- value_type& front() { return c.front(); }
- const value_type& front() const { return c.front(); }
- value_type& back() { return c.back(); }
- const value_type& back() const { return c.back(); }
- void push(const value_type& x) { c.push_back(x); }
- void pop() { c.pop_front(); }
- };
-</pre>
-
-<p>to:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = deque<T> >
- class queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit queue(const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- reference front() { return c.front(); }
- const_reference front() const { return c.front(); }
- reference back() { return c.back(); }
- const_reference back() const { return c.back(); }
- void push(const value_type& x) { c.push_back(x); }
- void pop() { c.pop_front(); }
- };
-</pre>
-
-<p>Change 23.2.3.2/1 from:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = vector<T>,
- class Compare = less<typename Container::value_type> >
- class priority_queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
- Compare comp;
-
- public:
- explicit priority_queue(const Compare& x = Compare(),
- const Container& = Container());
- template <class InputIterator>
- priority_queue(InputIterator first, InputIterator last,
- const Compare& x = Compare(),
- const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- const value_type& top() const { return c.front(); }
- void push(const value_type& x);
- void pop();
- };
- // no equality is provided
- }
-</pre>
-
-<p>to:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = vector<T>,
- class Compare = less<typename Container::value_type> >
- class priority_queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
- Compare comp;
-
- public:
- explicit priority_queue(const Compare& x = Compare(),
- const Container& = Container());
- template <class InputIterator>
- priority_queue(InputIterator first, InputIterator last,
- const Compare& x = Compare(),
- const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- const_reference top() const { return c.front(); }
- void push(const value_type& x);
- void pop();
- };
- // no equality is provided
- }
-</pre>
-
-<p>And change 23.2.3.3/1 from:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = deque<T> >
- class stack {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit stack(const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- value_type& top() { return c.back(); }
- const value_type& top() const { return c.back(); }
- void push(const value_type& x) { c.push_back(x); }
- void pop() { c.pop_back(); }
- };
-
- template <class T, class Container>
- bool operator==(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator< (const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator!=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator> (const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator>=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator<=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- }
-</pre>
-
-<p>to:</p>
-
-<pre>
- namespace std {
- template <class T, class Container = deque<T> >
- class stack {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit stack(const Container& = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- reference top() { return c.back(); }
- const_reference top() const { return c.back(); }
- void push(const value_type& x) { c.push_back(x); }
- void pop() { c.pop_back(); }
- };
-
- template <class T, class Container>
- bool operator==(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator< (const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator!=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator> (const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator>=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- template <class T, class Container>
- bool operator<=(const stack<T, Container>& x,
- const stack<T, Container>& y);
- }
-</pre>
-
-<p><i>[Copenhagen: This change was discussed before the IS was released
-and it was deliberately not adopted. Nevertheless, the LWG believes
-(straw poll: 10-2) that it is a genuine defect.]</i></p>
-
-<hr>
-<a name="308"><h3>308. Table 82 mentions unrelated headers</h3></a><p>
-<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>
-<p>
-Table 82 in section 27 mentions the header <cstdlib> for String
-streams (27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers <cstdio> and
-<cwchar> for File streams (27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
-why these headers are mentioned in this context since they do not
-define any of the library entities described by the
-subclauses. According to 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
-are to be listed in the summary.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove <cstdlib> and <cwchar> from
-Table 82.</p>
-
-<p><i>[Copenhagen: changed the proposed resolution slightly. The
-original proposed resolution also said to remove <cstdio> from
-Table 82. However, <cstdio> is mentioned several times within
-section 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>
-
-<hr>
-<a name="310"><h3>310. Is errno a macro?</h3></a><p>
-<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>
- <p>
- Exactly how should errno be declared in a conforming C++ header?
- </p>
-
- <p>
- The C standard says in 7.1.4 that it is unspecified whether errno is a
- macro or an identifier with external linkage. In some implementations
- it can be either, depending on compile-time options. (E.g., on
- Solaris in multi-threading mode, errno is a macro that expands to a
- function call, but is an extern int otherwise. "Unspecified" allows
- such variability.)
- </p>
-
- <p>The C++ standard:</p>
- <ul>
- <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
- <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
- name (true), and implies that it is an identifier.</li>
- <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
- on to say that the contents of of C++ <errno.h> are the
- same as in C, begging the question.</li>
- <li>C.2, table 95 lists errno as a macro, without comment.</li>
- </ul>
-
- <p>I find no other references to errno.</p>
-
- <p>We should either explicitly say that errno must be a macro, even
- though it need not be a macro in C, or else explicitly leave it
- unspecified. We also need to say something about namespace std.
- A user who includes <cerrno> needs to know whether to write
- <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
- else <cerrno> is useless.</p>
-
- <p>Two acceptable fixes:</p>
- <ul>
- <li><p>errno must be a macro. This is trivially satisfied by adding<br>
- #define errno (::std::errno)<br>
- to the headers if errno is not already a macro. You then always
- write errno without any scope qualification, and it always expands
- to a correct reference. Since it is always a macro, you know to
- avoid using errno as a local identifer.</p></li>
- <li><p>errno is in the global namespace. This fix is inferior, because
- ::errno is not guaranteed to be well-formed.</p></li>
- </ul>
-
- <p><i>[
- This issue was first raised in 1999, but it slipped through
- the cracks.
- ]</i></p>
-<p><b>Proposed resolution:</b></p>
- <p>Change the Note in section 17.4.1.2p5 from</p>
-
- <blockquote>
- Note: the names defined as macros in C include the following:
- assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
- </blockquote>
-
- <p>to</p>
-
- <blockquote>
- Note: the names defined as macros in C include the following:
- assert, offsetof, setjmp, va_arg, va_end, and va_start.
- </blockquote>
-
- <p>In section 19.3, change paragraph 2 from</p>
-
- <blockquote>
- The contents are the same as the Standard C library header
- <errno.h>.
- </blockquote>
-
- <p>to</p>
-
- <blockquote>
- The contents are the same as the Standard C library header
- <errno.h>, except that errno shall be defined as a macro.
- </blockquote>
-<p><b>Rationale:</b></p>
-<p>C++ must not leave it up to the implementation to decide whether or
-not a name is a macro; it must explicitly specify exactly which names
-are required to be macros. The only one that really works is for it
-to be a macro.</p>
-
-<p><i>[Curaçao: additional rationale added.]</i></p>
-
-<hr>
-<a name="311"><h3>311. Incorrect wording in basic_ostream class synopsis</h3></a><p>
-<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>
-
-<p>In 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
-
-<pre>
- // partial specializationss
- template<class traits>
- basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
- const char * );
-</pre>
-
-<p>Problems:</p>
-<ul>
-<li>Too many 's's at the end of "specializationss" </li>
-<li>This is an overload, not a partial specialization</li>
-</ul>
-
-<p><b>Proposed resolution:</b></p>
-<p>In the synopsis in 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
-<i>// partial specializationss</i> comment. Also remove the same
-comment (correctly spelled, but still incorrect) from the synopsis in
-27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
-</p>
-
-<p><i>[
-Pre-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
-comment in c++std-lib-8939.
-]</i></p>
-
-<hr>
-<a name="312"><h3>312. Table 27 is missing headers</h3></a><p>
-<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>
-<p>Table 27 in section 20 lists the header <memory> (only) for
-Memory (lib.memory) but neglects to mention the headers
-<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add <cstdlib> and <cstring> to Table 27, in the same row
-as <memory>.</p>
-<hr>
-<a name="315"><h3>315. Bad "range" in list::unique complexity</h3></a><p>
-<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>
-<p>
-23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
-list::unique as: "If the range (last - first) is not empty, exactly
-(last - first) -1 applications of the corresponding predicate,
-otherwise no applications of the predicate)".
-</p>
-
-<p>
-"(last - first)" is not a range.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the "range" from (last - first) to [first, last).
-</p>
-<hr>
-<a name="316"><h3>316. Vague text in Table 69</h3></a><p>
-<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>
-<p>Table 69 says this about a_uniq.insert(t):</p>
-
-<blockquote>
-inserts t if and only if there is no element in the container with key
-equivalent to the key of t. The bool component of the returned pair
-indicates whether the insertion takes place and the iterator component of the
-pair points to the element with key equivalent to the key of t.
-</blockquote>
-
-<p>The description should be more specific about exactly how the bool component
-indicates whether the insertion takes place.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in question to</p>
-
-<blockquote>
-...The bool component of the returned pair is true if and only if the insertion
-takes place...
-</blockquote>
-<hr>
-<a name="317"><h3>317. Instantiation vs. specialization of facets</h3></a><p>
-<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>
-<p>
-The localization section of the standard refers to specializations of
-the facet templates as instantiations even though the required facets
-are typically specialized rather than explicitly (or implicitly)
-instantiated. In the case of ctype<char> and
-ctype_byname<char> (and the wchar_t versions), these facets are
-actually required to be specialized. The terminology should be
-corrected to make it clear that the standard doesn't mandate explicit
-instantiation (the term specialization encompasses both explicit
-instantiations and specializations).
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In the following paragraphs, replace all occurrences of the word
-instantiation or instantiations with specialization or specializations,
-respectively:
-</p>
-
-<blockquote>
-22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
-22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
-22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
-Footnote 242.
-</blockquote>
-
-<p>And change the text in 22.1.1.1.1, p4 from</p>
-
-<blockquote>
- An implementation is required to provide those instantiations
- for facet templates identified as members of a category, and
- for those shown in Table 52:
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
- An implementation is required to provide those specializations...
-</blockquote>
-
-<p><i>[Nathan will review these changes, and will look for places where
-explicit specialization is necessary.]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>This is a simple matter of outdated language. The language to
-describe templates was clarified during the standardization process,
-but the wording in clause 22 was never updated to reflect that
-change.</p>
-<hr>
-<a name="318"><h3>318. Misleading comment in definition of numpunct_byname</h3></a><p>
-<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>
-<p>The definition of the numpunct_byname template contains the following
-comment:</p>
-
-<pre>
- namespace std {
- template <class charT>
- class numpunct_byname : public numpunct<charT> {
- // this class is specialized for char and wchar_t.
- ...
-</pre>
-
-<p>There is no documentation of the specializations and it seems
-conceivable that an implementation will not explicitly specialize the
-template at all, but simply provide the primary template.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the comment from the text in 22.2.3.2 and from the proposed
-resolution of library issue <a href="lwg-defects.html#228">228</a>.</p>
-<hr>
-<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p>
-<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>
-<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
-behavior" elements describe "the semantics of a function definition
-provided by either the implementation or a C++ program."</p>
-
-<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
-elements describe "the preconditions for calling the function."</p>
-
-<p>In the sections noted below, the current wording specifies
-"Required Behavior" for what are actually preconditions, and thus
-should be specified as "Requires".</p>
-
-<p><b>Proposed resolution:</b></p>
-
-<p>In 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
-<blockquote>
- <p>Required behavior: accept a value of ptr that is null or that was
- returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Requires: the value of ptr is null or the value returned by an
- earlier call ...</p>
-</blockquote>
-
-<p>In 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
-<blockquote>
- <p>Required behavior: accept a value of ptr that is null or that was
- returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Requires: the value of ptr is null or the value returned by an
- earlier call ...</p>
-</blockquote>
-
-<hr>
-<a name="321"><h3>321. Typo in num_get</h3></a><p>
-<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>
-<p>
-Section 22.2.2.1.2 at p7 states that "A length specifier is added to
-the conversion function, if needed, as indicated in Table 56."
-However, Table 56 uses the term "length modifier", not "length
-specifier".
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
-to be "A length modifier is added ..."
-</p>
-<p><b>Rationale:</b></p>
-<p>C uses the term "length modifier". We should be consistent.</p>
-<hr>
-<a name="322"><h3>322. iterator and const_iterator should have the same value type</h3></a><p>
-<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>
-<p>
-It's widely assumed that, if X is a container,
-iterator_traits<X::iterator>::value_type and
-iterator_traits<X::const_iterator>::value_type should both be
-X::value_type. However, this is nowhere stated. The language in
-Table 65 is not precise about the iterators' value types (it predates
-iterator_traits), and could even be interpreted as saying that
-iterator_traits<X::const_iterator>::value_type should be "const
-X::value_type".
-</p>
-
-<p>Related issue: <a href="lwg-closed.html#279">279</a>.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In Table 65 ("Container Requirements"), change the return type for
-X::iterator to "iterator type whose value type is T". Change the
-return type for X::const_iterator to "constant iterator type whose
-value type is T".</p>
-<p><b>Rationale:</b></p>
-<p>
-This belongs as a container requirement, rather than an iterator
-requirement, because the whole notion of iterator/const_iterator
-pairs is specific to containers' iterator.
-</p>
-<p>
-It is existing practice that (for example)
-iterator_traits<list<int>::const_iterator>::value_type
-is "int", rather than "const int". This is consistent with
-the way that const pointers are handled: the standard already
-requires that iterator_traits<const int*>::value_type is int.
-</p>
-<hr>
-<a name="327"><h3>327. Typo in time_get facet in table 52</h3></a><p>
-<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>
-<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
-<tt>time_get_byname</tt> are listed incorrectly in table 52,
-required instantiations. In both cases the second template
-parameter is given as OutputIterator. It should instead be
-InputIterator, since these are input facets.</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In table 52, required instantiations, in
-22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
-<pre>
- time_get<wchar_t, OutputIterator>
- time_get_byname<wchar_t, OutputIterator>
-</pre>
-<p>to</p>
-<pre>
- time_get<wchar_t, InputIterator>
- time_get_byname<wchar_t, InputIterator>
-</pre>
-
-<p><i>[Redmond: Very minor change in proposed resolution. Original had
-a typo, wchart instead of wchar_t.]</i></p>
-
-<hr>
-<a name="328"><h3>328. Bad sprintf format modifier in money_put<>::do_put()</h3></a><p>
-<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>
-<p>The sprintf format string , "%.01f" (that's the digit one), in the
-description of the do_put() member functions of the money_put facet in
-22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
-for values of type long double, and second, the precision of 01
-doesn't seem to make sense. What was most likely intended was
-"%.0Lf"., that is a precision of zero followed by the L length
-modifier.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change the format string to "%.0Lf".</p>
-<p><b>Rationale:</b></p>
-<p>Fixes an obvious typo</p>
-<hr>
-<a name="331"><h3>331. bad declaration of destructor for ios_base::failure</h3></a><p>
-<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>
-<p>
-With 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
- "An implementation may strengthen the exception-specification for a
- non-virtual function by removing listed exceptions."
-(issue <a href="lwg-defects.html#119">119</a>)
-and the following declaration of ~failure() in ios_base::failure
-</p>
-<pre>
- namespace std {
- class ios_base::failure : public exception {
- public:
- ...
- virtual ~failure();
- ...
- };
- }
-</pre>
-<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
-exception specification:</p>
-<pre>
- namespace std {
- class exception {
- public:
- ...
- virtual ~exception() throw();
- ...
- };
- }
-</pre>
-<p><b>Proposed resolution:</b></p>
-<p>Remove the declaration of ~failure().</p>
-<p><b>Rationale:</b></p>
-<p>The proposed resolution is consistent with the way that destructors
-of other classes derived from <tt>exception</tt> are handled.</p>
-<hr>
-<a name="335"><h3>335. minor issue with char_traits, table 37</h3></a><p>
-<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>
-<p>
-Table 37, in 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
-as:
-</p>
-<pre>
- X::assign(c,d) assigns c = d.
-</pre>
-
-<p>And para 1 says:</p>
-
-<blockquote>
- [...] c and d denote values of type CharT [...]
-</blockquote>
-
-<p>
-Naturally, if c and d are <i>values</i>, then the assignment is
-(effectively) meaningless. It's clearly intended that (in the case of
-assign, at least), 'c' is intended to be a reference type.
-</p>
-
-<p>I did a quick survey of the four implementations I happened to have
-lying around, and sure enough they all have signatures:</p>
-<pre>
- assign( charT&, const charT& );
-</pre>
-
-<p>(or the equivalent). It's also described this way in Nico's book.
-(Not to mention the synopses of char_traits<char> in 21.1.3.1
-and char_traits<wchar_t> in 21.1.3.2...)
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add the following to 21.1.1 para 1:</p>
-<blockquote>
- r denotes an lvalue of CharT
-</blockquote>
-
-<p>and change the description of assign in the table to:</p>
-<pre>
- X::assign(r,d) assigns r = d
-</pre>
-<hr>
-<a name="337"><h3>337. replace_copy_if's template parameter should be InputIterator</h3></a><p>
-<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>
-<p>From c++std-edit-876:</p>
-
-<p>
-In section 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
-parameter of template replace_copy_if should be "InputIterator"
-instead of "Iterator". According to 17.3.2.1 <a href="lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
-parameter name conveys real normative meaning.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
-<hr>
-<a name="345"><h3>345. type tm in <cwchar></h3></a><p>
-<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>
-<p>
-C99, and presumably amendment 1 to C90, specify that <wchar.h>
-declares 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
-<cwchar>. Is this omission intentional or accidental?
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>In section 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
-<hr>
-<a name="346"><h3>346. Some iterator member functions should be const</h3></a><p>
-<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>
-<p>Iterator member functions and operators that do not change the state
-of the iterator should be defined as const member functions or as
-functions that take iterators either by const reference or by
-value. The standard does not explicitly state which functions should
-be const. Since this a fairly common mistake, the following changes
-are suggested to make this explicit.</p>
-
-<p>The tables almost indicate constness properly through naming: r
-for non-const and a,b for const iterators. The following changes
-make this more explicit and also fix a couple problems.</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
-"In the following sections, a and b denote values of X..." to
-"In the following sections, a and b denote values of type const X...".</p>
-
-<p>In Table 73, change</p>
-<pre>
- a->m U& ...
-</pre>
-
-<p>to</p>
-
-<pre>
- a->m const U& ...
- r->m U& ...
-</pre>
-
-<p>In Table 73 expression column, change</p>
-
-<pre>
- *a = t
-</pre>
-
-<p>to</p>
-
-<pre>
- *r = t
-</pre>
-
-<p><i>[Redmond: The container requirements should be reviewed to see if
-the same problem appears there.]</i></p>
-
-<p>----- End of document -----</p>
-</body>
-</html>
projects / msp430-gcc.git / blobdiff