<html>
    <head>
        <title>C++ Standard Library Closed Issues List</title>
    </head>
    <body bgcolor="#ffffff" text="#000000">
        <table>
            <tr>
                <td>Doc. no.</td><td>J16/01-0007 = WG21 N1293</td>
            </tr>
            <tr>
                <td>Date:</td><td>20 Mar 2001</td>
            </tr>
            <tr>
                <td>Project:</td><td>Programming Language C++</td>
            </tr>
            <tr>
                <td>Reply to:</td><td>Matt Austern &lt;austern@research.att.com&gt;</td>
            </tr>
        </table>
        <h1>C++ Standard Library Closed Issues List
       (Revision 17)
     </h1>
        <p>Reference ISO/IEC IS 14882:1998(E)</p>
        <p>Also see:</p>
        <ul>
            <li>
                <a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
            <li>
                <a href="lwg-index.html">Index by Section</a> for all library issues.</li>
            <li>
                <a href="lwg-status.html">Index by Status</a> for all library issues.</li>
            <li>
                <a href="lwg-active.html">Library Active Issues List</a>
            </li>
            <li>
                <a href="lwg-defects.html">Library Defect Report List</a>
            </li>
            <li>
                <a href="lwg-prep.html">How to prepare and submit an issue</a>.</li>
        </ul>
        <p>This document contains only library issues which have been closed
  by the Library Working Group as duplicates or not defects. That is,
  issues which have a status of <a href="lwg-active.html#Dup">Dup</a>
  or <a href="lwg-active.html#NAD">NAD</a>. See "<a href="lwg-active.html">C++ Standard Library Active Issues
  List</a>" for active issues and more information. See "<a href="lwg-defects.html">C++ Standard Library Defect Report
  List</a>" for issues considered defects. The introductory
  material in that document also applies to this document.</p>
        <h2>Revision History</h2>
        <ul>
            <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>.
Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-active.html#311">311</a>.
</li>
            <li>R16:  
post-Toronto mailing; reflects actions taken in Toronto. Added new
issues <a href="lwg-active.html#265">265</a>-<a href="lwg-active.html#277">277</a>.  Changed status of issues
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
<a href="lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
the bug in enough places.
</li>
            <li>R15: 
pre-Toronto mailing. Added issues
<a href="lwg-active.html#233">233</a>-<a href="lwg-active.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)
</li>
            <li>R13: 
pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
</li>
            <li>R12: 
pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
of issue <a href="lwg-defects.html#29">29</a>.  Add further rationale to issue
<a href="lwg-closed.html#178">178</a>.
</li>
            <li>R11: 
post-Kona mailing: Updated to reflect LWG and full committee actions
in Kona (99-0048/N1224). Note changed resolution of issues
<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
to <a href="lwg-active.html#198">198</a>. Closed issues list split into "defects" and
"closed" documents.  Changed the proposed resolution of issue
<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
of issue <a href="lwg-defects.html#38">38</a>.
</li>
            <li>R10: 
pre-Kona updated.  Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
<a href="lwg-defects.html#86">86</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
<a href="lwg-active.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
</li>
            <li>R9: 
pre-Kona mailing.  Added issues <a href="lwg-closed.html#140">140</a> to
<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and
"closed" documents. (99-0030/N1206, 25 Aug 99)
</li>
            <li>R8: 
post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
            <li>R7: 
pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
<a href="lwg-closed.html#135">135</a>, <a href="lwg-active.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
</li>
            <li>R6: 
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
and <a href="lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
</li>
            <li>R5: 
update issues <a href="lwg-active.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
for making list public. (30 Dec 98)
</li>
            <li>R4: 
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
<a href="lwg-active.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
            <li>R3: 
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-active.html#109">109</a>
added, many issues updated to reflect LWG consensus (12 Oct 98)
</li>
            <li>R2: 
pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
</li>
            <li>R1: 
Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
</li>
        </ul>
        <h2>
        </h2>
        <hr>
        <a name="2">
            <h3>2.&nbsp;Auto_ptr conversions effects incorrect</h3>
        </a>
        <p>
            <b>Section:</b> 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv">[lib.auto.ptr.conv]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nathan Myers <b>Date:</b>&nbsp;4 Dec 1997</p>
<p>Paragraph 1 in "Effects", says "Calls
p-&gt;release()" where it clearly must be "Calls
p.release()". (As it is, it seems to require using
auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
exists.)</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Change 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv">[lib.auto.ptr.conv]</a> paragraph 1 Effects from 
"Calls p-&gt;release()" to "Calls p.release()".</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect: the proposed change is already found in the standard.
[Originally classified as a defect, later reclassified.]</p>
<hr>
        <a name="4">
            <h3>4.&nbsp;Basic_string size_type and difference_type should be implementation defined</h3>
        </a>
        <p>
            <b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string">[lib.basic.string]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Beman Dawes <b>Date:</b>&nbsp;16 Nov 1997</p>
<p>In Morristown we changed the size_type and difference_type typedefs
for all the other containers to implementation defined with a
reference to 23.1 <a href="lib-containers.html#lib.container.requirements">[lib.container.requirements]</a>.  This should probably also have been
done for strings. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect.  [Originally classified as a defect, later
reclassified.]  basic_string, unlike the other standard library
template containers, is severely constrained by its use of
char_traits. Those types are dictated by the traits class, and are far
from implementation defined.</p>
<hr>
        <a name="6">
            <h3>6.&nbsp;File position not an offset unimplementable</h3>
        </a>
        <p>
            <b>Section:</b> 27.4.3 <a href="lib-iostreams.html#lib.fpos">[lib.fpos]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;15 Dec 1997</p>
<p>Table 88, in I/O, is too strict; it's unimplementable on systems
where a file position isn't just an offset. It also never says just
what fpos&lt;&gt; is really supposed to be.  [Here's my summary, which
Jerry agrees is more or less accurate. "I think I now know what
the class really is, at this point: it's a magic cookie that
encapsulates an mbstate_t and a file position (possibly represented as
an fpos_t), it has syntactic support for pointer-like arithmetic, and
implementors are required to have real, not just syntactic, support
for arithmetic." This isn't standardese, of course.] </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. The LWG believes that the Standard is already clear,
and that the above summary is what the Standard in effect says.</p>
<hr>
        <a name="10">
            <h3>10.&nbsp;Codecvt&lt;&gt;::do unclear</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>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;14 Jan 1998</p>
<p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
should return the value noconv if "no conversion was
needed". However, I don't see anything anywhere that defines what
it means for a conversion to be needed or not needed. I can think of
several circumstances where one might plausibly think that a
conversion is not "needed", but I don't know which one is
intended here. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#19">19</a>.</p>
<hr>
        <a name="12">
            <h3>12.&nbsp;Way objects hold allocators unclear</h3>
        </a>
        <p>
            <b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements">[lib.allocator.requirements]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Angelika Langer <b>Date:</b>&nbsp;23 Feb 1998</p>
<p>I couldn't find a statement in the standard saying whether the allocator object held by
a container is held as a copy of the constructor argument or whether a pointer of
reference is maintained internal. There is an according statement for compare objects and
how they are maintained by the associative containers, but I couldn't find anything
regarding allocators. </p>

<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
unspecified? </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. The LWG believes that the Standard is already
clear.&nbsp; See 23.1 <a href="lib-containers.html#lib.container.requirements">[lib.container.requirements]</a>, paragraph 8.</p>
<hr>
        <a name="43">
            <h3>43.&nbsp;Locale table correction</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>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Brendan Kehoe <b>Date:</b>&nbsp;1 Jun 1998</p>
        <p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#33">33</a>.</p>
<hr>
        <a name="45">
            <h3>45.&nbsp;Stringstreams read/write pointers initial position unclear</h3>
        </a>
        <p>
            <b>Section:</b> 27.7.3 <a href="lib-iostreams.html#lib.ostringstream">[lib.ostringstream]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matthias Mueller <b>Date:</b>&nbsp;27 May 1998</p>
<p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>

<p>"We are not sure how to interpret the CD2 (see 27.2 <a href="lib-iostreams.html#lib.iostream.forward">[lib.iostream.forward]</a>, 27.7.3.1 <a href="lib-iostreams.html#lib.ostringstream.cons">[lib.ostringstream.cons]</a>, 27.7.1.1 <a href="lib-iostreams.html#lib.stringbuf.cons">[lib.stringbuf.cons]</a>)
with respect to the question as to what the correct initial positions
of the write and&nbsp; read pointers of a stringstream should
be."</p>

<p>"Is it the same to output two strings or to initialize the stringstream with the
first and to output the second?"</p>

<p>
            <i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
Jerry Schwarz have all offered opinions; see reflector messages
lib-6518, 6519, 6520, 6521, 6523, 6524.]</i>
        </p>

<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes the Standard is correct as written. The behavior
of stringstreams is consistent with fstreams, and there is a
constructor which can be used to obtain the desired effect. This
behavior is known to be different from strstreams.</p>
<hr>
        <a name="58">
            <h3>58.&nbsp;Extracting a char from a wide-oriented stream</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors">[lib.istream::extractors]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;1 Jul 1998</p>
<p>27.6.1.2.3 has member functions for extraction of signed char and
unsigned char, both singly and as strings. However, it doesn't say
what it means to extract a <tt>char</tt> from a
<tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>

<p>basic_streambuf, after all, has no members to extract a char, so
basic_istream must somehow convert from charT to signed char or
unsigned char. The standard doesn't say how it is to perform that
conversion. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>The Standard is correct as written.  There is no such extractor and
this is the intent of the LWG.</p>
<hr>
        <a name="65">
            <h3>65.&nbsp;Underspecification of strstreambuf::seekoff</h3>
        </a>
        <p>
            <b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals">[depr.strstreambuf.virtuals]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;18 Aug 1998</p>
<p>The standard says how this member function affects the current
stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
say how this member function affects the beginning and end of the
get/put area. </p>

<p>This is an issue when seekoff is used to position the get pointer
beyond the end of the current read area. (Which is legal. This is
implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG agrees that seekoff() is underspecified, but does not wish
to invest effort in this deprecated feature.</p>
<hr>
        <a name="67">
            <h3>67.&nbsp;Setw useless for strings</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io">[lib.string.io]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Steve Clamage <b>Date:</b>&nbsp;9 Jul 1998</p>
<p>In a comp.std.c++ posting Michel Michaud wrote: What
should be output by: </p>

<pre>   string text("Hello");
   cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
</pre>

<p>Shouldn't it be:</p>

<pre>   [     Hello]</pre>

<p>Another person replied: Actually, according to the FDIS, the width
of the field should be the minimum of width and the length of the
string, so the output shouldn't have any padding. I think that this is
a typo, however, and that what is wanted is the maximum of the
two. (As written, setw is useless for strings. If that had been the
intent, one wouldn't expect them to have mentioned using its value.)
</p>

<p>It's worth pointing out that this is a recent correction anyway;
IIRC, earlier versions of the draft forgot to mention formatting
parameters whatsoever.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#25">25</a>.</p>
<hr>
        <a name="72">
            <h3>72.&nbsp;Do_convert phantom member function</h3>
        </a>
        <p>
            <b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt">[lib.locale.codecvt]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nathan Myers <b>Date:</b>&nbsp;24 Aug 1998</p>
<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt">[lib.locale.codecvt]</a> par 3, and in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals">[lib.locale.codecvt.virtuals]</a> par 8, a nonexistent member function
"do_convert" is mentioned. This member was replaced with
"do_in" and "do_out", the proper referents in the
contexts above.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate: see issue <a href="lwg-defects.html#24">24</a>.</p>
<hr>
        <a name="73">
            <h3>73.&nbsp;<tt>is_open</tt> should be const</h3>
        </a>
        <p>
            <b>Section:</b> 27.8.1 <a href="lib-iostreams.html#lib.fstreams">[lib.fstreams]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;27 Aug 1998</p>
<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
should be a <tt>const</tt> member function, since it does nothing but
call one of <tt>basic_filebuf</tt>'s const member functions. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. This is a deliberate feature; const streams would be
meaningless.</p>
<hr>
        <a name="77">
            <h3>77.&nbsp;Valarray operator[] const returning value</h3>
        </a>
        <p>
            <b>Section:</b> 26.3.2.3 <a href="lib-numerics.html#lib.valarray.access">[lib.valarray.access]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Levente Farkas <b>Date:</b>&nbsp;9 Sep 1998</p>
<p>valarray:<br>
<br>
&nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt>
            <br>
<br>
why not <br>
<br>
&nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt>
            <br>
<br>
as in vector ???<br>
<br>
One can't copy even from a const valarray eg:<br>
<br>
&nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
</tt>
            <br>
[I] find this bug in valarray is very difficult.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes that the interface was deliberately designed that
way. That is what valarray was designed to do; that's where the
"value array" name comes from. LWG members further comment
that "we don't want valarray to be a full STL container."
26.3.2.3 <a href="lib-numerics.html#lib.valarray.access">[lib.valarray.access]</a> specifies properties that indicate "an
absence of aliasing" for non-constant arrays; this allows
optimizations, including special hardware optimizations, that are not
otherwise possible. </p>
<hr>
        <a name="81">
            <h3>81.&nbsp;Wrong declaration of slice operations</h3>
        </a>
        <p>
            <b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array">[lib.template.slice.array]</a>, 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array">[lib.template.gslice.array]</a>, 26.3.8 <a href="lib-numerics.html#lib.template.mask.array">[lib.template.mask.array]</a>, 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array">[lib.template.indirect.array]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>Isn't the definition of copy constructor and assignment operators wrong?
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;); 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>

<p>IMHO they have to be</p>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;); 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>

<p>Same for gslice_array. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. The Standard is correct as written. </p>
<hr>
        <a name="82">
            <h3>82.&nbsp;Missing constant for set elements</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>Paragraph 5 specifies:</p>

<blockquote>
For set and multiset the value type is the same as the key type. For
map and multimap it is equal to pair&lt;const Key, T&gt;.  
</blockquote>

<p>Strictly speaking, this is not correct because for set and multiset
the value type is the same as the <b>constant</b> key type.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. The Standard is correct as written; it uses a
different mechanism (const &amp;) for <tt>set</tt> and
<tt>multiset</tt>. See issue <a href="lwg-active.html#103">103</a> for a related
issue.</p>
<hr>
        <a name="84">
            <h3>84.&nbsp;Ambiguity with string::insert()</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.5 <a href="lib-strings.html#lib.string.modifiers">[lib.string.modifiers]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>If I try</p>
<pre>    s.insert(0,1,' ');</pre>

<p>&nbsp; I get an nasty ambiguity. It might be</p>
<pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>

<p>which inserts 1 space character at position 0, or</p>
<pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>

<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
<pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>

<p>which normally inserts characters from iterator 1 to iterator '
'. But according to 23.1.1.9 (the "do the right thing" fix)
it is equivalent to the second. However, it is still ambiguous,
because of course I mean the first!</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Not a defect. The LWG believes this is a "genetic
misfortune" inherent in the design of string and thus not a
defect in the Standard as such .</p>
<hr>
        <a name="85">
            <h3>85.&nbsp;String char types</h3>
        </a>
        <p>
            <b>Section:</b> 21 <a href="lib-strings.html#lib.strings">[lib.strings]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>The standard seems not to require that charT is equivalent to
traits::char_type. So, what happens if charT is not equivalent to
traits::char_type?</p>
<p>
            <b>Rationale:</b>
        </p>
<p>There is already wording in 21.1 <a href="lib-strings.html#lib.char.traits">[lib.char.traits]</a> paragraph 3 that
requires them to be the same.</p>
<hr>
        <a name="87">
            <h3>87.&nbsp;Error in description of string::compare()</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare">[lib.string::compare]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>The following compare() description is obviously a bug:</p>

<pre>
int compare(size_type pos, size_type n1, 
            charT *s, size_type n2 = npos) const;
</pre>

<p>because without passing n2 it should compare up to the end of the
string instead of comparing npos characters (which throws an
exception) </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate; see issue <a href="lwg-defects.html#5">5</a>.</p>
<hr>
        <a name="88">
            <h3>88.&nbsp;Inconsistency between string::insert() and string::append()</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.5.4 <a href="lib-strings.html#lib.string::insert">[lib.string::insert]</a>, 21.3.5.2 <a href="lib-strings.html#lib.string::append">[lib.string::append]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>Why does </p>
<pre>  template&lt;class InputIterator&gt; 
       basic_string&amp; append(InputIterator first, InputIterator last);</pre>

<p>return a string, while</p>
<pre>  template&lt;class InputIterator&gt; 
       void insert(iterator p, InputIterator first, InputIterator last);</pre>

<p>returns nothing ?</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes this stylistic inconsistency is not sufficiently 
serious to constitute a defect.</p>
<hr>
        <a name="89">
            <h3>89.&nbsp;Missing throw specification for string::insert() and string::replace()</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.5.4 <a href="lib-strings.html#lib.string::insert">[lib.string::insert]</a>, 21.3.5.6 <a href="lib-strings.html#lib.string::replace">[lib.string::replace]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>All insert() and replace() members for strings with an iterator as
first argument lack a throw specification. The throw
specification should probably be: length_error if size exceeds
maximum. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Considered a duplicate because it will be solved by the resolution
of issue <a href="lwg-defects.html#83">83</a>.</p>
<hr>
        <a name="93">
            <h3>93.&nbsp;Incomplete Valarray Subset Definitions</h3>
        </a>
        <p>
            <b>Section:</b> 26.3 <a href="lib-numerics.html#lib.numarray">[lib.numarray]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>You can easily create subsets, but you can't easily combine them
with other subsets.  Unfortunately, you almost always needs an
explicit type conversion to valarray. This is because the standard
does not specify that valarray subsets provide the same operations as
valarrays. </p>

<p>For example, to multiply two subsets and assign the result to a third subset, you can't
write the following:</p>

<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>

<p>Instead, you have to code as follows:</p>

<pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) * 
                   static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>

<p>This is tedious and error-prone. Even worse, it costs performance because each cast
creates a temporary objects, which could be avoided without the cast. </p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Extend all valarray subset types so that they offer all valarray operations.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard; it is a request for an extension.</p>
<hr>
        <a name="94">
            <h3>94.&nbsp;May library implementors add template parameters to Standard Library classes?</h3>
        </a>
        <p>
            <b>Section:</b> 17.4.4 <a href="lib-intro.html#lib.conforming">[lib.conforming]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt Austern <b>Date:</b>&nbsp;22 Jan 1998</p>
<p>Is it a permitted extension for library implementors to add template parameters to
standard library classes, provided that those extra parameters have defaults? For example,
instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
int N = 1&gt; class vector;</tt> </p>

<p>The standard may well already allow this (I can't think of any way that this extension
could break a conforming program, considering that users are not permitted to
forward-declare standard library components), but it ought to be explicitly permitted or
forbidden. </p>

<p>comment from Steve Cleary via comp.std.c++:</p>
<blockquote>
<p>I disagree [with the proposed resolution] for the following reason:
consider user library code with template template parameters. For
example, a user library object may be templated on the type of
underlying sequence storage to use (deque/list/vector), since these
classes all take the same number and type of template parameters; this
would allow the user to determine the performance tradeoffs of the
user library object. A similar example is a user library object
templated on the type of underlying set storage (set/multiset) or map
storage (map/multimap), which would allow users to change (within
reason) the semantic meanings of operations on that object.</p>
<p>I think that additional template parameters should be forbidden in
the Standard classes. Library writers don't lose any expressive power,
and can still offer extensions because additional template parameters
may be provided by a non-Standard implementation class:</p>
<pre> 
   template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
   class __vector
   { ... };
   template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
   class vector: public __vector&lt;T, Allocator&gt;
   { ... };
</pre>

</blockquote>

<p>
            <b>Proposed resolution:</b>
        </p>
<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling">[lib.res.on.exception.handling]</a>:</p>

<blockquote>
  <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
  template class described in the C++ Standard Library behaves the
  same as if the implementation declares no additional template
  parameters.</p> <p>Footnote: Additional template parameters with
  default values are thus permitted.</p>
</blockquote>

<p>Add "template parameters" to the list of subclauses at
the end of 17.4.4 <a href="lib-intro.html#lib.conforming">[lib.conforming]</a> paragraph 1.</p>

<p>
            <i>[Kona: The LWG agreed the standard needs clarification. After
discussion with John Spicer, it seems added template parameters can be
detected by a program using template-template parameters. A straw vote
- "should implementors be allowed to add template
parameters?" found no consensus ; 5 - yes, 7 - no.]</i>
        </p>

<p>
            <b>Rationale:</b>
        </p>
<p>
There is no ambiguity; the standard is clear as written.  Library
implementors are not permitted to add template parameters to standard
library classes.  This does not fall under the "as if" rule,
so it would be permitted only if the standard gave explicit license
for implementors to do this.  This would require a change in the 
standard.
</p>

<p>
The LWG decided against making this change, because it would break
user code involving template template parameters or specializations
of standard library class templates.
</p>
<hr>
        <a name="95">
            <h3>95.&nbsp;Members added by the implementation</h3>
        </a>
        <p>
            <b>Section:</b> 17.4.4.4 <a href="lib-intro.html#lib.member.functions">[lib.member.functions]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
members a base class and break user derived classes.</p>

<p>Example: </p>

<blockquote>
  <pre>// implementation code:
struct _Base { // _Base is in the implementer namespace
        virtual void foo ();
};
class vector : _Base // deriving from a class is allowed
{ ... };

// user code:
class vector_checking : public vector 
{
        void foo (); // don't want to override _Base::foo () as the 
                     // user doesn't know about _Base::foo ()
};</pre>
</blockquote>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Clarify the wording to make the example illegal.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard.&nbsp; The example is already
illegal.&nbsp; See 17.4.4.4 <a href="lib-intro.html#lib.member.functions">[lib.member.functions]</a> paragraph 2.</p>
<hr>
        <a name="97">
            <h3>97.&nbsp;Insert inconsistent definition</h3>
        </a>
        <p>
            <b>Section:</b> 23 <a href="lib-containers.html#lib.containers">[lib.containers]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>
            <tt>insert(iterator, const value_type&amp;)</tt> is defined both on
sequences and on set, with unrelated semantics: insert here (in
sequences), and insert with hint (in associative containers). They
should have different names (B.S. says: do not abuse overloading).</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard. It is a genetic misfortune of
the design, for better or for worse.</p>
<hr>
        <a name="99">
            <h3>99.&nbsp;Reverse_iterator comparisons completely wrong</h3>
        </a>
        <p>
            <b>Section:</b> 24.4.1.3.13 <a href="lib-iterators.html#lib.reverse.iter.op<">[lib.reverse.iter.op&lt;]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
return the opposite of what they should.</p>

<p>Note: same problem in CD2, these were not even defined in CD1.  SGI
STL code is correct; this problem is known since the Morristown
meeting but there it was too late</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard. A careful reading shows the Standard is correct
as written. A review of several implementations show that they implement
exactly what the Standard says.</p>
<hr>
        <a name="100">
            <h3>100.&nbsp;Insert iterators/ostream_iterators overconstrained</h3>
        </a>
        <p>
            <b>Section:</b> 24.4.2 <a href="lib-iterators.html#lib.insert.iterators">[lib.insert.iterators]</a>, 24.5.4 <a href="lib-iterators.html#lib.ostreambuf.iterator">[lib.ostreambuf.iterator]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>Overspecified For an insert iterator it, the expression *it is
required to return a reference to it. This is a simple possible
implementation, but as the SGI STL documentation says, not the only
one, and the user should not assume that this is the case.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes this causes no harm and is not a defect in the
standard. The only example anyone could come up with caused some
incorrect code to work, rather than the other way around.</p>
<hr>
        <a name="101">
            <h3>101.&nbsp;No way to free storage for vector and deque</h3>
        </a>
        <p>
            <b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector">[lib.vector]</a>, 23.2.1 <a href="lib-containers.html#lib.deque">[lib.deque]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>Reserve can not free storage, unlike string::reserve</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard. The LWG has considered this
issue in the past and sees no need to change the Standard. Deque has
no reserve() member function. For vector, shrink-to-fit can be
expressed in a single line of code (where <tt>v</tt> is
<tt>vector&lt;T&gt;</tt>):
</p>

<blockquote>
  <p>
                <tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt>
            </p>
</blockquote>
<hr>
        <a name="102">
            <h3>102.&nbsp;Bug in insert range in associative containers</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
impossible to implement, as it means that if [i, j) = [x], insert in an associative
container is O(1)!</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Subsumed by issue <a href="lwg-active.html#264">264</a>.</p>
<hr>
        <a name="104">
            <h3>104.&nbsp;Description of basic_string::operator[] is unclear</h3>
        </a>
        <p>
            <b>Section:</b> 21.3.4 <a href="lib-strings.html#lib.string.access">[lib.string.access]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>It is not clear that undefined behavior applies when pos == size ()
for the non const version.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
the non-const version is used, then the behavior is undefined.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The Standard is correct. The proposed resolution already appears in
the Standard.</p>
<hr>
        <a name="105">
            <h3>105.&nbsp;fstream ctors argument types desired</h3>
        </a>
        <p>
            <b>Section:</b> 27.8 <a href="lib-iostreams.html#lib.file.streams">[lib.file.streams]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>fstream ctors take a const char* instead of string.<br>
fstream ctors can't take wchar_t</p>

<p>An extension to add a const wchar_t* to fstream would make the
implementation non conforming.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect in the Standard. It might be an
interesting extension for the next Standard. </p>
<hr>
        <a name="107">
            <h3>107.&nbsp;Valarray constructor is strange</h3>
        </a>
        <p>
            <b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray">[lib.template.valarray]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;AFNOR <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>The order of the arguments is (elem, size) instead of the normal
(size, elem) in the rest of the library. Since elem often has an
integral or floating point type, both types are convertible to each
other and reversing them leads to a well formed program.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Inverting the arguments could silently break programs. Introduce
the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
but make the one we do not want private so errors result in a
diagnosed access violation. This technique can also be applied to STL
containers.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes that while the order of arguments is unfortunate,
it does not constitute a defect in the standard. The LWG believes that
the proposed solution will not work for valarray&lt;size_t&gt; and
perhaps other cases.</p>
<hr>
        <a name="113">
            <h3>113.&nbsp;Missing/extra iostream sync semantics</h3>
        </a>
        <p>
            <b>Section:</b> 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>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Steve Clamage <b>Date:</b>&nbsp;13 Oct 1998</p>
<p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
paragraph 36. </p>

<p>Following the chain of definitions, I find that the various sync functions have defined
semantics for output streams, but no semantics for input streams. On the other hand,
basic_ostream has no sync function. </p>

<p>The sync function should at minimum be added to basic_ostream, for internal
consistency. </p>

<p>A larger question is whether sync should have assigned semantics for input streams. </p>

<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
unread input characters to the source. It is a protected member function. The filebuf
version (which is public) has that behavior (it backs up the read pointer). Class
strstreambuf does not override streambuf::sync, and so sync can't be called on a
strstream. </p>

<p>If we can add corresponding semantics to the various sync functions, we should. If not,
we should remove sync from basic_istream.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>A sync function is not needed in basic_ostream because the flush function provides the
desired functionality.</p>

<p>As for the other points, the LWG finds the standard correct as written.</p>
<hr>
        <a name="116">
            <h3>116.&nbsp;bitset cannot be constructed with a const char*</h3>
        </a>
        <p>
            <b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset">[lib.template.bitset]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Judy Ward <b>Date:</b>&nbsp;6 Nov 1998</p>
<p>The following code does not compile with the EDG compiler:</p>

<blockquote>
  <pre>#include &lt;bitset&gt;
using namespace std;
bitset&lt;32&gt; b("111111111");</pre>
</blockquote>

<p>If you cast the ctor argument to a string, i.e.:</p>

<blockquote>
  <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
</blockquote>

<p>then it will compile. The reason is that bitset has the following templatized
constructor:</p>

<blockquote>
  <pre>template &lt;class charT, class traits, class Allocator&gt;
explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
</blockquote>

<p>According to the compiler vendor, Steve Adamcyk at EDG, the user
cannot pass this template constructor a <tt>const char*</tt> and
expect a conversion to <tt>basic_string</tt>.  The reason is
"When you have a template constructor, it can get used in
contexts where type deduction can be done. Type deduction basically
comes up with exact matches, not ones involving conversions."
</p>

<p>I don't think the intention when this constructor became
templatized was for construction from a <tt>const char*</tt> to no
longer work.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Add to 23.3.5 <a href="lib-containers.html#lib.template.bitset">[lib.template.bitset]</a> a bitset constructor declaration</p>

<blockquote>
  <pre>explicit bitset(const char*);</pre>
</blockquote>

<p>and in Section 23.3.5.1 <a href="lib-containers.html#lib.bitset.cons">[lib.bitset.cons]</a> add:</p>

<blockquote>
  <pre>explicit bitset(const char* str);</pre>
  <p>Effects: <br>
  &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt>
            </p>
</blockquote>
<p>
            <b>Rationale:</b>
        </p>
<p>Although the problem is real, the standard is designed that way so
it is not a defect.  Education is the immediate workaround. A future
standard may wish to consider the Proposed Resolution as an
extension.</p>
<hr>
        <a name="121">
            <h3>121.&nbsp;Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
        </a>
        <p>
            <b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category">[lib.locale.category]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Judy Ward <b>Date:</b>&nbsp;15 Dec 1998</p>
<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
ctype&lt;wchar_t&gt;. </p>

<p>Also Section 22.2.1.1 <a href="lib-locales.html#lib.locale.ctype">[lib.locale.ctype]</a> says: </p>

<blockquote>
  <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
  ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
  native character set. </p>
</blockquote>

<p>However, Section 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special">[lib.facet.ctype.special]</a>
only has a detailed description of the ctype&lt;char&gt; specialization, not the
ctype&lt;wchar_t&gt; specialization. </p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Add the ctype&lt;wchar_t&gt; detailed class description to Section 
22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special">[lib.facet.ctype.special]</a>. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Specialization for wchar_t is not needed since the default is acceptable.</p>
<hr>
        <a name="128">
            <h3>128.&nbsp;Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
        </a>
        <p>
            <b>Section:</b> 27.7 <a href="lib-iostreams.html#lib.string.streams">[lib.string.streams]</a>, 27.8 <a href="lib-iostreams.html#lib.file.streams">[lib.file.streams]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Angelika Langer <b>Date:</b>&nbsp;22 Feb 1999</p>
<p>The following question came from Thorsten Herlemann:</p>

<blockquote>
  <p>You can set a mode when constructing or opening a file-stream or
  filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
  that mode later on, e.g. in my own operator &lt;&lt; or operator
  &gt;&gt; or when I want to check whether a file-stream or
  file-buffer object passed as parameter is opened for input or output
  or binary? Is there no possibility? Is this a design-error in the
  standard C++ library? </p>
</blockquote>

<p>It is indeed impossible to find out what a stream's or stream
buffer's open mode is, and without that knowledge you don't know
how certain operations behave. Just think of the append mode. </p>

<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
current open mode setting. </p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>For stream buffers, add a function to the base class as a non-virtual function
qualified as const to 27.5.2 <a href="lib-iostreams.html#lib.streambuf">[lib.streambuf]</a>:</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>

<p>
            <b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>

<p>With streams, I'm not sure what to suggest. In principle, the mode
could already be returned by <tt>ios_base</tt>, but the mode is only
initialized for file and string stream objects, unless I'm overlooking
anything. For this reason it should be added to the most derived
stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This might be an interesting extension for some future, but it is
not a defect in the current standard. The Proposed Resolution is
retained for future reference.</p>
<hr>
        <a name="130">
            <h3>130.&nbsp;Return type of container::erase(iterator) differs for associative containers</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>, 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts">[lib.sequence.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Andrew Koenig <b>Date:</b>&nbsp;2 Mar 1999</p>
<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
iterator. Table 69 (23.1.2) says that in addition to this requirement,
associative containers also say that container::erase(iterator)
returns void.  That's not an addition; it's a change to the
requirements, which has the effect of making associative containers
fail to meet the requirements for containers.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes this was an explicit design decision by Alex
Stepanov driven by complexity considerations.&nbsp; It has been
previously discussed and reaffirmed, so this is not a defect in the
current standard. A future standard may wish to reconsider this
issue.</p>
<hr>
        <a name="131">
            <h3>131.&nbsp;list::splice throws nothing</h3>
        </a>
        <p>
            <b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops">[lib.list.ops]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Howard Hinnant <b>Date:</b>&nbsp;6 Mar 1999</p>
<p>What happens if a splice operation causes the size() of a list to grow 
beyond max_size()?</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Size() cannot grow beyond max_size().&nbsp; </p>
<hr>
        <a name="135">
            <h3>135.&nbsp;basic_iostream doubly initialized</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.1.5.1 <a href="lib-iostreams.html#lib.iostream.cons">[lib.iostream.cons]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Howard Hinnant <b>Date:</b>&nbsp;6 Mar 1999</p>
<p>-1- Effects Constructs an object of class basic_iostream, assigning
initial values to the base classes by calling
basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>

<p>The called for basic_istream and basic_ostream constructors call
init(sb). This means that the basic_iostream's virtual base class is
initialized twice.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Change 27.6.1.5.1, paragraph 1 to:</p>

<p>-1- Effects Constructs an object of class basic_iostream, assigning
initial values to the base classes by calling
basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG agreed that the <tt> init()</tt> function is called
twice, but said that this is harmless and so not a defect in the
standard.</p>
<hr>
        <a name="138">
            <h3>138.&nbsp;Class ctype_byname&lt;char&gt; redundant and misleading</h3>
        </a>
        <p>
            <b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special">[lib.locale.ctype.byname.special]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Angelika Langer <b>Date:</b>&nbsp;March 18, 1999</p>
<p>Section 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special">[lib.locale.ctype.byname.special]</a> specifies that
ctype_byname&lt;char&gt; must be a specialization of the ctype_byname
template.</p>

<p>It is common practice in the standard that specializations of class templates are only
mentioned where the interface of the specialization deviates from the interface of the
template that it is a specialization of. Otherwise, the fact whether or not a required
instantiation is an actual instantiation or a specialization is left open as an
implementation detail. </p>

<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
fact, that ctype_byname&lt;char&gt; is specified as a specialization suggests that there
must be something "special" about it, but it has the exact same interface as the
ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
redundant, at worst misleading - unless I am missing anything. </p>

<p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
specialization, because the base class ctype&lt;char&gt; is a specialization with an
interface different from the ctype template, but that's an implementation detail and need
not be mentioned in the standard. </p>
<p>
            <b>Rationale:</b>
        </p>
<p> The standard as written is mildly misleading, but the correct fix
is to deal with the underlying problem in the ctype_byname base class,
not in the specialization. See issue <a href="lwg-active.html#228">228</a>.</p>
<hr>
        <a name="140">
            <h3>140.&nbsp;map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
        </a>
        <p>
            <b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map">[lib.map]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Mark Mitchell <b>Date:</b>&nbsp;14 Apr 1999</p>
<blockquote>
  <p>23.1 <a href="lib-containers.html#lib.container.requirements">[lib.container.requirements]</a>
                <br>
  <br>
  expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
  &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
  -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
  -------------------<br>
  X::value_type&nbsp;&nbsp;&nbsp; T
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  T is assignable<br>
  <br>
  23.3.1 <a href="lib-containers.html#lib.map">[lib.map]</a>
                <br>
  <br>
  A map satisfies all the requirements of a container.<br>
  <br>
  For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
</blockquote>

<p>There's a contradiction here. In particular, `pair&lt;const Key,
T&gt;' is not assignable; the `const Key' cannot be assigned
to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
assignable requirement imposed by a container.</p>

<p>
            <i>[See issue <a href="lwg-active.html#103">103</a> for the slightly related issue of
modification of set keys.]</i>
        </p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes that the standard is inconsistent, but that this
is a design problem rather than a strict defect. May wish to
reconsider for the next standard.</p>
<hr>
        <a name="143">
            <h3>143.&nbsp;C .h header wording unclear</h3>
        </a>
        <p>
            <b>Section:</b> D.5 <a href="future.html#depr.c.headers">[depr.c.headers]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Christophe de Dinechin <b>Date:</b>&nbsp;4 May 1999</p>
<p>[depr.c.headers] paragraph 2 reads:</p>

<blockquote>

<p>Each C header, whose name has the form name.h, behaves as if each
name placed in the Standard library namespace by the corresponding
cname header is also placed within the namespace scope of the
namespace std and is followed by an explicit using-declaration
(_namespace.udecl_)</p>

</blockquote>

<p>I think it should mention the global name space somewhere...&nbsp;
Currently, it indicates that name placed in std is also placed in
std...</p>

<p>I don't know what is the correct wording. For instance, if struct
tm is defined in time.h, ctime declares std::tm. However, the current
wording seems ambiguous regarding which of the following would occur
for use of both ctime and time.h:</p>

<blockquote>
  <pre>// version 1:
namespace std {
        struct tm { ... };
}
using std::tm;

// version 2:
struct tm { ... };
namespace std {
        using ::tm;
}

// version 3:
struct tm { ... };
namespace std {
        struct tm { ... };
}</pre>
</blockquote>

<p>I think version 1 is intended.</p>

<p>
            <i>[Kona: The LWG agreed that the wording is not clear. It also
agreed that version 1 is intended, version 2 is not equivalent to
version 1, and version 3 is clearly not intended. The example below
was constructed by Nathan Myers to illustrate why version 2 is not
equivalent to version 1.</i>
        </p>

<p>
            <i>Although not equivalent, the LWG is unsure if (2) is enough of
a problem to be prohibited. Points discussed in favor of allowing
(2):</i>
        </p>

<blockquote>
  <ul>
    <li>
                    <i>It may be a convenience to implementors.</i>
                </li>
    <li>
                    <i>The only cases that fail are structs, of which the C library
      contains only a few.</i>
                </li>
  </ul>
</blockquote>

<p>
            <i>]</i>
        </p>

<p>
            <b>Example:</b>
        </p>

<blockquote>

<pre>#include &lt;time.h&gt;
#include &lt;utility&gt;

int main() {
    std::tm * t;
    make_pair( t, t ); // okay with version 1 due to Koenig lookup
                       // fails with version 2; make_pair not found
    return 0;
}</pre>

</blockquote>
<p>
            <b>Proposed resolution:</b>
        </p>

<p>Replace D.5 <a href="future.html#depr.c.headers">[depr.c.headers]</a> paragraph 2 with:</p>

<blockquote>

<p> Each C header, whose name has the form name.h, behaves as if each
name placed in the Standard library namespace by the corresponding
cname header is also placed within the namespace scope of the
namespace std by name.h and is followed by an explicit
using-declaration (_namespace.udecl_) in global scope.</p>

</blockquote>

<p>
            <b>Rationale:</b>
        </p>
<p> The current wording in the standard is the result of a difficult
compromise that averted delay of the standard. Based on discussions
in Tokyo it is clear that there is no still no consensus on stricter
wording, so the issue has been closed. It is suggested that users not
write code that depends on Koenig lookup of C library functions.</p>
<hr>
        <a name="145">
            <h3>145.&nbsp;adjustfield lacks default value</h3>
        </a>
        <p>
            <b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons">[lib.basic.ios.cons]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Angelika Langer <b>Date:</b>&nbsp;12 May 1999</p>
<p>There is no initial value for the adjustfield defined, although
many people believe that the default adjustment were right. This is a
common misunderstanding. The standard only defines that, if no
adjustment is specified, all the predefined inserters must add fill
characters before the actual value, which is "as if" the
right flag were set. The flag itself need not be set.</p>

<p>When you implement a user-defined inserter you cannot rely on right
being the default setting for the adjustfield. Instead, you must be
prepared to find none of the flags set and must keep in mind that in
this case you should make your inserter behave "as if" the
right flag were set. This is surprising to many people and complicates
matters more than necessary.</p>

<p>Unless there is a good reason why the adjustfield should not be
initialized I would suggest to give it the default value that
everybody expects anyway.</p>

<p>
            <b>Rationale:</b>
        </p>
<p>This is not a defect. It is deliberate that the default is no bits
set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals">[lib.facet.num.put.virtuals]</a> paragraph 19, Table 61 - Fill padding.</p>
<hr>
        <a name="149">
            <h3>149.&nbsp;Insert should return iterator to first element inserted</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts">[lib.sequence.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Andrew Koenig <b>Date:</b>&nbsp;28 Jun 1999</p>
<p>Suppose that c and c1 are sequential containers and i is an
iterator that refers to an element of c.  Then I can insert a copy of
c1's elements into c ahead of element i by executing </p>

<blockquote>

<pre>c.insert(i, c1.begin(), c1.end());</pre>

</blockquote>

<p>If c is a vector, it is fairly easy for me to find out where the
newly inserted elements are, even though i is now invalid: </p>

<blockquote>

<pre>size_t i_loc = i - c.begin();
c.insert(i, c1.begin(), c1.end());</pre>

</blockquote>

<p>and now the first inserted element is at c.begin()+i_loc and one
past the last is at c.begin()+i_loc+c1.size().<br>
<br>
But what if c is a list?  I can still find the location of one    past the last inserted element, because i is still valid.    To find the location of the first inserted element, though,    I must execute something like </p>

<blockquote>

<pre>for (size_t n = c1.size(); n; --n)
   --i;</pre>

</blockquote>

<p>because i is now no longer a random-access iterator.<br>
<br>
Alternatively, I might write something like </p>

<blockquote>

<pre>bool first = i == c.begin();
list&lt;T&gt;::iterator j = i;
if (!first) --j;
c.insert(i, c1.begin(), c1.end());
if (first)
   j = c.begin();
else
   ++j;</pre>

</blockquote>

<p>which, although wretched, requires less overhead.<br>
<br>
But I think the right solution is to change the definition of insert
so that instead of returning void, it returns an iterator that refers
to the first element inserted, if any, and otherwise is a copy of its
first argument.&nbsp; </p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes this was an intentional design decision and so is
not a defect. It may be worth revisiting for the next standard.</p>
<hr>
        <a name="157">
            <h3>157.&nbsp;Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt>
            </h3>
        </a>
        <p>
            <b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage">[lib.ios.base.storage]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>According to paragraphs 2 and 4 of 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage">[lib.ios.base.storage]</a>, the
functions <tt>iword()</tt> and <tt>pword()</tt> "set the
<tt>badbit</tt> (which might throw an exception)" on
failure. ... but what does it mean for <tt>ios_base</tt> to set the
<tt>badbit</tt>? The state facilities of the IOStream library are
defined in <tt>basic_ios</tt>, a derived class! It would be possible
to attempt a down cast but then it would be necessary to know the
character type used...</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#41">41</a>.</p>
<hr>
        <a name="162">
            <h3>162.&nbsp;Really "formatted input functions"?</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors">[lib.istream::extractors]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>It appears to be somewhat nonsensical to consider the functions
defined in the paragraphs 1 to 5 to be "Formatted input
function" but since these functions are defined in a section
labeled "Formatted input functions" it is unclear to me
whether these operators are considered formatted input functions which
have to conform to the "common requirements" from 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts">[lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not just
<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
(... but setting <tt>noskipws</tt> using the manipulator syntax would
also skip whitespace :-)</p>

<p>See also issue <a href="lwg-closed.html#166">166</a> for the same problem in formatted
output</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#60">60</a>.</p>
<hr>
        <a name="163">
            <h3>163.&nbsp;Return of <tt>gcount()</tt> after a call to <tt>gcount</tt>
            </h3>
        </a>
        <p>
            <b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted">[lib.istream.unformatted]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>It is not clear which functions are to be considered unformatted
input functions. As written, it seems that all functions in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted">[lib.istream.unformatted]</a> are unformatted input functions. However, it does not
really make much sense to construct a sentry object for
<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
These functions don't extract characters, some of them even
"unextract" a character. Should this still be reflected in
<tt>gcount()</tt>? Of course, it could be read as if after a call to
<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
unformatted input function, <tt>gcount()</tt>, didn't extract any
character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
returns <tt>-1</tt> (the last unformatted input function
<tt>putback()</tt> did "extract" back into the
stream). Correspondingly for <tt>unget()</tt>. Is this what is
intended?  If so, this should be clarified. Otherwise, a corresponding
clarification should be used.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate.&nbsp; See issue <a href="lwg-defects.html#60">60</a>.</p>
<hr>
        <a name="166">
            <h3>166.&nbsp;Really "formatted output functions"?</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.2.5.3 <a href="lib-iostreams.html#lib.ostream.inserters">[lib.ostream.inserters]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>From 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts">[lib.ostream.formatted.reqmts]</a> it appears that all the functions
defined in 27.6.2.5.3 <a href="lib-iostreams.html#lib.ostream.inserters">[lib.ostream.inserters]</a> have to construct a
<tt>sentry</tt> object. Is this really intended?</p> 

<p>This is basically the same problem as issue <a href="lwg-closed.html#162">162</a> but
for output instead of input.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate. See issue <a href="lwg-defects.html#60">60</a>.</p>
<hr>
        <a name="177">
            <h3>177.&nbsp;Complex operators cannot be explicitly instantiated</h3>
        </a>
        <p>
            <b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops">[lib.complex.ops]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Judy Ward <b>Date:</b>&nbsp;2 Jul 1999</p>
<p>A user who tries to explicitly instantiate a complex non-member operator will
get compilation errors. Below is a simplified example of the reason why. The
problem is that iterator_traits cannot be instantiated on a non-pointer type
like float, yet when the compiler is trying to decide which operator+ needs to
be instantiated it must instantiate the declaration to figure out the first
argument type of a reverse_iterator operator.</p>
<pre>namespace std {
template &lt;class Iterator&gt; 
struct iterator_traits
{
    typedef typename Iterator::value_type value_type;
};

template &lt;class T&gt; class reverse_iterator;

// reverse_iterator operator+
template &lt;class T&gt; 
reverse_iterator&lt;T&gt; operator+
(typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);

template &lt;class T&gt; struct complex {};

// complex operator +
template &lt;class T&gt;
complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs) 
{ return complex&lt;T&gt;();} 
}

// request for explicit instantiation
template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;, 
     const std::complex&lt;float&gt;&amp;);</pre>
<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Implementors can make minor changes and the example will
work. Users are not affected in any case.</p> <p>According to John
Spicer, It is possible to explicitly instantiate these operators using
different syntax: change "std::operator+&lt;float&gt;" to
"std::operator+".</p>

<p>The proposed resolution of issue 120 is that users will not be able
to explicitly instantiate standard library templates. If that
resolution is accepted then library implementors will be the only ones
that will be affected by this problem, and they must use the indicated
syntax.</p>
<hr>
        <a name="178">
            <h3>178.&nbsp;Should clog and cerr initially be tied to cout?</h3>
        </a>
        <p>
            <b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects">[lib.narrow.stream.objects]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Judy Ward <b>Date:</b>&nbsp;2 Jul 1999</p>
<p>
Section 27.3.1 says "After the object cerr is initialized,
cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
required for ios_base::init (lib.basic.ios.cons).  It doesn't say
anything about the the state of clog.  So this means that calling
cerr.tie() and clog.tie() should return 0 (see Table 89 for
ios_base::init effects).
</p>
<p>
Neither of the popular standard library implementations
that I tried does this, they both tie cerr and clog
to &amp;cout. I would think that would be what users expect.
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The standard is clear as written.</p>
<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
&amp; unitbuf is nonzero. Its state is otherwise the same as required for
ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
ios_base::init to basic_ios::init().)</p>
<hr>
        <a name="180">
            <h3>180.&nbsp;Container member iterator arguments constness has unintended consequences</h3>
        </a>
        <p>
            <b>Section:</b> 23 <a href="lib-containers.html#lib.containers">[lib.containers]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dave Abrahams <b>Date:</b>&nbsp;1 Jul 1999</p>
<p>It is the constness of the container which should control whether
it can be modified through a member function such as erase(), not the
constness of the iterators. The iterators only serve to give
positioning information.</p>

<p>Here's a simple and typical example problem which is currently very
difficult or impossible to solve without the change proposed
below.</p>

<p>Wrap a standard container C in a class W which allows clients to
find and read (but not modify) a subrange of (C.begin(), C.end()]. The
only modification clients are allowed to make to elements in this
subrange is to erase them from C through the use of a member function
of W.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Change all non-const iterator parameters of standard library
container member functions to accept const_iterator parameters.
Note that this change applies to all library clauses, including
strings.</p>

<p>For example, in   21.3.5.5  change:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(iterator p);</tt>
            <br>
<br>
to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(const_iterator p);</tt>
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The issue was discussed at length. It was generally agreed that 1)
There is no major technical argument against the change (although
there is a minor argument that some obscure programs may break), and
2) Such a change would not break const correctness. The concerns about
making the change were 1) it is user detectable (although only in
boundary cases), 2) it changes a large number of signatures, and 3) it
seems more of a design issue that an out-and-out defect.</p>

<p>The LWG believes that this issue should be considered as part of a
general review of const issues for the next revision of the
standard. Also see issue <a href="lwg-active.html#200">200</a>.</p>
<hr>
        <a name="188">
            <h3>188.&nbsp;valarray helpers missing augmented assignment operators</h3>
        </a>
        <p>
            <b>Section:</b> 26.3.2.6 <a href="lib-numerics.html#lib.valarray.cassign">[lib.valarray.cassign]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Gabriel Dos Reis <b>Date:</b>&nbsp;15 Aug 1999</p>
<p>26.3.2.6 defines augmented assignment operators
valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
corresponding versions for the helper classes. Thus making the
following illegal:</p>
<blockquote>
<pre>#include &lt;valarray&gt;

int main()
{
std::valarray&lt;double&gt; v(3.14, 1999);

v[99] *= 2.0; // Ok

std::slice s(0, 50, 2);

v[s] *= 2.0; // ERROR
}</pre>
</blockquote>
<p>I can't understand the intent of that omission.  It makes the
valarray library less intuitive and less useful.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Although perhaps an unfortunate
design decision, the omission is not a defect in the current
standard.&nbsp; A future standard may wish to add the missing
operators.</p>
<hr>
        <a name="190">
            <h3>190.&nbsp;min() and max() functions should be std::binary_functions</h3>
        </a>
        <p>
            <b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max">[lib.alg.min.max]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Mark Rintoul <b>Date:</b>&nbsp;26 Aug 1999</p>
<p>Both std::min and std::max are defined as template functions.  This
is very different than the definition of std::plus (and similar
structs) which are defined as function objects which inherit
std::binary_function.<br>
<br>
        This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
a function object that inherits std::binary_function.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Although perhaps an unfortunate design decision, the omission is not a defect
in the current standard.&nbsp; A future standard may wish to consider additional
function objects.</p>
<hr>
        <a name="191">
            <h3>191.&nbsp;Unclear complexity for algorithms such as binary search</h3>
        </a>
        <p>
            <b>Section:</b> 25.3.3 <a href="lib-algorithms.html#lib.alg.binary.search">[lib.alg.binary.search]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;10 Oct 1999</p>
<p>The complexity of binary_search() is stated as "At most
log(last-first) + 2 comparisons", which seems to say that the
algorithm has logarithmic complexity. However, this algorithms is
defined for forward iterators. And for forward iterators, the need to
step element-by-element results into linear complexity. But such a
statement is missing in the standard. The same applies to
lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
<br>
However, strictly speaking the standard contains no bug here. So this
might considered to be a clarification or improvement.
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The complexity is expressed in terms of comparisons, and that
complexity can be met even if the number of iterators accessed is
linear. Paragraph 1 already says exactly what happens to
iterators.</p>
<hr>
        <a name="192">
            <h3>192.&nbsp;a.insert(p,t) is inefficient and overconstrained</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Ed Brey <b>Date:</b>&nbsp;6 Jun 1999</p>
<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
several problems:</p>
<table border="1" cellpadding="5">
  <tr>
    <td><b>expression</b></td>
    <td><b>return type</b></td>
    <td><b>pre/post-condition</b></td>
    <td><b>complexity</b></td>
  </tr>
  <tr>
    <td><tt>a.insert(p,t)</tt></td>
    <td><tt>iterator</tt></td>
    <td>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 . iterator p is a hint pointing to where the insert should start to search.</td>
    <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
  </tr>
</table>
<p>1. For a container with unique keys, only logarithmic complexity is
guaranteed if no element is inserted, even though constant complexity is always
possible if p points to an element equivalent to t.</p>
<p>2. For a container with equivalent keys, the amortized constant complexity
guarantee is only useful if no key equivalent to t exists in the container.
Otherwise, the insertion could occur in one of multiple locations, at least one
of which would not be right after p.</p>
<p>3. By guaranteeing amortized constant complexity only when t is inserted
after p, it is impossible to guarantee constant complexity if t is inserted at
the beginning of the container. Such a problem would not exist if amortized
constant complexity was guaranteed if t is inserted before p, since there is
always some p immediately before which an insert can take place.</p>
<p>4. For a container with equivalent keys, p does not allow specification of
where to insert the element, but rather only acts as a hint for improving
performance. This negates the added functionality that p would provide if it
specified where within a sequence of equivalent keys the insertion should occur.
Specifying the insert location provides more control to the user, while
providing no disadvantage to the container implementation.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a> paragraph 7, replace the row in table 69
for a.insert(p,t) with the following two rows:</p>
<table border="1" cellpadding="5">
  <tr>
    <td><b>expression</b></td>
    <td><b>return type</b></td>
    <td><b>pre/post-condition</b></td>
    <td><b>complexity</b></td>
  </tr>
  <tr>
    <td><tt>a_uniq.insert(p,t)</tt></td>
    <td><tt>iterator</tt></td>
    <td>inserts t if and only if there is no element with key equivalent to the
      key of t. returns the iterator pointing to the element with key equivalent
      to the key of t.</td>
    <td>logarithmic in general, but amortized constant if t is inserted right
      before p or p points to an element with key equivalent to t.</td>
  </tr>
  <tr>
    <td><tt>a_eq.insert(p,t)</tt></td>
    <td><tt>iterator</tt></td>
    <td>inserts t and returns the iterator pointing to the newly inserted
      element. t is inserted right before p if doing so preserves the container
      ordering.</td>
    <td>logarithmic in general, but amortized constant if t is inserted right
      before p.</td>
  </tr>
</table>

<p>
            <b>Rationale:</b>
        </p>
<p>Too big a change.&nbsp; Furthermore, implementors report checking
both before p and after p, and don't want to change this behavior.</p>
<hr>
        <a name="194">
            <h3>194.&nbsp;rdbuf() functions poorly specified</h3>
        </a>
        <p>
            <b>Section:</b> 27.4.4 <a href="lib-iostreams.html#lib.ios">[lib.ios]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Steve Clamage <b>Date:</b>&nbsp;7 Sep 1999</p>
<p>In classic iostreams, base class ios had an rdbuf function that returned a
pointer to the associated streambuf. Each derived class had its own rdbuf
function that returned a pointer of a type reflecting the actual type derived
from streambuf. Because in ARM C++, virtual function overrides had to have the
same return type, rdbuf could not be virtual.</p>
<p>In standard iostreams, we retain the non-virtual rdbuf function design, and
in addition have an overloaded rdbuf function that sets the buffer pointer.
There is no need for the second function to be virtual nor to be implemented in
derived classes.</p>
<p>Minor question: Was there a specific reason not to make the original rdbuf
function virtual?</p>
<p>Major problem: Friendly compilers warn about functions in derived classes
that hide base-class overloads. Any standard implementation of iostreams will
result in such a warning on each of the iostream classes, because of the
ill-considered decision to overload rdbuf only in a base class.</p>
<p>In addition, users of the second rdbuf function must use explicit
qualification or a cast to call it from derived classes. An explicit
qualification or cast to basic_ios would prevent access to any later overriding
version if there was one.</p>
<p>What I'd like to do in an implementation is add a using- declaration for the
second rdbuf function in each derived class. It would eliminate warnings about
hiding functions, and would enable access without using explicit qualification.
Such a change I don't think would change the behavior of any valid program, but
would allow invalid programs to compile:</p>
<blockquote>
  <pre> filebuf mybuf;
 fstream f;
 f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
</blockquote>
<p>I'd like to suggest this problem as a defect, with the proposed resolution to
require the equivalent of a using-declaration for the rdbuf function that is not
replaced in a later derived class. We could discuss whether replacing the
function should be allowed.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>

<p>Permission is not required to add such an extension.  See 
17.4.4.4 <a href="lib-intro.html#lib.member.functions">[lib.member.functions]</a>.</p>
<hr>
        <a name="196">
            <h3>196.&nbsp;Placement new example has alignment problems</h3>
        </a>
        <p>
            <b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement">[lib.new.delete.placement]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Herb Sutter <b>Date:</b>&nbsp;15 Dec 1998</p>
<p>The example in 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement">[lib.new.delete.placement]</a> paragraph 4 reads: </p>

<blockquote>

<p>[Example: This can be useful for constructing an object at a known address:<br>
<br>
<tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
&nbsp;&nbsp; Something* p = new (place) Something();<br>
<br>
</tt>end example] </p>

</blockquote>

<p>This example has potential alignment problems. </p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate: see issue <a href="lwg-defects.html#114">114</a>.</p>
<hr>
        <a name="203">
            <h3>203.&nbsp;basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry">[lib.istream::sentry]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Matt McClure and Dietmar K&uuml;hl <b>Date:</b>&nbsp;1 Jan 2000</p>
<p>27.6.1.1.2 Paragraph 4 states:</p>
<blockquote>
  <p>To decide if the character c is a whitespace character, the constructor      
     performs ''as if'' it executes the following code fragment:&nbsp;</p>
  <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
if (ctype.is(ctype.space,c)!=0)
// c is a whitespace character.</pre>
</blockquote>

<p> But Table 51 in 22.1.1.1.1 only requires an implementation to
provide specializations for ctype&lt;char&gt; and
ctype&lt;wchar_t&gt;.  If sentry's constructor is implemented using
ctype, it will be uninstantiable for a user-defined character type
charT, unless the implementation has provided non-working (since it
would be impossible to define a correct ctype&lt;charT&gt; specialization
for an arbitrary charT) definitions of ctype's virtual member
functions.</p>

<p>
It seems the intent the standard is that sentry should behave, in
every respect, not just during execution, as if it were implemented
using ctype, with the burden of providing a ctype specialization
falling on the user.  But as it is written, nothing requires the
translation of sentry's constructor to behave as if it used the above
code, and it would seem therefore, that sentry's constructor should be
instantiable for all character types.
</p>

<p> 
Note: If I have misinterpreted the intent of the standard with
respect to sentry's constructor's instantiability, then a note should
be added to the following effect:
</p>

<blockquote>
An implementation is forbidden from using the above code if it renders
the constructor uninstantiable for an otherwise valid character
type.
</blockquote>

<p>In any event, some clarification is needed.</p>

<p>
            <b>Rationale:</b>
        </p>
<p>It is possible but not easy to instantiate on types other than char
or wchar_t; many things have to be done first. That is by intention
and is not a defect.</p>
<hr>
        <a name="204">
            <h3>204.&nbsp;distance(first, last) when "last" is before "first"</h3>
        </a>
        <p>
            <b>Section:</b> 24.3.4 <a href="lib-iterators.html#lib.iterator.operations">[lib.iterator.operations]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Rintala Matti <b>Date:</b>&nbsp;28 Jan 2000</p>
<p>Section 24.3.4 describes the function distance(first, last) (where first and
last are iterators) which calculates "the number of increments or
decrements needed to get from 'first' to 'last'".</p>
<p>The function should work for forward, bidirectional and random access
iterators, and there is a requirement 24.3.4.5 which states that "'last'
must be reachable from 'first'".</p>
<p>With random access iterators the function is easy to implement as "last
- first".</p>
<p>With forward iterators it's clear that 'first' must point to a place before
'last', because otherwise 'last' would not be reachable from 'first'.</p>
<p>But what about bidirectional iterators? There 'last' is reachable from
'first' with the -- operator even if 'last' points to an earlier position than
'first'. However, I cannot see how the distance() function could be implemented
if the implementation does not know which of the iterators points to an earlier
position (you cannot use ++ or -- on either iterator if you don't know which
direction is the "safe way to travel").</p>
<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
use ++ to provide linear time implementations". However, the ++ operator is
not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
mentions that distance() returns the number of increments _or decrements_,
suggesting that it could return a negative number also for bidirectional
iterators when 'last' points to a position before 'first'.</p>
<p>Is a further requirement is needed to state that for forward and
bidirectional iterators "'last' must be reachable from 'first' using the ++
operator". Maybe this requirement might also apply to random access
iterators so that distance() would work the same way for every iterator
category?</p>
<p>
            <b>Rationale:</b>
        </p>
<p>"Reachable" is defined in the standard in 24.1 <a href="lib-iterators.html#lib.iterator.requirements">[lib.iterator.requirements]</a> paragraph 6.
The definition is only in terms of operator++(). The LWG sees no defect in
the standard.</p>
<hr>
        <a name="205">
            <h3>205.&nbsp; numeric_limits unclear on how to determine floating point types</h3>
        </a>
        <p>
            <b>Section:</b> 18.2.1.2 <a href="lib-support.html#lib.numeric.limits.members">[lib.numeric.limits.members]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Steve Cleary <b>Date:</b>&nbsp;28 Jan 2000</p>
<p>In several places in 18.2.1.2 <a href="lib-support.html#lib.numeric.limits.members">[lib.numeric.limits.members]</a>, a member is
described as "Meaningful for all floating point types."
However, no clear method of determining a floating point type is
provided.</p>

<p>In 18.2.1.5 <a href="lib-support.html#lib.numeric.special">[lib.numeric.special]</a>, paragraph 1 states ". . . (for
example, epsilon() is only meaningful if is_integer is
false). . ." which suggests that a type is a floating point type
if is_specialized is true and is_integer is false; however, this is
unclear.</p>

<p>When clarifying this, please keep in mind this need of users: what
exactly is the definition of floating point? Would a fixed point or
rational representation be considered one? I guess my statement here
is that there could also be types that are neither integer or
(strictly) floating point.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>It is up to the implementor of a user define type to decide if it is a
floating point type.</p>
<hr>
        <a name="206">
            <h3>206.&nbsp;operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
        </a>
        <p>
            <b>Section:</b> 18.4.1.1 <a href="lib-support.html#lib.new.delete.single">[lib.new.delete.single]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Howard Hinnant <b>Date:</b>&nbsp;29 Aug 1999</p>
<p>As specified, the implementation of the nothrow version of operator
new does not necessarily call the ordinary operator new, but may
instead simply call the same underlying allocator and return a null
pointer instead of throwing an exception in case of failure.</p>

<p>Such an implementation breaks code that replaces the ordinary
version of new, but not the nothrow version. If the ordinary version
of new/delete is replaced, and if the replaced delete is not
compatible with pointers returned from the library versions of new,
then when the replaced delete receives a pointer allocated by the
library new(nothrow), crash follows.</p>

<p>The fix appears to be that the lib version of new(nothrow) must
call the ordinary new. Thus when the ordinary new gets replaced, the
lib version will call the replaced ordinary new and things will
continue to work.</p>

<p>An alternative would be to have the ordinary new call
new(nothrow). This seems sub-optimal to me as the ordinary version of
new is the version most commonly replaced in practice. So one would
still need to replace both ordinary and nothrow versions if one wanted
to replace the ordinary version.</p>

<p>Another alternative is to put in clear text that if one version is
replaced, then the other must also be replaced to maintain
compatibility. Then the proposed resolution below would just be a
quality of implementation issue. There is already such text in
paragraph 7 (under the new(nothrow) version). But this nuance is
easily missed if one reads only the paragraphs relating to the
ordinary new.</p>

<p>
            <b>Rationale:</b>
        </p>
<p>Yes, they may become unlinked, and that is by design. If a user
replaces one, the user should also replace the other.</p>
<hr>
        <a name="207">
            <h3>207.&nbsp;ctype&lt;char&gt; members return clause incomplete</h3>
        </a>
        <p>
            <b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members">[lib.facet.ctype.char.members]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Robert Klarer <b>Date:</b>&nbsp;2 Nov 1999</p>
<p>
The <tt>widen</tt> and <tt>narrow</tt> member functions are described
in 22.2.1.3.2, paragraphs 9-11.  In each case we have two overloaded
signatures followed by a <b>Returns</b> clause.  The <b>Returns</b>
clause only describes one of the overloads.
</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Change the returns clause in 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members">[lib.facet.ctype.char.members]</a>
paragraph 10 from:</p>
<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>

<p>to:</p>
<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
respectively.</p>

<p>Change the returns clause in 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members">[lib.facet.ctype.char.members]</a> paragraph 11
from:</p> 
<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>

<p>to:</p>
<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to), 
respectively.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Subsumed by issue <a href="lwg-active.html#153">153</a>, which addresses the same
paragraphs.</p>
<hr>
        <a name="213">
            <h3>213.&nbsp;Math function overloads ambiguous</h3>
        </a>
        <p>
            <b>Section:</b> 26.5 <a href="lib-numerics.html#lib.c.math">[lib.c.math]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Nico Josuttis <b>Date:</b>&nbsp;26 Feb 2000</p>
<p>Due to the additional overloaded versions of numeric functions for
float and long double according to Section 26.5, calls such as int x;
std::pow (x, 4) are ambiguous now in a standard conforming
implementation. Current implementations solve this problem very
different (overload for all types, don't overload for float and long
double, use preprocessor, follow the standard and get
ambiguities).</p> <p>This behavior should be standardized or at least
identified as implementation defined.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>These math issues are an
understood and accepted consequence of the design. They have
been discussed several times in the past. Users must write casts
or write floating point expressions as arguments.</p>
<hr>
        <a name="215">
            <h3>215.&nbsp;Can a map's key_type be const?</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Judy Ward <b>Date:</b>&nbsp;29 Feb 2000</p>
<p>A user noticed that this doesn't compile with the Rogue Wave library because
the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
not legal, I think:</p>
<blockquote>
  <pre>map &lt; const int, ... &gt; // legal?</pre>
</blockquote>
<p>which made me wonder whether it is legal for a map's key_type to be const. In
email from Matt Austern he said:</p>
<blockquote>
<p>I'm not sure whether it's legal to declare a map with a const key type. I
hadn't thought about that question until a couple weeks ago. My intuitive
feeling is that it ought not to be allowed, and that the standard ought to say
so. It does turn out to work in SGI's library, though, and someone in the
compiler group even used it. Perhaps this deserves to be written up as an issue
too.</p>
</blockquote>
<p>
            <b>Rationale:</b>
        </p>
<p>The "key is assignable" requirement from table 69 in
23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a> already implies the key cannot be const.</p>
<hr>
        <a name="216">
            <h3>216.&nbsp;setbase manipulator description flawed</h3>
        </a>
        <p>
            <b>Section:</b> 27.6.3 <a href="lib-iostreams.html#lib.std.manip">[lib.std.manip]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Hyman Rosen <b>Date:</b>&nbsp;29 Feb 2000</p>
<p>27.6.3 <a href="lib-iostreams.html#lib.std.manip">[lib.std.manip]</a> paragraph 5 says:</p>
<blockquote>
<pre>smanip setbase(int base);</pre>
<p> Returns: An object s of unspecified type such that if out is an
(instance of) basic_ostream then the expression out&lt;&lt;s behaves
as if f(s) were called, in is an (instance of) basic_istream then the
expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
defined as:</p>
<pre>ios_base&amp; f(ios_base&amp; str, int base)
{
  // set basefield
  str.setf(n == 8 ? ios_base::oct :
                n == 10 ? ios_base::dec :
                n == 16 ? ios_base::hex :
                  ios_base::fmtflags(0), ios_base::basefield);
  return str;
}</pre>
</blockquote>
<p>There are two problems here. First, f takes two parameters, so the
description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
had been called. Second, f is has a parameter named base, but is written as if
the parameter was named n.</p>
<p>Actually, there's a third problem. The paragraph has grammatical errors.
There needs to be an "and" after the first comma, and the "Where
f" sentence fragment needs to be merged into its preceding sentence. You
may also want to format the function a little better. The formatting above is
more-or-less what the Standard contains.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The resolution of this defect is subsumed by the proposed resolution for
issue <a href="lwg-defects.html#193">193</a>.</p>

<p>
            <i>[Tokyo: The LWG agrees that this is a defect and notes that it
occurs additional places in the section, all requiring fixes.]</i>
        </p>
<hr>
        <a name="218">
            <h3>218.&nbsp;Algorithms do not use binary predicate objects for default comparisons</h3>
        </a>
        <p>
            <b>Section:</b> 25.3 <a href="lib-algorithms.html#lib.alg.sorting">[lib.alg.sorting]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Pablo Halpern <b>Date:</b>&nbsp;6 Mar 2000</p>
<p>Many of the algorithms take an argument, pred, of template parameter type
BinaryPredicate or an argument comp of template parameter type Compare. These
algorithms usually have an overloaded version that does not take the predicate
argument. In these cases pred is usually replaced by the use of operator== and
comp is replaced by the use of operator&lt;.</p>
<p>This use of hard-coded operators is inconsistent with other parts of the
library, particularly the containers library, where equality is established
using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
the use of operator&lt;, would cause the following innocent-looking code to have
undefined behavior:</p>
<blockquote>
  <pre>vector&lt;string*&gt; vec;
sort(vec.begin(), vec.end());</pre>
</blockquote>
<p>The use of operator&lt; is not defined for pointers to unrelated objects. If
std::sort used less&lt;&gt; to compare elements, then the above code would be
well-defined, since less&lt;&gt; is explicitly specialized to produce a total
ordering of pointers.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>This use of operator== and operator&lt; was a very deliberate, conscious, and
explicitly made design decision; these operators are often more efficient. The
predicate forms are available for users who don't want to rely on operator== and
operator&lt;.</p>
<hr>
        <a name="219">
            <h3>219.&nbsp;find algorithm missing version that takes a binary predicate argument</h3>
        </a>
        <p>
            <b>Section:</b> 25.1.2 <a href="lib-algorithms.html#lib.alg.find">[lib.alg.find]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Pablo Halpern <b>Date:</b>&nbsp;6 Mar 2000</p>
<p>The find function always searches for a value using operator== to compare the
value argument to each element in the input iterator range. This is inconsistent
with other find-related functions such as find_end and find_first_of, which
allow the caller to specify a binary predicate object to be used for determining
equality. The fact that this can be accomplished using a combination of find_if
and bind_1st or bind_2nd does not negate the desirability of a consistent,
simple, alternative interface to find.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<blockquote>
<p>In section 25.1.2 <a href="lib-algorithms.html#lib.alg.find">[lib.alg.find]</a>, add a second prototype for find
(between the existing prototype and the prototype for find_if), as
follows:</p>
<pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
      InputIterator find(InputIterator first, InputIterator last,
                         const T&amp; value, BinaryPredicate bin_pred);</pre>
<p>Change the description of the return from:</p>
<blockquote>
  <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
  conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
</blockquote>
<p>&nbsp;to:</p>
<blockquote>
  <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
  corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
  != false. Return last if no such iterator is found.</p>
</blockquote>
</blockquote>
<p>
            <b>Rationale:</b>
        </p>
<p>This is request for a pure extension, so it is not a defect in the
current standard.&nbsp; As the submitter pointed out, "this can
be accomplished using a combination of find_if and bind_1st or
bind_2nd".</p>
<hr>
        <a name="236">
            <h3>236.&nbsp;ctype&lt;char&gt;::is() member modifies facet</h3>
        </a>
        <p>
            <b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members">[lib.facet.ctype.char.members]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Dietmar K&uuml;hl <b>Date:</b>&nbsp;24 Apr 2000</p>
<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members">[lib.facet.ctype.char.members]</a> is broken: According to this description, the
second form of the <tt>is()</tt> method modifies the masks in the
<tt>ctype</tt> object. The correct semantics if, of course, to obtain
an array of masks. The corresponding method in the general case,
ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals">[lib.locale.ctype.virtuals]</a> paragraph 1 does the right thing.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
  <p>Change paragraph 4 from</p>
    <blockquote>
    The second form, for all *p in the range [low, high), assigns
    vec[p-low] to table()[(unsigned char)*p].
    </blockquote>
  <p>to become</p>
    <blockquote>
    The second form, for all *p in the range [low, high), assigns
    table()[(unsigned char)*p] to vec[p-low].
  </blockquote>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate.  See issue <a href="lwg-defects.html#28">28</a>.</p>
<hr>
        <a name="244">
            <h3>244.&nbsp;Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
        </a>
        <p>
            <b>Section:</b> 25.1.2 <a href="lib-algorithms.html#lib.alg.find">[lib.alg.find]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Andrew Koenig <b>Date:</b>&nbsp;02 May 2000</p>
<p>Is the following implementation of <tt>find</tt> acceptable?</p>

<pre>
        template&lt;class Iter, class X&gt;
        Iter find(Iter begin, Iter end, const X&amp; x)
        {
            X x1 = x;           // this is the crucial statement
            while (begin != end &amp;&amp; *begin != x1)
                ++begin;
            return begin;
        }
</pre>

<p>If the answer is yes, then it is implementation-dependent as to
whether the following fragment is well formed:</p>

<pre>
        vector&lt;string&gt; v;

        find(v.begin(), v.end(), "foo");
</pre>

<p>At issue is whether there is a requirement that the third argument
of find be CopyConstructible.  There may be no problem here, but
analysis is necessary.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>There is no indication in the standard that find's third argument
is required to be Copy Constructible.  The LWG believes that no such
requirement was intended.  As noted above, there are times when a user
might reasonably pass an argument that is not Copy Constructible.</p>
<hr>
        <a name="245">
            <h3>245.&nbsp;Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
        </a>
        <p>
            <b>Section:</b> 24.5.1 <a href="lib-iterators.html#lib.istream.iterator">[lib.istream.iterator]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Andrew Koenig <b>Date:</b>&nbsp;02 May 2000</p>
<p>I do not think the standard specifies what operation(s) on istream
iterators trigger input operations.  So, for example:</p>

<pre>
        istream_iterator&lt;int&gt; i(cin);

        int n = *i++;
</pre>

<p>I do not think it is specified how many integers have been read
from cin.  The number must be at least 1, of course, but can it be 2?
More?</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The standard is clear as written: the stream is read every time
operator++ is called, and it is also read either when the iterator is
constructed or when operator* is called for the first time.  In the
example above, exactly two integers are read from cin.</p>

<p>There may be a problem with the interaction between istream_iterator
and some STL algorithms, such as find.  There are no guarantees about
how many times find may invoke operator++.</p>
<hr>
        <a name="246">
            <h3>246.&nbsp;<tt>a.insert(p,t)</tt> is incorrectly specified</h3>
        </a>
        <p>
            <b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts">[lib.associative.reqmts]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#Dup">Dup</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Mark Rodgers <b>Date:</b>&nbsp;19 May 2000</p>
<p>Closed issue 192 raised several problems with the specification of
this function, but was rejected as Not A Defect because it was too big
a change with unacceptable impacts on existing implementations.
However, issues remain that could be addressed with a smaller change
and with little or no consequent impact.</p>

<ol>
   <li>
                <p> The specification is inconsistent with the original
   proposal and with several implementations.</p>

   <p>The initial implementation by Hewlett Packard only ever looked
   immediately <i>before</i> p, and I do not believe there was any
   intention to standardize anything other than this behavior.
   Consequently, current implementations by several leading
   implementors also look immediately before p, and will only insert
   after p in logarithmic time.  I am only aware of one implementation
   that does actually look after p, and it looks before p as well.  It
   is therefore doubtful that existing code would be relying on the
   behavior defined in the standard, and it would seem that fixing
   this defect as proposed below would standardize existing
   practice.</p>
            </li>

   <li>
                <p>
   The specification is inconsistent with insertion for sequence
   containers.</p>

   <p>This is difficult and confusing to teach to newcomers.  All
   insert operations that specify an iterator as an insertion location
   should have a consistent meaning for the location represented by
   that iterator.</p>
            </li>

   <li>
                <p> As specified, there is no way to hint that the insertion
   should occur at the beginning of the container, and the way to hint
   that it should occur at the end is long winded and unnatural.</p>

   <p>For a container containing n elements, there are n+1 possible
   insertion locations and n+1 valid iterators.  For there to be a
   one-to-one mapping between iterators and insertion locations, the
   iterator must represent an insertion location immediately before
   the iterator.</p>
            </li>

   <li>
                <p> When appending sorted ranges using insert_iterators,
   insertions are guaranteed to be sub-optimal.</p>

   <p>In such a situation, the optimum location for insertion is
   always immediately after the element previously inserted.  The
   mechanics of the insert iterator guarantee that it will try and
   insert after the element after that, which will never be correct.
   However, if the container first tried to insert before the hint,
   all insertions would be performed in amortized constant
   time.</p>
            </li>
</ol>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
the following changes in the row for a.insert(p,t):</p>

<p>
            <i>assertion/note pre/post condition:</i>
<br>Change the last sentence from</p>
     <blockquote>
     "iterator p is a hint pointing to where the insert should
     start to search."
     </blockquote>
<p>to</p>
     <blockquote>
     "iterator p is a hint indicating that immediately before p
     may be a correct location where the insertion could occur."
     </blockquote>

<p>
            <i>complexity:</i>
            <br>
Change the words "right after" to "immediately before".</p>
<p>
            <b>Rationale:</b>
        </p>
<p>Duplicate; see issue <a href="lwg-active.html#233">233</a>.</p>
<hr>
        <a name="249">
            <h3>249.&nbsp;Return Type of <tt>auto_ptr::operator=</tt>
            </h3>
        </a>
        <p>
            <b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr">[lib.auto.ptr]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Joseph Gottman <b>Date:</b>&nbsp;30 Jun 2000</p>
<p>According to section 20.4.5, the function
<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
The reason that <tt>operator=()</tt> usually returns a reference is to
facilitate code like</p>

<pre>
    int x,y,z;
    x = y = z = 1;
</pre>

<p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
<pre>
    auto_ptr&lt;int&gt; x, y, z;
    z.reset(new int(1));
    x = y = z;
</pre>

<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to 
NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value. 
This makes such cascading assignments useless and counterintuitive for 
<tt>auto_ptr</tt>s.</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
of an <tt>auto_ptr</tt> reference.</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The return value has uses other than cascaded assignments: a user can
call an auto_ptr member function, pass the auto_ptr to a
function, etc.  Removing the return value could break working user
code.</p>
<hr>
        <a name="255">
            <h3>255.&nbsp;Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
        </a>
        <p>
            <b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf">[lib.streambuf]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="#NAD">NAD</a>&nbsp;<a href="#Future">Future</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Martin Sebor <b>Date:</b>&nbsp;12 Aug 2000</p>
<p>
The basic_streambuf members gbump() and pbump() are specified to take an
int argument. This requirement prevents the functions from effectively
manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
characters. It also makes the common use case for these functions
somewhat difficult as many compilers will issue a warning when an
argument of type larger than int (such as ptrdiff_t on LLP64
architectures) is passed to either of the function. Since it's often the
result of the subtraction of two pointers that is passed to the
functions, a cast is necessary to silence such warnings. Finally, the
usage of a native type in the functions signatures is inconsistent with
other member functions (such as sgetn() and sputn()) that manipulate the
underlying character buffer. Those functions take a streamsize argument.
</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>
Change the signatures of these functions in the synopsis of template
class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
and 27.5.2.3.2, p4) to take a streamsize argument.
</p>

<p>
Although this change has the potential of changing the ABI of the
library, the change will affect only platforms where int is different
than the definition of streamsize. However, since both functions are
typically inline (they are on all known implementations), even on such
platforms the change will not affect any user code unless it explicitly
relies on the existing type of the functions (e.g., by taking their
address). Such a possibility is IMO quite remote.
</p>

<p>
Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
</p>

<p>
This is something of a nit, but I'm wondering if streamoff wouldn't be a 
better choice than streamsize.  The argument to pbump and gbump MUST be 
signed.  But the standard has this to say about streamsize 
(27.4.1/2/Footnote):
</p>

<blockquote>
     [Footnote: streamsize is used in most places where ISO C would use
     size_t.  Most of the uses of streamsize could use size_t, except for
     the strstreambuf constructors, which require negative values. It
     should probably be the signed type corresponding to size_t (which is
     what Posix.2 calls ssize_t). --- end footnote]
</blockquote>

<p>
This seems a little weak for the argument to pbump and gbump.  Should we 
ever really get rid of strstream, this footnote might go with it, along 
with the reason to make streamsize signed.
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>The LWG believes this change is too big for now.  We may wish to
reconsider this for a future revision of the standard.  One
possibility is overloading pbump, rather than changing the
signature.</p>
<hr>
        <a name="257">
            <h3>257.&nbsp;STL functional object and iterator inheritance.</h3>
        </a>
        <p>
            <b>Section:</b> 20.3.1 <a href="lib-utilities.html#lib.base">[lib.base]</a>, 24.3.2 <a href="lib-iterators.html#lib.iterator.basic">[lib.iterator.basic]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;Robert Dick  <b>Date:</b>&nbsp;17 Aug 2000</p>
<p>
According to the November 1997 Draft Standard, the results of deleting an
object of a derived class through a pointer to an object of its base class are
undefined if the base class has a non-virtual destructor.  Therefore, it is
potentially dangerous to publicly inherit from such base classes.
</p>

<p>Defect:
<br>
The STL design encourages users to publicly inherit from a number of classes
which do nothing but specify interfaces, and which contain non-virtual
destructors.
</p>

<p>Attribution:
<br>
Wil Evers and William E. Kempf suggested this modification for functional
objects.
</p>
<p>
            <b>Proposed resolution:</b>
        </p>
<p>
When a base class in the standard library is useful only as an interface
specifier, i.e., when an object of the class will never be directly
instantiated, specify that the class contains a protected destructor.  This
will prevent deletion through a pointer to the base class without performance,
or space penalties (on any implementation I'm aware of).
</p>

<p>
As an example, replace...
</p>

<pre>
    template &lt;class Arg, class Result&gt;
    struct unary_function {
            typedef Arg    argument_type;
            typedef Result result_type;
    };
</pre>

<p>
... with...
</p>

<pre>
    template &lt;class Arg, class Result&gt;
    struct unary_function {
            typedef Arg    argument_type;
            typedef Result result_type;
    protected:
            ~unary_function() {}
    };
</pre>

<p>
Affected definitions:
<br>
  &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
  <br>
  &nbsp;24.3.2 [lib.iterator.basic] -- iterator
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>
The standard is clear as written; this is a request for change, not a
defect in the strict sense.  The LWG had several different objections
to the proposed change.  One is that it would prevent users from
creating objects of type <tt>unary_function</tt> and
<tt>binary_function</tt>.  Doing so can sometimes be legitimate, if users
want to pass temporaries as traits or tag types in generic code.
</p>
<hr>
        <a name="269">
            <h3>269.&nbsp;cstdarg and unnamed parameters</h3>
        </a>
        <p>
            <b>Section:</b> 18.7 <a href="lib-support.html#lib.support.runtime">[lib.support.runtime]</a>
  &nbsp;
<b>Status:</b>&nbsp;
   <a href="lwg-active.html#NAD">NAD</a>
   
   
     
       &nbsp;
   <b>Submitter:</b>&nbsp;J. Stephen Adamczyk <b>Date:</b>&nbsp;10 Oct 2000</p>
<p>
One of our customers asks whether this is valid C++:
</p>

<pre>
   #include &lt;cstdarg&gt;

   void bar(const char *, va_list);

   void
   foo(const char *file, const char *, ...)
   {
     va_list ap;
     va_start(ap, file);
     bar(file, ap);
     va_end(ap);
   }
</pre>

<p>
The issue being whether it is valid to use cstdarg when the final
parameter before the "..." is unnamed.  cstdarg is, as far
as I can tell, inherited verbatim from the C standard. and the
definition there (7.8.1.1 in the ISO C89 standard) refers to "the
identifier of the rightmost parameter".  What happens when there
is no such identifier?
</p>

<p>
My personal opinion is that this should be allowed, but some tweak
might be required in the C++ standard.
</p>
<p>
            <b>Rationale:</b>
        </p>
<p>
Not a defect, the C and C++ standards are clear.  It is impossible to
use varargs if the parameter immediately before "..." has no
name, because that is the parameter that must be passed to va_start.
The example given above is broken, because va_start is being passed
the wrong parameter.
</p>

<p>
There is no support for extending varargs to provide additional
functionality beyond what's currently there.  For reasons of C/C++
compatibility, it is especially important not to make gratuitous
changes in this part of the C++ standard.  The C committee has already
been requested not to touch this part of the C standard unless
necessary.
</p>

     ----- End of document -----
    </body>
</html>
