<table>
<tr>
<td align="left">Doc. no.</td>
-<td align="left">J16/01-0031 = WG21 N1317</td>
+<td align="left">J16/01-0052 = WG21 N1337</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">11 Sep 2001</td>
+<td align="left">09 Nov 2001</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Matt Austern <austern@research.att.com></td>
</tr>
</table>
-<h1>C++ Standard Library Active Issues List (Revision 19)</h1>
+<h1>C++ Standard Library Active Issues List (Revision 20)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
directory as the issues list files. </p>
<h2>Revision History</h2>
<ul>
+<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-active.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-active.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-active.html#335">335</a>.
</li>
<li>R18:
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-
active.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
-new issues <a href="lwg-
active.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
+Added new issues <a href="lwg-
defects.html#312">312</a>-<a href="lwg-active.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>
to DR.
Changed status of issues
-<a href="lwg-active.html#49">49</a> <a href="lwg-active.html#109">109</a> <a href="lwg-active.html#117">117</a> <a href="lwg-active.html#182">182</a>
-<a href="lwg-active.html#228">228</a> <a href="lwg-active.html#230">230</a> <a href="lwg-active.html#232">232</a> <a href="lwg-active.html#235">235</a>
-<a href="lwg-active.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-active.html#242">242</a> <a href="lwg-active.html#250">250</a>
-<a href="lwg-active.html#259">259</a> <a href="lwg-active.html#264">264</a> <a href="lwg-active.html#266">266</a> <a href="lwg-active.html#267">267</a>
-<a href="lwg-active.html#271">271</a> <a href="lwg-active.html#272">272</a> <a href="lwg-active.html#273">273</a> <a href="lwg-active.html#275">275</a>
-<a href="lwg-active.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-active.html#285">285</a> <a href="lwg-active.html#286">286</a>
-<a href="lwg-active.html#288">288</a> <a href="lwg-active.html#292">292</a> <a href="lwg-active.html#295">295</a> <a href="lwg-active.html#297">297</a>
-<a href="lwg-active.html#298">298</a> <a href="lwg-active.html#301">301</a> <a href="lwg-active.html#303">303</a> <a href="lwg-active.html#306">306</a>
-<a href="lwg-active.html#307">307</a> <a href="lwg-active.html#308">308</a> <a href="lwg-active.html#312">312</a>
+<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-active.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
</li>
<li>R17:
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="lwg-active.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#235">235</a>, <a href="lwg-active.html#250">250</a>, <a href="lwg-active.html#267">267</a>.
+resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-active.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-active.html#311">311</a>.
</li>
<li>R16:
</li>
<li>R15:
pre-Toronto mailing. Added issues
-<a href="lwg-active.html#233">233</a>-<a href="lwg-active.html#264">264</a>. Some small HTML formatting
+<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-active.html#228">228</a> to <a href="lwg-active.html#232">232</a>. (00-0019R1/N1242)
+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>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-
active.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
+<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:
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-active.html#109">109</a>
+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:
<ul>
<li>
- According to 22.2.2.1.2
+ According to 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
return an input error; otherwise a value is converted to the rules
of <tt>scanf</tt>.
</li>
</ul>
-<p>
-Now the proposed resolution results in not modifying the value passed
-as last argument if an overflow is encountered but <tt>failbit</tt>
-is set. Checking <tt>errno</tt> for <tt>ERANGE</tt> still allows for
-detection of an overflow but not what the sign was.
-</p>
-
-<p>
-Actually, my problem is not that much with the sign but this is at least
-making things worse... My problem is more that it is still necessary
-to check <tt>errno</tt> for the error description. Thus, I propose the
-following resolution:
-</p>
-
-<p>Change paragraph 11 from</p>
-
-<blockquote>
-<p>
-<b>-11-</b> <b>Stage 3:</b>
-The result of stage 2 processing can be one of</p>
+<p><b>Further discussion from Redmond:</b></p>
-<ul>
-<li>A sequence of <tt>char</tt>s
-has been accumulated in stage 2 that is converted (according to the
-rules of <tt>scanf)</tt> to a value of the type of <tt><i>val</i></tt>.
-This value is stored in <tt><i>val</i></tt> and
-<tt>ios_base::goodbit</tt> is stored in <tt><i>err</i></tt>.</li>
-
-<li>The sequence of <tt>char</tt>s
-accumulated in stage 2 would have caused scanf to report an input failure.
-<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</li>
-</ul>
-</blockquote>
+<p>The basic problem is that we've defined our behavior,
+including our error-reporting behavior, in terms of C90. However,
+C90's method of reporting overflow in scanf is not technically an
+"input error". The <tt>strto_*</tt> functions are more precise.</p>
-<p>to become</p>
+<p>There was general consensus that <tt>failbit</tt> should be set
+upon overflow. We considered three options based on this:</p>
+<ol>
+<li>Set failbit upon conversion error (including overflow), and
+ don't store any value.</li>
+<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
+ indicated the precise nature of the error.</li>
+<li>Set failbit upon conversion error. If the error was due to
+ overflow, store +-numeric_limits<T>::max() as an
+ overflow indication.</li>
+</ol>
-<blockquote>
-<p>
-<b>-11-</b> <b>Stage 3:</b>
-The result of stage 2 processing can be one of</p>
+<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
-<ul>
-<li>A sequence of <tt>char</tt>s
-has been accumulated in stage 2 that is converted (according to the
-rules of <tt>scanf)</tt> to a value of the type of <tt><i>val</i></tt>.
-This value is stored in <tt><i>val</i></tt>. If the conversion reported
-an overflow error for the type of <tt><i>val</i></tt> (ie.
-<tt><i>errno</i></tt> would be set to <tt>ERANGE</tt> by the used
-conversion function) then <tt>ios_base::failbit</tt> is stored in
-<tt><i>err</i></tt>, otherwise <tt>ios_base::goodbit</tt> is stored in
-<tt><i>err</i></tt>.</li>
-
-<li>The sequence of <tt>char</tt>s accumulated in stage 2 would have
-caused scanf to report an input failure. <tt>ios_base::failbit</tt>
-is assigned to <i>err</i>.</li>
-</ul>
-</blockquote>
+<p>PJP will provide wording.</p>
-<p>
-With this definition, overflow can be detected easily by storing a value
-different from the maximum value in <tt><i>val</i></tt> and checking whether
-this value was modified in case <tt>failbit</tt> is set: If it was, there
-was an overflow error, otherwise some other input error occurred (under the
-conditions for the second bullet <tt><i>val</i></tt> is not changed).
-</p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 , paragraph 11, second bullet item,
-change </p>
-
-<blockquote>
- <p>The sequence of chars accumulated in stage 2 would have caused scanf to report an input
- failure. </p>
-</blockquote>
-
-<p>to </p>
-
-<blockquote>
- <p>The sequence of chars accumulated in stage 2 would have caused scanf to report an input
- failure, or the value of the sequence cannot be represented in the type of _val_. </p>
-</blockquote>
-
-<p><i>[post-Toronto: "cannot be represented" is probably wrong:
-infinity can be represented on an IEC559 platform, but 0.1 cannot be
-represented exactly. However, the alternate proposal may be wrong as
-well. It's not clear whether overflow (and underflow?) should always
-be treated as errors. This issue requires much more thought]</i></p>
-
<hr>
<a name="44"><h3>44. Iostreams use operator== on int_type values</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#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
]</i></p>
<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#Ready">Ready</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
-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 ,
-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="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#Review">Review</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Sep 1998</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#Ready">Ready</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
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 ,
-paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 , paragraph 3) suggests that it must always be
+<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>
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 paragraph 2:</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 ) must have the property that if</p>
+(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 succeed (return value would be <tt>ok</tt>), where
-<tt>from != from_end</tt>, then
+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 succeed, and that if
+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 succeed, where <tt>to != to_lim</tt>, then
+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 succeed. [<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>
+<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
stream can't read anymore without reaching EOF. So shouldn't it be
changed into that it reads until !good() ? </p>
<p><b>Proposed resolution:</b></p>
-<p>In 21.3.7.9 , paragraph 1, replace:</p>
+<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
<blockquote>
Effects: Begins by constructing a sentry object k as if k were
constructed by typename basic_istream<charT,traits>::sentry k( is). If
</blockquote>
<p>with:</p>
<blockquote>
-Effects: Behaves as an unformatted input function (27.6.1.2 ). After constructing a sentry object, if the
+Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>). After constructing a sentry object, if the
sentry converts to true, calls str.erase() and then extracts
characters from is and appends them to str as if by calling
str.append(1,c). If is.width() is greater than zero, the maximum
following occurs:
</blockquote>
-<p>In 21.3.7.9 , paragraph 6, replace</p>
+<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
<blockquote>
Effects: Begins by constructing a sentry object k as if by typename
basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
</blockquote>
<p>with:</p>
<blockquote>
-Effects: Behaves as an unformatted input function (27.6.1.2 ). After constructing a sentry object, if the
-sentry converts to true, calls str.erase() and then extracts
-characters from is and appends them to str as if by calling
-str.append(1,c) until any of the following occurs:
+Effects: Behaves as an unformatted input function (27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
+by subsequent calls to basic_istream<>::gcount(). After
+constructing a sentry object, if the sentry converts to true, calls
+str.erase() and then extracts characters from is and appends them to
+str as if by calling str.append(1,c) until any of the following
+occurs:
</blockquote>
+<p><i>[Redmond: Made changes in proposed resolution. <tt>operator>></tt>
+should be a formatted input function, not an unformatted input function.
+<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
+there is no mechanism for <tt>gcount</tt> to be set except by one of
+<tt>basic_istream</tt>'s member functions.]</i></p>
+
<p><b>Rationale:</b></p>
<p>The real issue here is whether or not these string input functions
-perform formatted input. If they do, then they get their characters
-from a streambuf, rather than by calling an istream's member functions,
-and a streambuf signals failure either by returning eof or by throwing
-an exception. The proposed resolution makes it clear that these two
-functions do perform formatted input.</p>
+get their characters from a streambuf, rather than by calling an
+istream's member functions, a streambuf signals failure either by
+returning eof or by throwing an exception; there are no other
+possibilities. The proposed resolution makes it clear that these two
+functions do get characters from a streambuf.</p>
<hr>
<a name="92"><h3>92. Incomplete Algorithm Requirements</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#Open">Open</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p><i>[Kona: Nico will provide wording to the effect that "unless
otherwise specified, the number of copies of and calls to function
objects by algorithms is unspecified". Consider placing in
-25 after paragraph 9.]</i></p>
+25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
<p><i>[Pre-Tokyo: Angelika Langer comments: if the resolution is
that algorithms are free to copy and pass around any function objects,
<hr>
<a name="98"><h3>98. Input iterator requirements are badly written</h3></a><p>
<b>Section:</b> 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
-<p>Table 72 in 24.1.1 specifies semantics for
+<p>Table 72 in 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
<tt>*r++</tt> of:</p>
<p> <tt>{ T tmp = *r; ++r; return tmp; }</tt>
</p>
-<p>This does not work for pointers and over constrains implementors.</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add for *r++: “To call the copy constructor for the type T is
-allowed but not required.”</p>
-
-<p><i>[Dublin: Pete Becker will attempt improved wording.]</i></p>
-
-<p><i>[Tokyo: The essence of the issue seems to have escaped.
-Pete will email Valentin to try to recapture it.]</i></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#Ready">Ready</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>In 20.3.6.1 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 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>There are two problems with this. First, the return type is
+specified to be "T", as opposed to something like "convertible to T".
+This is too specific: we want to allow *r++ to return an lvalue.</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>
+<p>Second, writing the semantics in terms of code misleadingly
+suggests that the effects *r++ should precisely replicate the behavior
+of this code, including side effects. (What if it's a user-defined
+type whose copy constructor has observable behavior?) We should
+replace the code with words, or else put some blanket statement in
+clause 17 saying that code samples aren't intended to specify exactly
+how many times a copy constructor is called, even if the copy
+constructor has observable behavior. (See issue <a href="lwg-active.html#334">334</a>
+for a similar problem.)</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#Ready">Ready</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="120"><h3>120. Can an implementor add specializations?</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#Open">Open</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>Section 17.4.3.1 says: </p>
-
-<blockquote>
- <p>It is undefined for a C++ program to add declarations or definitions to namespace std
- or namespaces within namespace std unless otherwise specified. A program may add template
- specializations for any standard library template to namespace std. Such a specialization
- (complete or partial) of a standard library template results in undefined behavior unless
- the declaration depends on a user-defined name of external linkage and unless the
- specialization meets the standard library requirements for the original template... </p>
-</blockquote>
-
-<p>This implies that it is ok for library users to add specializations, but not
-implementors. A user program can actually detect this, for example, the following manual
-instantiation will not compile if the implementor has made ctype<wchar_t> a
-specialization: </p>
-
-<pre>
-#include <locale>
-#include <wchar.h>
-template class std::ctype<wchar_t>; // can't be specialization
-</pre>
-
-<p>
-Lib-7047 Matt Austern comments:
-</p>
-<blockquote>
-<p>The status quo is unclear, and probably contradictory. This issue
-applies both to explicit instantiations and to specializations, since
-it is not permitted to provide both a specialization and an explicit
-instantiation.
-</p>
-<p>
-The specialization issue is actually more serious than the
-instantiation one.
-</p>
-</blockquote>
+<p>The original issue asked whether a library implementor could
+specialize standard library templates for built-in types. (This was
+an issue because users are permitted to explicitly instantiate
+standard library templates.)</p>
-<p>In Copenhagen, core working group decided on a proposed resolution
+<p>Specializations are no longer a problem, because of the resolution
to core issue 259. Under the proposed resolution, it will be legal
for a translation unit to contain both a specialization and an
explicit instantiation of the same template, provided that the
instantiation will be ignored. Further discussion of library issue
120 assumes that the core 259 resolution will be adopted.</p>
+<p>However, as noted in lib-7047, one piece of this issue still
+remains: what happens if a standard library implementor explicitly
+instantiates a standard library templates? It's illegal for a program
+to contain two different explicit instantiations of the same template
+for the same type in two different translation units (ODR violation),
+and the core working group doesn't believe it is practical to relax
+that restriction.</p>
+
+<p>The issue, then, is: are users allowed to implicitly instantiate
+standard library templates for non-user defined types? The status quo
+answer is 'yes'. Changing it to 'no' would give library implementors
+more freedom.</p>
+
+<p>This is an issue because, for performance reasons, library
+implementors often need to explicitly instantiate standard library
+templates. (for example, std::basic_string<char>) Does giving
+users freedom to explicitly instantiate standard library templates for
+non-user defined types make it impossible or painfully difficult for
+library implementors to do this?</p>
+
+<p>John Spicer suggests, in lib-8957, that library implementors have a
+mechanism they can use for explicit instantiations that doesn't
+prevent users from performing their own explicit instantiations: put
+each explicit instantiation in its own object file. (Different
+solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On
+some platforms, library implementors might not need to do anything
+special: the "undefined behavior" that results from having two
+different explicit instantiations might be harmless.</p>
+
<p><b>Proposed resolution:</b></p>
<p>Option 1.</p>
<blockquote>
- <p>Append to 17.4.3.1 paragraph 1: </p>
+ <p>Append to 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
<blockquote>
A program may explicitly instantiate any templates in the standard
library only if the declaration depends on a user-defined name of
<blockquote>
<p>In light of the resolution to core issue 259, no normative changes
in the library clauses are necessary. Add the following non-normative
- note to the end of 17.4.3.1 paragraph 1:</p>
+ note to the end of 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
<blockquote>
[<i>Note:</i> A program may explicitly instantiate standard library
templates, even when an explicit instantiation does not depend on
specialize or instantiate templates. (B) It is implementation defined
whether users may explicitly instantiate standard library templates on
non-user-defined types. Consequence: library implementors may freely
-specialize or instantiate templates, but must document the templates
-they have explicitly instantiated. (C) Users may explicitly
-instantiate any standard library template. Consequence: library
-implementors may freely specialize templates, but may not explicitly
-instantiate them. This is a serious burden for implementors; one way
-they can manage it is by defining the standard template as a wrapper,
-and putting all of the real work in an internal helper class/function.
+specialize or instantiate templates, but may need to document some or
+all templates that have been explicitly instantiated. (C) Users may
+explicitly instantiate any standard library template.
]</i></p>
<p><i>[Straw poll (first number is favor, second is strongly oppose):
option A. (It is the original proposed resolution.) Proposed
resolution 2, above, is option C. Because there was no support
for option B, no wording is provided.]</i></p>
+
+<p><i>[Redmond: discussed again; straw poll had results similar to
+those of Copenhagen (A - 1, 3; B - 6, 2; C - 8, 4). Most people said
+they could live with any option. The only objection to option A is
+potential implementation difficulty. Steve Clamage volunteered do a
+survey to see if there are any popular platforms where option A would
+present a real problem for implementors. See his reflector message,
+c++std-lib-9002.
+]</i></p>
+
<hr>
<a name="123"><h3>123. Should valarray helper arrays fill functions be const?</h3></a><p>
-<b>Section:</b> 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p>
+<b>Section:</b> 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p>
<p>One of the operator= in the valarray helper arrays is const and one
is not. For example, look at slice_array. This operator= in Section
-26.3.5.2 is const: </p>
+26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
<p> <tt>void operator=(const valarray<T>&) const;</tt> </p>
-<p>but this one in Section 26.3.5.4 is not: </p>
+<p>but this one in Section 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
<p> <tt>void operator=(const T&); </tt>
</p>
<p>The description of the semantics for these two functions is similar. </p>
<p><b>Proposed resolution:</b></p>
-<p>Make the <tt>operator=(const T&)</tt> versions of slice_array, gslice_array,
-indirect_array, and mask_array <tt>const</tt> member functions. </p>
-
-<p><i>[Dublin: Pete Becker spoke to Daveed Vandevoorde about this and will work on a
-proposed resolution.]</i></p>
-
-<p><i>[Tokyo: Discussed together with the AFNOR paper
-00-0023/N1246. The current helper slices now violate language rules
-due to a core language change (but most compilers don't check, so the
-violation has previously gone undetected). Major surgery is being
-asked for in this and other valarray proposals (see issue <a href="lwg-closed.html#77">77</a>Rationale), and a complete design review is needed before
-making piecemeal changes. Robert Klarer will work on formulating the
-issues.]</i></p>
+
+<p>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
+<blockquote>
+
+ <p>In the class template definition for slice_array, replace the member
+ function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>with</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
+<blockquote>
+
+ <p>Change the function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>to</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
+<blockquote>
+
+ <p>In the class template definition for gslice_array, replace the member
+ function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>with</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
+<blockquote>
+
+ <p>Change the function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>to</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
+<blockquote>
+
+ <p>In the class template definition for mask_array, replace the member
+ function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>with</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
+<blockquote>
+
+ <p>Change the function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>to</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
+<blockquote>
+
+ <p>In the class template definition for indirect_array, replace the member
+ function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>with</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+<p>26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
+<blockquote>
+
+ <p>Change the function declaration</p>
+ <pre>
+ void operator=(const T&);
+ </pre>
+ <p>to</p>
+ <pre>
+ void operator=(const T&) const;
+ </pre>
+</blockquote>
+
+
+<p><i>[Redmond: Robert provided wording.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>There's no good reason for one version of operator= being const and
+another one not. Because of issue <a href="lwg-active.html#253">253</a>, this now
+matters: these functions are now callable in more circumstances. In
+many existing implementations, both versions are already const.</p>
<hr>
<a name="167"><h3>167. Improper use of <tt>traits_type::length()</tt>
</h3></a><p>
-<b>Section:</b> 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>Paragraph 4 states that the length is determined using
<tt>traits::length(s)</tt>. Unfortunately, this function is not
defined for example if the character type is <tt>wchar_t</tt> and the
either <tt>signed char const*</tt> or <tt>unsigned char
const*</tt>.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.2.5.4 paragraph 4 from:</p>
+<p>Change 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
<blockquote>
<p>Effects: Behaves like an formatted inserter (as described in
lib.ostream.formatted.reqmts) of out. After a sentry object is
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In section 23.1 after paragraph 7 add:</p>
+<p>Insert this paragraph after 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
<blockquote>
- <p>It is possible to mix <tt>iterator</tt>s and
- <tt>const_iterator</tt>s in iterator comparison and
- iterator difference operations.</p>
+ <p>In the expressions</p>
+ <pre>
+ i == j
+ i != j
+ i < j
+ i <= j
+ i >= j
+ i > j
+ i - j
+ </pre>
+ <p>Where i and j denote objects of a container's iterator type,
+ either or both may be replaced by an object of the container's
+ const_iterator type referring to the same element with no
+ change in semantics.</p>
</blockquote>
-<p><i>[Post-Tokyo: Judy supplied the above wording at the request of
-the LWG.]</i></p>
-
-<p><i>[post-Toronto: Judy supplied a new proposed resolution. The old
-version did not include the words "and iterator
-difference".]</i></p>
+<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
+<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
+iterator comparison and difference operations.]</i></p>
-<p><i>[Copenhagen: There was some concern that "it is possible
-to mix" might be too informal. Howard and Dave will provide new
-wording, which will involve a list of expressions that are
-guaranteed to be valid.]</i></p>
+<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
+explicitly listed expressions; there was concern that the previous
+proposed resolution was too informal.]</i></p>
<p><b>Rationale:</b></p>
<p>
The LWG believes it is clear that the above wording applies only to
separate issue. (Issue <a href="lwg-active.html#280">280</a>.)
</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#Ready">Ready</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 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 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 ,</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="187"><h3>187. iter_swap underspecified</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#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Aug 1999</p>
<p>The description of iter_swap in 25.2.2 paragraph 7,says that it ``exchanges the values''
sense for iter_swap to do something other than swap. If performance
is a concern, it may be better to have explicit complexity
requirements than to say how iter_swap should be implemented.]</i></p>
+
+<p><i>[Redmond: Discussed, with no consensus. There was very little
+support for the proposed resolution. Some people favored closing this
+issue as NAD. Others favored a more complicated specification of
+<tt>iter_swap</tt>, which might distinguish between ordinary iterators
+and proxies. A possible new issue: how do we know that the iterators
+passed to <tt>iter_swap</tt> have Assignable value types? (If this
+new issue is real, it extends far beyond just
+<tt>iter_swap</tt>.)]</i></p>
+
<hr>
<a name="197"><h3>197. max_size() underspecified</h3></a><p>
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Oct 1999</p>
obviously, has to be determined dynamically each time max_size() is
called. </p>
<p><b>Proposed resolution:</b></p>
-<p>Change 20.1.5 table 32 max_size() wording from:<br>
+<p>Change 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br>
<br>
the largest value that can meaningfully be
passed to X::allocate<br>
to:<br>
the value of the largest constant expression
-(5.19 ) that could ever meaningfully be passed to X::allocate</p>
+(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p>
<p>
-Change 23.1 table 65 max_size() wording from:<br>
+Change 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br>
<br>
size() of the largest possible container.<br>
to:<br>
the value of the largest constant expression
-(5.19 ) that could ever meaningfully be returned by X::size().
+(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size().
</p>
<p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit
<p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p>
<p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the
-request of the LWG. 21.3.3 was not changed because it
+request of the LWG. 21.3.3 <a href="lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it
references max_size() in 23.1. The term "compile-time" was
avoided because it is not defined anywhere in the standard (even
though it is used several places in the library clauses).]</i></p>
Nathan will provide new wording.]</i></p>
<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#Review">Review</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Nov 1999</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#Ready">Ready</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>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 , which returns a reference, defines
+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 , which returns a pointer, defines effects:</p>
+<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>
unexpectedly when porting to a different standard library
implementation.</p>
<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph to 24.1 :</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 with:</p>
+<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>
[<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 .) The name of this member variable is shown for
+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>[Tokyo: The LWG reformulated the question purely in terms of
-iterators. The answer to the question is "no, pointers and references
-don't remain valid after iterator destruction." PJP explained that
-implementors use considerable care to avoid such ephemeral pointers and
-references. Several LWG members said that they thought that the standard
-did not actually specify the lifetime of pointers and references obtained from
-iterators, except possibly input iterators.]</i></p>
-
<p><i>[Post-Tokyo: The issue has been reformulated purely
in terms of iterators.]</i></p>
assumption by reverse_iterator. The issue and proposed resolution was
reformulated yet again to reflect this reality.]</i></p>
-<p><i>[Copenhagen: Andy Koenig pointed out that it is possible to
-rewrite reverse_iterator so that it no longer makes this assumption.
+<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, then
+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="200"><h3>200. Forward iterator requirements don't allow constant iterators</h3></a><p>
-<b>Section:</b> 24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
+<b>Section:</b> 24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
<p>
In table 74, the return type of the expression <tt>*a</tt> is given
as <tt>T&</tt>, where <tt>T</tt> is the iterator's value type.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-In table 74, change the <b>return type</b> column for <tt>*a</tt>
-from "<tt>T&</tt>" to "<tt>T&</tt> if
-<tt>X</tt> is mutable, otherwise <tt>const T&</tt>".
+In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
+return type from "<tt>T&</tt>" to "<tt>T&</tt>
+if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>".
+In the <tt>a->m</tt> row, change the return type from
+"<tt>U&</tt>" to "<tt>U&</tt> if <tt>X</tt> is mutable,
+otherwise <tt>const U&</tt>".
</p>
<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
and that these should be addressed as a single package. Note
that issue <a href="lwg-closed.html#180">180</a> has already been declared NAD Future for
that very reason.]</i></p>
+
+<p><i>[Redmond: the LWG thinks this is separable from other constness
+issues. This issue is just cleanup; it clarifies language that was
+written before we had iterator_traits. Proposed resolution was
+modified: the original version only discussed *a. It was pointed out
+that we also need to worry about *r++ and a->m.]</i></p>
+
<hr>
<a name="201"><h3>201. Numeric limits terminology wrong</h3></a><p>
<b>Section:</b> 18.2.1 <a href="lib-support.html#lib.limits"> [lib.limits]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 21 Dec 1999</p>
review of numeric_limits is needed. A paper would be welcome.]</i></p>
<hr>
<a name="202"><h3>202. unique() effects unclear when predicate not an equivalence relation</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#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 13 Jan 2000</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#Review">Review</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 13 Jan 2000</p>
<p>
What should unique() do if you give it a predicate that is not an
equivalence relation? There are at least two plausible answers:
3, 7.
</p>
<p><b>Proposed resolution:</b></p>
-<p>Options:</p>
-<blockquote>
- <p> 1. Impose an explicit requirement that the predicate be an
- equivalence relation. </p>
- <p> 2. Drop the word "equal" from the description to make it clear that
- the intent is to compare pairs of adjacent elements, and
- change pred(*i, *(i - 1)) to pred(*(i - 1), i).</p>
- <p> 3. Change the effects to:</p>
- <blockquote>
- Effects: Eliminates all but the first element e from
- every consecutive group of elements referred to by the
- iterator i in the range [first, last) for which the
- following corresponding conditions hold: e == *i or
- pred(e,*i) != false.
- </blockquote>
-</blockquote>
-<p>A LWG member, Nico Josuttis, comments:</p>
-<p>First, I agree that the current wording is simply wrong. However, to follow
-all [known] current implementations I propose [option 3 above].</p>
-
-<p><i>[ Tokyo: The issue was discussed at length without reaching
-consensus. Straw vote: Option 1 - preferred by 2 people. Option 2 -
-preferred by 0 people. Option 3 - preferred by 3 people. Many
-abstentions. ]</i></p>
-
-<p><i>[Copenhagen: There was some support for all options. The option
-with the least support was 1 (one person in favor), and the option
-with the most support was 2 (seven in favor). One person was strongly
-opposed to option 1, and one person was strongly opposed to the
-variation on option 2 in which the order of arguments would remain
-pred(*i, *(i - 1)).]</i></p>
+<p>Change 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
+<blockquote>
+For a nonempty range, eliminates all but the first element from every
+consecutive group of equivalent elements referred to by the iterator
+<tt>i</tt> in the range (first, last) for which the following
+conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
+false</tt>.
+</blockquote>
+
+<p>
+Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
+comparison function must be an equivalence relation."
+</p>
+
+<p><i>[Redmond: discussed arguments for and against requiring the
+comparison function to be an equivalence relation. Straw poll:
+14-2-5. First number is to require that it be an equivalence
+relation, second number is to explicitly not require that it be an
+equivalence relation, third number is people who believe they need
+more time to consider the issue. A separate issue: Andy Sawyer
+pointed out that "i-1" is incorrect, since "i" can refer to the first
+iterator in the range. Matt provided wording to address this
+problem.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>The LWG also considered an alternative resolution: change
+25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
+
+<blockquote>
+For a nonempty range, eliminates all but the first element from every
+consecutive group of elements referred to by the iterator
+<tt>i</tt> in the range (first, last) for which the following
+conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
+false</tt>.
+</blockquote>
+
+<p>
+Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
+comparison function need not be an equivalence relation."
+</p>
+
+
+<p>Informally: the proposed resolution imposes an explicit requirement
+that the comparison function be an equivalence relation. The
+alternative resolution does not, and it gives enough information so
+that the behavior of unique() for a non-equivalence relation is
+specified. Both resolutions are consistent with the behavior of
+existing implementations.</p>
<hr>
<a name="225"><h3>225. std:: algorithms use of other unqualified algorithms</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#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
</p>
<p><b>Proposed resolution:</b></p>
<p>Add a paragraph and a note at the end of
-17.4.4.3 :</p>
+17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
<blockquote>
<p>Unless otherwise specified, no global or non-member function in the
standard library shall use a function from another namespace which is
-found through <i>argument-dependent name lookup</i> (3.4.2 ).</p>
+found through <i>argument-dependent name lookup</i> (3.4.2 <a href="basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
<p>[Note: the phrase "unless otherwise specified" is intended to
allow Koenig lookup in cases like that of ostream_iterators:<br>
option had both support and opposition. Straw poll (first number is
support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
(4) 4, 4.]</i></p>
-<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#Ready">Ready</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p>
-<p>The sections 22.2.1.2 , 22.2.1.4 ,
-22.2.1.6 , 22.2.3.2 , 22.2.4.2 , 22.2.5.4 , 22.2.6.4 , and 22.2.7.2 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 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>
+<p><i>[Redmond: Discussed, again no consensus. Herb presented an
+argument that a user who is defining a type <tt>T</tt> with an
+associated <tt>swap</tt> should not be expected to put that
+<tt>swap</tt> in namespace std, either by overloading or by partial
+specialization. The argument is that <tt>swap</tt> is part of
+<tt>T</tt>'s interface, and thus should to in the same namespace as
+<tt>T</tt> and only in that namespace. If we accept this argument,
+the consequence is that standard library functions should use
+unqualified call of <tt>swap</tt>. (And which other functions? Any?)
+A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
+try to put together a proposal before the next meeting.]</i></p>
<hr>
<a name="229"><h3>229. Unqualified references of other library entities</h3></a><p>
"::std::" throughout, too many lines in the standard would have to be
adjusted to make that change in a Technical Corrigendum.</p>
-<p>Issue <a href="lwg-active.html#182">182</a>, which addresses qualification of
+<p>Issue <a href="lwg-defects.html#182">182</a>, which addresses qualification of
<tt>size_t</tt>, is a special case of this.
</p>
<p><b>Proposed resolution:</b></p>
but that the wording may not be clear enough to fall under
"unless explicitly described otherwise".]</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#Ready">Ready</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 .</p>
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1 table 65 for value_type:
-change "T is Assignable" to "T is CopyConstructible and
-Assignable"
-</p>
-
-<p>In 23.1.2 table 69 X::key_type; change
-"Key is Assignable" to "Key is
-CopyConstructible and Assignable"<br>
-</p>
-
-<p>In 24.1.2 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 and 25.2.5 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="231"><h3>231. Precision in iostream?</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#Review">Review</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</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#Ready">Ready</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</p>
<p>What is the following program supposed to output?</p>
<pre>#include <iostream>
{
std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
std::cout.precision( 0 ) ;
- std::cout << 1.23 << '\n' ;
+ std::cout << 1.00 << '\n' ;
return 0 ;
}</pre>
<p>From my C experience, I would expect "1e+00"; this is what
-<tt>printf("%.0e" , 1.23 );</tt> does. G++ outputs
+<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
"1.000000e+00".</p>
<p>The only indication I can find in the standard is 22.2.2.2.2/11,
of the anomalies of printf:-).</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 22.2.2.2.2 , paragraph 11, change
+In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, change
"if <tt>(flags & fixed) != 0</tt>" to
"if <tt>(flags & floatfield) == fixed ||
(flags & floatfield) == scientific</tt>"
<p>The proposed resolution has the effect that the output of
the above program will be "1e+00".</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#Ready">Ready</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="233"><h3>233. Insertion hints in associative containers</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#Review">Review</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Apr 2000</p>
<p>
can supply <tt>p</tt>, and the implementation is allowed to
disregard it entirely.
</p>
-<p><b>Proposed resolution:</b></p>
<p>
-General Idea (Andrew Koenig):
-t is inserted at the point closest to (the point immediately
-ahead of) p. That would give the user a way of controlling the order
-in which elements appear that have equal keys. Doing so would be
-particularly easy in two cases that I suspect are common:
-</p>
-<pre>
- mm.insert(mm.begin(), t); // inserts as first element of set of equal keys
- mm.insert(mm.end(), t); // inserts as last element of set of equal keys
-</pre>
+<b>Additional comments from Nathan:</b><br>
-<p>
-These examples would allow t to be inserted at the beginning and end,
-respectively, of the set of elements with the same key as t.
+The vote [in Redmond] was on whether to elaborately specify the use of
+the hint, or to require behavior only if the value could be inserted
+adjacent to the hint. I would like to ensure that we have a chance to
+vote for a deterministic treatment: "before, if possible, otherwise
+after, otherwise anywhere appropriate", as an alternative to the
+proposed "before or after, if possible, otherwise [...]".
</p>
-<p>
-assertion/note/pre/postcondition in table 69<br>
-Change:
-</p>
+
+<p><b>Proposed resolution:</b></p>
+
+<p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
+change</p>
+
<blockquote>
-iterator p is a hint pointing to where the insert should start to search.
+iterator p is a hint pointing to where the insert
+should start to search.
</blockquote>
-<p>To:</p>
+
+<p>to</p>
+
<blockquote>
-if t is inserted, p is used as follows: insert t right before p
-if possible; otherwise, if p is equal to a.end(), or if the key value
-of t is greater than the key value of *p, t is inserted just before
-a.lowerbound(the key value of t); otherwise, t is inserted right
-before a.upperbound(the key value of t).
+insertion adjacent to iterator p is preferred if
+more than one insertion point is valid.
</blockquote>
-<p>complexity:<br>
-Change:</p>
-<blockquote>right after p</blockquote>
-<p>To:</p>
-<blockquote>right before p</blockquote>
-
-<p>
-Thus making:<br>
-assertion/note/pre/postcondition:
-</p>
-<blockquote>
-inserts t if and only if there is no element with key equivalent to
-the key of t in containers with unique keys; always inserts t in
-containers with equivalent keys. always returns the iterator pointing
-to the element with key equivalent to the key of t.
-if t is inserted, p is used as follows: insert t right before p
-if possible; otherwise, if p is equal to a.end(), or if the key value
-of t is greater than the key value of *p, t is inserted just before
-a.lowerbound(the key value of t); otherwise, t is inserted right
-before a.upperbound(the key value of t).
-<br>NON-NORMATIVE FOOTNOTE:
-| This gives the user a way of controlling the order
-| in which elements appear that have equal keys. Doing this is
-| particularly easy in two common cases:
-<pre>
-| mm.insert(mm.begin(), t); // inserts as first element of set of equal keys
-| mm.insert(mm.end(), t); // inserts as last element of set of equal keys
-</pre>
-<br>END-FOOTNOTE
+
+<p>and change</p>
+
+<blockquote>
+logarithmic in general, but amortized constant if
+t is inserted right after p.
</blockquote>
-<p>complexity:</p>
+<p>to</p>
+
<blockquote>
-logarithmic in general, but amortized constant if t is inserted right
-before p.
+logarithmic in general, but amortized constant if
+t is inserted adjacent to iterator p.
</blockquote>
<p><i>[Toronto: there was general agreement that this is a real defect:
implementation showing that it is possible to implement this
requirement without loss of efficiency.]</i></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#Ready">Ready</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 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="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#Ready">Ready</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><i>[Redmond: The LWG was reluctant to adopt the proposal that
+emerged from Copenhagen: it seemed excessively complicated, and went
+beyond fixing the defect that we identified in Toronto. PJP provided
+the new wording described in this issue. Nathan agrees that we
+shouldn't adopt the more detailed semantics, and notes: "we know that
+you can do it efficiently enough with a red-black tree, but there are
+other (perhaps better) balanced tree techniques that might differ
+enough to make the detailed semantics hard to satisfy."]</i></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#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</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#Review">Review</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>
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 to:</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: Exactly last - first - 1 applications of the
-corresponding predicate.</blockquote>
+<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
+applications of the corresponding predicate.</blockquote>
-<p><i>[Toronto: This is related to issue <a href="lwg-active.html#202">202</a>. We can't
-specify <tt>unique</tt>'s complexity until we decide what
-<tt>unique</tt> is supposed to do.]</i></p>
<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#Review">Review</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</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#Ready">Ready</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
<p>The complexity section of adjacent_find is defective:</p>
<blockquote>
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 to:</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
<hr>
<a name="241"><h3>241. Does unique_copy() require CopyConstructible and Assignable?</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#Ready">Ready</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</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#Review">Review</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
<p>Some popular implementations of unique_copy() create temporary
copies of values in the input sequence, at least if the input iterator
specify any additional requirements that they impose on any of the
types used by the algorithm. An example of an algorithm that creates
temporary copies and correctly specifies the additional requirements
-is accumulate(), 26.4.1 .</p>
+is accumulate(), 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
<p>Since the specifications of unique() and unique_copy() do not
require CopyConstructible and Assignable of the InputIterator's value
<p>to:</p>
<blockquote>
--4- Requires: The ranges [first, last) and [result, result+(last-first))
-shall not overlap. The expression *result = *first is valid.
-</blockquote>
-<p><b>Rationale:</b></p>
-<p>
-Creating temporary copies is unavoidable, since the arguments may be
-input iterators; this implies that the value type must be copy
-constructible. However, we don't need to say this explicitly; it's
-already implied by table 72 in 24.1.1. We don't precisely want to say
-that the input iterator's value type <tt>T</tt> must be assignable,
-because we never quite use that property. We assign through the
-output iterator. The output iterator might have a different value
-type, or no value type; it might not use <tt>T</tt>'s assignment
-operator. If it's an <tt>ostream_iterator</tt>, for example, then
-we'll use <tt>T</tt>'s operator<< but not its assignment
-operator.
-</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#Ready">Ready</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 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]
+-4- Requires: The ranges [first, last) and [result, result+(last-first))
+shall not overlap. The expression *result = *first must be valid. If
+both InputIterator and OutputIterator do not meet the requirements of
+forward iterator then the value type of InputIterator must be copy
+constructible. Otherwise copy constructible is not required.
</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>
+<p><i>[Redmond: the original proposed resolution didn't impose an
+explicit requirement that the iterator's value type must be copy
+constructible, on the grounds that an input iterator's value type must
+always be copy constructible. Not everyone in the LWG thought that
+this requirement was clear from table 72. It has been suggested that
+it might be possible to implement <tt>unique_copy</tt> without
+requiring assignability, although current implementations do impose
+that requirement. Howard provided new wording.]</i></p>
<hr>
<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p>
<p>I looked to see if <tt>deque</tt> had a similar problem, and was
surprised to find that <tt>deque</tt> places no requirement on the
-complexity of inserting multiple elements (23.2.1.3 ,
+complexity of inserting multiple elements (23.2.1.3 <a href="lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
paragraph 3):</p>
<blockquote>
complicated than a while loop whose body is a single-element
insert.]</i></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#Ready">Ready</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 , paragraph 1:</p>
-<blockquote>
-[<i>Footnote:</i> As specified in 20.1.5 , 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 , 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 , 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 , 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 paragraph 4, the behavior of list when
-allocators compare nonequal is outside the scope of the standard.</p>
-<hr>
<a name="253"><h3>253. valarray helper functions are almost entirely useless</h3></a><p>
-<b>Section:</b> 26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p>
+<b>Section:</b> 26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p>
<p>This discussion is adapted from message c++std-lib-7056 posted
November 11, 1999. I don't think that anyone can reasonably claim
that the problem described below is NAD.</p>
Furthermore, since these functions cannot be called, the valarray helper
classes are almost entirely useless.</p>
<p><b>Proposed resolution:</b></p>
-<p>
-Adopt section 2 of 00-0023/N1246. Sections 1 and 5 of that paper have
-already been classified as "Request for Extension". Sections
-3 and 4 are reasonable generalizations of section 2, but they do not
-resolve an obvious inconsistency in the standard.
-</p>
+<p>slice_array:</p>
+<ul>
+<li> remove the copy constructor and copy-assignment operator declarations
+ from the slice_array class template definition in 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
+<li> remove paragraph 3 of 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
+</li>
+<li> remove the copy constructor declaration from 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
+</li>
+<li> change paragraph 1 of 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared
+ to be private. This constructor need not be defined."</li>
+<li> remove the copy-assignment operator declaration from 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
+</li>
+<li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
+</li>
+<li> Change the first two words of the second sentence of paragraph 1 of
+ 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "This function."</li>
+</ul>
+
+<p>gslice_array:</p>
+<ul>
+<li> remove the copy constructor and copy-assignment operator declarations
+ from the gslice_array class template definition in 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
+<li> remove the note in paragraph 3 of 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
+</li>
+<li> remove the copy constructor declaration from 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
+</li>
+<li> change paragraph 1 of 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared
+ to be private. This constructor need not be defined."</li>
+<li> remove the copy-assignment operator declaration from 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
+</li>
+<li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
+</li>
+<li> Change the first two words of the second sentence of paragraph 1 of
+ 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "This function."</li>
+</ul>
+
+<p>mask_array:</p>
+<ul>
+<li> remove the copy constructor and copy-assignment operator declarations
+ from the mask_array class template definition in 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
+<li> remove the note in paragraph 2 of 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
+</li>
+<li> remove the copy constructor declaration from 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
+</li>
+<li> change paragraph 1 of 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared
+ to be private. This constructor need not be defined."</li>
+<li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
+</li>
+<li> Change the first two words of the second sentence of paragraph 1 of
+ 26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "This function."</li>
+</ul>
-<p><i>[Toronto: it is agreed that there is a defect. A full
-discussion, and an attempt at fixing the defect, should wait until we
-can hear from valarray experts.]</i></p>
+<p>indirect_array:</p>
+<ul>
+<li>remove the copy constructor and copy-assignment operator declarations
+ from the indirect_array class definition in 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
+</li>
+<li> remove the note in paragraph 2 of 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
+</li>
+<li> remove the copy constructor declaration from 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
+</li>
+<li> change the descriptive text in 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is
+ declared to be private. This constructor need not be defined."</li>
+<li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
+</li>
+<li> Change the first two words of the second sentence of paragraph 1 of
+ 26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "This function."</li>
+</ul>
+<p><i>[This wording is taken from Robert Klarer's reflector message,
+c++std-lib-7827. Gabriel Dos Reis agrees that this general solution
+is correct.]</i></p>
+<p><b>Rationale:</b></p>
+<p>Keeping the valarray constructors private is untenable. Merely
+making valarray a friend of the helper classes isn't good enough,
+because access to the copy constructor is checked in the user's
+environment.</p>
+
+<p>Making the assignment operator public is not strictly necessary to
+solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i>
+believed we should make the assignment operators public, in addition
+to the copy constructors, for reasons of symmetry and user
+expectation.</p>
<hr>
<a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt>
</h3></a><p>
would do.
</p>
-<p>
-Further discussion, in email:
-</p>
+<p><b>Further discussion, in email:</b></p>
<p>
...I'm not so concerned about (1). After all, a library implementation
For all values of what_arg (i.e. very long values). That means that
the only truly conforming solution requires a dynamic allocation.
</p>
+
+<p><b>Further discussion, from Redmond:</b></p>
+
+<p>The most important progress we made at the Redmond meeting was
+realizing that there are two separable issues here: the const
+string& constructor, and the copy constructor. If a user writes
+something like <tt>throw std::out_of_range("foo")</tt>, the const
+string& constructor is invoked before anything gets thrown. The
+copy constructor is potentially invoked during stack unwinding.</p>
+
+<p>The copy constructor is a more serious problem, becuase failure
+during stack unwinding invokes <tt>terminate</tt>. The copy
+constructor must be nothrow.</p>
+
+<p>The fundamental problem is that it's difficult to get the nothrow
+requirement to work well with the requirement that the exception
+objects store a string of unbounded size, particularly if you also try
+to make the const string& constructor nothrow. Options discussed
+include:</p>
+
+<ul>
+<li>Limit the size of a string that exception objects are required to
+throw: change the postconditions of 19.1.2 <a href="lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
+and 19.1.6 <a href="lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
+"strncmp(what(), what_arg._str(), N) == 0, where N is an
+implementation defined constant no smaller than 256".</li>
+<li>Allow the const string& constructor to throw, but not the
+copy constructor. It's the implementor's responsibility to get it
+right. (An implementor might use a simple refcount class.)</li>
+<li>Compromise between the two: an implementation is not allowed to
+throw if the string's length is less than some N, but, if it doesn't
+throw, the string must compare equal to the argument.</li>
+<li>Add a new constructor that takes a const char*</li>
+</ul>
+
+<p>(Not all of these options are mutually exclusive.)</p>
+
<p><b>Proposed resolution:</b></p>
<p><i>[Toronto: some LWG members thought this was merely a QoI issue,
but most believed that it was at least a borderline defect. There was
more support for nonnormative advice to implementors than for a
normative change.]</i></p>
+
+<p><i>[Redmond: discussed, without definite conclusion. Most LWG
+members thought there was a real defect lurking here. A small group
+(Herb, Kevlin, Howard, Martin, Dave) will try to make a
+recommendation.]</i></p>
+
<hr>
<a name="258"><h3>258. Missing 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#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Aug 2000</p>
desired property. This issue should be considered in light of
other issues related to allocator instances.]</i></p>
<hr>
-<a name="2
59"><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#Ready">Ready</a> <b>Submitter:</b> Chris Newton <b>Date:</b> 27 Aug 2000</p>
+<a name="2
70"><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#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Oct 2000</p>
<p>
-<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
+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>
-The standard's description of <tt>basic_string<>::operator[]</tt>
-seems to violate const correctness.
+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>
-
-<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="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#Ready">Ready</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="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#Ready">Ready</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 ),
-<tt>bad_cast</tt> (18.5.2 ),
-<tt>bad_typeid</tt> (18.5.3 ),
-and <tt>bad_exception</tt> (18.6.2.1 ).
-</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="267"><h3>267. interaction of strstreambuf::overflow() and seekoff()</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#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
-<p>
-It appears that the interaction of the strstreambuf members overflow()
-and seekoff() can lead to undefined behavior in cases where defined
-behavior could reasonably be expected. The following program
-demonstrates this behavior:
-</p>
-
-<pre>
- #include <strstream>
-
- int main ()
- {
- std::strstreambuf sb;
- sb.sputc ('c');
-
- sb.pubseekoff (-1, std::ios::end, std::ios::in);
- return !('c' == sb.sgetc ());
- }
-</pre>
-
-<p>
-D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(),
-which in turn sets all pointers to 0 in 27.5.2.1, p1.
-</p>
-
-<p>
-27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls
-overflow(traits::to_int_type(c)) if a write position isn't available (it
-isn't due to the above).
-</p>
-
-<p>
-D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
-least one write position available (i.e., it allows the function to make
-any positive number of write positions available).
-</p>
-
-<p>
-D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
-seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
-case. newoff is then epptr() - eback().
-</p>
-
-<p>
-D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
-gptr() == epptr() + off holds.
-</p>
-
-<p>
-If strstreambuf::overflow() made exactly one write position available
-then gptr() will be set to just before epptr(), and the program will
-return 0. Buf if the function made more than one write position
-available, epptr() and gptr() will both point past pptr() and the
-behavior of the program is undefined.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-
- <p>Change the last sentence of D.7.1 paragraph 4 from</p>
-
- <blockquote>
- Otherwise, seeklow equals gbeg and seekhigh is either pend, if
- pend is not a null pointer, or gend.
- </blockquote>
-
- <p>to become</p>
-
- <blockquote>
- Otherwise, seeklow equals gbeg and seekhigh is either gend if
- 0 == pptr(), or pbase() + max where max is the maximum value of
- pptr() - pbase() ever reached for this stream.
- </blockquote>
-
-<p><i>[
- pre-Copenhagen: Dietmar provided wording for proposed resolution.
-]</i></p>
-
-<p><i>[
- post-Copenhagen: Fixed a typo: proposed resolution said to fix
- 4.7.1, not D.7.1.
-]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>Note that this proposed resolution does not require an increase in
-the layout of strstreambuf to maintain max: If overflow() is
-implemented to make exactly one write position available, max ==
-epptr() - pbase() always holds. However, if overflow() makes more than
-one write position available, the number of additional character (or
-some equivalent) has to be stored somewhere.</p>
-<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#Review">Review</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;
- }
- }
+<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>
<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 not described in lib.alg.binary.search
- (25.3.3) to work correctly, comp has to induce a strict weak
- ordering on the values.
+ 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 a non-negative integer n such that
+ 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>
<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).
-</blockquote>
-
-<p>
-Optionally add the following to the end of the proposed text above,
-which allows library implementors to make a small optimization at the
-cost of slightly complexifying the standard text. The idea is that we
-want to ensure that the partition point which defines the upper_bound
-is no earlier in the sequence than the partion point which defines the
-lower_bound, so that the implementor can do one of the searches over a
-subrange:
-</p>
-
-<blockquote>
- Also, for all elements e of [first, last), e < value implies
- !(value < e) or comp(e, value) implies !comp(value, e)
+ 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>Note also that if we don't add the above, the result of
-equal_range() might be an invalid range.</p>
-
-
<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
<blockquote>
upper_bound(first, last, value, comp))
</pre>
-<p>
-Note that the original text did not say whether the first element of
-the return value was the beginning or end of the range, or something
-else altogether. The proposed text is both more precise and general
-enough to accomodate heterogeneous comparisons.
-</p>
-
<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
<blockquote>
!comp(value, e)
</blockquote>
-<p><i>[Dave Abrahams provided this wording]</i></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#Ready">Ready</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 , immediately after <tt>public</tt>:</p>
+<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></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#Ready">Ready</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><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>
-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#Ready">Ready</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>
+<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="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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</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#Ready">Ready</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
<p>to</p>
<blockquote>
- any non-const, non-volatile, non-reference type
+ 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
also forbids volatile types and reference types.
</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#Ready">Ready</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 , 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#Review">Review</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 07 Nov 2000</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#Ready">Ready</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 , paragraph 2,
+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.
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="278"><h3>278. What does iterator validity mean?</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#Review">Review</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 27 Nov 2000</p>
</p>
<p>
-If we accept the proposed resolution to issue <a href="lwg-active.html#250">250</a>,
+If we accept the proposed resolution to issue <a href="lwg-defects.html#250">250</a>,
then we'd better clarify that a "valid" iterator need no
longer designate an element within the same container as it once did.
We then have to clarify what we mean by invalidating a past-the-end
introduce separate terms for the two kinds of "validity."
</p>
<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of section 24.1 ,
+<p>Add the following text to the end of section 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
after paragraph 5:</p>
<blockquote>
-<i>Invalidating</i> an iterator means modifying it such that
-it may have a singular value. [Footnote: This definition applies to
-pointers, since pointers are iterators. The effect of dereferencing
-an iterator that has been invalidated is undefined.]
+An <i>invalid</i> iterator is an iterator that may be
+singular. [Footnote: This definition applies to pointers, since
+pointers are iterators. The effect of dereferencing an iterator that
+has been invalidated is undefined.]
</blockquote>
<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
+<p><i>[Redmond: General agreement with the intent, some objections to
+the wording. Dave provided new wording.]</i></p>
+
<hr>
<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p>
<b>Section:</b> 24.4.1 <a href="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p>
</p>
<p><b>Proposed resolution:</b></p>
<p>
-<b>Section:</b> 24.4.1.1
+<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
add/change the following declarations:</p>
<pre>
A) Add a templated assignment operator, after the same manner
</pre>
<p>
Also make the addition/changes for these signatures in
-24.4.1.3 .
+24.4.1.3 <a href="lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
</p>
<p><i>[
]</i></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#Ready">Ready</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 )
-and <tt>CopyConstructible</tt> (20.1.3 ).
-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 ).
-</p>
-<p>and replace 25.3.7, p4 with</p>
-<p>
-<b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
-(20.1.2 ).
-</p>
-<hr>
<a name="282"><h3>282. What types does numpunct grouping refer to?</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#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 5 Dec 2000</p>
<p>
<blockquote>
For integral types, punct.thousands_sep() characters are inserted into
the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 .
+using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
</blockquote>
<p>To:</p>
<blockquote>
For arithmetic types, punct.thousands_sep() characters are inserted into
the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 .
+using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
</blockquote>
<p><i>[
<p><i>[
A survey of existing practice is needed; it is believed that some
implementations do insert thousands_sep characters for floating-point
-output and others doing.
+output and others fail to insert thousands_sep characters for
+floating-point input even though this is unambiguously required by the
+standard.
]</i></p>
<hr>
<a name="283"><h3>283. std::replace() requirement incorrect/insufficient</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#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Dec 2000</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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Dec 2000</p>
<p>
-The requirements in 25.2.4 , p1 that <tt>T</tt> to be
-<tt>Assignable</tt> (23.1 ) is not necessary or
+The requirements in 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>, p1 that <tt>T</tt> to be
+<tt>Assignable</tt> (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) is not necessary or
sufficient for either of the algorithms. The algorithms require that
<tt>std::iterator_traits<ForwardIterator>::value_type</tt> be
<tt>Assignable</tt> and that both
<tt>std::iterator_traits<ForwardIterator>::value_type</tt> and be
-<tt>EqualityComparable</tt> (20.1.1 ) with respect to
+<tt>EqualityComparable</tt> (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>) with respect to
one another.
</p>
<p>
-Note that a similar problem occurs in several other places in section
-25 as well (e.g., 25.1.6 , or 25.2.5 ) so
-what really needs to happen is for all those places to be identified
-and corrected. The proposed resolution below addresses only 25.2.4.
+<b>Further discussion, from Jeremy</b>:
</p>
+
+<p>There are a number of problems with the requires clauses for the
+algorithms in 25.1 <a href="lib-algorithms.html#lib.alg.nonmodifying"> [lib.alg.nonmodifying]</a> and 25.2 <a href="lib-algorithms.html#lib.alg.modifying.operations"> [lib.alg.modifying.operations]</a>. The requires
+clause of each algorithm should describe the necessary and sufficient
+requirements on the inputs to the algorithm such that the algorithm
+compiles and runs properly. Many of the requires clauses fail to do
+this. Here is a summary of the kinds of mistakes:</p>
+
+<ol>
+<li> Use of EqualityComparable, which only puts requirements on a single
+ type, when in fact an equality operator is required between two
+ different types, typically either T and the iterators value_type
+ or between the value_type's of two different iterators.</li>
+
+<li> Use of Assignable for T when in fact what was needed is Assignable
+ for the value_type of the iterator, and convertability from T to the
+ value_type of the iterator. Or for output iterators, the requirement
+ should be that T is writable to the iterator (output iterators do
+ not have value types; see issue <a href="lwg-active.html#324">324</a>).</li>
+
+<li> Lack of a requires clause.</li>
+</ol>
+
+<p>Here is the list of algorithms that contain mistakes:</p>
+<ul>
+<li>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>
+</li>
+<li>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a>
+</li>
+<li>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>
+</li>
+<li>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a>
+</li>
+<li>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a>
+</li>
+<li>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a>
+</li>
+<li>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>
+</li>
+<li>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>
+</li>
+<li>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>
+</li>
+<li>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>
+</li>
+</ul>
+
+<p>Also, in the requirements for EqualityComparable, the requirement that
+the operator be defined for const objects is lacking.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.2.4, p1 from</p>
+<p>20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a> Change p1 from</p>
<blockquote>
-<b>-1- Requires:</b>Type <tt>T</tt> is <tt>Assignable</tt>
-(23.1 ) (and, for <tt>replace()</tt>,
-<tt>EqualityComparable</tt> (20.1.1 )).
+In Table 28, T is a type to be supplied by a C++ program instantiating
+a template, a, b, and c are values of type T.
</blockquote>
<p>to</p>
<blockquote>
-<b>-1- Requires:</b>Type
-<tt>std::iterator_traits<ForwardIterator>::value_type</tt>
-is <tt>Assignable</tt> (23.1 ), the type <tt>T</tt> is
-convertible to<tt>std::iterator_traits<ForwardIterator>::value_type</tt>,
-(and, for <tt>replace()</tt>, types
-<tt>std::iterator_traits<ForwardIterator>::value_type</tt> and
-<tt>T</tt> are <tt>EqualityComparable</tt> (20.1.1 )
-with respect to one another).
+In Table 28, T is a type to be supplied by a C++ program instantiating
+a template, a, b, and c are values of type const T.
</blockquote>
-<p><i>[
-The LWG agrees with the general idea of the proposed resolution, but
-not with the specific wording. (There is no definition in the
-standard of what it means for one type to be EqualityComparable to
-another.) Jeremy will provide new wording, and will review clause 25
-for similar issues.
-]</i></p>
+<p>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> Change p1 from</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#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 26 Dec 2000</p>
-<p>The example in 20.3.7 , 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 ], and since
-function pointers with different the language linkage specifications
-(7.5 ) are incompatible, whether this example is
-well-formed is unspecified.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Replace the code snippet in the following text</p>
<blockquote>
- <p>
-<b>-6- </b>[<i>Example:</i>
-</p>
- <pre>
- replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
- </pre>
+Requires: Type T is EqualityComparable (20.1.1).
</blockquote>
+<p>to </p>
-<p>with</p>
<blockquote>
- <p>
-<b>-6- </b>[<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>
+Requires: There must be a equality operator defined that accepts type
+std::iterator_traits<InputIterator>::reference for the left operand
+and const T for the right operand.
</blockquote>
-<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>
-<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#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 31 Dec 2000</p>
-<p>27.8.1.6 , p2, 27.8.1.9 , p2, and
-27.8.1.12 , p2 say about the effects of each constructor:
-<a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>
-</p>
-<p>... If that function returns a null pointer, calls
-<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
-</p>
+<p>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a> Add the following requires clause</p>
-<p>The parenthetical note doesn't apply since the ctors cannot throw an
-exception due to the requirement in 27.4.4.1 , 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#Ready">Ready</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#Ready">Ready</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>
+<blockquote>
+Requires: There must be an equality operator defined that accepts
+type const std::iterator_traits<ForwardIterator1>::value_type for the
+left operand and const
+std::iterator_traits<ForwardIterator2>::value_type for the right
+operand.
+</blockquote>
-<p>
-ISO/IEC 14882:1998(E) section 19.3 does not refer
-to the above amendment.
-</p>
+<p>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> Add the following requires clause</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="290"><h3>290. Requirements to for_each and its function object</h3></a><p>
-<b>Section:</b> 25.1.1 <a href="lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p>
-<p>The specification of the for_each algorithm does not have a
-"Requires" section, which means that there are no
-restrictions imposed on the function object whatsoever. In essence it
-means that I can provide any function object with arbitrary side
-effects and I can still expect a predictable result. In particular I
-can expect that the function object is applied exactly last - first
-times, which is promised in the "Complexity" section.
-</p>
+<blockquote>
+Requires: There must be an equality operator defined that accepts
+type const std::iterator_traits<ForwardIterator1>::value_type for the
+left operand and const
+std::iterator_traits<ForwardIterator2>::value_type for the right
+operand.
+</blockquote>
-<p>I don't see how any implementation can give such a guarantee
-without imposing requirements on the function object.
-</p>
-<p>Just as an example: consider a function object that removes
-elements from the input sequence. In that case, what does the
-complexity guarantee (applies f exactly last - first times) mean?
-</p>
+<p>25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> Add the following requires clause</p>
-<p>One can argue that this is obviously a nonsensical application and
-a theoretical case, which unfortunately it isn't. I have seen
-programmers shooting themselves in the foot this way, and they did not
-understand that there are restrictions even if the description of the
-algorithm does not say so.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add a "Requires" section to section 25.1.1 similar to those
-proposed for transform and the numeric algorithms (see issue
-<a href="lwg-active.html#242">242</a>):
-</p>
+<blockquote>
+Requires: T must be EqualityComparable (20.1.1).
+</blockquote>
+
+<p>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a> Change p1 from</p>
<blockquote>
- -2- <b>Requires</b>: In the range [first, last], f shall not invalidate
- iterators or subranges.
+Requires: Type T is EqualityComparable (20.1.1).
</blockquote>
-<p><i>[Copenhagen: The LWG agrees that a function object passed to an
+<p>to</p>
+
+<blockquote>
+Requires: There must be a equality operator defined that accepts type
+std::iterator_traits<InputIterator>::reference for the left operand
+and const T for the right operand.
+</blockquote>
+
+<p>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a> Add the following requires clause</p>
+
+<blockquote>
+Requires: There must be an equality operator defined that accepts type
+std::iterator_traits<InputIterator1>::reference for the left operand
+and std::iterator_traits<InputIterator2>::reference for the right operand.
+</blockquote>
+
+
+<p>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a> Add the following requires clause</p>
+
+<blockquote>
+Requires: There must be an equality operator defined that accepts type
+std::iterator_traits<InputIterator1>::reference for the left operand
+and std::iterator_traits<InputIterator2>::reference for the right operand.
+</blockquote>
+
+<p>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a> Add the following requires clause</p>
+
+<blockquote>
+Requires: There must be an equality operator defined that accepts
+type const std::iterator_traits<ForwardIterator1>::value_type for
+the left operand and const
+std::iterator_traits<ForwardIterator2>::value_type for the right
+operand.
+</blockquote>
+
+<p>Change change p4 from</p>
+
+<blockquote>
+Requires: Type T is EqualityComparable (20.1.1), type Size is
+convertible to integral type (4.7.12.3).
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+Requires: There must be an equality operator defined that accepts
+const std::iterator_traits<ForwardIterator>::value_type for the left
+operand and const T for the right operand. The type Size is convertible to
+integral type (4.7.12.3).
+</blockquote>
+
+<p>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> Change p1 from</p>
+
+<blockquote>
+Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace(),
+EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)).
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+Requires: Type std::iterator_traits<ForwardIterator>::value_type
+is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) and the type const T is convertible to
+std::iterator_traits<ForwardIterator>::value_type. For replace(), an
+equality operator must be defined that accepts type
+std::iterator_traits<ForwardIterator>::reference for the left operand
+and const T for the right operand.
+</blockquote>
+
+<p>and change p4 from</p>
+
+<blockquote>
+Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace_copy(),
+EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)). The ranges [first, last) and [result,
+result + (last - first)) shall not overlap.
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+Requires: Both types const T and
+std::iterator_traits<InputIterator>::reference are writable to the
+OutputIterator type. For replace_copy() an equality operator must be
+defined that accepts type
+std::iterator_traits<InputIterator>::reference for the left operand
+and const T for the right operand. The ranges [first, last) and [result,
+result + (last - first)) shall not overlap.
+</blockquote>
+
+<p>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> Change p1 from</p>
+
+<blockquote>
+Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> ). Size is convertible to an integral
+ type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+Requires: Type const T is writable to the OutputIterator. Size is
+convertible to an integral type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
+</blockquote>
+
+
+<p>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> Change p1 from</p>
+
+<blockquote>
+Requires: Type T is EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>).
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+Requires: There must be an equality operator defined that accepts
+type const std::iterator_traits<ForwardIterator>::value_type for the left
+operand and const T for the right operand. The type
+std::iterator_traits<ForwardIterator>::value_type must be Assignable
+(23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>).
+</blockquote>
+
+<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#Ready">Ready</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="290"><h3>290. Requirements to for_each and its function object</h3></a><p>
+<b>Section:</b> 25.1.1 <a href="lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p>
+<p>The specification of the for_each algorithm does not have a
+"Requires" section, which means that there are no
+restrictions imposed on the function object whatsoever. In essence it
+means that I can provide any function object with arbitrary side
+effects and I can still expect a predictable result. In particular I
+can expect that the function object is applied exactly last - first
+times, which is promised in the "Complexity" section.
+</p>
+
+<p>I don't see how any implementation can give such a guarantee
+without imposing requirements on the function object.
+</p>
+
+<p>Just as an example: consider a function object that removes
+elements from the input sequence. In that case, what does the
+complexity guarantee (applies f exactly last - first times) mean?
+</p>
+
+<p>One can argue that this is obviously a nonsensical application and
+a theoretical case, which unfortunately it isn't. I have seen
+programmers shooting themselves in the foot this way, and they did not
+understand that there are restrictions even if the description of the
+algorithm does not say so.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add a "Requires" section to section 25.1.1 similar to those
+proposed for transform and the numeric algorithms (see issue
+<a href="lwg-defects.html#242">242</a>):
+</p>
+
+<blockquote>
+ -2- <b>Requires</b>: In the range [first, last], f shall not invalidate
+ iterators or subranges.
+</blockquote>
+
+<p><i>[Copenhagen: The LWG agrees that a function object passed to an
algorithm should not invalidate iterators in the range that the
algorithm is operating on. The LWG believes that this should be a
blanket statement in Clause 25, not just a special requirement for
<p><i>[The LWG agrees that the standard should answer these questions.
Matt will provide wording.]</i></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#Ready">Ready</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="294"><h3>294. User defined macros and standard headers</h3></a><p>
<b>Section:</b> 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p>
-<p>Paragraph 2 of 17.4.3.1.1 reads: "A
+<p>Paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
translation unit that includes a header shall not contain any macros
that define names declared in that header." As I read this, it
would mean that the following program is legal:</p>
<p>I think that this phrase was probably formulated before it was
decided that a standard header may freely include other standard
headers. The phrase would be perfectly appropriate for C, for
-example. In light of 17.4.4.1 paragraph 1, however,
+example. In light of 17.4.4.1 <a href="lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
it isn't stringent enough.</p>
<p><b>Proposed resolution:</b></p>
-<p>In paragraph 2 of 17.4.3.1.1 , change "A
+<p>In paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change "A
translation unit that includes a header shall not contain any macros
that define names declared in that header." to "A
translation unit that includes a header shall not contain any macros
that define names declared in any standard header."</p>
<p><i>[Copenhagen: the general idea is clearly correct, but there is
-concern about making sure that the two paragraphs in 17.4.3.1.1 remain consistent. Nathan will provide new
+concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent. Nathan will provide new
wording.]</i></p>
<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#Ready">Ready</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 ,
-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>
-
-<hr>
-<a name="296"><h3>296. Missing descriptions and requirements of pair operators</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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 Jan 2001</p>
-<p>The synopsis of the header <tt><utility></tt> in 20.2
-lists the complete set of equality and relational operators for <tt>pair</tt>
-but the section describing the template and the operators only describes
-<tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention
-any requirements on the template arguments. The remaining operators are
-not mentioned at all.
-</p>
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following after 20.2.2 , paragraph 5:</p>
-
-<blockquote>
- <blockquote>
- <tt>template <class T1, class T2></tt>
- <br><tt>bool operator!=(const pair<T1, T2>& x, const pair<T1,
- T2>& y);</tt>
- </blockquote>
-
- <p>
-<b>Requires: </b>Types <tt>T1</tt> and <tt>T2</tt> are
- <tt>EqualityComparable</tt> (20.1.1 ).</p>
-
- <p>
-<b>Returns:</b> <tt>!(x == y)</tt>.</p>
-</blockquote>
-
-<p>Add the following after 20.2.2 , paragraph 6:</p>
-
-<blockquote>
- <blockquote>
- <tt>template <class T1, class T2></tt>
- <br><tt>bool operator>(const pair<T1, T2>& x, const pair<T1, T2>& y);</tt>
- </blockquote>
-
- <p>
-<b>Requires: </b>Types <tt>T1</tt> and <tt>T2</tt> are
- <tt>LessThanComparable</tt> (20.1.2 ).</p>
-
- <p>
-<b>Returns:</b> <tt>y < x</tt>.</p>
-
- <blockquote>
- <tt>template <class T1, class T2></tt>
- <br><tt>bool operator<=(const pair<T1, T2>& x, const pair<T1, T2>& y);</tt>
- </blockquote>
-
- <p>
-<b>Requires: </b>Types <tt>T1</tt> and <tt>T2</tt> are
- <tt>LessThanComparable</tt> (20.1.2 ).</p>
-
- <p>
-<b>Returns: </b><tt>!(y < x)</tt>.</p>
-
- <blockquote>
- <tt>template <class T1, class T2></tt>
- <br><tt>bool operator>=(const pair<T1, T2>& x, const pair<T1, T2>& y);</tt>
- </blockquote>
-
- <p>
-<b>Requires: </b>Types <tt>T1</tt> and <tt>T2</tt> are
- <tt>LessThanComparable</tt> (20.1.2 ).</p>
-
- <p>
-<b>Returns:</b> <tt>!(x < y)</tt>.</p>
-</blockquote>
-
-<p><i>[post-Copenhagen: modified proposed resolution so that it does
-not create a new section 20.2.2.1. That would violate ISO rules: we
-cannot have 20.2.2.1 unless we also have 20.2.2.2.]</i></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#Ready">Ready</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#Ready">Ready</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 ).
---- 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="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p>
<b>Section:</b> 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p>
<p>
-In section 24.1.4 ,
+In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
Table 75 gives the return type of *r-- as convertible to T. This is
not consistent with Table 74 which gives the return type of *r++ as
T&. *r++ = t is valid while *r-- = t is invalid.
</p>
<p>
-In section 24.1.5 ,
+In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
Table 76 gives the return type of a[n] as convertible to T. This is
not consistent with the semantics of *(a + n) which returns T& by
Table 74. *(a + n) = t is valid while a[n] = t is invalid.
</p>
<p><b>Proposed resolution:</b></p>
-<p>In section 24.1.4 , change the return type in table
+<p>In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, change the return type in table
75 from "convertible to T" to T&.</p>
-<p>In section 24.1.5 , change the return type in table
+<p>In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>, change the return type in table
76 from "convertible to T" to T&.</p>
<hr>
</blockquote>
<p><i>[Copenhagen: The proposed resolution does not fix all of the
-problems in 23.2.2.4 , p22-25. Three different
+problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25. Three different
paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
Changing p23, without changing the other two, appears to introduce
contradictions. Additionally, "merges the argument list into the
list" is excessively vague.]</i></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#Ready">Ready</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#Ready">Ready</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>
-
+<a name="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</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#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 5 Feb 2001</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.
+We all "know" that input iterators are allowed to produce
+values when dereferenced of which there is no other in-memory copy.
</p>
<p>
-A reasonable solution will probably involve <tt>widen()</tt> and/or
-<tt>narrow()</tt>, since they are the supplied mechanism for a single
-character between <tt>char</tt> and arbitrary <tt>charT</tt>.
+But: Table 72, with a careful reading, seems to imply that this can only be
+the case if the value_type has no members (e.g. is a built-in type).
</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>The problem occurs in the following entry:</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>
+<pre>
+ a->m pre: (*a).m is well-defined
+ Equivalent to (*a).m
+</pre>
-<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="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</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#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 5 Feb 2001</p>
-<p>
-We all "know" that input iterators are allowed to produce
-values when dereferenced of which there is no other in-memory copy.
-</p>
-
-<p>
-But: Table 72, with a careful reading, seems to imply that this can only be
-the case if the value_type has no members (e.g. is a built-in type).
-</p>
-
-<p>The problem occurs in the following entry:</p>
-
-<pre>
- a->m pre: (*a).m is well-defined
- Equivalent to (*a).m
-</pre>
-
-<p>
-<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
-type, but since <tt>operator->()</tt> must return a pointer for
-<tt>a->m</tt> to be well-formed, it needs something to return a
-pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
-buffered somewhere to make a legal input iterator.
+<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
+type, but since <tt>operator->()</tt> must return a pointer for
+<tt>a->m</tt> to be well-formed, it needs something to return a
+pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
+buffered somewhere to make a legal input iterator.
</p>
<p>I don't think this was intentional.</p>
for characters that are not part of the basic execution character set.
</p>
<p><b>Proposed resolution:</b></p>
+<p>
+Change 22.2.1.5.2/5 from:
+</p>
+<p>
+The instantiations required in Table 51 (lib.locale.category), namely
+codecvt<wchar_t,char,mbstate_t> and
+codecvt<char,char,mbstate_t>, store no characters. Stores no more
+than (to_limit-to) destination elements. It always leaves the to_next
+pointer pointing one beyond the last element successfully stored.
+</p>
+<p>
+to:
+</p>
+<p>
+Stores no more than (to_limit-to) destination elements, and leaves the
+to_next pointer pointing one beyond the last element successfully
+stored. codecvt<char,char,mbstate_t> stores no characters.
+</p>
+
<p>Change 22.2.1.5.2/10 from:</p>
<blockquote>
the lesser of max and (from_end-from).
</blockquote>
-<p><i>[Copenhagen: straw poll was 3-1 in favor, with many abstentions.
-Nathan would like to see more guarantees than are in the proposed
-resolution. He will discuss this issue with the other people who
-care about it.]</i></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#Ready">Ready</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 , 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#Ready">Ready</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
-paragraph 1 and 23.2.3.3 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#Ready">Ready</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 ) and the headers <cstdio> and
-<cwchar> for File streams (27.8 ). 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 , 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 , including 27.8.2 .]</i></p>
+<p><i>[Redmond: Nathan suggested an alternative resolution: same as
+above, but require that, in the default encoding, a character from the
+basic execution character set would map to a single external
+character. The straw poll was 8-1 in favor of the proposed
+resolution.]</i></p>
+<p><b>Rationale:</b></p>
+<p>The default encoding should be whatever users of a given platform
+would expect to be the most natural. This varies from platform to
+platform. In many cases there is a preexisting C library, and users
+would expect the default encoding to be whatever C uses in the default
+"C" locale. We could impose a guarantee like the one Nathan suggested
+(a character from the basic execution character set must map to a
+single external character), but this would rule out important
+encodings that are in common use: it would rule out Shift-JIS, for
+example, and it would rule out a fixed-width encoding of UCS-4.</p>
<hr>
<a name="309"><h3>309. Does sentry catch exceptions?</h3></a><p>
<b>Section:</b> 27.6 <a href="lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p>
<p>
The descriptions of the constructors of basic_istream<>::sentry
-(27.6.1.1.2 ) and basic_ostream<>::sentry
-(27.6.2.3 ) do not explain what the functions do in
+(27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream<>::sentry
+(27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in
case an exception is thrown while they execute. Some current
implementations allow all exceptions to propagate, others catch them
and set ios_base::badbit instead, still others catch some but let
argument is meant). That may have been fine for
basic_istream<>::sentry prior to issue <a href="lwg-defects.html#195">195</a>, since
the function performs an input operation which may fail. However,
-issue <a href="lwg-defects.html#195">195</a> amends 27.6.1.1.2 , p2 to
+issue <a href="lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to
clarify that the function should actually call setstate(failbit |
eofbit), so the sentence in p3 is redundant or even somewhat
contradictory.
</p>
<p>
-The same sentence that appears in 27.6.2.3 , p3
+The same sentence that appears in 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3
doesn't seem to be very meaningful for basic_istream<>::sentry
which performs no input. It is actually rather misleading since it
would appear to guide library implementers to calling
</p>
<p><b>Proposed resolution:</b></p>
<p>Add the following paragraph immediately after
-27.6.1.1.2 , p5</p>
+27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
<blockquote>
<p>
</p>
</blockquote>
-<p>And strike the following sentence from 27.6.1.1.2 , p5</p>
+<p>And strike the following sentence from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
<blockquote>
During preparation, the constructor may call setstate(failbit)
</blockquote>
<p>Add the following paragraph immediately after
-27.6.2.3 , p3</p>
+27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
<blockquote>
<p>
</p>
</blockquote>
-<p>And strike the following sentence from 27.6.2.3 , p3</p>
+<p>And strike the following sentence from 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
<blockquote>
During preparation, the constructor may call setstate(failbit)
<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#Review">Review</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</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#Ready">Ready</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>
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.</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#Review">Review</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Mar 2001</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#Ready">Ready</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Mar 2001</p>
-<p>In 27.6.2.1 , the synopsis of class basic_ostream says:</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
</ul>
<p><b>Proposed resolution:</b></p>
-<p>In the synopsis in 27.6.2.1 , remove the
-<i>// partial specializationss</i> comment.</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#Ready">Ready</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 .</p>
-<p><b>Proposed resolution:</b></p>
-<p>Add <cstdlib> and <cstring> to Table 27, in the same row
-as <memory>.</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="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#New">New</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</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#Ready">Ready</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p>
<p>
-23.2.2.4 , Para 21 describes the complexity of
+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><b>Proposed resolution:</b></p>
<p>
-Change the "range" from (last - first) to [first, last). Change the
-complexity from "(last - first) -1 applications of the corresponding
-predicate" to "distance(first,last)-1 applications of the corresponding
-predicate.
+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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</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#Ready">Ready</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>
</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p>
+<b>Section:</b> 22 <a href="lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</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
<p>to</p>
<blockquote>
- An implementation is required to support those specializations...
+ 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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 May 2001</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#Ready">Ready</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>
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-active.html#228">228</a>.</p>
+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#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p>
-<p>The standard specifies 17.3.1.3 that "Required
+<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#Ready">Ready</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 that "Requires"
+<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
<p><b>Proposed resolution:</b></p>
-<p>In 18.4.1.1 Para 12 Change:</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 be null or the value returned by an
+ <p>Requires: the value of ptr is null or the value returned by an
earlier call ...</p>
</blockquote>
-<p>In 18.4.1.2 Para 11 Change:</p>
+<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 be null or the value returned by an
+ <p>Requires: the value of ptr is null or the value returned by an
earlier call ...</p>
</blockquote>
<hr>
<a name="320"><h3>320. list::assign overspecified</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#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 17 May 2001</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#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 17 May 2001</p>
<p>
Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
the "effects" of a call to erase followed by a call to insert.
<blockquote>
<p>Effects: Replaces the contents of the list with the range [first, last).</p>
-<p>PostCondition: *this == list<T, Allocator>(first, last)</p>
-<p>Notes: If an exception is thrown, the contents of the list are
-indeterminate.</p>
</blockquote>
+<p>In 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
+add a new row:</p>
+<pre>
+ a.assign(i,j) void pre: i,j are not iterators into a.
+ Replaces elements in a with copies
+ of elements in [i, j).
+</pre>
+
<p>Change 23.2.2.1/8 from:</p>
<blockquote>
<blockquote>
<p>Effects: Replaces the contents of the list with n copies of t.</p>
-<p>PostCondition: *this == list<T, Allocator>(n, t)</p>
-<p>Notes: If an exception is thrown, the contents of the list are self
-consistent but indeterminate.</p>
</blockquote>
+
+<p><i>[Redmond: Proposed resolution was changed slightly. Previous
+version made explicit statement about exception safety, which wasn't
+consistent with the way exception safety is expressed elsewhere.
+Also, the change in the sequence requirements is new. Without that
+change, the proposed resolution would have required that assignment of
+a subrange would have to work. That too would have been
+overspecification; it would effectively mandate that assignment use a
+temporary.
+]</i></p>
+
<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#New">New</a> <b>Submitter:</b> Kevin Djang <b>Date:</b> 17 May 2001</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#Ready">Ready</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."
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#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 17 May 2001</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#Ready">Ready</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
</p>
<hr>
<a name="323"><h3>323. abs() overloads in different headers</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#New">New</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 4 June 2001</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#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 4 June 2001</p>
<p>Currently the standard mandates the following overloads of
abs():</p>
</p>
<p>The same issue may exist for other functions in the library.</p>
+
+<p>Redmond: PJP reports that C99 adds two new kinds of abs: comples,
+and int_max_abs.</p>
+
+<p>Related issue: <a href="lwg-closed.html#343">343</a>.</p>
+
<p><b>Proposed resolution:</b></p>
+
+<p><i>[Redmond: General agreement that the current situation is
+somewhat fragile. No consensus on whether it's more fragile than any
+number of other things, or whether there's any good way to fix it.
+Walter suggests that <tt>abs</tt> should be defined for all built-in
+types in both <cmath> and <cstdlib>, but that no effort
+should be made to put all overloads for class types in one place.
+Beman suggests closing this issue as "NAD Future", and adding a
+<all> header as an extension. The <all> header would
+solve a more general problem: users who can't remember which names are
+defined in which headers. (See issue <a href="lwg-closed.html#343">343</a>)]</i></p>
+
<hr>
<a name="324"><h3>324. Do output iterators have value types?</h3></a><p>
-<b>Section:</b> 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 June 2001</p>
+<b>Section:</b> 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 June 2001</p>
-<p>Table 73 suggests that output iterators have value types. It says
-defines the expression "*a = t". Additionally, although Table 73
+<p>Table 73 suggests that output iterators have value types. It
+requires the expression "*a = t". Additionally, although Table 73
never lists "a = t" or "X(a) = t" in the "expressions" column, it
contains a note saying that "a = t" and "X(a) = t" have equivalent
(but nowhere specified!) semantics.</p>
iterator type, like non-const pointers, that satisfies both the output
iterator requirements and the forward iterator requirements.</p>
-<p>What should the standard say about "*i's" return value when i is an
-output iterator, and what should it say about that t is in the
+<p>What should the standard say about <tt>*i</tt>'s return value when
+i is an output iterator, and what should it say about that t is in the
expression "*i = t"? Finally, should the standard say anything about
output iterators' pointer and reference types?</p>
<p><b>Proposed resolution:</b></p>
+<p>24.1 p1, change</p>
+
+<blockquote>
+<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
+in a value of some class, enumeration, or built-in type <tt>T</tt>,
+called the value type of the itereator.</p>
+</blockquote>
-<p>A sketch of one proposed resolution, without language: Make it
-clear that the notion of "value type" does not apply to output
-iterators.</p>
+<p>to</p>
<blockquote>
-Put an "except for output iterators" qualification in 24.1/1; remove
-the note in table 73 about "a = t" and "X(a) = t"; put language in
-24.1.2 paragraph 1 saying that "t" is a value of whatever type or
-types for which "*i = t" is defined and that an output iterator need
-not have a unique value type; change 24.3.1/1 to say that an output
-iterator may, but need not, define
-iterator_traits<Iterator>::difference_type
-iterator_traits<Iterator>::value_type as void.
+<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
+resulting in a value of some class, enumeration, or built-in type
+<tt>T</tt>, called the value type of the iterator. All output
+iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
+value of some type that is in the set of types that are <i>writable</i> to
+the particular iterator type of <tt>i</tt>.
+</p>
</blockquote>
-<p>A sketch of an alternate proposed resolution, also without
-language: Require every output iterator to have a value type, just
-like other kinds of iterators.</p>
+<p>24.1 p9, add</p>
<blockquote>
-Put an "except for output iterators" qualification in 24.1/1; remove
-the note in table 73 about "a = t" and "X(a) = t"; put language in
-24.1.2 paragraph 1 saying that an output iterator's value type is the
-type for which "*i = t" is defined; remove the note in 24.3.1/1 saying
-that iterator_traits<>::value_type is void for an output
-iterator; change all of the predefined output iterators
-(ostream_iterator, ostreambuf_iterator, back_insert_iterator,
-front_insert_iterator, insert_iterator) so that they have non-void
-value types.
+<p>
+<tt>o</tt> denotes a value of some type that is writable to the
+output iterator.
+</p>
</blockquote>
+<p>Table 73, change</p>
+
+<blockquote>
+<pre>
+*a = t
+</pre>
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+<pre>
+*r = o
+</pre>
+</blockquote>
+
+<p>and change</p>
+
+<blockquote>
+<pre>
+*r++ = t
+</pre>
+</blockquote>
+
+<p>to</p>
+
+<blockquote>
+<pre>
+*r++ = o
+</pre>
+</blockquote>
+
+<p><i>[post-Redmond: Jeremy provided wording]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>The LWG considered two options: change all of the language that
+seems to imply that output iterators have value types, thus making it
+clear that output iterators have no value types, or else define value
+types for output iterator consistently. The LWG chose the former
+option, because it seems clear that output iterators were never
+intended to have value types. This was a deliberate design decision,
+and any language suggesting otherwise is simply a mistake.</p>
+
+<p>A future revision of the standard may wish to revisit this design
+decision.</p>
<hr>
<a name="325"><h3>325. Misleading text in moneypunct<>::do_grouping</h3></a><p>
-<b>Section:</b> 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Jul 2001</p>
+<b>Section:</b> 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Jul 2001</p>
<p>The Returns clause in 22.2.6.3.2, p3 says about
moneypunct<charT>::do_grouping()
</p>
<p>and replace the text in Footnote 241 with the following:</p>
<blockquote>
- The moneypunct facet (or its derivative) installed in named locales
- other than "C" will most commonly return the value "\003" (not "3").
+ To specify grouping by 3s the value is "\003", not "3".
</blockquote>
<p><b>Rationale:</b></p>
<p>
-Note that the proposed resolution is sufficiently vague to allow
-implementations to implement the behavior of both moneypunct and
-moneypunct_byname to be implemented by the base. This may or may
-not be desirable depending on whether we want the base behavior
-to strictly reflect the "C" locale (only) and the derived behavior
-to implement the behavior specific to the named locales. This
-distinction would be detectable by obtaining a reference to
-moneypunct_byname, say mp, and calling mp.do_grouping() or
-mp.moneypunct<charT>::do_grouping() to get one or the other.
+The fundamental problem is that the description of the locale facet
+virtuals serves two purposes: describing the behavior of the base
+class, and describing the meaning of and constraints on the behavior
+in arbitrary derived classes. The new wording makes that separation a
+little bit clearer. The footnote (which is nonnormative) is not
+supposed to say what the grouping is in the "C" locale or in any other
+locale. It is just a reminder that the values are interpreted as small
+integers, not ASCII characters.
</p>
<hr>
-<a name="326"><h3>326. Missing typedef in moneypunct_byname</h3></a><p>
-<b>Section:</b> 22.2.6.4 <a href="lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jul 2001</p>
-<p>The definition of the moneypunct facet contains the typedefs char_type
-and string_type. Only one of these names, string_type, is defined in
-the derived facet, moneypunct_byname.</p>
-<p><b>Proposed resolution:</b></p>
-<p>For consistency with the numpunct facet, add a typedef for
-char_type to the definition of the moneypunct_byname facet in
-22.2.6.4 .</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#New">New</a> <b>Submitter:</b> Tiki Wan <b>Date:</b> 06 Jul 2001</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#Ready">Ready</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
<p><b>Proposed resolution:</b></p>
<p>
In table 52, required instantiations, in
-22.1.1.1.1 , change</p>
+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<wchart, OutputIterator>
+ time_get_byname<wchar_t, OutputIterator>
</pre>
<p>to</p>
<pre>
time_get<wchar_t, InputIterator>
- time_get_byname<wchart, 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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 07 Jul 2001</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#Ready">Ready</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
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="329"><h3>329. vector capacity, reserve and reallocation</h3></a><p>
-<b>Section:</b> 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 Jul 2001</p>
+<b>Section:</b> 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 Jul 2001</p>
<p>
There is an apparent contradiction about which circumstances can cause
-a reallocation of a vector in Section 23.2.4.2 and
-section 23.2.4.3 .
+a reallocation of a vector in Section 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
+section 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
</p>
<p>23.2.4.2p5 says:</p>
</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the wording of 23.2.4.5p5 to:</p>
+<p>Change the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
<blockquote>
Notes: Reallocation invalidates all the references, pointers, and
iterators referring to the elements in the sequence. It is guaranteed
that no reallocation takes place during insertions that happen after a
call to reserve() until the time when an insertion would make the size
-of the vector greater than the value of capacity() after the most
-recent call to reserve().
+of the vector greater than the value of capacity().
</blockquote>
-<hr>
-<a name="330"><h3>330. Misleading "exposition only" value in class locale definition</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Jul 2001</p>
-<p>
-The "exposition only" value of the std::locale::none constant shown in
-the definition of class locale is misleading in that it on many
-systems conflicts with the value assigned to one if the LC_XXX
-constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
-on Linux and SunOS). This causes incorrect behavior when such a
-constant is passed to one of the locale member functions that accept a
-locale::category argument and interpret it as either the C LC_XXX
-constant or a bitmap of locale::category values. At least three major
-implementations adopt the suggested value without a change and
-consequently suffer from this problem.
-</p>
-
-<p>
-For instance, the following code will (presumably) incorrectly copy facets
-belonging to the collate category from the German locale on AIX:
-</p>
+<p><i>[Redmond: original proposed resolution was modified slightly. In
+the original, the guarantee was that there would be no reallocation
+until the size would be greater than the value of capacity() after the
+most recent call to reserve(). The LWG did not believe that the
+"after the most recent call to reserve()" added any useful
+information.]</i></p>
-<pre>
- std::locale l (std::locale ("C"), "de_DE", std::locale::none);
-</pre>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the value from 0 to some other bit value, say 0x400, distinct
-from any of the other values shown.
-</p>
+<p><b>Rationale:</b></p>
+<p>There was general agreement that, when reserve() is called twice in
+succession and the argument to the second invocation is smaller than
+the argument to the first, the intent was for the second invocation to
+have no effect. Wording implying that such cases have an effect on
+reallocation guarantees was inadvertant.</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#New">New</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 23 Aug 2001</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#Ready">Ready</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 23 Aug 2001</p>
<p>
-With the change in 17.4.4.8 to state
+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>)
};
}
</pre>
-<p>the class failure cannot be implemented since in 18.6.1 the destructor of class exception has an empty
+<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 {
}
</pre>
<p><b>Proposed resolution:</b></p>
-<p>Two alternatives:</p>
-<ol>
-<li>Change the declaration of ~failure() to virtual ~failure() throw();</li>
-<li>Remove the declaration of ~failure().</li>
-</ol>
-<hr>
-<a name="332"><h3>332. Consider adding increment and decrement operators to std::fpos< T > </h3></a><p>
-<b>Section:</b> 27.4.3 <a href="lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
-<p>
-Increment and decrement operators are missing from
-Table 88 -- Position type requirements in 27.4.3 .
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Table 88 (section 27.4.3) -- Position type requirements
-be updated to include increment and decrement operators.
-</p>
-
-<pre>
-expression return type operational note
-
-++p fpos& p += O(1)
-p++ fpos { P tmp = p;
- ++p;
- return tmp; }
---p fpos& p -= O(1)
-p-- fpos { P tmp = p;
- --p;
- return tmp; }
-</pre>
-
+<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="333"><h3>333. does endl imply synchronization with the device?</h3></a><p>
-<b>Section:</b> 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
-<p>A footnote in 27.6.2.7 states:</p>
+<b>Section:</b> 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
+<p>A footnote in 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
<blockquote>
[Footnote: The effect of executing cout << endl is to insert a
newline character in the output sequence controlled by cout, then
the behavior one way or the other.
</p>
<p><b>Proposed resolution:</b></p>
+<p>Remove footnote 300 from section 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
+<p><b>Rationale:</b></p>
+<p>We already have normative text saying what <tt>endl</tt> does: it
+inserts a newline character and calls <tt>flush</tt>. This footnote
+is at best redundant, at worst (as this issue says) misleading,
+because it appears to make promises about what <tt>flush</tt>
+does.</p>
<hr>
<a name="334"><h3>334. map::operator[] specification forces inefficient implementation</h3></a><p>
-<b>Section:</b> 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Andrea Griffini <b>Date:</b> 02 Sep 2001</p>
+<b>Section:</b> 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Andrea Griffini <b>Date:</b> 02 Sep 2001</p>
<p>
The current standard describes map::operator[] using a
code example. That code example is however quite
in the map; otherwise at least another copy
construction for each type).
</p>
-<p><b>Proposed resolution:</b></p>
+
<p>A simple (half) solution would be replacing the description with:</p>
<pre>
Returns:
non-conforming.
</p>
+<p><b>Proposed resolution:</b></p>
+
<p>
-Note that this is a "relaxing" of requirment and won't
-make any currently conforming implementation on this
-point to become non-conforming because of the change.
+Replace 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
+</p>
+<blockquote>
+<p>
+-1- Effects: If there is no key equivalent to x in the map, inserts
+value_type(x, T()) into the map.
+</p>
+<p>
+-2- Returns: A reference to the mapped_type corresponding to x in *this.
</p>
-
<p>
-There is a small risk that current code may be depending
-on the number of temporaries created by map::operator[];
-but I think that such dependencies would be present only
-in code that is most probably already non portable as
-the number of copies of parameters isn't guaranteed by
-the standard (in the current wording there's just an
-implicit *minimum* number of required copies).
+-3- Complexity: logarithmic.
</p>
+</blockquote>
+
+<p><i>[This is the second option mentioned above. Howard provided
+wording. We may also wish to have a blanket statement somewhere in
+clause 17 saying that we do not intend the semantics of sample code
+fragments to be interpreted as specifing exactly how many copies are
+made. See issue <a href="lwg-active.html#98">98</a> for a similar problem.]</i></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#New">New</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 06 Sep 2001</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#Ready">Ready</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 06 Sep 2001</p>
<p>
-Table 37, in 21.1.1 , descibes char_traits::assign
+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>
<p><b>Proposed resolution:</b></p>
<p>Add the following to 21.1.1 para 1:</p>
<blockquote>
- r denotes a reference to CharT
+ 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="336"><h3>336. Clause 17 lack of references to deprecated headers</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#Open">Open</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 05 Sep 2001</p>
+<p>From c++std-edit-873:</p>
+
+<p>17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11. In this table, the header
+<strstream> is missing.</p>
+
+<p>This shows a general problem: The whole clause 17 refers quite
+often to clauses 18 through 27, but D.7 is also a part of the standard
+library (though a deprecated one).</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[Redmond: The LWG agrees that <strstream> should be added
+to table 11. A review is needed to determine whether there are any
+other places in clause 17 where clause D material should be referred
+to. Beman will review clause 17.]</i></p>
+<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#Ready">Ready</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="338"><h3>338. is whitespace allowed between `-' and a digit?</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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 Sep 2001</p>
+<p>
+From Stage 2 processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
+original text or the text corrected by the proposed resolution of
+issue <a href="lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
+within a number, but 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
+format for integer and floating point values, says that whitespace is
+optional between a plusminus and a sign.
+</p>
+
+<p>
+The text needs to be clarified to either consistently allow or
+disallow whitespace between a plusminus and a sign. It might be
+worthwhile to consider the fact that the C library stdio facility does
+not permit whitespace embedded in numbers and neither does the C or
+C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the first part of 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
+<blockquote>
+<p>
+The syntax for number formats is as follows, where <tt>digit</tt>
+represents the radix set specified by the <tt>fmtflags</tt> argument
+value, <tt>whitespace</tt> is as determined by the facet
+<tt>ctype<charT></tt> (22.2.1.1), and <tt>thousands-sep</tt> and
+<tt>decimal-point</tt> are the results of corresponding
+<tt>numpunct<charT></tt> members. Integer values have the
+format:
+</p>
+<pre>
+ integer ::= [sign] units
+ sign ::= plusminus [whitespace]
+ plusminus ::= '+' | '-'
+ units ::= digits [thousands-sep units]
+ digits ::= digit [digits]
+</pre>
+</blockquote>
+<p>to:</p>
+<blockquote>
+<p>
+The syntax for number formats is as follows, where <tt>digit</tt>
+represents the radix set specified by the <tt>fmtflags</tt> argument
+value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
+results of corresponding <tt>numpunct<charT></tt> members.
+Integer values have the format:
+</p>
+<pre>
+ integer ::= [sign] units
+ sign ::= plusminus
+ plusminus ::= '+' | '-'
+ units ::= digits [thousands-sep units]
+ digits ::= digit [digits]
+</pre>
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>It's not clear whether the format described in 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
+standard says how, or whether, it's used. However, there's no reason
+for it to differ gratuitously from the very specific description of
+numeric processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>. The proposed
+resolution removes all mention of "whitespace" from that format.</p>
+<hr>
+<a name="339"><h3>339. definition of bitmask type restricted to clause 27</h3></a><p>
+<b>Section:</b> 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 September 2001</p>
+<p>
+The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
+likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
+clause 27, making the reference in 22.2.1 somewhat dubious.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
+ <blockquote>
+ Several types defined in clause 27 are bitmask types. Each bitmask type
+ can be implemented as an enumerated type that overloads certain operators,
+ as an integer type, or as a bitset (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
+ </blockquote>
+<p>to read</p>
+ <blockquote>
+ Several types defined in clauses lib.language.support through
+ lib.input.output and Annex D are bitmask types. Each bitmask type can
+ be implemented as an enumerated type that overloads certain operators,
+ as an integer type, or as a bitset (lib.template.bitset).
+ </blockquote>
+
+<p>
+Additionally, change the definition in 22.2.1 to adopt the same
+convention as in clause 27 by replacing the existing text with the
+following (note, in particluar, the cross-reference to 17.3.2.1.2 in
+22.2.1, p1):
+</p>
+
+<blockquote>
+<p>22.2.1 The ctype category [lib.category.ctype]</p>
+<pre>
+namespace std {
+ class ctype_base {
+ public:
+ typedef T mask;
+
+ // numeric values are for exposition only.
+ static const mask space = 1 << 0;
+ static const mask print = 1 << 1;
+ static const mask cntrl = 1 << 2;
+ static const mask upper = 1 << 3;
+ static const mask lower = 1 << 4;
+ static const mask alpha = 1 << 5;
+ static const mask digit = 1 << 6;
+ static const mask punct = 1 << 7;
+ static const mask xdigit = 1 << 8;
+ static const mask alnum = alpha | digit;
+ static const mask graph = alnum | punct;
+ };
+}
+</pre>
+
+<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
+</blockquote>
+
+<hr>
+<a name="340"><h3>340. interpretation of <tt>has_facet<Facet>(loc)</tt>
+</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#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2001</p>
+<p>
+It's unclear whether 22.1.1.1.1, p3 says that
+<tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt>
+from Table 51 or whether it includes Table 52 as well:
+</p>
+
+<blockquote>
+For any locale <tt>loc</tt> either constructed, or returned by
+locale::classic(), and any facet <tt>Facet</tt> that is a member of a
+standard category, <tt>has_facet<Facet>(loc)</tt> is true. Each
+locale member function which takes a <tt>locale::category</tt>
+argument operates on the corresponding set of facets.
+</blockquote>
+
+<p>
+It seems that it comes down to which facets are considered to be members of a
+standard category. Intuitively, I would classify all the facets in Table 52 as
+members of their respective standard categories, but there are an unbounded set
+of them...
+</p>
+
+<p>
+The paragraph implies that, for instance, <tt>has_facet<num_put<C,
+OutputIterator> >(loc)</tt> must always return true. I don't think that's
+possible. If it were, then <tt>use_facet<num_put<C, OutputIterator>
+>(loc)</tt> would have to return a reference to a distinct object for each
+valid specialization of <tt>num_put<C, OutputIteratory></tt>, which is
+clearly impossible.
+</p>
+
+<p>
+On the other hand, if none of the facets in Table 52 is a member of a standard
+category then none of the locale member functions that operate on entire
+categories of facets will work properly.
+</p>
+
+<p>
+It seems that what p3 should mention that it's required (permitted?)
+to hold only for specializations of <tt>Facet</tt> from Table 52 on
+<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
+<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
+{
+{i,o}<tt>streambuf_iterator</tt><{<tt>char</tt>,<tt>wchar_t</tt>}<tt>></tt>
+}.
+</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 3, change
+"that is a member of a standard category" to "shown in Table 51".</p>
+<p><b>Rationale:</b></p>
+<p>The facets in Table 52 are an unbounded set. Locales should not be
+required to contain an infinite number of facets.</p>
+
+<p>It's not necessary to talk about which values of InputIterator and
+OutputIterator must be supported. Table 51 already contains a
+complete list of the ones we need.</p>
+<hr>
+<a name="341"><h3>341. Vector reallocation and swap</h3></a><p>
+<b>Section:</b> 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 27 Sep 2001</p>
+<p>It is a common idiom to reduce the capacity of a vector by swapping it with
+an empty one:</p>
+<pre>
+ std::vector<SomeType> vec;
+ // fill vec with data
+ std::vector<SomeType>().swap(vec);
+ // vec is now empty, with minimal capacity
+</pre>
+
+<p>However, the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
+the capacity of a vector being reduced, following a call to
+reserve(). This invalidates the idiom, as swap() is thus prevented
+from reducing the capacity. The proposed wording for issue <a href="lwg-active.html#329">329</a> does not affect this. Consequently, the example above
+requires the temporary to be expanded to cater for the contents of
+vec, and the contents be copied across. This is a linear-time
+operation.</p>
+
+<p>However, the container requirements state that swap must have constant
+complexity (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
+
+<p>This is an important issue, as reallocation affects the validity of
+references and iterators.</p>
+
+<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
+references and iterators remain valid after a call to swap, if they refer to
+an element before the new end() of the vector into which they originally
+pointed, in which case they refer to the element at the same index position.
+Iterators and references that referred to an element whose index position
+was beyond the new end of the vector are invalidated.</p>
+
+<p>If the note to table 65 is taken as the desired intent, then there are two
+possibilities with regard to iterators and references:</p>
+
+<ol>
+<li>All Iterators and references into both vectors are invalidated.</li>
+<li>Iterators and references into either vector remain valid, and remain
+pointing to the same element. Consequently iterators and references that
+referred to one vector now refer to the other, and vice-versa.</li>
+</ol>
+<p><b>Proposed resolution:</b></p>
+<p>Add a new paragraph after 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
+<blockquote>
+<pre>
+ void swap(vector<T,Allocator>& x);
+</pre>
+<p>
+<b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
+with that of <tt>x</tt>.</p>
+<p>
+<b>Complexity:</b> Constant time.</p>
+</blockquote>
+
+<p><i>[This solves the problem reported for this issue. We may also
+have a problem with a circular definition of swap() for other
+containers.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+swap should be constant time. The clear intent is that it should just
+do pointer twiddling, and that it should exchange all properties of
+the two vectors, including their reallocation guarantees.
+ay be useful.
+</p>
+<hr>
+<a name="342"><h3>342. seek and eofbit</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#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 201</p>
+<p>I think we have a defect.</p>
+
+<p>According to lwg issue <a href="lwg-defects.html#60">60</a> which is now a dr, the
+description of seekg in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
+like:</p>
+
+<blockquote>
+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() != true,
+executes rdbuf()­>pubseekpos( pos).
+</blockquote>
+
+<p>And according to lwg issue <a href="lwg-defects.html#243">243</a> which is also now a dr,
+27.6.1.3, paragraph 1 looks like:</p>
+
+<blockquote>
+Each unformatted input function begins execution by constructing an
+object of class sentry with the default argument noskipws (second)
+argument true. If the sentry object returns true, when converted to a
+value of type bool, the function endeavors to obtain the requested
+input. 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. If an exception is thrown during
+input then ios::badbit is turned on in *this'ss error state. If
+(exception()&badbit)!= 0 then the exception is rethrown. It also counts
+the number of characters extracted. If no exception has been thrown it
+ends by storing the count in a member object and returning the value
+specified. In any event the sentry object is destroyed before leaving
+the unformatted input function.
+</blockquote>
+
+<p>And finally 27.6.1.1.2/5 says this about sentry:</p>
+
+<blockquote>
+If, after any preparation is completed, is.good() is true, ok_ != false
+otherwise, ok_ == false.
+</blockquote>
+
+<p>
+So although the seekg paragraph says that the operation proceeds if
+!fail(), the behavior of unformatted functions says the operation
+proceeds only if good(). The two statements are contradictory when only
+eofbit is set. I don't think the current text is clear which condition
+should be respected.
+</p>
+
+<p><b>Further discussion from Redmond:</b></p>
+
+<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
+"unformatted". That makes specific claims about sentry that
+aren't quite appropriate for seeking, which has less fragile failure
+modes than actual input. If we do really mean that it's unformatted
+input, it should behave the same way as other unformatted input. On
+the other hand, "principle of least surprise" is that seeking from EOF
+ought to be OK.</p>
+
+<p>Dietmar: nothing should depend on eofbit. Eofbit should only be
+examined by the user to determine why something failed.</p>
+
+<p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p><i>[Howard will do a survey to find out if there are any other
+places where we have a problem, where the difference between
+<tt>fail()</tt> and <tt>!good()</tt> is important.]</i></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#Ready">Ready</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#Ready">Ready</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>
+
+<hr>
+<a name="347"><h3>347. locale::category and bitmask requirements</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#New">New</a> <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 23 Oct 2001</p>
+<p>
+In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
+are described as bitmask elements. In fact, the bitmask requirements
+in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
+and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
+
+<p>In particular, the requirements for <tt>none</tt> interact poorly
+with the requirement that the LC_* constants from the C library must
+be recognizable as C++ locale category constants. LC_* values should
+not be mixed with these values to make category values.</p>
+
+<p>We have two options for the proposed resolution. Informally:
+option 1 removes the requirement that LC_* values be recognized as
+category arguments. Option 2 changes the category type so that this
+requirement is implementable, by allowing <tt>none</tt> to be some
+value such as 0x1000 instead of 0.</p>
+
+<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
+re-expresses the status quo more clearly, without introducing any
+changes beyond resolving the DR.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+<b>Option 1:</b> <br>
+Replace the first two paragraphs of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
+<blockquote>
+<pre>
+ typedef int category;
+</pre>
+
+<p>Valid category values include the <tt>locale</tt> member bitmask
+elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
+<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
+represents a single locale category. In addition, <tt>locale</tt> member
+bitmask constant <tt>none</tt> is defined as zero and represents no
+category. And locale member bitmask constant <tt>all</tt> is defined such that
+the expression</p>
+<pre>
+ (collate | ctype | monetary | numeric | time | messages | all) == all
+</pre>
+<p>
+is <tt>true</tt>, and represents the union of all categories. Further
+the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
+represent a single category, represents the union of the two
+categories.
+</p>
+
+<p>
+<tt>locale</tt> member functions expecting a <tt>category</tt>
+argument require one of the <tt>category</tt> values defined above, or
+the union of two or more such values. Such a <tt>category</tt>
+argument identifies a set of locale categories. Each locale category,
+in turn, identifies a set of locale facets, including at least those
+shown in Table 51:
+</p>
+</blockquote>
+
+<p>
+<b>Option 2:</b> <br>
+Replace the first paragraph of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
+<blockquote>
+<p>
+Valid category values include the enumerated values. In addition, the
+result of applying commutative operators | and & to any two valid
+values is valid, and results in the setwise union and intersection,
+respectively, of the argument categories. The values <tt>all</tt> and
+<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
+expressions <tt>(cat | all == all)</tt>, <tt>(cat & all == cat)</tt>,
+<tt>(cat | none == cat)</tt> and <tt>(cat & none == none)</tt> are
+true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
+remaining enumerated values, <tt>(cat1 & cat2 == none)</tt> is true.
+For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
+of <tt>(cat1 & ~cat2)</tt> is valid, and equals the setwise union of
+those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
+[Footnote: it is not required that <tt>all</tt> equal the setwise union
+of the other enumerated values; implementations may add extra categories.]
+</p>
+</blockquote>
+
+<hr>
+<a name="348"><h3>348. Minor issue with std::pair operator<</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#New">New</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 23 Oct 2001</p>
+<p>
+The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
+operator< on any pair type which contains a pointer.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 6, replace:</p>
+<pre>
+ Returns: x.first < y.first || (!(y.first < x.first) && x.second <
+ y.second).
+</pre>
+<p>With:</p>
+<pre>
+ Returns: std::less<T1>()( x.first, y.first ) ||
+ (!std::less<T1>()( y.first, x.first) &&
+ std::less<T2>()( x.second, y.second ) )
+</pre>
+<hr>
+<a name="349"><h3>349. Minor typographical error in ostream_iterator</h3></a><p>
+<b>Section:</b> 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 24 Oct 2001</p>
+<p>24.5.2 [lib.ostream.iterator] states:</p>
+<pre>
+ [...]
+
+ private:
+ // basic_ostream<charT,traits>* out_stream; exposition only
+ // const char* delim; exposition only
+</pre>
+
+<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
+should be of type 'const charT*'.</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
+<tt>const charT* delim</tt>.
+</p>
+<hr>
+<a name="350"><h3>350. allocator<>::address</h3></a><p>
+<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 25 Oct 2001</p>
+<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
+verbatim from -9007.</p>
+
+<p>
+The core language feature allowing definition of operator&() applied
+to any non-builtin type makes that operator often unsafe to use in
+implementing libraries, including the Standard Library. The result
+is that many library facilities fail for legal user code, such as
+the fragment</p>
+<pre>
+ class A { private: A* operator&(); };
+ std::vector<A> aa;
+
+ class B { };
+ B* operator&(B&) { return 0; }
+ std::vector<B> ba;
+</pre>
+
+<p>
+In particular, the requirements table for Allocator (Table 32) specifies
+no semantics at all for member address(), and allocator<>::address is
+defined in terms of unadorned operator &.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.4.1.1, Change the definition of allocator<>::address from:</p>
+<blockquote>
+ Returns: &x
+</blockquote>
+
+<p>to:</p>
+
+<p>
+ Returns: The value that the built in operator&(x) would return if not
+ overloaded.
+</p>
+
+<p>
+In 20.1.5, Table 32, add to the Notes column of the a.address(r) and
+a.address(s) lines, respectively:
+</p>
+
+<pre>
+ allocator<T>::address(r)
+ allocator<T>::address(s)
+</pre>
+
+<p>In addition, in clause 17.4.1.1, add a statement:</p>
+
+<blockquote>
+ The Standard Library does not apply operator& to any type for which
+ operator& may be overloaded.
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>The obvious implementations for std::allocator<>::address are</p>
+<pre>
+ T* reinterpret_cast<T*>(&static_cast<char&>(o));
+</pre>
+
+<p>and</p>
+
+<pre>
+ T const* reinterpret_cast<T const*>(&static_cast<char const&>(o));
+</pre>
+
+<p>
+but to define them formally in terms of reinterpret_cast<> seems
+to introduce semantic difficulties best avoided. Using a.address()
+should not introduce unspecified or implementation-defined semantics
+into a user program.</p>
<p>----- End of document -----</p>
</body>
</html>
<table>
<tr>
<td align="left">Doc. no.</td>
-<td align="left">J16/01-0032 = WG21 N1318</td>
+<td align="left">J16/01-0053 = WG21 N1338</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">11 Sep 2001</td>
+<td align="left">09 Nov 2001</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Matt Austern <austern@research.att.com></td>
</tr>
</table>
-<h1>C++ Standard Library Defect Report List (Revision 19)</h1>
+<h1>C++ Standard Library Defect Report List (Revision 20)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
document.</p>
<h2>Revision History</h2>
<ul>
+<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-active.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-active.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-active.html#335">335</a>.
</li>
<li>R18:
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="lwg-
active.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
-new issues <a href="lwg-
active.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
+Added new issues <a href="lwg-
defects.html#312">312</a>-<a href="lwg-active.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>
to DR.
Changed status of issues
-<a href="lwg-active.html#49">49</a> <a href="lwg-active.html#109">109</a> <a href="lwg-active.html#117">117</a> <a href="lwg-active.html#182">182</a>
-<a href="lwg-active.html#228">228</a> <a href="lwg-active.html#230">230</a> <a href="lwg-active.html#232">232</a> <a href="lwg-active.html#235">235</a>
-<a href="lwg-active.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-active.html#242">242</a> <a href="lwg-active.html#250">250</a>
-<a href="lwg-active.html#259">259</a> <a href="lwg-active.html#264">264</a> <a href="lwg-active.html#266">266</a> <a href="lwg-active.html#267">267</a>
-<a href="lwg-active.html#271">271</a> <a href="lwg-active.html#272">272</a> <a href="lwg-active.html#273">273</a> <a href="lwg-active.html#275">275</a>
-<a href="lwg-active.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-active.html#285">285</a> <a href="lwg-active.html#286">286</a>
-<a href="lwg-active.html#288">288</a> <a href="lwg-active.html#292">292</a> <a href="lwg-active.html#295">295</a> <a href="lwg-active.html#297">297</a>
-<a href="lwg-active.html#298">298</a> <a href="lwg-active.html#301">301</a> <a href="lwg-active.html#303">303</a> <a href="lwg-active.html#306">306</a>
-<a href="lwg-active.html#307">307</a> <a href="lwg-active.html#308">308</a> <a href="lwg-active.html#312">312</a>
+<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-active.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
</li>
<li>R17:
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="lwg-active.html#49">49</a>, <a href="lwg-active.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#235">235</a>, <a href="lwg-active.html#250">250</a>, <a href="lwg-active.html#267">267</a>.
+resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-active.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-active.html#311">311</a>.
</li>
<li>R16:
</li>
<li>R15:
pre-Toronto mailing. Added issues
-<a href="lwg-active.html#233">233</a>-<a href="lwg-active.html#264">264</a>. Some small HTML formatting
+<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-active.html#228">228</a> to <a href="lwg-active.html#232">232</a>. (00-0019R1/N1242)
+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>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-
active.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
+<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:
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-active.html#109">109</a>
+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:
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 paragraph 2
+<p>Change 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
from:</p>
<blockquote>
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
+<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>
size_type n2) const;</tt></p>
</blockquote>
-<p>Replace the portion of 21.3.6.8
+<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>
<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#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
-<p>(1) In 21.3.5.4 , the description of template
+<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
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 </p>
+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 ,
+<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
<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 ,
+<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><b>Proposed resolution:</b></p>
<p>ITEMS 1 AND 2:<br>
<br>
-In the bitset synopsis (23.3.5 ),
+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> 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 ,
+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>
</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 .
+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>
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 , replace "eos" with
+<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>
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 and also in 22.1.1.3 , add
+<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>
<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 , paragraph 5, replace
+<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>
<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 .</p>
+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#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
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 , in the first line of paragraph 14,
+<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>
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
+<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 .</p>
+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#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</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 to read:
+22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
</p>
<blockquote>
<p>
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 , above paragraph 2, change
+<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>
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 to the table captioned
+<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>
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 paragraph 3, <i>and</i> in 27.8.1.10 paragraph 3, under open() effects, add a footnote:
+<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#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
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 , paragraph 3, change
-"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 , change "do_convert()" to "do_in
+<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>
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 paragraph 4 from:<br>
+<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>
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
+<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
"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 , paragraph 10, change: </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
<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 , paragraph 4, to read </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]
<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#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
-<p>Sections 27.3.1 and 27.3.2 mention
+<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 ,
+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 paragraph 2 and 5, change </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>
<p>basic_ios<char>::init </p>
</blockquote>
-<p>Also, make a similar change in 27.3.2 except it
+<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>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 , paragraph 2, change
+<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>
...". This has caused some confusion, because locale variables
are manifestly assignable. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 replace paragraph 6</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
<p>It appears that the pbackfail description is wrong. </p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.4 , paragraph 1, change:</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>
<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 paragraph 4, replace the definition
+<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>
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 , paragraph 19, in the Effects:
+<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>
<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#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
-<p>In 27.4.5.1 , we have a definition for a manipulator
+<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 , after
+<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>
<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 , in both paragraph 2 and also in
+<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>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 , paragraph 4, delete the parenthesized
+<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
expression </p>
<blockquote>
<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 . </p>
+ 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>[
return(tmp); </pre>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 , delete the three lines of code at the
+<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [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>
implementation technique that has lost its referent, and doesn't mean
anything. </p>
<p><b>Proposed resolution:</b></p>
-<p>Delete 22.2.8 paragraph 3 which begins "This
+<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#DR">DR</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 , say that if they fail, they "set badbit,
+<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 in
+<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>
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 , replace the declaration of the copy
+<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>
const Allocator& a = Allocator());</pre>
</blockquote>
-<p>In 21.3.1 , replace the copy constructor declaration
+<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>The LWG considered two other possible resolutions:</p>
-<p>A. In 21.3 , replace the declaration of the copy
+<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>
size_type n, const Allocator& a); </pre>
</blockquote>
-<p>In 21.3.1 , replace the copy constructor declaration
+<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>
value <tt>str.get_allocator()</tt>. </p>
</blockquote>
-<p>B. In 21.3 , and also in 21.3.1 , replace
+<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>
<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</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 (since streambuf is a typedef of
+<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>
<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
-<p>In D.7.4 insert the semicolon now missing after
+<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 {
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 swap paragraphs 2 and 4.</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#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
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 , paragraph 2, with</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#DR">DR</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
semantics (e.g. what happens to the iarray and parray stuff).
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2 , class ios_base, specify the copy
+<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
<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#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
-<p>First, 27.4.4.1 , table 89. This is pretty obvious:
+<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 table 88 . There are a couple
+<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
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 table 89 title from
+<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>
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 paragraph 2:</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>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 , paragraph 6. This issue was reviewed at length
+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>
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 paragraph 2:</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>
stream position" should not be changed:</p>
<blockquote>
- <p>27.7.1.3 , paragraph 14<br>
- 27.8.1.4 , paragraph 14<br>
- D.7.1.3 , paragraph 17
- <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>
-</p>
+ <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 , paragraph 4, change "Returns an
+<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 , paragraph 6, change "Returns
+<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 , paragraph 13, change "the object
+<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 , paragraph 13, change "returns an
+<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 , paragraph 15, change "Otherwise
+<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 , paragraph 15, change "the object
+<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 , paragraph 18, change "the object
+<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>
return type is streamsize. </p>
<p><b>Proposed resolution:</b></p>
<p>Change <tt>showmanyc</tt>'s return type in the
-27.5.2 class summary to <tt>streamsize</tt>.</p>
+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#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
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 paragraph 3 which
+<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>
<p>(The "classic" AT&T implementation used the
former interpretation.)</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.3.1 paragraph 4 gbump effects from:</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>
<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 paragraph 4 pbump
+<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>
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 paragraphs 1 to 5 to be "Formatted input
+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 : If this is the case, all manipulators, not
+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 are unformatted input
+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
<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 , paragraph 36, change "returns
+<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>
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 , paragraph 13, which begins
+<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>
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 , paragraph 19, replace the setbuf effects
+<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:<a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>
-</p>
+with:</p>
<blockquote>
<p>
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 , paragraph 7, change the last list
-item from:<a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>
-</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
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 ,
+<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>
<ul>
<li>An operational definition similar to the above proposed resolution is
- already used for valarray (26.3.2.3 ).</li>
+ 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 para 3)
- and copyconstructible (20.1.3 ) specifies
+ 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>
<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 , paragraph 1, 18.6 , and 18.6.4 , add "throw()" to uncaught_exception().</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#DR">DR</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 with five arguments,
+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 , add an "end" argument to
+<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&,
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 paragraph 11 with the
+<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>
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 , and also in 22.2.1.6 ,
+<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>
<p><tt>stateT&</tt></p>
</blockquote>
-<p>In 22.2.1.5.2 , add to the definition for member
+<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>
<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#DR">DR</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 synopsis change
+<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#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
-<p>In 26.2.1 polar is declared as follows:</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 it is declared as follows:</p>
+<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 change:</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>
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 paragraph 4 ("The functions
+<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>
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 , Strike throws paragraphs for
+<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>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 paragraph 1 Effects clause replace:</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>
<p><tt>typedef implementation defined iterator;<br>
// See _lib.container.requirements_</tt></p>
-<p>23.1 actually requires that iterator type pointing
+<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
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. <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>
-</p>
+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 , paragraph 2, after
+<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>
<p>Modification of keys shall not change their strict weak ordering. </p>
</blockquote>
-<p>Option B. Add three new sentences to 23.1.2 :</p>
+<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
type."</p>
</blockquote>
-<p>Option C. To 23.1.2 , paragraph 3, which
+<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>
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 at
+<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>
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 paragraph 9 (exception::what notes
+<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>
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#DR">DR</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 says that operator==,
+"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 and also in 24.5.3.5 ,
+<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>
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 :</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>
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 with:
+18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
</p>
<blockquote>
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 paragraph 2 and D.7.4.1
+<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>,
use_facet< numget >(loc).get(*this, 0, *this, err, val);
setstate(err);</pre>
-<p>According to section 22.2.2.1.1 , however,
+<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>,
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 Arithmetic Extractors, remove the
+<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);
<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#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>Section 17.4.4.8 states: </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>
// overridden virtual function ios_base::failure::~failure()
};</pre>
<p><b>Proposed resolution:</b></p>
-<p>Change Section 17.4.4.8 from:</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>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 paragraphs 2 and 3 (the above two
+<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
<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#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>In Section 22.2.1.2
+<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 <tt>do_scan_is()</tt> and
+<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#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
-<p>In Section 26.3.2 valarray<T>::operator!() is
-declared to return a valarray<T>, but in Section 26.3.2.5 it is declared to return a valarray<bool>. The
+<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 the declaration of
+<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>
<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#DR">DR</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 change: </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>Tokyo: The LWG removed the following from the proposed resolution:</p>
- <p>In 20.4.5 , paragraph 2, and 20.4.5.3 ,
+ <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 , paragraph 2, move
+<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 , paragraph 2, add
+<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 : </p>
+<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>
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 and to the Effects: clause of seekp() in
-27.6.2.4 : </p>
+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>).
<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</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>The title says it all.</p>
<p><b>Proposed resolution:</b></p>
-<p>Insert in 23.3.1 , paragraph 2,
+<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>
<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 , paragraph 1 to:</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)
<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#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
-<p>Section 22.1.1 says:</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
function has_facet<Facet>(). </p>
<p>This contradicts the specification given in section
-22.1.2 :
+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>
right! (and Matt states this complexity in his book)</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.8 complexity to:</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.
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 paragraph 14 (operator>>), add a
+<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>
<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#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
-<p>In 22.2.8 paragraph 13, the do_truename() and
+<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 paragraph 13, insert "const" in
+<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>
<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#DR">DR</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
<p><b>Proposed resolution:</b></p>
-<p>Change 25.1.4 paragraph 2 from:</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
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 paragraphs 4 and 6, change the returns
+<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>
one of them.</p>
<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2
+<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> Returns: do_widen(c) or do_widen(low, high, to),
respectively.</p>
-<p>Change 22.2.1.3.2 paragraph 10 and 11 from:</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>
(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 , paragraph 7, add a row in the Length
+<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>
</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#DR">DR</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 paragraph 2
-it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 it is defined as <tt>ios_base::Init</tt>.</p>
+<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 paragraph 2 from
+<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>
<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#DR">DR</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 the argument is passed as
-<tt>locale const&</tt> (correct), in 27.4.2.3 it
+<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 change the <tt>imbue</tt> argument
+<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>
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 , paragraph 3, Default behavior,
+<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>
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 paragraph 1,
+<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>
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 , 27.6.1.3 , paragraph 1,
-27.6.2.1 , paragraph 3, and 27.6.2.5.1 ,
+<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>
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 from:</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>
<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#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
-<p>In 22.2.5.3.2 the do_put() function is specified
+<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
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
+<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
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 paragraph 1, the first and last
+<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>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 ): For each character to be inserted, a new buffer
+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 paragraph 8, Notes, insert the words
+<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
<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#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
-<p>The classes <tt>basic_stringstream</tt> (27.7.4 ),
-<tt>basic_istringstream</tt> (27.7.2 ), and
-<tt>basic_ostringstream</tt> (27.7.3 ) are inconsistent
+<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 ) and
-<tt>basic_stringstream</tt> (27.7.4 ) add:</p>
+<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 paragraph 3, it is stated that a joint input and
+<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
<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#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
-<p>In 27.6.1.1 the function
+<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
+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>
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 paragraph 23 and 24, change both uses
+<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>
<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> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>
-In 27.8.1.1 the function <tt>setbuf()</tt> gets an
+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 paragraph 9 the second argument is of type
+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>
<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.4 paragraph 9, change all uses of
+<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>
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
</p>
<p><b>Proposed resolution:</b></p>
-<p>Change D.6 paragraph 1 from "<tt>typedef
+<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>
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 paragraph 8, remove the default arguments for
+<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>
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 ."</p>
+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 paragraph 8, move the declaration of the
+<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>
I doubt anyone intended that behavior...
</p>
<p><b>Proposed resolution:</b></p>
-<p>In 20.2 , paragraph 1 change the following
+<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>
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
</blockquote>
-<p> In 20.2.2 paragraph 7 and the line before, change:</p>
+<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>
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 paragraph 3 says (clause numbering added for
-exposition):<a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>
-</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
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 except paragraph 1 with the
+<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
<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 paragraph 7. However "integer types"
+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>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 :</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 {
<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 says:</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
<p>Thus the example "mandates" behavior that is explicitly
not required elsewhere.</p>
<p><b>Proposed resolution:</b></p>
-<p>In 20.3 paragraph 1, remove the sentence:</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 paragraph 2, which reads:</p>
+<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 paragraph 4, remove the sentence:</p>
+<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>
<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 , paragraph 13 defines the
+<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
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 Para 1 Replace:</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>
<blockquote>
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
</blockquote>
-<p>In 23.3.5.2 Para 12(.5) Replace:</p>
+<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>
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 , paragraph 9, the text
+<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>
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 property (1) from:</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>
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 says that
+<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 paragraph 4 says that if
+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
<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 paragraph 5, the last sentence, from:</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>
<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#DR">DR</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
-<p>In Section 21.3 the basic_string member function
+<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);
- 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 change the basic_string member
+<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);
<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#DR">DR</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
-<p>In paragraph 9 of section 25 , it is written:</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
</p>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>On the last line of paragraph 9 of section 25 change
+<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>
</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 and 27.6.1.3 ), where this
+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 paragraph 8.)</p>
+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 :</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
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 - Minimum and maximum, paragraphs 7 and
+<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
</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 and section 23.3.4 to each have two overloads:</p>
+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>
</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 paragraph 4.</p>
+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
"Effects" clauses correct, or are the "Throws" clauses
missing?</p>
<p><b>Proposed resolution:</b></p>
-<p>In 17.3.1.3 paragraph 3, the footnote 148 attached to
+<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>
<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#DR">DR</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 , replace:</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.
<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
<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
<p>to become</p>
<blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
<hr>
-<a name="2
43"><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>
+<a name="2
38"><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>
-<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>
+<pre>
+ std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
+ std::cout << "'" << sbuf.str() << "'\n";
+</pre>
-<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>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>Add to 27.6.1.3, p1 after the sentence</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="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>
-"... If the sentry object returns true, when converted to a value of
-type bool, the function endeavors to obtain the requested input."
+ -2- Requires: op and binary_op shall not have any side effects.
</blockquote>
-<p>the following</p>
-
+<p>to:</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."
+ -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
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>
<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>
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>
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:
locale() throw();
locale(const locale& other) throw();
</pre>
+<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="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="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="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="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>
<p>----- End of document -----</p>
</body>
</html>
OSDN Git Service
