mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-01-09 08:54:31 +08:00
77cd227ec3
2001-09-25 Phil Edwards <pme@gcc.gnu.org> * docs/html/20_util/howto.html: Add anchor name. * docs/html/23_containers/howto.html: Line wrapping, another link. * docs/html/25_algorithms/howto.html: Another note. * docs/html/ext/howto.html: Link to SGI extensions. List DRs and link to them... * docs/html/ext/lwg-active.html: ...in this new file (from R19), * docs/html/ext/lwg-defects.html: and this new file (from R19). * docs/html/ext/sgiexts.html: New file. Mention SGI extensions carried over to libstdc++-v3. * docs/html/faq/index.html: Link to SGI extensions. Mention the "missing .." pseudobug. * docs/html/faq/index.txt: Regenerate. * include/bits/ios_base.h: DR-related comment cleanup. * include/bits/istream.tcc: Likewise. * include/bits/locale_facets.h: Likewise. * include/bits/locale_facets.tcc: Likewise. * include/bits/ostream.tcc: Likewise. * include/bits/std_bitset.h: Likewise. * include/bits/std_iosfwd.h: Likewise. * include/bits/std_istream.h: Likewise. * include/bits/std_ostream.h: Likewise. * include/bits/std_streambuf.h: Likewise. * include/bits/stl_pair.h: Likewise. * include/bits/streambuf_iterator.h: Likewise. * include/bits/std_map.h: Remove unused header inclusion guard _CPP_BITS_STL_TREE_H from around bits/stl_tree.h. * include/bits/std_set.h: Likewise. * include/bits/stl_function.h: Doxygen markup. * docs/doxygen/doxygroups.cc: New file, specifying module grouping. * libsupc++/typeinfo: Doxygen markup tweak. From-SVN: r45816
4867 lines
240 KiB
HTML
4867 lines
240 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<html>
|
|
<head><title>C++ Standard Library Defect Report List</title></head>
|
|
<body bgcolor="#ffffff" text="#000000">
|
|
<table>
|
|
<tr>
|
|
<td align="left">Doc. no.</td>
|
|
<td align="left">J16/01-0032 = WG21 N1318</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Date:</td>
|
|
<td align="left">11 Sep 2001</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Project:</td>
|
|
<td align="left">Programming Language C++</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Reply to:</td>
|
|
<td align="left">Matt Austern <austern@research.att.com></td>
|
|
</tr>
|
|
</table>
|
|
<h1>C++ Standard Library Defect Report List (Revision 19)</h1>
|
|
<p>Reference ISO/IEC IS 14882:1998(E)</p>
|
|
<p>Also see:</p>
|
|
<ul>
|
|
<li>
|
|
<a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
|
|
<li>
|
|
<a href="lwg-index.html">Index by Section</a> for all library issues.</li>
|
|
<li>
|
|
<a href="lwg-status.html">Index by Status</a> for all library issues.</li>
|
|
<li><a href="lwg-active.html">Library Active Issues List</a></li>
|
|
<li><a href="lwg-closed.html">Library Closed Issues List</a></li>
|
|
</ul>
|
|
<p>This document contains only library issues which have been closed
|
|
by the Library Working Group (LWG) after being found to be defects
|
|
in the standard. That is, issues which have a status of <a href="lwg-active.html#DR">DR</a>, <a href="lwg-active.html#TC">TC</a>, or <a href="lwg-active.html#RR">RR</a>. See the
|
|
<a href="lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the
|
|
<a href="lwg-active.html">Library Active Issues List</a> for active issues and more information. The
|
|
introductory material in that document also applies to this
|
|
document.</p>
|
|
<h2>Revision History</h2>
|
|
<ul>
|
|
<li>R19:
|
|
Pre-Redmond mailing. Added new issues
|
|
<a href="lwg-active.html#323">323</a>-<a href="lwg-active.html#335">335</a>.
|
|
</li>
|
|
<li>R18:
|
|
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
|
|
Added new issues <a href="lwg-active.html#312">312</a>-<a href="lwg-active.html#317">317</a>, and discussed
|
|
new issues <a href="lwg-active.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
|
|
|
|
Changed status of issues
|
|
<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
|
|
<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
|
|
<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
|
|
<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
|
|
<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
|
|
<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
|
|
<a href="lwg-defects.html#268">268</a>
|
|
to DR.
|
|
|
|
Changed status of issues
|
|
<a href="lwg-active.html#49">49</a> <a href="lwg-active.html#109">109</a> <a href="lwg-active.html#117">117</a> <a href="lwg-active.html#182">182</a>
|
|
<a href="lwg-active.html#228">228</a> <a href="lwg-active.html#230">230</a> <a href="lwg-active.html#232">232</a> <a href="lwg-active.html#235">235</a>
|
|
<a href="lwg-active.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-active.html#242">242</a> <a href="lwg-active.html#250">250</a>
|
|
<a href="lwg-active.html#259">259</a> <a href="lwg-active.html#264">264</a> <a href="lwg-active.html#266">266</a> <a href="lwg-active.html#267">267</a>
|
|
<a href="lwg-active.html#271">271</a> <a href="lwg-active.html#272">272</a> <a href="lwg-active.html#273">273</a> <a href="lwg-active.html#275">275</a>
|
|
<a href="lwg-active.html#281">281</a> <a href="lwg-active.html#284">284</a> <a href="lwg-active.html#285">285</a> <a href="lwg-active.html#286">286</a>
|
|
<a href="lwg-active.html#288">288</a> <a href="lwg-active.html#292">292</a> <a href="lwg-active.html#295">295</a> <a href="lwg-active.html#297">297</a>
|
|
<a href="lwg-active.html#298">298</a> <a href="lwg-active.html#301">301</a> <a href="lwg-active.html#303">303</a> <a href="lwg-active.html#306">306</a>
|
|
<a href="lwg-active.html#307">307</a> <a href="lwg-active.html#308">308</a> <a href="lwg-active.html#312">312</a>
|
|
to Ready.
|
|
|
|
Closed issues
|
|
<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
|
|
<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
|
|
<a href="lwg-closed.html#314">314</a>
|
|
as NAD.
|
|
|
|
</li>
|
|
<li>R17:
|
|
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
|
|
resolutions for issues <a href="lwg-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-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>. Changed status of issues
|
|
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
|
|
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
|
|
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
|
|
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
|
|
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
|
|
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
|
|
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
|
|
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
|
|
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
|
|
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
|
|
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
|
|
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
|
|
<a href="lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
|
|
issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
|
|
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
|
|
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
|
|
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
|
|
the bug in enough places.
|
|
</li>
|
|
<li>R15:
|
|
pre-Toronto mailing. Added issues
|
|
<a href="lwg-active.html#233">233</a>-<a href="lwg-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-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
|
|
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
|
|
</li>
|
|
<li>R6:
|
|
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
|
|
and <a href="lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
|
|
</li>
|
|
<li>R5:
|
|
update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
|
|
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
|
|
for making list public. (30 Dec 98)
|
|
</li>
|
|
<li>R4:
|
|
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
|
|
<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
|
|
issues corrected. (22 Oct 98)
|
|
</li>
|
|
<li>R3:
|
|
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-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>Defect Reports</h2>
|
|
<hr>
|
|
<a name="1"><h3>1. C library linkage editing oversight</h3></a><p>
|
|
<b>Section:</b> 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
|
|
<p>The change specified in the proposed resolution below did not make
|
|
it into the Standard. This change was accepted in principle at the
|
|
London meeting, and the exact wording below was accepted at the
|
|
Morristown meeting.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 17.4.2.2 paragraph 2
|
|
from:</p>
|
|
|
|
<blockquote>
|
|
<p>It is unspecified whether a name from the Standard C library
|
|
declared with external linkage has either extern "C" or
|
|
extern "C++" linkage.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Whether a name from the Standard C library declared with external
|
|
linkage has extern "C" or extern "C++" linkage
|
|
is implementation defined. It is recommended that an implementation
|
|
use extern "C++" linkage for this purpose.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p>
|
|
<b>Section:</b> 18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p>
|
|
<p>We appear not to have covered all the possibilities of
|
|
exit processing with respect to
|
|
atexit registration. <br>
|
|
<br>
|
|
Example 1: (C and C++)</p>
|
|
|
|
<pre> #include <stdlib.h>
|
|
void f1() { }
|
|
void f2() { atexit(f1); }
|
|
|
|
int main()
|
|
{
|
|
atexit(f2); // the only use of f2
|
|
return 0; // for C compatibility
|
|
}</pre>
|
|
|
|
<p>At program exit, f2 gets called due to its registration in
|
|
main. Running f2 causes f1 to be newly registered during the exit
|
|
processing. Is this a valid program? If so, what are its
|
|
semantics?</p>
|
|
|
|
<p>
|
|
Interestingly, neither the C standard, nor the C++ draft standard nor
|
|
the forthcoming C9X Committee Draft says directly whether you can
|
|
register a function with atexit during exit processing.</p>
|
|
|
|
<p>
|
|
All 3 standards say that functions are run in reverse order of their
|
|
registration. Since f1 is registered last, it ought to be run first,
|
|
but by the time it is registered, it is too late to be first.</p>
|
|
|
|
<p>If the program is valid, the standards are self-contradictory about
|
|
its semantics.</p>
|
|
|
|
<p>Example 2: (C++ only)</p>
|
|
|
|
<pre>
|
|
void F() { static T t; } // type T has a destructor
|
|
|
|
int main()
|
|
{
|
|
atexit(F); // the only use of F
|
|
}
|
|
</pre>
|
|
|
|
<p>Function F registered with atexit has a local static variable t,
|
|
and F is called for the first time during exit processing. A local
|
|
static object is initialized the first time control flow passes
|
|
through its definition, and all static objects are destroyed during
|
|
exit processing. Is the code valid? If so, what are its semantics?</p>
|
|
|
|
<p>
|
|
Section 18.3 "Start and termination" says that if a function
|
|
F is registered with atexit before a static object t is initialized, F
|
|
will not be called until after t's destructor completes.</p>
|
|
|
|
<p>
|
|
In example 2, function F is registered with atexit before its local
|
|
static object O could possibly be initialized. On that basis, it must
|
|
not be called by exit processing until after O's destructor
|
|
completes. But the destructor cannot be run until after F is called,
|
|
since otherwise the object could not be constructed in the first
|
|
place.</p>
|
|
|
|
<p>If the program is valid, the standard is self-contradictory about
|
|
its semantics.</p>
|
|
|
|
<p>I plan to submit Example 1 as a public comment on the C9X CD, with
|
|
a recommendation that the results be undefined. (Alternative: make it
|
|
unspecified. I don't think it is worthwhile to specify the case where
|
|
f1 itself registers additional functions, each of which registers
|
|
still more functions.)</p>
|
|
|
|
<p>I think we should resolve the situation in the whatever way the C
|
|
committee decides. </p>
|
|
|
|
<p>For Example 2, I recommend we declare the results undefined.</p>
|
|
|
|
<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change section 18.3/8 from:</p>
|
|
<blockquote>
|
|
First, objects with static storage duration are destroyed and
|
|
functions registered by calling atexit are called. Objects with
|
|
static storage duration are destroyed in the reverse order of the
|
|
completion of their constructor. (Automatic objects are not
|
|
destroyed as a result of calling exit().) Functions registered with
|
|
atexit are called in the reverse order of their registration. A
|
|
function registered with atexit before an object obj1 of static
|
|
storage duration is initialized will not be called until obj1's
|
|
destruction has completed. A function registered with atexit after
|
|
an object obj2 of static storage duration is initialized will be
|
|
called before obj2's destruction starts.
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
First, objects with static storage duration are destroyed and
|
|
functions registered by calling atexit are called. Non-local objects
|
|
with static storage duration are destroyed in the reverse order of
|
|
the completion of their constructor. (Automatic objects are not
|
|
destroyed as a result of calling exit().) Functions registered with
|
|
atexit are called in the reverse order of their registration, except
|
|
that a function is called after any previously registered functions
|
|
that had already been called at the time it was registered. A
|
|
function registered with atexit before a non-local object obj1 of
|
|
static storage duration is initialized will not be called until
|
|
obj1's destruction has completed. A function registered with atexit
|
|
after a non-local object obj2 of static storage duration is
|
|
initialized will be called before obj2's destruction starts. A local
|
|
static object obj3 is destroyed at the same time it would be if a
|
|
function calling the obj3 destructor were registered with atexit at
|
|
the completion of the obj3 constructor.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
|
|
supporting to the proposed resolution.</p>
|
|
<hr>
|
|
<a name="5"><h3>5. String::compare specification questionable</h3></a><p>
|
|
<b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p>
|
|
<p>At the very end of the basic_string class definition is the signature: int
|
|
compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
|
|
following text this is defined as: returns
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
|
basic_string<charT,traits,Allocator>(s,n2); </p>
|
|
|
|
<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a
|
|
= Allocator()) clearly requires that s != NULL and n < npos and further states that it
|
|
throws length_error if n == npos, it appears the compare() signature above should always
|
|
throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
|
|
null terminated character array. </p>
|
|
|
|
<p>This appears to be a typo since the obvious intent is to allow either the call above or
|
|
something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
|
|
|
|
<p>This would imply that what was really intended was two signatures int compare(size_type
|
|
pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
|
|
charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the compare signature in 21.3
|
|
(at the very end of the basic_string synopsis) which reads:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s,
|
|
size_type n2 = npos) const;</tt></p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s) const;<br>
|
|
int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s,
|
|
size_type n2) const;</tt></p>
|
|
</blockquote>
|
|
|
|
<p>Replace the portion of 21.3.6.8
|
|
paragraphs 5 and 6 which read:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>int compare(size_type pos, size_type n1,<br>
|
|
charT * s, size_type n2
|
|
= npos) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>int compare(size_type pos, size_type n1,<br>
|
|
const charT * s) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s ))<br>
|
|
<br>
|
|
int compare(size_type pos, size_type n1,<br>
|
|
const charT * s,
|
|
size_type n2) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>Editors please note that in addition to splitting the signature, the third argument
|
|
becomes const, matching the existing synopsis.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>While the LWG dislikes adding signatures, this is a clear defect in
|
|
the Standard which must be fixed. The same problem was also
|
|
identified in issues 7 (item 5) and 87.</p>
|
|
<hr>
|
|
<a name="7"><h3>7. String clause minor problems</h3></a><p>
|
|
<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
|
|
<p>(1) In 21.3.5.4 , the description of template
|
|
<class InputIterator> insert(iterator, InputIterator,
|
|
InputIterator) makes no sense. It refers to a member function that
|
|
doesn't exist. It also talks about the return value of a void
|
|
function. </p>
|
|
|
|
<p>(2) Several versions of basic_string::replace don't appear in the
|
|
class synopsis. </p>
|
|
|
|
<p>(3) basic_string::push_back appears in the synopsis, but is never
|
|
described elsewhere. In the synopsis its argument is const charT,
|
|
which doesn't makes much sense; it should probably be charT, or
|
|
possible const charT&. </p>
|
|
|
|
<p>(4) basic_string::pop_back is missing. </p>
|
|
|
|
<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
|
|
= npos) make no sense. First, it's const charT* in the synopsis and
|
|
charT* in the description. Second, given what it says in RETURNS,
|
|
leaving out the final argument will always result in an exception
|
|
getting thrown. This is paragraphs 5 and 6 of
|
|
21.3.6.8 </p>
|
|
|
|
<p>(6) In table 37, in section 21.1.1 ,
|
|
there's a note for X::move(s, p, n). It says "Copies correctly
|
|
even where p is in [s, s+n)". This is correct as far as it goes,
|
|
but it doesn't go far enough; it should also guarantee that the copy
|
|
is correct even where s in in [p, p+n). These are two orthogonal
|
|
guarantees, and neither one follows from the other. Both guarantees
|
|
are necessary if X::move is supposed to have the same sort of
|
|
semantics as memmove (which was clearly the intent), and both
|
|
guarantees are necessary if X::move is actually supposed to be
|
|
useful. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
|
|
<br>
|
|
EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
|
|
<br>
|
|
ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in
|
|
the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
|
|
<br>
|
|
ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
|
|
[lib.basic.string]) from:</p>
|
|
|
|
<p> void push_back(const charT)<br>
|
|
<br>
|
|
to<br>
|
|
<br>
|
|
void push_back(charT)<br>
|
|
<br>
|
|
Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
|
|
<br>
|
|
void basic_string::push_back(charT c);<br>
|
|
EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br>
|
|
<br>
|
|
ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
|
|
<br>
|
|
ITEM 5: Duplicate; see issue 5 (and 87).<br>
|
|
<br>
|
|
ITEM 6: In table 37, Replace:<br>
|
|
<br>
|
|
"Copies correctly even where p is in [s, s+n)."<br>
|
|
<br>
|
|
with:<br>
|
|
<br>
|
|
"Copies correctly even where the ranges [p, p+n) and [s,
|
|
s+n) overlap."</p>
|
|
<hr>
|
|
<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p>
|
|
<b>Section:</b> 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p>
|
|
<p>It appears there's an important guarantee missing from clause
|
|
22. We're told that invoking locale::global(L) sets the C locale if L
|
|
has a name. However, we're not told whether or not invoking
|
|
setlocale(s) sets the global C++ locale. </p>
|
|
|
|
<p>The intent, I think, is that it should not, but I can't find any
|
|
such words anywhere. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a sentence at the end of 22.1.1.5 ,
|
|
paragraph 2: </p>
|
|
|
|
<blockquote>
|
|
<p>No library function other than <tt>locale::global()</tt> shall affect
|
|
the value returned by <tt>locale()</tt>. </p>
|
|
|
|
</blockquote>
|
|
<hr>
|
|
<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p>
|
|
<b>Section:</b> 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p>
|
|
<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
|
|
section 3.7.3.1 of CD2 seems to allow for the possibility that all
|
|
calls to operator new(0) yield the same pointer, an implementation
|
|
technique specifically prohibited by ARM 5.3.3.Was this prohibition
|
|
really lifted? Does the FDIS agree with CD2 in the regard? [Issues
|
|
list maintainer's note: the IS is the same.]</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the last paragraph of 3.7.3 from:</p>
|
|
<blockquote>
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program shall
|
|
conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program,
|
|
including the default versions in the library, shall conform to the semantics
|
|
specified in 3.7.3.1 and 3.7.3.2.</p>
|
|
</blockquote>
|
|
<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
|
|
<blockquote>
|
|
<p>If the size of the space requested is zero, the value returned shall not be
|
|
a null pointer value (4.10).</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Even if the size of the space requested is zero, the request can fail. If
|
|
the request succeeds, the value returned shall be a non-null pointer value
|
|
(4.10) p0 different from any previously returned value p1, unless that value
|
|
p1 was since passed to an operator delete.</p>
|
|
</blockquote>
|
|
<p>5.3.4/7 currently reads:</p>
|
|
<blockquote>
|
|
<p>When the value of the expression in a direct-new-declarator is zero, the
|
|
allocation function is called to allocate an array with no elements. The
|
|
pointer returned by the new-expression is non-null. [Note: If the library
|
|
allocation function is called, the pointer returned is distinct from the
|
|
pointer to any other object.]</p>
|
|
</blockquote>
|
|
<p>Retain the first sentence, and delete the remainder.</p>
|
|
<p>18.4.1 currently has no text. Add the following:</p>
|
|
<blockquote>
|
|
<p>Except where otherwise specified, the provisions of 3.7.3 apply to the
|
|
library versions of operator new and operator delete.</p>
|
|
</blockquote>
|
|
<p>To 18.4.1.3, add the following text:</p>
|
|
<blockquote>
|
|
<p>The provisions of 3.7.3 do not apply to these reserved placement forms of
|
|
operator new and operator delete.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
|
|
supporting to the proposed resolution.</p>
|
|
<hr>
|
|
<a name="11"><h3>11. Bitset minor problems</h3></a><p>
|
|
<b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
|
|
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
|
|
not documented in 23.3.5.2. </p>
|
|
|
|
<p>(2) The class synopsis only gives a single signature for bitset<>::operator[],
|
|
reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
|
|
on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
|
|
|
|
<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
|
|
trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
|
|
go in the Effects clause.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>ITEMS 1 AND 2:<br>
|
|
<br>
|
|
In the bitset synopsis (23.3.5 ),
|
|
replace the member function <br>
|
|
<br>
|
|
<tt> reference operator[](size_t pos);<br>
|
|
</tt><br>
|
|
with the two member functions<br>
|
|
<br>
|
|
<tt> bool operator[](size_t pos) const; <br>
|
|
reference operator[](size_t pos); <br>
|
|
</tt><br>
|
|
Add the following text at the end of 23.3.5.2 ,
|
|
immediately after paragraph 45:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>bool operator[](size_t pos) const;</tt><br>
|
|
Requires: pos is valid<br>
|
|
Throws: nothing<br>
|
|
Returns: <tt>test(pos)</tt><br>
|
|
<br>
|
|
<tt>bitset<N>::reference operator[](size_t pos);</tt> <br>
|
|
Requires: pos is valid<br>
|
|
Throws: nothing<br>
|
|
Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos]
|
|
== this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos,
|
|
val);</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes Item 3 is not a defect. "Formatted
|
|
input" implies the desired semantics. See 27.6.1.2 .
|
|
</p>
|
|
<hr>
|
|
<a name="13"><h3>13. Eos refuses to die</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p>
|
|
<p>In 27.6.1.2.3, there is a reference to "eos", which is
|
|
the only one in the whole draft (at least using Acrobat search), so
|
|
it's undefined. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.2.3 , replace "eos" with
|
|
"charT()"</p>
|
|
<hr>
|
|
<a name="14"><h3>14. Locale::combine should be const</h3></a><p>
|
|
<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>locale::combine is the only member function of locale (other than constructors and
|
|
destructor) that is not const. There is no reason for it not to be const, and good reasons
|
|
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
|
|
paragraph 6: "An instance of a locale is immutable." </p>
|
|
|
|
<p>History: this member function originally was a constructor. it happened that the
|
|
interface it specified had no corresponding language syntax, so it was changed to a member
|
|
function. As constructors are never const, there was no "const" in the interface
|
|
which was transformed into member "combine". It should have been added at that
|
|
time, but the omission was not noticed. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 and also in 22.1.1.3 , add
|
|
"const" to the declaration of member combine: </p>
|
|
<blockquote>
|
|
<pre>template <class Facet> locale combine(const locale& other) const; </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p>
|
|
<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>locale::name() is described as returning a string that can be passed to a locale
|
|
constructor, but there is no matching constructor. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1.3 , paragraph 5, replace
|
|
"<tt>locale(name())</tt>" with
|
|
"<tt>locale(name().c_str())</tt>".
|
|
</p>
|
|
<hr>
|
|
<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p>
|
|
<b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
|
|
edited in properly. Instead, the member do_widen appears four times, with wrong argument
|
|
lists. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>The correct declarations for the overloaded members
|
|
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
|
|
from 22.2.1.3 .</p>
|
|
<hr>
|
|
<a name="17"><h3>17. Bad bool parsing</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>This section describes the process of parsing a text boolean value from the input
|
|
stream. It does not say it recognizes either of the sequences "true" or
|
|
"false" and returns the corresponding bool value; instead, it says it recognizes
|
|
only one of those sequences, and chooses which according to the received value of a
|
|
reference argument intended for returning the result, and reports an error if the other
|
|
sequence is found. (!) Furthermore, it claims to get the names from the ctype<>
|
|
facet rather than the numpunct<> facet, and it examines the "boolalpha"
|
|
flag wrongly; it doesn't define the value "loc"; and finally, it computes
|
|
wrongly whether to use numeric or "alpha" parsing.<br>
|
|
<br>
|
|
I believe the correct algorithm is "as if": </p>
|
|
|
|
<pre> // in, err, val, and str are arguments.
|
|
err = 0;
|
|
const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
|
|
const string_type t = np.truename(), f = np.falsename();
|
|
bool tm = true, fm = true;
|
|
size_t pos = 0;
|
|
while (tm && pos < t.size() || fm && pos < f.size()) {
|
|
if (in == end) { err = str.eofbit; }
|
|
bool matched = false;
|
|
if (tm && pos < t.size()) {
|
|
if (!err && t[pos] == *in) matched = true;
|
|
else tm = false;
|
|
}
|
|
if (fm && pos < f.size()) {
|
|
if (!err && f[pos] == *in) matched = true;
|
|
else fm = false;
|
|
}
|
|
if (matched) { ++in; ++pos; }
|
|
if (pos > t.size()) tm = false;
|
|
if (pos > f.size()) fm = false;
|
|
}
|
|
if (tm == fm || pos == 0) { err |= str.failbit; }
|
|
else { val = tm; }
|
|
return in;</pre>
|
|
|
|
<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
|
|
when one is a substring of the other. The proposed text below captures the logic of the
|
|
code above.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 , in the first line of paragraph 14,
|
|
change "&&" to "&".</p>
|
|
|
|
<p>Then, replace paragraphs 15 and 16 as follows:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>Otherwise target sequences are determined "as if" by
|
|
calling the members <tt>falsename()</tt> and
|
|
<tt>truename()</tt> of the facet obtained by
|
|
<tt>use_facet<numpunct<charT> >(str.getloc())</tt>.
|
|
Successive characters in the range <tt>[in,end)</tt> (see
|
|
[lib.sequence.reqmts]) are obtained and matched against
|
|
corresponding positions in the target sequences only as necessary to
|
|
identify a unique match. The input iterator <tt>in</tt> is
|
|
compared to <tt>end</tt> only when necessary to obtain a
|
|
character. If and only if a target sequence is uniquely matched,
|
|
<tt>val</tt> is set to the corresponding value.</p>
|
|
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
|
|
successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
|
|
<tt>str.eofbit</tt> if, when seeking another character to match, it is found that
|
|
<tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
|
|
<tt>(str.failbit|str.eofbit)</tt>if
|
|
the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
|
|
<tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
|
|
<tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
|
|
<tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
|
|
<tt>true</tt>:"1"
|
|
and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
|
|
and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
|
|
<tt>err==str.failbit</tt>. --end example]</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the list of num_get<> non-virtual members on page 22-23, the member
|
|
that parses bool values was omitted from the list of definitions of non-virtual
|
|
members, though it is listed in the class definition and the corresponding
|
|
virtual is listed everywhere appropriate. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add at the beginning of 22.2.2.1.1
|
|
another get member for bool&, copied from the entry in
|
|
22.2.2.1 .</p>
|
|
<hr>
|
|
<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>
|
|
In the definitions of codecvt<>::do_out and do_in, they are
|
|
specified to return noconv if "no conversion is
|
|
needed". This definition is too vague, and does not say
|
|
normatively what is done with the buffers.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the entry for noconv in the table under paragraph 4 in section
|
|
22.2.1.5.2 to read:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
|
|
and input sequence is identical to converted sequence.</p>
|
|
</blockquote>
|
|
<p>Change the Note in paragraph 2 to normative text as follows:</p>
|
|
<blockquote>
|
|
<p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
|
|
same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
|
|
<tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
|
|
unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p>
|
|
<b>Section:</b> 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The synopsis for numpunct<>::do_thousands_sep, and the
|
|
definition of numpunct<>::thousands_sep which calls it, specify
|
|
that it returns a value of type char_type. Here it is erroneously
|
|
described as returning a "string_type". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.3.1.2 , above paragraph 2, change
|
|
"string_type" to "char_type". </p>
|
|
<hr>
|
|
<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the second table in the section, captioned "Required
|
|
instantiations", the instantiations for codecvt_byname<>
|
|
have been omitted. These are necessary to allow users to construct a
|
|
locale by name from facets. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add in 22.1.1.1.1 to the table captioned
|
|
"Required instantiations", in the category "ctype"
|
|
the lines </p>
|
|
|
|
<blockquote>
|
|
<pre>codecvt_byname<char,char,mbstate_t>,
|
|
codecvt_byname<wchar_t,char,mbstate_t> </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="22"><h3>22. Member open vs. flags</h3></a><p>
|
|
<b>Section:</b> 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of basic_istream<>::open leaves unanswered questions about how it
|
|
responds to or changes flags in the error status for the stream. A strict reading
|
|
indicates that it ignores the bits and does not change them, which confuses users who do
|
|
not expect eofbit and failbit to remain set after a successful open. There are three
|
|
reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
|
|
and eofbit on call to open(). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.8.1.7 paragraph 3, <i>and</i> in 27.8.1.10 paragraph 3, under open() effects, add a footnote:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>A successful open does not change the error state.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of codecvt<>::do_out and do_in mentions a
|
|
symbol "do_convert" which is not defined in the
|
|
standard. This is a leftover from an edit, and should be "do_in
|
|
and do_out". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5 , paragraph 3, change
|
|
"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 , change "do_convert()" to "do_in
|
|
or do_out". </p>
|
|
<hr>
|
|
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the description of operator<< applied to strings, the standard says that uses
|
|
the smaller of os.width() and str.size(), to pad "as described in stage 3"
|
|
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 21.3.7.9 paragraph 4 from:<br>
|
|
<br>
|
|
"... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
|
..."<br>
|
|
<br>
|
|
to: <br>
|
|
<br>
|
|
"... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
|
..."</p>
|
|
<hr>
|
|
<a name="26"><h3>26. Bad sentry example</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In paragraph 6, the code in the example: </p>
|
|
|
|
<pre> template <class charT, class traits = char_traits<charT> >
|
|
basic_istream<charT,traits>::sentry(
|
|
basic_istream<charT,traits>& is, bool noskipws = false) {
|
|
...
|
|
int_type c;
|
|
typedef ctype<charT> ctype_type;
|
|
const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
|
|
while ((c = is.rdbuf()->snextc()) != traits::eof()) {
|
|
if (ctype.is(ctype.space,c)==0) {
|
|
is.rdbuf()->sputbackc (c);
|
|
break;
|
|
}
|
|
}
|
|
...
|
|
}</pre>
|
|
|
|
<p>fails to demonstrate correct use of the facilities described. In
|
|
particular, it fails to use traits operators, and specifies incorrect
|
|
semantics. (E.g. it specifies skipping over the first character in the
|
|
sequence without examining it.) </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the example above from 27.6.1.1.2
|
|
paragraph 6.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The originally proposed replacement code for the example was not
|
|
correct. The LWG tried in Kona and again in Tokyo to correct it
|
|
without success. In Tokyo, an implementor reported that actual working
|
|
code ran over one page in length and was quite complicated. The LWG
|
|
decided that it would be counter-productive to include such a lengthy
|
|
example, which might well still contain errors.</p>
|
|
<hr>
|
|
<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p>
|
|
<b>Section:</b> 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The string::erase(iterator first, iterator last) is specified to return an element one
|
|
place beyond the next element after the last one erased. E.g. for the string
|
|
"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
|
|
while 'd' has not been erased. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.5.5 , paragraph 10, change: </p>
|
|
|
|
<blockquote>
|
|
<p>Returns: an iterator which points to the element immediately following _last_ prior to
|
|
the element being erased. </p>
|
|
</blockquote>
|
|
|
|
<p>to read </p>
|
|
|
|
<blockquote>
|
|
<p>Returns: an iterator which points to the element pointed to by _last_ prior to the
|
|
other elements being erased. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p>
|
|
<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of the vector form of ctype<char>::is can be interpreted to mean
|
|
something very different from what was intended. Paragraph 4 says </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
|
|
table()[(unsigned char)*p]. </p>
|
|
</blockquote>
|
|
|
|
<p>This is intended to copy the value indexed from table()[] into the place identified in
|
|
vec[]. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 22.2.1.3.2 , paragraph 4, to read </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
|
|
the value table()[(unsigned char)*p]. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p>
|
|
<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Sections 27.3.1 and 27.3.2 mention
|
|
a function ios_base::init, which is not defined. Probably they mean
|
|
basic_ios<>::init, defined in 27.4.4.1 ,
|
|
paragraph 3. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>[R12: modified to include paragraph 5.]</p>
|
|
|
|
<p>In 27.3.1 paragraph 2 and 5, change </p>
|
|
|
|
<blockquote>
|
|
<p>ios_base::init </p>
|
|
</blockquote>
|
|
|
|
<p>to </p>
|
|
|
|
<blockquote>
|
|
<p>basic_ios<char>::init </p>
|
|
</blockquote>
|
|
|
|
<p>Also, make a similar change in 27.3.2 except it
|
|
should read </p>
|
|
|
|
<blockquote>
|
|
<p>basic_ios<wchar_t>::init </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="30"><h3>30. Wrong header for LC_*</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
|
|
where they are in fact defined elsewhere to appear in <clocale>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1.1.1 , paragraph 2, change
|
|
"<cctype>" to read "<clocale>". </p>
|
|
<hr>
|
|
<a name="31"><h3>31. Immutable locale values</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
|
|
<i>immutable</i>; once a facet reference is obtained from it,
|
|
...". This has caused some confusion, because locale variables
|
|
are manifestly assignable. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 replace paragraph 6</p>
|
|
|
|
<blockquote>
|
|
<p>An instance of <tt>locale</tt> is immutable; once a facet
|
|
reference is obtained from it, that reference remains usable as long
|
|
as the locale value itself exists.</p>
|
|
</blockquote>
|
|
|
|
<p>with</p>
|
|
|
|
<blockquote>
|
|
<p>Once a facet reference is obtained from a locale object by
|
|
calling use_facet<>, that reference remains usable, and the
|
|
results from member functions of it may be cached and re-used, as
|
|
long as some locale object refers to that facet.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of the required state before calling virtual member
|
|
basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
|
|
described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
|
|
Specifically, the latter says it calls pbackfail if: </p>
|
|
|
|
<p> traits::eq(c,gptr()[-1]) is false </p>
|
|
|
|
<p>where pbackfail claims to require: </p>
|
|
|
|
<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
|
|
|
|
<p>It appears that the pbackfail description is wrong. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.5.2.4.4 , paragraph 1, change:</p>
|
|
|
|
<blockquote>
|
|
<p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
|
|
</blockquote>
|
|
|
|
<p>to </p>
|
|
|
|
<blockquote>
|
|
<p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Note deliberate reordering of arguments for clarity in addition to the correction of
|
|
the argument value.</p>
|
|
<hr>
|
|
<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the table defining the results from do_out and do_in, the specification for the
|
|
result <i>error</i> says </p>
|
|
|
|
<blockquote>
|
|
<p>encountered a from_type character it could not convert </p>
|
|
</blockquote>
|
|
|
|
<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
|
|
an internT for do_out. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5.2 paragraph 4, replace the definition
|
|
in the table for the case of _error_ with </p>
|
|
|
|
<blockquote>
|
|
<p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p>
|
|
<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
|
|
ctype<charT>, but it has no such members. Note that this is also a problem in
|
|
22.2.2.1.2, addressed in (4). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.2.2 , paragraph 19, in the Effects:
|
|
clause for member put(...., bool), replace the initialization of the
|
|
string_type value s as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>const numpunct& np = use_facet<numpunct<charT> >(loc);
|
|
string_type s = val ? np.truename() : np.falsename(); </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p>
|
|
<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In 27.4.5.1 , we have a definition for a manipulator
|
|
named "unitbuf". Unlike other manipulators, it's not listed
|
|
in synopsis. Similarly for "nounitbuf". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the synopsis for <ios> in 27.4 , after
|
|
the entry for "nouppercase", the prototypes: </p>
|
|
|
|
<blockquote>
|
|
<pre>ios_base& unitbuf(ios_base& str);
|
|
ios_base& nounitbuf(ios_base& str); </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p>
|
|
<b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
|
|
specified badly, so that an implementation which only keeps the last value stored appears
|
|
to conform. In particular, it says: </p>
|
|
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
|
member with a different index ... </p>
|
|
|
|
<p>This is not idle speculation; at least one implementation was done this way. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add in 27.4.2.5 , in both paragraph 2 and also in
|
|
paragraph 4, replace the sentence: </p>
|
|
|
|
<blockquote>
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
|
[pword] member with a different index, after a call to its copyfmt member, or when the
|
|
object is destroyed. </p>
|
|
</blockquote>
|
|
|
|
<p>with: </p>
|
|
|
|
<blockquote>
|
|
<p>The reference returned is invalid after any other operations on the object. However,
|
|
the value of the storage referred to is retained, so that until the next call to copyfmt,
|
|
calling iword [pword] with the same index yields another reference to the same value. </p>
|
|
</blockquote>
|
|
|
|
<p>substituting "iword" or "pword" as appropriate. </p>
|
|
<hr>
|
|
<a name="37"><h3>37. Leftover "global" reference</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
|
|
|
|
<blockquote>
|
|
<p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
|
|
the standard exception bad_cast. </p>
|
|
</blockquote>
|
|
|
|
<p>This is not supported by the definition of use_facet<>, and represents semantics
|
|
from an old draft. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 , paragraph 4, delete the parenthesized
|
|
expression </p>
|
|
|
|
<blockquote>
|
|
<p>(or, failing that, in the global locale) </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="38"><h3>38. Facet definition incomplete</h3></a><p>
|
|
<b>Section:</b> 22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>It has been noticed by Esa Pulkkinen that the definition of
|
|
"facet" is incomplete. In particular, a class derived from
|
|
another facet, but which does not define a member <i>id</i>, cannot
|
|
safely serve as the argument <i>F</i> to use_facet<F>(loc),
|
|
because there is no guarantee that a reference to the facet instance
|
|
stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which
|
|
reads: </p>
|
|
|
|
<blockquote>
|
|
<p>Get a reference to a facet of a locale. </p>
|
|
</blockquote>
|
|
|
|
<p>with: </p>
|
|
|
|
<blockquote>
|
|
<p>Requires: <tt>Facet</tt> is a facet class whose definition
|
|
contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 . </p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Kona: strike as overspecification the text "(not inherits)"
|
|
from the original resolution, which read "... whose definition
|
|
contains (not inherits) the public static member
|
|
<tt>id</tt>..."
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p>
|
|
<b>Section:</b> 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
|
|
3, the standard contains three lines of garbage text left over from a previous edit. </p>
|
|
|
|
<blockquote>
|
|
<pre>istreambuf_iterator<charT,traits> tmp = *this;
|
|
sbuf_->sbumpc();
|
|
return(tmp); </pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.3.4 , delete the three lines of code at the
|
|
end of paragraph 3. </p>
|
|
<hr>
|
|
<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 3 of the locale examples is a description of part of an
|
|
implementation technique that has lost its referent, and doesn't mean
|
|
anything. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Delete 22.2.8 paragraph 3 which begins "This
|
|
initialization/identification system depends...", or (at the
|
|
editor's option) replace it with a place-holder to keep the paragraph
|
|
numbering the same. </p>
|
|
<hr>
|
|
<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of ios_base::iword() and pword() in 27.4.2.4 , say that if they fail, they "set badbit,
|
|
which may throw an exception". However, ios_base offers no
|
|
interface to set or to test badbit; those interfaces are defined in
|
|
basic_ios<>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the description in 27.4.2.5 in
|
|
paragraph 2, and also in paragraph 4, as follows. Replace</p>
|
|
|
|
<blockquote>
|
|
<p>If the function fails it sets badbit, which may throw an exception.</p>
|
|
</blockquote>
|
|
|
|
<p>with</p>
|
|
|
|
<blockquote>
|
|
<p>If the function fails, and <tt>*this</tt> is a base sub-object of
|
|
a <tt>basic_ios<></tt> object or sub-object, the effect is
|
|
equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt>
|
|
on the derived object (which may throw <tt>failure</tt>).</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
|
|
setstate(badbit).]</i></p>
|
|
|
|
<hr>
|
|
<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The basic_string<> copy constructor: </p>
|
|
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos, const Allocator& a = Allocator()); </pre>
|
|
|
|
<p>specifies an Allocator argument default value that is
|
|
counter-intuitive. The natural choice for a the allocator to copy from
|
|
is str.get_allocator(). Though this cannot be expressed in
|
|
default-argument notation, overloading suffices. </p>
|
|
|
|
<p>Alternatively, the other containers in Clause 23 (deque, list,
|
|
vector) do not have this form of constructor, so it is inconsistent,
|
|
and an evident source of confusion, for basic_string<> to have
|
|
it, so it might better be removed. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> In 21.3 , replace the declaration of the copy
|
|
constructor as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str);
|
|
basic_string(const basic_string& str, size_type pos, size_type n = npos,
|
|
const Allocator& a = Allocator());</pre>
|
|
</blockquote>
|
|
|
|
<p>In 21.3.1 , replace the copy constructor declaration
|
|
as above. Add to paragraph 5, Effects:</p>
|
|
|
|
<blockquote>
|
|
<p>In the first form, the Allocator value used is copied from
|
|
<tt>str.get_allocator()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes the constructor is actually broken, rather than
|
|
just an unfortunate design choice.</p>
|
|
|
|
<p>The LWG considered two other possible resolutions:</p>
|
|
|
|
<p>A. In 21.3 , replace the declaration of the copy
|
|
constructor as follows:</p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos);
|
|
basic_string(const basic_string& str, size_type pos,
|
|
size_type n, const Allocator& a); </pre>
|
|
</blockquote>
|
|
|
|
<p>In 21.3.1 , replace the copy constructor declaration
|
|
as above. Add to paragraph 5, Effects: </p>
|
|
|
|
<blockquote>
|
|
<p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
|
|
value <tt>str.get_allocator()</tt>. </p>
|
|
</blockquote>
|
|
|
|
<p>B. In 21.3 , and also in 21.3.1 , replace
|
|
the declaration of the copy constructor as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos); </pre>
|
|
</blockquote>
|
|
|
|
<p>The proposed resolution reflects the original intent of the LWG. It
|
|
was also noted by Pete Becker that this fix "will cause
|
|
a small amount of existing code to now work correctly."</p>
|
|
|
|
<p><i>[
|
|
Kona: issue editing snafu fixed - the proposed resolution now correctly
|
|
reflects the LWG consensus.
|
|
]</i></p>
|
|
<hr>
|
|
<a name="46"><h3>46. Minor Annex D errors</h3></a><p>
|
|
<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
|
|
<p>See lib-6522 and edit-814.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change D.7.1 (since streambuf is a typedef of
|
|
basic_streambuf<char>) from:</p>
|
|
|
|
<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
|
|
|
|
<p>In D.7.4 insert the semicolon now missing after
|
|
int_type:</p>
|
|
|
|
<pre> namespace std {
|
|
class strstream
|
|
: public basic_iostream<char> {
|
|
public:
|
|
// Types
|
|
typedef char char_type;
|
|
typedef typename char_traits<char>::int_type int_type
|
|
typedef typename char_traits<char>::pos_type pos_type;</pre>
|
|
<hr>
|
|
<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p>
|
|
<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
|
|
section has two RETURNS clauses, and they make no sense as
|
|
stated. They make perfect sense, though, if you swap them. Am I
|
|
correct in thinking that paragraphs 2 and 4 just got mixed up by
|
|
accident?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2.3 swap paragraphs 2 and 4.</p>
|
|
<hr>
|
|
<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p>
|
|
<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
|
|
base class, exception, with exception(msg). Class exception (see
|
|
18.6.1) has no such constructor.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 27.4.2.1.1 , paragraph 2, with</p>
|
|
|
|
<blockquote>
|
|
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>As written, ios_base has a copy constructor and an assignment
|
|
operator. (Nothing in the standard says it doesn't have one, and all
|
|
classes have copy constructors and assignment operators unless you
|
|
take specific steps to avoid them.) However, nothing in 27.4.2 says
|
|
what the copy constructor and assignment operator do. </p>
|
|
|
|
<p>My guess is that this was an oversight, that ios_base is, like
|
|
basic_ios, not supposed to have a copy constructor or an assignment
|
|
operator.</p>
|
|
|
|
<p>
|
|
Jerry Schwarz comments: Yes, its an oversight, but in the opposite
|
|
sense to what you're suggesting. At one point there was a definite
|
|
intention that you could copy ios_base. It's an easy way to save the
|
|
entire state of a stream for future use. As you note, to carry out
|
|
that intention would have required a explicit description of the
|
|
semantics (e.g. what happens to the iarray and parray stuff).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2 , class ios_base, specify the copy
|
|
constructor and operator= members as being private.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes the difficulty of specifying correct semantics
|
|
outweighs any benefit of allowing ios_base objects to be copyable.</p>
|
|
<hr>
|
|
<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p>
|
|
<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p>
|
|
<p>The std::sort algorithm can in general only sort a given sequence
|
|
by moving around values. The list<>::sort() member on the other
|
|
hand could move around values or just update internal pointers. Either
|
|
method can leave iterators into the list<> dereferencable, but
|
|
they would point to different things. </p>
|
|
|
|
<p>Does the FDIS mandate anywhere which method should be used for
|
|
list<>::sort()?</p>
|
|
|
|
<p>Matt Austern comments:</p>
|
|
|
|
<p>I think you've found an omission in the standard. </p>
|
|
|
|
<p>The library working group discussed this point, and there was
|
|
supposed to be a general requirement saying that list, set, map,
|
|
multiset, and multimap may not invalidate iterators, or change the
|
|
values that iterators point to, except when an operation does it
|
|
explicitly. So, for example, insert() doesn't invalidate any iterators
|
|
and erase() and remove() only invalidate iterators pointing to the
|
|
elements that are being erased. </p>
|
|
|
|
<p>I looked for that general requirement in the FDIS, and, while I
|
|
found a limited form of it for the sorted associative containers, I
|
|
didn't find it for list. It looks like it just got omitted. </p>
|
|
|
|
<p>The intention, though, is that list<>::sort does not
|
|
invalidate any iterators and does not change the values that any
|
|
iterator points to. There would be no reason to have the member
|
|
function otherwise.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a new paragraph at the end of 23.1:</p>
|
|
|
|
<blockquote>
|
|
<p>Unless otherwise specified (either explicitly or by defining a function in terms of
|
|
other functions), invoking a container member function or passing a container as an
|
|
argument to a library function shall not invalidate iterators to, or change the values of,
|
|
objects within that container. </p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This was US issue CD2-23-011; it was accepted in London but the
|
|
change was not made due to an editing oversight. The wording in the
|
|
proposed resolution below is somewhat updated from CD2-23-011,
|
|
particularly the addition of the phrase "or change the values
|
|
of"</p>
|
|
<hr>
|
|
<a name="52"><h3>52. Small I/O problems</h3></a><p>
|
|
<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
|
<p>First, 27.4.4.1 , table 89. This is pretty obvious:
|
|
it should be titled "basic_ios<>() effects", not
|
|
"ios_base() effects". </p>
|
|
|
|
<p>[The second item is a duplicate; see issue <a href="lwg-closed.html#6">6</a> for
|
|
resolution.]</p>
|
|
|
|
<p>Second, 27.4.3.2 table 88 . There are a couple
|
|
different things wrong with it, some of which I've already discussed
|
|
with Jerry, but the most obvious mechanical sort of error is that it
|
|
uses expressions like P(i) and p(i), without ever defining what sort
|
|
of thing "i" is.
|
|
</p>
|
|
|
|
<p>(The other problem is that it requires support for streampos
|
|
arithmetic. This is impossible on some systems, i.e. ones where file
|
|
position is a complicated structure rather than just a number. Jerry
|
|
tells me that the intention was to require syntactic support for
|
|
streampos arithmetic, but that it wasn't actually supposed to do
|
|
anything meaningful except on platforms, like Unix, where genuine
|
|
arithmetic is possible.) </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.4.4.1 table 89 title from
|
|
"ios_base() effects" to "basic_ios<>()
|
|
effects". </p>
|
|
<hr>
|
|
<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p>
|
|
<b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
|
<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
|
|
The important question is whether basic_ios::~basic_ios() destroys
|
|
rdbuf().</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add after 27.4.4.1 paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>virtual ~basic_ios();</tt></p>
|
|
<p>
|
|
<b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG reviewed the additional question of whether or not
|
|
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
|
|
clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 , paragraph 6. This issue was reviewed at length
|
|
by the LWG, which removed from the original proposed resolution a
|
|
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
|
|
<tt>badbit</tt>".</p>
|
|
<hr>
|
|
<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p>
|
|
<b>Section:</b> 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p>
|
|
<p>The class synopsis for basic_streambuf shows a (virtual)
|
|
destructor, but the standard doesn't say what that destructor does. My
|
|
assumption is that it does nothing, but the standard should say so
|
|
explicitly. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add after 27.5.2.1 paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>virtual ~basic_streambuf();</tt></p>
|
|
<p>
|
|
<b>Effects</b>: None.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p>
|
|
<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p>
|
|
<p>Several member functions in clause 27 are defined in certain
|
|
circumstances to return an "invalid stream position", a term
|
|
that is defined nowhere in the standard. Two places (27.5.2.4.2,
|
|
paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
|
|
a definition in _lib.iostreams.definitions_, a nonexistent
|
|
section. </p>
|
|
|
|
<p>I suspect that the invalid stream position is just supposed to be
|
|
pos_type(-1). Probably best to say explicitly in (for example)
|
|
27.5.2.4.2 that the return value is pos_type(-1), rather than to use
|
|
the term "invalid stream position", define that term
|
|
somewhere, and then put in a cross-reference. </p>
|
|
|
|
<p>The phrase "invalid stream position" appears ten times in
|
|
the C++ Standard. In seven places it refers to a return value, and it
|
|
should be changed. In three places it refers to an argument, and it
|
|
should not be changed. Here are the three places where "invalid
|
|
stream position" should not be changed:</p>
|
|
|
|
<blockquote>
|
|
<p>27.7.1.3 , paragraph 14<br>
|
|
27.8.1.4 , paragraph 14<br>
|
|
D.7.1.3 , paragraph 17
|
|
<a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.5.2.4.2 , paragraph 4, change "Returns an
|
|
object of class pos_type that stores an invalid stream position
|
|
(_lib.iostreams.definitions_)" to "Returns
|
|
<tt>pos_type(off_type(-1))</tt>".
|
|
</p>
|
|
|
|
<p>In 27.5.2.4.2 , paragraph 6, change "Returns
|
|
an object of class pos_type that stores an invalid stream
|
|
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
|
|
|
|
<p>In 27.7.1.3 , paragraph 13, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>". </p>
|
|
|
|
<p>In 27.8.1.4 , paragraph 13, change "returns an
|
|
invalid stream position (27.4.3)" to "returns
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
|
|
|
<p>In 27.8.1.4 , paragraph 15, change "Otherwise
|
|
returns an invalid stream position (_lib.iostreams.definitions_)"
|
|
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
|
|
</p>
|
|
|
|
<p>In D.7.1.3 , paragraph 15, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
|
|
|
<p>In D.7.1.3 , paragraph 18, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>"</p>
|
|
<hr>
|
|
<a name="56"><h3>56. Showmanyc's return type</h3></a><p>
|
|
<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p>
|
|
<p>The class summary for basic_streambuf<>, in 27.5.2, says that
|
|
showmanyc has return type int. However, 27.5.2.4.3 says that its
|
|
return type is streamsize. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change <tt>showmanyc</tt>'s return type in the
|
|
27.5.2 class summary to <tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="57"><h3>57. Mistake in char_traits</h3></a><p>
|
|
<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
|
|
<p>21.1.3.2, paragraph 3, says "The types streampos and
|
|
wstreampos may be different if the implementation supports no shift
|
|
encoding in narrow-oriented iostreams but supports one or more shift
|
|
encodings in wide-oriented streams". </p>
|
|
|
|
<p>That's wrong: the two are the same type. The <iosfwd> summary
|
|
in 27.2 says that streampos and wstreampos are, respectively, synonyms
|
|
for fpos<char_traits<char>::state_type> and
|
|
fpos<char_traits<wchar_t>::state_type>, and, flipping back
|
|
to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
|
|
char_traits<char>::state_type and
|
|
char_traits<wchar_t>::state_type must both be mbstate_t. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the sentence in 21.1.3.2 paragraph 3 which
|
|
begins "The types streampos and wstreampos may be
|
|
different..." . </p>
|
|
<hr>
|
|
<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p>
|
|
<b>Section:</b> 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p>
|
|
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
|
|
next pointer for the input sequence by n." </p>
|
|
|
|
<p>The straightforward interpretation is that it is just gptr() +=
|
|
n. An alternative interpretation, though, is that it behaves as if it
|
|
calls sbumpc n times. (The issue, of course, is whether it might ever
|
|
call underflow.) There is a similar ambiguity in the case of
|
|
pbump. </p>
|
|
|
|
<p>(The "classic" AT&T implementation used the
|
|
former interpretation.)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.3.1 paragraph 4 gbump effects from:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Advances the next pointer for the input sequence by n.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
|
|
</blockquote>
|
|
|
|
<p>Make the same change to 27.5.2.3.2 paragraph 4 pbump
|
|
effects.</p>
|
|
<hr>
|
|
<a name="60"><h3>60. What is a formatted input function?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p>
|
|
<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
|
|
formatted input functions. Some of the functions defined in section
|
|
27.6.1.2 explicitly say that those requirements apply ("Behaves
|
|
like a formatted input member (as described in 27.6.1.2.1)"), but
|
|
others don't. The question: is 27.6.1.2.1 supposed to apply to
|
|
everything in 27.6.1.2, or only to those member functions that
|
|
explicitly say "behaves like a formatted input member"? Or
|
|
to put it differently: are we to assume that everything that appears
|
|
in a section called "Formatted input functions" really is a
|
|
formatted input function? I assume that 27.6.1.2.1 is intended to
|
|
apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
|
|
is not intended to apply to extractors like </p>
|
|
|
|
<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre>
|
|
|
|
<p>and </p>
|
|
|
|
<pre> basic_istream& operator>>(basic_streammbuf*);</pre>
|
|
|
|
<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
|
|
output. </p>
|
|
|
|
<p>Comments from Judy Ward: It seems like the problem is that the
|
|
basic_istream and basic_ostream operator <<()'s that are used
|
|
for the manipulators and streambuf* are in the wrong section and
|
|
should have their own separate section or be modified to make it clear
|
|
that the "Common requirements" listed in section 27.6.1.2.1
|
|
(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
|
|
apply to them. </p>
|
|
|
|
<p>Additional comments from Dietmar Kühl: It appears to be somewhat
|
|
nonsensical to consider the functions defined in 27.6.1.2.3 paragraphs 1 to 5 to be "Formatted input
|
|
function" but since these functions are defined in a section
|
|
labeled "Formatted input functions" it is unclear to me
|
|
whether these operators are considered formatted input functions which
|
|
have to conform to the "common requirements" from 27.6.1.2.1 : If this is the case, all manipulators, not
|
|
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
|
|
set (... but setting <tt>noskipws</tt> using the manipulator syntax
|
|
would also skip whitespace :-)</p> <p>It is not clear which functions
|
|
are to be considered unformatted input functions. As written, it seems
|
|
that all functions in 27.6.1.3 are unformatted input
|
|
functions. However, it does not really make much sense to construct a
|
|
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
|
|
unclear what happens to the <tt>gcount()</tt> if
|
|
eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
|
|
<tt>sync()</tt> is called: These functions don't extract characters,
|
|
some of them even "unextract" a character. Should this still
|
|
be reflected in <tt>gcount()</tt>? Of course, it could be read as if
|
|
after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
|
|
(the last unformatted input function, <tt>gcount()</tt>, didn't
|
|
extract any character) and after a call to <tt>putback()</tt>
|
|
<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
|
|
function <tt>putback()</tt> did "extract" back into the
|
|
stream). Correspondingly for <tt>unget()</tt>. Is this what is
|
|
intended? If so, this should be clarified. Otherwise, a corresponding
|
|
clarification should be used.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
|
|
Change the beginning of the second sentence from "The conversion
|
|
occurs" to "These extractors behave as formatted input functions (as
|
|
described in 27.6.1.2.1). After a sentry object is constructed,
|
|
the conversion occurs"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
|
|
Add an effects clause. "Effects: None. This extractor does
|
|
not behave as a formatted input function (as described in
|
|
27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
|
|
first two sentences from "If sb is null, calls setstate(failbit),
|
|
which may throw ios_base::failure (27.4.4.3). Extracts characters
|
|
from *this..." to "Behaves as a formatted input function (as described
|
|
in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
|
|
throw ios_base::failure (27.4.4.3). After a sentry object is
|
|
constructed, extracts characters from *this...".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
|
|
effects clause. "Effects: none. This member function does not behave
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
|
character" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
|
character"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
|
character" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
|
character"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 10, because it refers to paragraph 7.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 15.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 23.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
|
described in 27.6.1.3, paragraph 1). After constructing a sentry
|
|
object, reads but does not extract the current input character."
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
|
|
first sentence of the Effects clause from "If !good() calls..." to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good()
|
|
calls..." Add a new sentence to the end of the Effects clause:
|
|
"[Note: this function extracts no characters, so the value returned
|
|
by the next call to gcount() is 0.]"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls".
|
|
Add a new sentence to the end of the Effects clause: "[Note: this
|
|
function extracts no characters, so the value returned by the next
|
|
call to gcount() is 0.]"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
|
|
first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if rdbuf() is"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
|
described in 27.6.1.3, paragraph 1), except that it does not count the
|
|
number of characters extracted and does not affect the value returned
|
|
by subsequent calls to gcount()." Change the first sentence of
|
|
paragraph 37 from "if fail()" to "after constructing a sentry object,
|
|
if fail()".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if fail()
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if fail()
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
|
|
the beginning of the third sentence from "The formatting conversion"
|
|
to "These extractors behave as formatted output functions (as
|
|
described in 27.6.2.5.1). After the sentry object is constructed, the
|
|
conversion occurs".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
|
|
effects clause: "Effects: None. Does not behave as a formatted output
|
|
function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
|
|
sentence from "If sb" to "Behaves as a formatted output function (as
|
|
described in 27.6.2.5.1). After the sentry object is constructed, if
|
|
sb".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
|
|
sentence from "Inserts the character" to "Behaves as an unformatted
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
|
constructing a sentry object, inserts the character".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
|
|
sentence from "Obtains characters" to "Behaves as an unformatted
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
|
constructing a sentry object, obtains characters".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
|
|
sentence at the end of the paragraph: "Does not behave as an
|
|
unformatted output function (as described in 27.6.2.6, paragraph 1)."
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
|
|
by Judy Ward and Matt Austern. This proposed resolution is section
|
|
VI of that paper.</p>
|
|
<hr>
|
|
<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The introduction to the section on unformatted input (27.6.1.3)
|
|
says that every unformatted input function catches all exceptions that
|
|
were thrown during input, sets badbit, and then conditionally rethrows
|
|
the exception. That seems clear enough. Several of the specific
|
|
functions, however, such as get() and read(), are documented in some
|
|
circumstances as setting eofbit and/or failbit. (The standard notes,
|
|
correctly, that setting eofbit or failbit can sometimes result in an
|
|
exception being thrown.) The question: if one of these functions
|
|
throws an exception triggered by setting failbit, is this an exception
|
|
"thrown during input" and hence covered by 27.6.1.3, or does
|
|
27.6.1.3 only refer to a limited class of exceptions? Just to make
|
|
this concrete, suppose you have the following snippet. </p>
|
|
|
|
<pre>
|
|
char buffer[N];
|
|
istream is;
|
|
...
|
|
is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
|
|
is.read(buffer, N);</pre>
|
|
|
|
<p>Now suppose we reach EOF before we've read N characters. What
|
|
iostate bits can we expect to be set, and what exception (if any) will
|
|
be thrown? </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.1.3, paragraph 1, after the sentence that begins
|
|
"If an exception is thrown...", add the following
|
|
parenthetical comment: "(Exceptions thrown from
|
|
<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)"
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG looked to two alternative wordings, and choose the proposed
|
|
resolution as better standardese.</p>
|
|
<hr>
|
|
<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
|
|
"calls rdbuf()->pubsync() and, if that function returns -1
|
|
... returns traits::eof()." </p>
|
|
|
|
<p>That looks suspicious, because traits::eof() is of type
|
|
traits::int_type while the return type of sync() is int. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.3 , paragraph 36, change "returns
|
|
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
|
|
</p>
|
|
<hr>
|
|
<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p>
|
|
<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p>
|
|
<p>Clause 27 details an exception-handling policy for formatted input,
|
|
unformatted input, and formatted output. It says nothing for
|
|
unformatted output (27.6.2.6). 27.6.2.6 should either include the same
|
|
kind of exception-handling policy as in the other three places, or
|
|
else it should have a footnote saying that the omission is
|
|
deliberate. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.2.6, paragraph 1, replace the last sentence ("In any
|
|
case, the unformatted output function ends by destroying the sentry
|
|
object, then returning the value specified for the formatted output
|
|
function.") with the following text:
|
|
</p>
|
|
<blockquote>
|
|
If an exception is thrown during output, then <tt>ios::badbit</tt> is
|
|
turned on [Footnote: without causing an <tt>ios::failure</tt> to be
|
|
thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &
|
|
badbit) != 0</tt> then the exception is rethrown. In any case, the
|
|
unformatted output function ends by destroying the sentry object,
|
|
then, if no exception was thrown, returning the value specified for
|
|
the formatted output function.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
This exception-handling policy is consistent with that of formatted
|
|
input, unformatted input, and formatted output.
|
|
</p>
|
|
<hr>
|
|
<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p>
|
|
<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
|
|
different ways, depending on whether the second sentence is read as an
|
|
elaboration of the first. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 27.6.1.2.3 , paragraph 13, which begins
|
|
"If the function inserts no characters ..." with:</p>
|
|
|
|
<blockquote>
|
|
<p>If the function inserts no characters, it calls
|
|
<tt>setstate(failbit)</tt>, which may throw
|
|
<tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
|
|
because it caught an exception thrown while extracting characters
|
|
from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
|
|
(27.4.4.3), then the caught exception is rethrown. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p>
|
|
<b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
|
|
<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
|
|
"Performs an operation that is defined separately for each class
|
|
derived from strstreambuf". This is obviously an incorrect
|
|
cut-and-paste from basic_streambuf. There are no classes derived from
|
|
strstreambuf. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>D.7.1.3 , paragraph 19, replace the setbuf effects
|
|
clause which currently says "Performs an operation that is
|
|
defined separately for each class derived from strstreambuf"
|
|
with:<a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>Effects</b>: implementation defined, except that
|
|
<tt>setbuf(0,0)</tt> has no effect.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p>
|
|
<p>Extractors for char* (27.6.1.2.3) do not store a null character
|
|
after the extracted character sequence whereas the unformatted
|
|
functions like get() do. Why is this?</p>
|
|
|
|
<p>Comment from Jerry Schwarz: There is apparently an editing
|
|
glitch. You'll notice that the last item of the list of what stops
|
|
extraction doesn't make any sense. It was supposed to be the line that
|
|
said a null is stored.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>27.6.1.2.3 , paragraph 7, change the last list
|
|
item from:<a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>
|
|
</p>
|
|
|
|
<blockquote>
|
|
A null byte (<tt>charT()</tt>) in the next position, which may be
|
|
the first position if no characters were extracted.
|
|
</blockquote>
|
|
|
|
<p>to become a new paragraph which reads:</p>
|
|
|
|
<blockquote>
|
|
Operator>> then stores a null byte (<tt>charT()</tt>) in the
|
|
next position, which may be the first position if no characters were
|
|
extracted.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p>
|
|
<b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
|
|
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
|
|
|
|
<p>(Please note that this is entirely separate from the question of
|
|
whether a vector iterator is required to be a pointer; the answer to
|
|
that question is clearly "no," as it would rule out
|
|
debugging implementations)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following text to the end of 23.2.4 ,
|
|
paragraph 1. </p>
|
|
|
|
<blockquote>
|
|
<p>The elements of a vector are stored contiguously, meaning that if
|
|
v is a <tt>vector<T, Allocator></tt> where T is some type
|
|
other than <tt>bool</tt>, then it obeys the identity <tt>&v[n]
|
|
== &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG feels that as a practical matter the answer is clearly
|
|
"yes". There was considerable discussion as to the best way
|
|
to express the concept of "contiguous", which is not
|
|
directly defined in the standard. Discussion included:</p>
|
|
|
|
<ul>
|
|
<li>An operational definition similar to the above proposed resolution is
|
|
already used for valarray (26.3.2.3 ).</li>
|
|
<li>There is no need to explicitly consider a user-defined operator&
|
|
because elements must be copyconstructible (23.1 para 3)
|
|
and copyconstructible (20.1.3 ) specifies
|
|
requirements for operator&.</li>
|
|
<li>There is no issue of one-past-the-end because of language rules.</li>
|
|
</ul>
|
|
<hr>
|
|
<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p>
|
|
<b>Section:</b> 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p>
|
|
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
|
|
|
|
<p>uncaught_exception() doesn't have a throw specification.</p>
|
|
|
|
<p>It is intentional ? Does it means that one should be prepared to
|
|
handle exceptions thrown from uncaught_exception() ?</p>
|
|
|
|
<p>uncaught_exception() is called in exception handling contexts where
|
|
exception safety is very important.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 15.5.3 , paragraph 1, 18.6 , and 18.6.4 , add "throw()" to uncaught_exception().</p>
|
|
<hr>
|
|
<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p>
|
|
<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
|
|
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
|
|
is described in 22.2.5.1.2 with five arguments,
|
|
consistent with do_get_weekday and with its specified use by member
|
|
get_monthname. However, in the synopsis, it is specified instead with
|
|
four arguments. The missing argument is the "end" iterator
|
|
value.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.5.1 , add an "end" argument to
|
|
the declaration of member do_monthname as follows:</p>
|
|
|
|
<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
|
|
ios_base::iostate& err, tm* t) const;</pre>
|
|
<hr>
|
|
<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p>
|
|
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
|
|
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
|
|
parentheses and a spurious <b>n</b>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 22.2.1.5.2 paragraph 11 with the
|
|
following:</p>
|
|
|
|
<blockquote>
|
|
<b>Returns</b>: The maximum value that
|
|
<tt>do_length(state, from, from_end, 1)</tt> can return for any
|
|
valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
|
|
<tt>state</tt>. The specialization <tt>codecvt<char, char,
|
|
mbstate_t>::do_max_length()</tt> returns 1.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt
|
|
Austern <b>Date:</b> 18 Sep 1998</p>
|
|
<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
|
|
and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
|
|
parameter of the member functions <tt>length</tt> and
|
|
<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member
|
|
function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
|
|
paragraph 9) say that the type is <tt>stateT&</tt>. Either the
|
|
synopsis or the summary must be changed. </p>
|
|
|
|
<p>If (as I believe) the member function descriptions are correct,
|
|
then we must also add text saying how <tt>do_length</tt> changes its
|
|
<tt>stateT</tt> argument. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5 , and also in 22.2.1.6 ,
|
|
change the <tt>stateT</tt> argument type on both member
|
|
<tt>length()</tt> and member <tt>do_length()</tt> from </p>
|
|
|
|
<blockquote>
|
|
<p><tt>const stateT&</tt></p>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<p><tt>stateT&</tt></p>
|
|
</blockquote>
|
|
|
|
<p>In 22.2.1.5.2 , add to the definition for member
|
|
<tt>do_length</tt> a paragraph:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The effect on the <tt>state</tt> argument is ``as if''
|
|
it called <tt>do_in(state, from, from_end, from, to, to+max,
|
|
to)</tt> for <tt>to</tt> pointing to a buffer of at least
|
|
<tt>max</tt> elements.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="78"><h3>78. Typo: event_call_back</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>typo: event_call_back should be event_callback </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the 27.4.2 synopsis change
|
|
"event_call_back" to "event_callback". </p>
|
|
<hr>
|
|
<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p>
|
|
<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>In 26.2.1 polar is declared as follows:</p>
|
|
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
|
|
|
|
<p>In 26.2.7 it is declared as follows:</p>
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
|
|
|
<p>Thus whether the second parameter is optional is not clear. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 26.2.1 change:</p>
|
|
<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
|
|
|
|
<p>to:</p>
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
|
<hr>
|
|
<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p>
|
|
<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
|
|
class complex. This redundancy should be removed.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Reduce redundancy according to the general style of the standard. </p>
|
|
<hr>
|
|
<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>Many string member functions throw if size is getting or exceeding
|
|
npos. However, I wonder why they don't throw if size is getting or
|
|
exceeding max_size() instead of npos. May be npos is known at compile
|
|
time, while max_size() is known at runtime. However, what happens if
|
|
size exceeds max_size() but not npos, then? It seems the standard
|
|
lacks some clarifications here.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>After 21.3 paragraph 4 ("The functions
|
|
described in this clause...") add a new paragraph:</p>
|
|
|
|
<blockquote>
|
|
<p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
|
|
<tt> max_size()</tt> then
|
|
the operation throws <tt>length_error</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes length_error is the correct exception to throw.</p>
|
|
<hr>
|
|
<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p>
|
|
<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>The constructor from a range:</p>
|
|
|
|
<pre>template<class InputIterator>
|
|
basic_string(InputIterator begin, InputIterator end,
|
|
const Allocator& a = Allocator());</pre>
|
|
|
|
<p>lacks a throws clause. However, I would expect that it throws
|
|
according to the other constructors if the numbers of characters in
|
|
the range equals npos (or exceeds max_size(), see above). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.1 , Strike throws paragraphs for
|
|
constructors which say "Throws: length_error if n ==
|
|
npos."</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Throws clauses for length_error if n == npos are no longer needed
|
|
because they are subsumed by the general wording added by the
|
|
resolution for issue <a href="lwg-defects.html#83">83</a>.</p>
|
|
<hr>
|
|
<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>The effect of operator >> for strings contain the following item:</p>
|
|
|
|
<p> <tt>isspace(c,getloc())</tt> is true for the next available input
|
|
character c.</p>
|
|
|
|
<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.7.9 paragraph 1 Effects clause replace:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>Set::iterator is described as implementation-defined with a
|
|
reference to the container requirement; the container requirement says
|
|
that const_iterator is an iterator pointing to const T and iterator an
|
|
iterator pointing to T.</p>
|
|
|
|
<p>23.1.2 paragraph 2 implies that the keys should not be modified to
|
|
break the ordering of elements. But that is not clearly
|
|
specified. Especially considering that the current standard requires
|
|
that iterator for associative containers be different from
|
|
const_iterator. Set, for example, has the following: </p>
|
|
|
|
<p><tt>typedef implementation defined iterator;<br>
|
|
// See _lib.container.requirements_</tt></p>
|
|
|
|
<p>23.1 actually requires that iterator type pointing
|
|
to T (table 65). Disallowing user modification of keys by changing the
|
|
standard to require an iterator for associative container to be the
|
|
same as const_iterator would be overkill since that will unnecessarily
|
|
significantly restrict the usage of associative container. A class to
|
|
be used as elements of set, for example, can no longer be modified
|
|
easily without either redesigning the class (using mutable on fields
|
|
that have nothing to do with ordering), or using const_cast, which
|
|
defeats requiring iterator to be const_iterator. The proposed solution
|
|
goes in line with trusting user knows what he is doing. <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>
|
|
</p>
|
|
|
|
<p>
|
|
<b>Other Options Evaluated:</b> </p>
|
|
|
|
<p>Option A. In 23.1.2 , paragraph 2, after
|
|
first sentence, and before "In addition,...", add one line:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Modification of keys shall not change their strict weak ordering. </p>
|
|
</blockquote>
|
|
|
|
<p>Option B. Add three new sentences to 23.1.2 :</p>
|
|
|
|
<blockquote>
|
|
<p>At the end of paragraph 5: "Keys in an associative container
|
|
are immutable." At the end of paragraph 6: "For
|
|
associative containers where the value type is the same as the key
|
|
type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
|
|
constant iterators. It is unspecified whether or not
|
|
<tt>iterator</tt> and <tt>const_iterator</tt> are the same
|
|
type."</p>
|
|
</blockquote>
|
|
|
|
<p>Option C. To 23.1.2 , paragraph 3, which
|
|
currently reads:</p>
|
|
|
|
<blockquote>
|
|
<p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
|
|
comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
|
|
container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
|
|
== false && comp(k2, k1) == false.</p>
|
|
</blockquote>
|
|
|
|
<p> add the following:</p>
|
|
|
|
<blockquote>
|
|
<p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
|
|
value whenever it is evaluated. [Note: If k2 is removed from the container and later
|
|
reinserted, comp(k1, k2) must still return a consistent value but this value may be
|
|
different than it was the first time k1 and k2 were in the same container. This is
|
|
intended to allow usage like a string key that contains a filename, where comp compares
|
|
file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
|
|
reinserted, comp(k1, k2) must again return a consistent value but this value may be
|
|
different than it was the previous time k2 was in the container.]</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following to 23.1.2 at
|
|
the indicated location:</p>
|
|
|
|
<blockquote>
|
|
<p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
|
|
calling comp(k1, k2) shall always return the same
|
|
value."</p>
|
|
<p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
|
|
<p>At the end of paragraph 6: "For associative containers where the value type is the
|
|
same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
|
|
iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
|
|
are the same type."</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Several arguments were advanced for and against allowing set elements to be
|
|
mutable as long as the ordering was not effected. The argument which swayed the
|
|
LWG was one of safety; if elements were mutable, there would be no compile-time
|
|
way to detect of a simple user oversight which caused ordering to be
|
|
modified. There was a report that this had actually happened in practice,
|
|
and had been painful to diagnose. If users need to modify elements,
|
|
it is possible to use mutable members or const_cast.</p>
|
|
|
|
<p>Simply requiring that keys be immutable is not sufficient, because the comparison
|
|
object may indirectly (via pointers) operate on values outside of the keys.</p>
|
|
|
|
<p>
|
|
The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
|
|
to be different types to allow for potential future work in which some
|
|
member functions might be overloaded between the two types. No such
|
|
member functions exist now, and the LWG believes that user functionality
|
|
will not be impaired by permitting the two types to be the same. A
|
|
function that operates on both iterator types can be defined for
|
|
<tt>const_iterator</tt> alone, and can rely on the automatic
|
|
conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
|
|
</p>
|
|
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
|
|
<hr>
|
|
<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p>
|
|
<b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>This is the only place in the whole standard where the implementation has to document
|
|
something private.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Remove the comment which says "// remainder implementation defined" from:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
|
|
</li>
|
|
<li>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
|
|
</li>
|
|
<li>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
|
|
</li>
|
|
<li>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
|
</li>
|
|
</ul>
|
|
<hr>
|
|
<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p>
|
|
<b>Section:</b> 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
|
|
exception::what() is left unspecified. This issue has implications
|
|
with exception safety of exception handling: some exceptions should
|
|
not throw bad_alloc.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to 18.6.1 paragraph 9 (exception::what notes
|
|
clause) the sentence:</p>
|
|
|
|
<blockquote>
|
|
<p>The return value remains valid until the exception object from which it is obtained is
|
|
destroyed or a non-const member function of the exception object is called.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>If an exception object has non-const members, they may be used
|
|
to set internal state that should affect the contents of the string
|
|
returned by <tt>what()</tt>.
|
|
</p>
|
|
<hr>
|
|
<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p>
|
|
<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
|
|
<p>Member istreambuf_iterator<>::equal is not declared
|
|
"const", yet 24.5.3.6 says that operator==,
|
|
which is const, calls it. This is contradictory. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.3 and also in 24.5.3.5 ,
|
|
replace:</p>
|
|
|
|
<blockquote>
|
|
<pre>bool equal(istreambuf_iterator& b);</pre>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<pre>bool equal(const istreambuf_iterator& b) const;</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
|
|
<b>Section:</b> 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p>
|
|
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
|
|
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
|
|
reads "<i>s</i> is not null". However, <i>s</i> is a
|
|
reference, and references can't be null. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.4.1 :</p>
|
|
|
|
<p>Move the current paragraph 1, which reads "Requires: s is not
|
|
null.", from the first constructor to the second constructor.</p>
|
|
|
|
<p>Insert a new paragraph 1 Requires clause for the first constructor
|
|
reading:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="114"><h3>114. Placement forms example in error twice</h3></a><p>
|
|
<b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
|
|
<p>Section 18.4.1.3 contains the following example: </p>
|
|
|
|
<pre>[Example: This can be useful for constructing an object at a known address:
|
|
char place[sizeof(Something)];
|
|
Something* p = new (place) Something();
|
|
-end example]</pre>
|
|
|
|
<p>First code line: "place" need not have any special alignment, and the
|
|
following constructor could fail due to misaligned data.</p>
|
|
|
|
<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG
|
|
believes the () are correct.]</p>
|
|
|
|
<p>Examples are not normative, but nevertheless should not show code that is invalid or
|
|
likely to fail.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the <u> first line of code</u> in the example in
|
|
18.4.1.3 with:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<pre>void* place = operator new(sizeof(Something));</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="115"><h3>115. Typo in strstream constructors</h3></a><p>
|
|
<b>Section:</b> D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p>
|
|
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Constructs an object of class strstream, initializing the base class with
|
|
iostream(& sb) and initializing sb with one of the two constructors: </p>
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
|
elements. The constructor is strstreambuf(s, n, s). </p>
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
|
elements that contains an NTBS whose first element is designated by s. The constructor is
|
|
strstreambuf(s, n, s+std::strlen(s)).</p>
|
|
</blockquote>
|
|
|
|
<p>Notice the second condition is the same as the first. I think the second condition
|
|
should be "If mode&app==app", or "mode&app!=0", meaning that
|
|
the append bit is set.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.7.3.1 paragraph 2 and D.7.4.1
|
|
paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
|
|
and the second condition to <tt>(mode&app)!=0</tt>.</p>
|
|
<hr>
|
|
<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
|
|
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
|
|
<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
|
|
<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
|
|
formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
|
|
|
|
<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, val);
|
|
setstate(err);</pre>
|
|
|
|
<p>According to section 22.2.2.1.1 , however,
|
|
<tt>num_get<>::get()</tt> is only overloaded for the types
|
|
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
|
|
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
|
|
<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
|
|
<tt>void*</tt>. Comparing the lists from the two sections, we find
|
|
that 27.6.1.2.2 is using a nonexistent function for types
|
|
<tt>short</tt> and <tt>int</tt>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.2.2 Arithmetic Extractors, remove the
|
|
two lines (1st and 3rd) which read:</p>
|
|
<blockquote>
|
|
<pre>operator>>(short& val);
|
|
...
|
|
operator>>(int& val);</pre>
|
|
</blockquote>
|
|
|
|
<p>And add the following at the end of that section (27.6.1.2.2) :</p>
|
|
|
|
<blockquote>
|
|
<pre>operator>>(short& val);</pre>
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
|
the same notation as for the preceding code fragment):</p>
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
long lval;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
|
if (err == 0
|
|
&& (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
|
|
err = ios_base::failbit;
|
|
setstate(err);</pre>
|
|
<pre>operator>>(int& val);</pre>
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
|
the same notation as for the preceding code fragment):</p>
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
long lval;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
|
if (err == 0
|
|
&& (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
|
|
err = ios_base::failbit;
|
|
setstate(err);</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
|
|
<hr>
|
|
<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
|
|
<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Section 17.4.4.8 states: </p>
|
|
|
|
<p>"An implementation may strengthen the exception-specification
|
|
for a function by removing listed exceptions." </p>
|
|
|
|
<p>The problem is that if an implementation is allowed to do this for
|
|
virtual functions, then a library user cannot write a class that
|
|
portably derives from that class. </p>
|
|
|
|
<p>For example, this would not compile if ios_base::failure::~failure
|
|
had an empty exception specification: </p>
|
|
|
|
<pre>#include <ios>
|
|
#include <string>
|
|
|
|
class D : public std::ios_base::failure {
|
|
public:
|
|
D(const std::string&);
|
|
~D(); // error - exception specification must be compatible with
|
|
// overridden virtual function ios_base::failure::~failure()
|
|
};</pre>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Section 17.4.4.8 from:</p>
|
|
|
|
<p> "may strengthen the
|
|
exception-specification for a function"</p>
|
|
|
|
<p>to:</p>
|
|
|
|
<p> "may strengthen the
|
|
exception-specification for a non-virtual function". </p>
|
|
<hr>
|
|
<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p>
|
|
<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Section 27.5.2 describes the streambuf classes this way: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>The class streambuf is a specialization of the template class basic_streambuf
|
|
specialized for the type char. </p>
|
|
|
|
<p>The class wstreambuf is a specialization of the template class basic_streambuf
|
|
specialized for the type wchar_t. </p>
|
|
|
|
</blockquote>
|
|
|
|
<p>This implies that these classes must be template specializations, not typedefs. </p>
|
|
|
|
<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove 27.5.2 paragraphs 2 and 3 (the above two
|
|
sentences). </p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The <tt>streambuf</tt> synopsis already has a declaration for the
|
|
typedefs and that is sufficient. </p>
|
|
<hr>
|
|
<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p>
|
|
<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>In Section 22.2.1.2
|
|
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
|
|
to return a const char* not a const charT*. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Section 22.2.1.2 <tt>do_scan_is()</tt> and
|
|
<tt>do_scan_not()</tt> to return a <tt> const
|
|
charT*</tt>. </p>
|
|
<hr>
|
|
<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p>
|
|
<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>In Section 26.3.2 valarray<T>::operator!() is
|
|
declared to return a valarray<T>, but in Section 26.3.2.5 it is declared to return a valarray<bool>. The
|
|
latter appears to be correct. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change in Section 26.3.2 the declaration of
|
|
<tt>operator!()</tt> so that the return type is
|
|
<tt>valarray<bool></tt>. </p>
|
|
<hr>
|
|
<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p>
|
|
<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Typos in 22.2.1.1.2 need to be fixed.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In Section 22.2.1.1.2 change: </p>
|
|
|
|
<pre> do_widen(do_narrow(c),0) == c</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> do_widen(do_narrow(c,0)) == c</pre>
|
|
|
|
<p>and change:</p>
|
|
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
|
|
<hr>
|
|
<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p>
|
|
<b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p>
|
|
<p>There are two problems with the current <tt>auto_ptr</tt> wording
|
|
in the standard: </p>
|
|
|
|
<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
|
|
because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to
|
|
<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by
|
|
Nathan Myers, with the same proposed resolution.</i>
|
|
</p>
|
|
|
|
<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
|
|
<tt>auto_ptr_ref</tt> argument. </p>
|
|
|
|
<p>I have discussed these problems with my proposal coauthor, Bill
|
|
Gibbons, and with some compiler and library implementors, and we
|
|
believe that these problems are not desired or desirable implications
|
|
of the standard. </p>
|
|
|
|
<p>25 Aug 1999: The proposed resolution now reflects changes suggested
|
|
by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
|
|
"assignment operator" to "public assignment
|
|
operator", 2) changed effects to specify use of release(), 3)
|
|
made the conversion to auto_ptr_ref const. </p>
|
|
|
|
<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
|
|
states that the conversion from auto_ptr to auto_ptr_ref should
|
|
be const. This is not acceptable, because it would allow
|
|
initialization and assignment from _any_ const auto_ptr! It also
|
|
introduces an implementation difficulty in writing this conversion
|
|
function -- namely, somewhere along the line, a const_cast will be
|
|
necessary to remove that const so that release() may be called. This
|
|
may result in undefined behavior [7.1.5.1/4]. The conversion
|
|
operator does not have to be const, because a non-const implicit
|
|
object parameter may be bound to an rvalue [13.3.3.1.4/3]
|
|
[13.3.1/5]. </p>
|
|
|
|
<p>Tokyo: The LWG removed the following from the proposed resolution:</p>
|
|
|
|
<p>In 20.4.5 , paragraph 2, and 20.4.5.3 ,
|
|
paragraph 2, make the conversion to auto_ptr_ref const:</p>
|
|
<blockquote>
|
|
<pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.4.5 , paragraph 2, move
|
|
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
|
|
|
|
<p>In 20.4.5 , paragraph 2, add
|
|
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
|
|
|
|
<blockquote>
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
|
|
</blockquote>
|
|
|
|
<p>Also add the assignment operator to 20.4.5.3 : </p>
|
|
|
|
<blockquote>
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
|
|
|
|
<b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
|
|
p</tt> that <tt>r</tt> holds a reference to.<br>
|
|
<b>Returns: </b><tt>*this</tt>.
|
|
|
|
</blockquote>
|
|
<hr>
|
|
<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
|
|
<p>Currently, the standard does not specify how seekg() and seekp()
|
|
indicate failure. They are not required to set failbit, and they can't
|
|
return an error indication because they must return *this, i.e. the
|
|
stream. Hence, it is undefined what happens if they fail. And they
|
|
<i>can</i> fail, for instance, when a file stream is disconnected from the
|
|
underlying file (is_open()==false) or when a wide character file
|
|
stream must perform a state-dependent code conversion, etc. </p>
|
|
|
|
<p>The stream functions seekg() and seekp() should set failbit in the
|
|
stream state in case of failure.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the Effects: clause of seekg() in
|
|
27.6.1.3 and to the Effects: clause of seekp() in
|
|
27.6.2.4 : </p>
|
|
|
|
<blockquote>
|
|
<p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Setting failbit is the usual error reporting mechanism for streams</p>
|
|
<hr>
|
|
<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p>
|
|
<b>Section:</b> 23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The description reads:</p>
|
|
|
|
<p>-1- Effects:</p>
|
|
|
|
<pre> if (sz > size())
|
|
insert(end(), sz-size(), c);
|
|
else if (sz < size())
|
|
erase(begin()+sz, end());
|
|
else
|
|
; // do nothing</pre>
|
|
|
|
<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 23.2.2.2 paragraph 1 to:</p>
|
|
|
|
<p>Effects:</p>
|
|
|
|
<pre> if (sz > size())
|
|
insert(end(), sz-size(), c);
|
|
else if (sz < size())
|
|
{
|
|
iterator i = begin();
|
|
advance(i, sz);
|
|
erase(i, end());
|
|
}</pre>
|
|
|
|
<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
|
|
with David Abrahams. They had a discussion and believe there is
|
|
no issue of exception safety with the proposed resolution.]</i></p>
|
|
<hr>
|
|
<a name="133"><h3>133. map missing get_allocator()</h3></a><p>
|
|
<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The title says it all.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Insert in 23.3.1 , paragraph 2,
|
|
after operator= in the map declaration:</p>
|
|
|
|
<pre> allocator_type get_allocator() const;</pre>
|
|
<hr>
|
|
<a name="134"><h3>134. vector constructors over specified</h3></a><p>
|
|
<b>Section:</b> 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The complexity description says: "It does at most 2N calls to the copy constructor
|
|
of T and logN reallocations if they are just input iterators ...".</p>
|
|
|
|
<p>This appears to be overly restrictive, dictating the precise memory/performance
|
|
tradeoff for the implementor.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 23.2.4.1 , paragraph 1 to:</p>
|
|
|
|
<p>-1- Complexity: The constructor template <class
|
|
InputIterator> vector(InputIterator first, InputIterator last)
|
|
makes only N calls to the copy constructor of T (where N is the
|
|
distance between first and last) and no reallocations if iterators
|
|
first and last are of forward, bidirectional, or random access
|
|
categories. It makes order N calls to the copy constructor of T and
|
|
order logN reallocations if they are just input iterators.
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>"at most 2N calls" is correct only if the growth factor
|
|
is greater than or equal to 2.
|
|
</p>
|
|
<hr>
|
|
<a name="136"><h3>136. seekp, seekg setting wrong streams?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>I may be misunderstanding the intent, but should not seekg set only
|
|
the input stream and seekp set only the output stream? The description
|
|
seems to say that each should set both input and output streams. If
|
|
that's really the intent, I withdraw this proposal.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In section 27.6.1.3 change:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre>
|
|
|
|
<p>In section 27.6.1.3 change:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre>
|
|
|
|
<p>In section 27.6.2.4, paragraph 2 change:</p>
|
|
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre>
|
|
|
|
<p>In section 27.6.2.4, paragraph 4 change:</p>
|
|
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre>
|
|
|
|
<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
|
|
like the opinion of more iostream experts before taking action.]</i></p>
|
|
|
|
<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
|
|
incorrect, his implementation already implements the Proposed
|
|
Resolution.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Matt Austern comments:<br>
|
|
Is it a problem with basic_istream and basic_ostream, or is it a problem
|
|
with basic_stringbuf?
|
|
We could resolve the issue either by changing basic_istream and
|
|
basic_ostream, or by changing basic_stringbuf. I prefer the latter
|
|
change (or maybe both changes): I don't see any reason for the standard to
|
|
require that std::stringbuf s(std::string("foo"), std::ios_base::in);
|
|
s.pubseekoff(0, std::ios_base::beg); must fail.<br>
|
|
This requirement is a bit weird. There's no similar requirement
|
|
for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or
|
|
basic_filebuf<>::seekpos.]</i></p>
|
|
<hr>
|
|
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
|
|
<p>Section 22.1.1 says:</p>
|
|
|
|
<p>-4- In the call to use_facet<Facet>(loc), the type argument
|
|
chooses a facet, making available all members of the named type. If
|
|
Facet is not present in a locale (or, failing that, in the global
|
|
locale), it throws the standard exception bad_cast. A C++ program can
|
|
check if a locale implements a particular facet with the template
|
|
function has_facet<Facet>(). </p>
|
|
|
|
<p>This contradicts the specification given in section
|
|
22.1.2 :
|
|
<br><br>
|
|
template <class Facet> const Facet& use_facet(const
|
|
locale& loc); <br>
|
|
<br>
|
|
-1- Get a reference to a facet of a locale. <br>
|
|
-2- Returns: a reference to the corresponding facet of loc, if present. <br>
|
|
-3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br>
|
|
-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the phrase "(or, failing that, in the global locale)"
|
|
from section 22.1.1. </p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Needed for consistency with the way locales are handled elsewhere
|
|
in the standard.</p>
|
|
<hr>
|
|
<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p>
|
|
<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p>
|
|
<p>The sentence introducing the Optional sequence operation table
|
|
(23.1.1 paragraph 12) has two problems:</p>
|
|
|
|
<p>A. It says ``The operations in table 68 are provided only for the containers for which
|
|
they take constant time.''<br>
|
|
<br>
|
|
That could be interpreted in two ways, one of them being ``Even though table 68 shows
|
|
particular operations as being provided, implementations are free to omit them if they
|
|
cannot implement them in constant time.''<br>
|
|
<br>
|
|
B. That paragraph says nothing about amortized constant time, and it should. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..."
|
|
with:</p>
|
|
|
|
<blockquote>
|
|
<p>Table 68 lists sequence operations that are provided for some types of sequential
|
|
containers but not others. An implementation shall provide these operations for all
|
|
container types shown in the ``container'' column, and shall implement them so as to take
|
|
amortized constant time.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
|
|
<b>Section:</b> 21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p>
|
|
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
|
|
say:<br>
|
|
<br>
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();</tt>
|
|
</p>
|
|
|
|
<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p>
|
|
|
|
<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
|
|
proposed resolution.]</i></p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
|
|
<br>
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();<br>
|
|
<br>
|
|
</tt>to:<br>
|
|
<tt><br>
|
|
</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p>
|
|
<b>Section:</b> 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
|
|
<p>The lexicographical_compare complexity is specified as:<br>
|
|
<br>
|
|
"At most min((last1 - first1), (last2 - first2))
|
|
applications of the corresponding comparison."<br>
|
|
<br>
|
|
The best I can do is twice that expensive.</p>
|
|
|
|
<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
|
|
equality you have to check both < and >? Yes, IMO you are
|
|
right! (and Matt states this complexity in his book)</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.3.8 complexity to:</p>
|
|
<blockquote>
|
|
At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
|
|
applications of the corresponding comparison.
|
|
</blockquote>
|
|
|
|
<p>Change the example at the end of paragraph 3 to read:</p>
|
|
<blockquote>
|
|
[Example:<br>
|
|
<br>
|
|
for ( ; first1 != last1 && first2 != last2 ;
|
|
++first1, ++first2) {<br>
|
|
if (*first1 < *first2) return true;<br>
|
|
if (*first2 < *first1) return false;<br>
|
|
}<br>
|
|
return first1 == last1 && first2 != last2;<br>
|
|
<br>
|
|
--end example]
|
|
</blockquote>
|
|
<hr>
|
|
<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p>
|
|
<b>Section:</b> 23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p>
|
|
<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
|
|
to have complexity requirements which are incorrect, and which contradict the
|
|
complexity requirements for insert(). I suspect that the text in question,
|
|
below, was taken from vector:</p>
|
|
<blockquote>
|
|
<p>Complexity: If the iterators first and last are forward iterators,
|
|
bidirectional iterators, or random access iterators the constructor makes only
|
|
N calls to the copy constructor, and performs no reallocations, where N is
|
|
last - first.</p>
|
|
</blockquote>
|
|
<p>The word "reallocations" does not really apply to deque. Further,
|
|
all of the following appears to be spurious:</p>
|
|
<blockquote>
|
|
<p>It makes at most 2N calls to the copy constructor of T and log N
|
|
reallocations if they are input iterators.1)</p>
|
|
<p>1) The complexity is greater in the case of input iterators because each
|
|
element must be added individually: it is impossible to determine the distance
|
|
between first abd last before doing the copying.</p>
|
|
</blockquote>
|
|
<p>This makes perfect sense for vector, but not for deque. Why should deque gain
|
|
an efficiency advantage from knowing in advance the number of elements to
|
|
insert?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
|
|
footnote, with the following text (which also corrects the "abd"
|
|
typo):</p>
|
|
<blockquote>
|
|
<p>Complexity: Makes last - first calls to the copy constructor of T.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p>
|
|
<b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
|
|
<p>The <u> extractor</u> for complex numbers is specified as: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p> template<class T, class charT, class traits> <br>
|
|
basic_istream<charT, traits>& <br>
|
|
operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br>
|
|
<br>
|
|
Effects: Extracts a complex number x of the form: u, (u), or (u,v),
|
|
where u is the real part and v is the imaginary part
|
|
(lib.istream.formatted). <br>
|
|
Requires: The input values be convertible to T. If bad input is
|
|
encountered, calls is.setstate(ios::failbit) (which may throw
|
|
ios::failure (lib.iostate.flags). <br>
|
|
Returns: is .</p>
|
|
|
|
</blockquote>
|
|
<p>Is it intended that the extractor for complex numbers does not skip
|
|
whitespace, unlike all other extractors in the standard library do?
|
|
Shouldn't a sentry be used? <br>
|
|
<br>
|
|
The <u>inserter</u> for complex numbers is specified as:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p> template<class T, class charT, class traits> <br>
|
|
basic_ostream<charT, traits>& <br>
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br>
|
|
<br>
|
|
Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
|
|
<br>
|
|
template<class T, class charT, class traits> <br>
|
|
basic_ostream<charT, traits>& <br>
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br>
|
|
{ <br>
|
|
basic_ostringstream<charT, traits> s; <br>
|
|
s.flags(o.flags()); <br>
|
|
s.imbue(o.getloc()); <br>
|
|
s.precision(o.precision()); <br>
|
|
s << '(' << x.real() << "," << x.imag() << ')'; <br>
|
|
return o << s.str(); <br>
|
|
}</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>Is it intended that the inserter for complex numbers ignores the
|
|
field width and does not do any padding? If, with the suggested
|
|
implementation above, the field width were set in the stream then the
|
|
opening parentheses would be adjusted, but the rest not, because the
|
|
field width is reset to zero after each insertion.</p>
|
|
|
|
<p>I think that both operations should use sentries, for sake of
|
|
consistency with the other inserters and extractors in the
|
|
library. Regarding the issue of padding in the inserter, I don't know
|
|
what the intent was. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>After 26.2.6 paragraph 14 (operator>>), add a
|
|
Notes clause:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>Notes: This extraction is performed as a series of simpler
|
|
extractions. Therefore, the skipping of whitespace is specified to be the
|
|
same for each of the simpler extractions.</p>
|
|
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>For extractors, the note is added to make it clear that skipping whitespace
|
|
follows an "all-or-none" rule.</p>
|
|
|
|
<p>For inserters, the LWG believes there is no defect; the standard is correct
|
|
as written.</p>
|
|
<hr>
|
|
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p>
|
|
<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
|
<p>The library had many global functions until 17.4.1.1 [lib.contents]
|
|
paragraph 2 was added: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>All library entities except macros, operator new and operator
|
|
delete are defined within the namespace std or namespaces nested
|
|
within namespace std. </p>
|
|
|
|
</blockquote>
|
|
|
|
<p>It appears "global function" was never updated in the following: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>17.4.4.3 - Global functions [lib.global.functions]<br>
|
|
<br>
|
|
-1- It is unspecified whether any global functions in the C++ Standard
|
|
Library are defined as inline (dcl.fct.spec).<br>
|
|
<br>
|
|
-2- A call to a global function signature described in Clauses
|
|
lib.language.support through lib.input.output behaves the same as if
|
|
the implementation declares no additional global function
|
|
signatures.*<br>
|
|
<br>
|
|
[Footnote: A valid C++ program always calls the expected library
|
|
global function. An implementation may also define additional
|
|
global functions that would otherwise not be called by a valid C++
|
|
program. --- end footnote]<br>
|
|
<br>
|
|
-3- A global function cannot be declared by the implementation as
|
|
taking additional default arguments. <br>
|
|
<br>
|
|
17.4.4.4 - Member functions [lib.member.functions]<br>
|
|
<br>
|
|
-2- An implementation can declare additional non-virtual member
|
|
function signatures within a class: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>-- by adding arguments with default values to a member function
|
|
signature; The same latitude does not extend to the implementation of
|
|
virtual or global functions, however. </p>
|
|
|
|
</blockquote>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> Change "global" to "global or non-member" in:</p>
|
|
<blockquote>
|
|
<p>17.4.4.3 [lib.global.functions] section title,<br>
|
|
17.4.4.3 [lib.global.functions] para 1,<br>
|
|
17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
|
|
places in the footnote,<br>
|
|
17.4.4.3 [lib.global.functions] para 3,<br>
|
|
17.4.4.4 [lib.member.functions] para 2</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Because operator new and delete are global, the proposed resolution
|
|
was changed from "non-member" to "global or non-member.
|
|
</p>
|
|
<hr>
|
|
<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
|
|
<p>In 22.2.8 paragraph 13, the do_truename() and
|
|
do_falsename() functions in the example facet BoolNames should be
|
|
const. The functions they are overriding in
|
|
numpunct_byname<char> are const. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.8 paragraph 13, insert "const" in
|
|
two places:</p>
|
|
<blockquote>
|
|
<p><tt>string do_truename() const { return "Oui Oui!"; }<br>
|
|
string do_falsename() const { return "Mais Non!"; }</tt></p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p>
|
|
<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.1.4 paragraph 2 from:</p>
|
|
|
|
<blockquote>
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
|
that for some <u>integer</u> j in the range [first2, last2) ...</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
|
that for some iterator j in the range [first2, last2) ...</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p>
|
|
<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p>
|
|
<p>For both sequences and associative containers, a.clear() has the
|
|
semantics of erase(a.begin(),a.end()), which is undefined for an empty
|
|
container since erase(q1,q2) requires that q1 be dereferenceable
|
|
(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
|
|
not dereferenceable.<br>
|
|
<br>
|
|
The requirement that q1 be unconditionally dereferenceable causes many
|
|
operations to be intuitively undefined, of which clearing an empty
|
|
container is probably the most dire.<br>
|
|
<br>
|
|
Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
|
|
q2) is required to be a valid range, stating that q1 and q2 must be
|
|
iterators or certain kinds of iterators is unnecessary.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.1.1, paragraph 3, change:</p>
|
|
<blockquote>
|
|
<p>p and q2 denote valid iterators to a, q <u> and q1</u> denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
|
|
in a</u>
|
|
</p>
|
|
</blockquote>
|
|
<p>In 23.1.2, paragraph 7, change:</p>
|
|
<blockquote>
|
|
<p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
|
|
iterators to a, [q1, q2) is a valid range</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
|
|
<u>into a</u>
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p>
|
|
<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
|
|
because there is no function <tt>is()</tt> which only takes a character as
|
|
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
|
|
vague.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.1.2 paragraphs 4 and 6, change the returns
|
|
clause from:</p>
|
|
<blockquote>
|
|
<p>"... such that <tt>is(*p)</tt>
|
|
would..."</p>
|
|
</blockquote>
|
|
<p>to: "... such that <tt>is(m, *p)</tt>
|
|
would...."</p>
|
|
<hr>
|
|
<a name="153"><h3>153. Typo in <tt>narrow()</tt> semantics</h3></a><p>
|
|
<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The description of the array version of <tt>narrow()</tt> (in
|
|
paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
|
|
takes only three arguments because in addition to the range a default
|
|
character is needed.</p>
|
|
|
|
<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
|
|
two signatures followed by a <b>Returns</b> clause that only addresses
|
|
one of them.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the returns clause in 22.2.1.3.2
|
|
paragraph 10 from:</p>
|
|
<p> Returns: do_widen(low, high, to).</p>
|
|
|
|
<p>to:</p>
|
|
<p> Returns: do_widen(c) or do_widen(low, high, to),
|
|
respectively.</p>
|
|
|
|
<p>Change 22.2.1.3.2 paragraph 10 and 11 from:</p>
|
|
<pre> char narrow(char c, char /*dfault*/) const;
|
|
const char* narrow(const char* low, const char* high,
|
|
char /*dfault*/, char* to) const;</pre>
|
|
<pre> Returns: do_narrow(low, high, to).</pre>
|
|
<p>to:</p>
|
|
<pre> char narrow(char c, char dfault) const;
|
|
const char* narrow(const char* low, const char* high,
|
|
char dfault, char* to) const;</pre>
|
|
<pre> Returns: do_narrow(c, dfault) or
|
|
do_narrow(low, high, dfault, to), respectively.</pre>
|
|
|
|
<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
|
|
defined version could be different.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
|
|
the LWG. He could find no other places the problem occurred. He
|
|
asks for clarification of the Kona "a user defined
|
|
version..." comment above. Perhaps it was a circuitous way of
|
|
saying "dfault" needed to be uncommented?]</i></p>
|
|
|
|
<p><i>[Post-Toronto: the issues list maintainer has merged in the
|
|
proposed resolution from issue <a href="lwg-closed.html#207">207</a>, which addresses the
|
|
same paragraphs.]</i></p>
|
|
<hr>
|
|
<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The table in paragraph 7 for the length modifier does not list the length
|
|
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
|
|
standard asks the implementation to do undefined things when using <tt>scanf()</tt>
|
|
(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
|
|
is actually a problem I found quite often in production code, too).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 , paragraph 7, add a row in the Length
|
|
Modifier table to say that for <tt>double</tt> a length modifier
|
|
<tt>l</tt> is to be used.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The standard makes an embarrassing beginner's mistake.</p>
|
|
<hr>
|
|
<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>There are conflicting statements about where the class
|
|
<tt>Init</tt> is defined. According to 27.3 paragraph 2
|
|
it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 it is defined as <tt>ios_base::Init</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.3 paragraph 2 from
|
|
"<tt>basic_ios::Init"</tt> to
|
|
"<tt>ios_base::Init"</tt>.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although not strictly wrong, the standard was misleading enough to warrant
|
|
the change.</p>
|
|
<hr>
|
|
<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p>
|
|
<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>There is a small discrepancy between the declarations of
|
|
<tt>imbue()</tt>: in 27.4.2 the argument is passed as
|
|
<tt>locale const&</tt> (correct), in 27.4.2.3 it
|
|
is passed as <tt>locale const</tt> (wrong).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2.3 change the <tt>imbue</tt> argument
|
|
from "<tt>locale const" to "locale
|
|
const&".</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The default behavior of <tt>setbuf()</tt> is described only for the
|
|
situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
|
|
namely to do nothing. What has to be done in other situations
|
|
is not described although there is actually only one reasonable
|
|
approach, namely to do nothing, too.</p>
|
|
|
|
<p>Since changing the buffer would almost certainly mess up most
|
|
buffer management of derived classes unless these classes do it
|
|
themselves, the default behavior of <tt>setbuf()</tt> should always be
|
|
to do nothing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.4.2 , paragraph 3, Default behavior,
|
|
to: "Default behavior: Does nothing. Returns this."</p>
|
|
<hr>
|
|
<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The description of the meaning of the result of
|
|
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
|
|
<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
|
|
this function only reads the current character but does not extract
|
|
it, <tt>uflow()</tt> would extract the current character. This should
|
|
be fixed to use <tt>sbumpc()</tt> instead.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.4.3 paragraph 1,
|
|
<tt>showmanyc()</tt>returns clause, by replacing the word
|
|
"supplied" with the words "extracted from the
|
|
stream".</p>
|
|
<hr>
|
|
<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
|
|
is not defined. Probably, the referred function is
|
|
<tt>basic_ios<>::exceptions()</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.1 , 27.6.1.3 , paragraph 1,
|
|
27.6.2.1 , paragraph 3, and 27.6.2.5.1 ,
|
|
paragraph 1, change "<tt>exception()" to
|
|
"exceptions()"</tt>.</p>
|
|
|
|
<p><i>[Note to Editor: "exceptions" with an "s"
|
|
is the correct spelling.]</i></p>
|
|
<hr>
|
|
<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The note in the second paragraph pretends that the first argument
|
|
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
|
|
an object of type <tt>istreambuf_iterator</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.6.1.2.2 from:</p>
|
|
<blockquote>
|
|
<p>The first argument provides an object of the istream_iterator class...</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>The first argument provides an object of the istreambuf_iterator class...</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p>
|
|
<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
|
|
<p>In 22.2.5.3.2 the do_put() function is specified
|
|
as taking a fill character as an argument, but the description of the
|
|
function does not say whether the character is used at all and, if so,
|
|
in which way. The same holds for any format control parameters that
|
|
are accessible through the ios_base& argument, such as the
|
|
adjustment or the field width. Is strftime() supposed to use the fill
|
|
character in any way? In any case, the specification of
|
|
time_put.do_put() looks inconsistent to me.<br> <br> Is the
|
|
signature of do_put() wrong, or is the effects clause incomplete?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following note after 22.2.5.3.2
|
|
paragraph 2:</p>
|
|
<blockquote>
|
|
<p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
|
|
for this argument. --end Note]</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG felt that while the normative text was correct,
|
|
users need some guidance on what to pass for the <tt>fill</tt>
|
|
argument since the standard doesn't say how it's used.</p>
|
|
<hr>
|
|
<a name="165"><h3>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p>
|
|
<b>Section:</b> 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
|
|
functions falling into one of the groups "formatted output functions"
|
|
and "unformatted output functions" calls any stream buffer function
|
|
which might call a virtual function other than <tt>overflow()</tt>. Basically
|
|
this is fine but this implies that <tt>sputn()</tt> (this function would call
|
|
the virtual function <tt>xsputn()</tt>) is never called by any of the standard
|
|
output functions. Is this really intended? At minimum it would be convenient to
|
|
call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
|
|
is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
|
|
with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt>
|
|
and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
|
|
under "unformatted output functions").</p>
|
|
<p>In addition, I guess that the sentence starting with "They may use other
|
|
public members of <tt>basic_ostream</tt> ..." probably was intended to
|
|
start with "They may use other public members of <tt>basic_streamuf</tt>..."
|
|
although the problem with the virtual members exists in both cases.</p>
|
|
<p>I see two obvious resolutions:</p>
|
|
<ol>
|
|
<li>state in a footnote that this means that <tt>xsputn()</tt> will never be
|
|
called by any ostream member and that this is intended.</li>
|
|
<li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
|
|
Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
|
|
</ol>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
|
|
<blockquote>
|
|
<p>They may use other public members of basic_ostream except that they do not
|
|
invoke any virtual members of rdbuf() except overflow().</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>They may use other public members of basic_ostream except that they shall
|
|
not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
|
|
sync().</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
|
|
PJP why the standard is written this way.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
|
|
LWG. He comments: The rules can be made a little bit more specific if
|
|
necessary be explicitly spelling out what virtuals are allowed to be
|
|
called from what functions and eg to state specifically that flush()
|
|
is allowed to call sync() while other functions are not.]</i></p>
|
|
<hr>
|
|
<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p>
|
|
<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The first paragraph begins with a descriptions what has to be done
|
|
in <i>formatted</i> output functions. Probably this is a typo and the
|
|
paragraph really want to describe unformatted output functions...</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.2.6 paragraph 1, the first and last
|
|
sentences, change the word "formatted" to
|
|
"unformatted":</p>
|
|
<blockquote>
|
|
<p>"Each <b>unformatted </b> output function begins ..."<br>
|
|
"... value specified for the <b>unformatted </b> output
|
|
function."</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
|
|
<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
|
|
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
|
|
especially in view of the restriction that <tt>basic_ostream</tt>
|
|
member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 ): For each character to be inserted, a new buffer
|
|
is to be created.</p>
|
|
<p>Of course, the resolution below requires some handling of
|
|
simultaneous input and output since it is no longer possible to update
|
|
<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
|
|
solution is to handle this in <tt>underflow()</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.7.1.3 paragraph 8, Notes, insert the words
|
|
"at least" as in the following:</p>
|
|
<blockquote>
|
|
<p>To make a write position available, the function reallocates (or initially
|
|
allocates) an array object with a sufficient number of elements to hold the
|
|
current array object (if any), plus <b>at least</b> one additional write
|
|
position.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The classes <tt>basic_stringstream</tt> (27.7.4 ),
|
|
<tt>basic_istringstream</tt> (27.7.2 ), and
|
|
<tt>basic_ostringstream</tt> (27.7.3 ) are inconsistent
|
|
in their definition of the type <tt>traits_type</tt>: For
|
|
<tt>istringstream</tt>, this type is defined, for the other two it is
|
|
not. This should be consistent.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><b>Proposed resolution:</b></p> <p>To the declarations of
|
|
<tt>basic_ostringstream</tt> (27.7.3 ) and
|
|
<tt>basic_stringstream</tt> (27.7.4 ) add:</p>
|
|
<blockquote>
|
|
<pre>typedef traits traits_type;</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p>
|
|
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 paragraph 3, it is stated that a joint input and
|
|
output position is maintained by <tt>basic_filebuf</tt>. Still, the
|
|
description of <tt>seekpos()</tt> seems to talk about different file
|
|
positions. In particular, it is unclear (at least to me) what is
|
|
supposed to happen to the output buffer (if there is one) if only the
|
|
input position is changed. The standard seems to mandate that the
|
|
output buffer is kept and processed as if there was no positioning of
|
|
the output position (by changing the input position). Of course, this
|
|
can be exactly what you want if the flag <tt>ios_base::ate</tt> is
|
|
set. However, I think, the standard should say something like
|
|
this:</p>
|
|
<ul>
|
|
<li>If <tt>(which & mode) == 0</tt> neither read nor write position is
|
|
changed and the call fails. Otherwise, the joint read and write position is
|
|
altered to correspond to <tt>sp</tt>.</li>
|
|
<li>If there is an output buffer, the output sequences is updated and any
|
|
unshift sequence is written before the position is altered.</li>
|
|
<li>If there is an input buffer, the input sequence is updated after the
|
|
position is altered.</li>
|
|
</ul>
|
|
<p>Plus the appropriate error handling, that is...</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
|
|
paragraph 14 from:</p>
|
|
<blockquote>
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
|
ios_base::out);</p>
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
|
in sp (as described below).</p>
|
|
<p>- if (which&ios_base::in)!=0, set the file position to sp, then update
|
|
the input sequence</p>
|
|
<p>- if (which&ios_base::out)!=0, then update the output sequence, write
|
|
any unshift sequence, and set the file position to sp.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
|
ios_base::out);</p>
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
|
in sp (as described below). Altering the file position performs as follows:</p>
|
|
<p>1. if (om & ios_base::out)!=0, then update the output sequence and
|
|
write any unshift sequence;</p>
|
|
<p>2. set the file position to sp;</p>
|
|
<p>3. if (om & ios_base::in)!=0, then update the input sequence;</p>
|
|
<p>where om is the open mode passed to the last call to open(). The operation
|
|
fails if is_open() returns false.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
|
|
<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
|
|
<hr>
|
|
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>In 27.6.1.1 the function
|
|
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
|
|
argument. However, in 27.6.1.3
|
|
paragraph 23 the first argument is of type <tt>int.</tt>
|
|
</p>
|
|
|
|
<p>As far as I can see this is not really a contradiction because
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
|
intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
|
|
as described in issue <a href="lwg-defects.html#173">173</a>.</p>
|
|
|
|
<p>Darin Adler also
|
|
submitted this issue, commenting: Either 27.6.1.1 should be modified
|
|
to show a first parameter of type int, or 27.6.1.3 should be modified
|
|
to show a first parameter of type streamsize and use
|
|
numeric_limits<streamsize>::max.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.3 paragraph 23 and 24, change both uses
|
|
of <tt>int</tt> in the description of <tt>ignore()</tt> to
|
|
<tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
|
|
<p>
|
|
In 27.8.1.1 the function <tt>setbuf()</tt> gets an
|
|
object of type <tt>streamsize</tt> as second argument. However, in
|
|
27.8.1.4 paragraph 9 the second argument is of type
|
|
<tt>int</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
As far as I can see this is not really a contradiction because
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
|
intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
|
|
as described in issue <a href="lwg-defects.html#172">172</a>.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.8.1.4 paragraph 9, change all uses of
|
|
<tt>int</tt> in the description of <tt>setbuf()</tt> to
|
|
<tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
|
|
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
|
|
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change D.6 paragraph 1 from "<tt>typedef
|
|
OFF_T streampos;</tt>" to "<tt>typedef POS_T
|
|
streampos;</tt>"</p>
|
|
<hr>
|
|
<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>According to paragraph 8 of this section, the methods
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
|
<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
|
|
"may" be overloaded by a version of this function taking the
|
|
type <tt>ios_base::open_mode</tt> as last argument argument instead of
|
|
<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
|
|
in this section to be an alias for one of the integral types). The
|
|
clause specifies, that the last argument has a default argument in
|
|
three cases. However, this generates an ambiguity with the overloaded
|
|
version because now the arguments are absolutely identical if the last
|
|
argument is not specified.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.6 paragraph 8, remove the default arguments for
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
|
<tt>basic_ifstream::open()</tt>, and
|
|
<tt>basic_ofstream::open().</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>The "overload" for the function <tt>exceptions()</tt> in
|
|
paragraph 8 gives the impression that there is another function of
|
|
this function defined in class <tt>ios_base</tt>. However, this is not
|
|
the case. Thus, it is hard to tell how the semantics (paragraph 9) can
|
|
be implemented: "Call the corresponding member function specified
|
|
in clause 27 ."</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.6 paragraph 8, move the declaration of the
|
|
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
|
|
<hr>
|
|
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p>
|
|
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
|
|
<p>The claim has surfaced in Usenet that expressions such as<br>
|
|
<br>
|
|
<tt>make_pair("abc", 3)</tt><br>
|
|
<br>
|
|
are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
|
|
parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br>
|
|
<br>
|
|
I doubt anyone intended that behavior...
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.2 , paragraph 1 change the following
|
|
declaration of make_pair():</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
|
|
</blockquote>
|
|
<p> In 20.2.2 paragraph 7 and the line before, change:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2>
|
|
pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2>
|
|
pair<T1, T2> make_pair(T1 x, T2 y);</pre>
|
|
</blockquote>
|
|
<p>and add the following footnote to the effects clause:</p>
|
|
<blockquote>
|
|
<p> According to 12.8 [class.copy], an implementation is permitted
|
|
to not perform a copy of an argument, thus avoiding unnecessary
|
|
copies.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Two potential fixes were suggested by Matt Austern and Dietmar
|
|
Kühl, respectively, 1) overloading with array arguments, and 2) use of
|
|
a reference_traits class with a specialization for arrays. Andy
|
|
Koenig suggested changing to pass by value. In discussion, it appeared
|
|
that this was a much smaller change to the standard that the other two
|
|
suggestions, and any efficiency concerns were more than offset by the
|
|
advantages of the solution. Two implementors reported that the
|
|
proposed resolution passed their test suites.</p>
|
|
<hr>
|
|
<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p>
|
|
<b>Section:</b> 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 7 Jul 1999</p>
|
|
<p>27.6.3 paragraph 3 says (clause numbering added for
|
|
exposition):<a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>
|
|
</p>
|
|
<blockquote>
|
|
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
|
|
of) basic_ostream then the expression out<<s behaves as if f(s) were
|
|
called, and if [2] in is an (instance of) basic_istream then the expression
|
|
in>>s behaves as if f(s) were called. Where f can be defined as: ios_base&
|
|
f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags
|
|
str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
|
|
out<<s has type ostream& and value out. [4] The expression in>>s
|
|
has type istream& and value in.</p>
|
|
</blockquote>
|
|
<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
|
|
"The expression out << s has type basic_ostream& ..." and
|
|
[4] should read: "The expression in >> s has type basic_istream&
|
|
..."</p>
|
|
<p>If the wording in the standard is correct, I can see no way of implementing
|
|
any of the manipulators so that they will work with wide character streams.</p>
|
|
<p>e.g. wcout << setbase( 16 );</p>
|
|
<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which
|
|
doesn't).</p>
|
|
<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
|
|
8. In addition, Para 6 [setfill] has a similar error, but relates only to
|
|
ostreams.</p>
|
|
<p>I'd be happier if there was a better way of saying this, to make it clear
|
|
that the value of the expression is "the same specialization of
|
|
basic_ostream as out"&</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace section 27.6.3 except paragraph 1 with the
|
|
following:</p>
|
|
<blockquote>
|
|
<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
|
|
function.<br>
|
|
<br>
|
|
<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
|
|
<br>
|
|
-3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if
|
|
f(s, mask) were called. The function f can be defined as:*<br>
|
|
<br>
|
|
[Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the
|
|
basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears
|
|
ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout <<
|
|
noshowbase). --- end footnote]<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
|
{<br>
|
|
// reset specified flags<br>
|
|
str.setf(ios_base::fmtflags(0), mask);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
|
|
<br>
|
|
-4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s,
|
|
mask) were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
|
{<br>
|
|
// set specified flags<br>
|
|
str.setf(mask);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setbase(int base);</tt><br>
|
|
<br>
|
|
-5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, base) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s,
|
|
base) were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int base)<br>
|
|
{<br>
|
|
// set basefield<br>
|
|
str.setf(base == 8 ? ios_base::oct :<br>
|
|
base == 10 ? ios_base::dec :<br>
|
|
base == 16 ? ios_base::hex :<br>
|
|
ios_base::fmtflags(0), ios_base::basefield);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setfill(char_type c);<br>
|
|
</tt><br>
|
|
-6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream<charT,traits> and c has type charT then the
|
|
expression out<<s behaves as if f(s, c) were called. The function f can be
|
|
defined as:<br>
|
|
<br>
|
|
<tt>template<class charT, class traits><br>
|
|
basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br>
|
|
{<br>
|
|
// set fill character<br>
|
|
str.fill(c);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.<br>
|
|
<br>
|
|
<tt>smanip setprecision(int n);</tt><br>
|
|
<br>
|
|
-7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n)
|
|
were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
|
{<br>
|
|
// set precision<br>
|
|
str.precision(n);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in<br>
|
|
.<br>
|
|
<tt>smanip setw(int n);<br>
|
|
</tt><br>
|
|
-8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n)
|
|
were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
|
{<br>
|
|
// set width<br>
|
|
str.width(n);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type
|
|
basic_ostream<charT,traits>& and value out. The expression
|
|
in>>s has type basic_istream<charT,traits>& and value
|
|
in.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
|
|
the proposed resolution.]</i></p>
|
|
|
|
<p><i>[Tokyo - The LWG noted that issue <a href="lwg-closed.html#216">216</a> involves
|
|
the same paragraphs.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
|
|
resolution of this issue with the proposed resolution for issue <a href="lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
|
|
intertwined that dealing with them separately appear fraught with
|
|
error. The full text was supplied by Bill Plauger; it was cross
|
|
checked against changes supplied by Andy Sawyer. It should be further
|
|
checked by the LWG.]</i></p>
|
|
<hr>
|
|
<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p>
|
|
<b>Section:</b> 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p>
|
|
<p>bools are defined by the standard to be of integer types, as per
|
|
3.9.1 paragraph 7. However "integer types"
|
|
seems to have a special meaning for the author of 18.2. The net effect
|
|
is an unclear and confusing specification for
|
|
numeric_limits<bool> as evidenced below.</p>
|
|
|
|
<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer
|
|
types, the number of non-sign bits in the representation.</p>
|
|
|
|
<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
|
|
arithmetical value converts to true.</p>
|
|
|
|
<p>I don't think it makes sense at all to require
|
|
numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to
|
|
be meaningful.</p>
|
|
|
|
<p>The standard defines what constitutes a signed (resp. unsigned) integer
|
|
types. It doesn't categorize bool as being signed or unsigned. And the set of
|
|
values of bool type has only two elements.</p>
|
|
|
|
<p>I don't think it makes sense to require numeric_limits<bool>::is_signed
|
|
to be meaningful.</p>
|
|
|
|
<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p>
|
|
<blockquote>
|
|
<p>For integer types, specifies the base of the representation.186)</p>
|
|
</blockquote>
|
|
|
|
<p>This disposition is at best misleading and confusing for the standard
|
|
requires a "pure binary numeration system" for integer types as per
|
|
3.9.1/7</p>
|
|
|
|
<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
|
|
BCD)." This also erroneous as the standard never defines any integer
|
|
types with base representation other than 2.</p>
|
|
|
|
<p>Furthermore, numeric_limits<bool>::is_modulo and
|
|
numeric_limits<bool>::is_signed have similar problems.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Append to the end of 18.2.1.5 :</p>
|
|
<blockquote>
|
|
<p>The specialization for bool shall be provided as follows:</p>
|
|
<pre> namespace std {
|
|
template<> class numeric_limits<bool> {
|
|
public:
|
|
static const bool is_specialized = true;
|
|
static bool min() throw() { return false; }
|
|
static bool max() throw() { return true; }
|
|
|
|
static const int digits = 1;
|
|
static const int digits10 = 0;
|
|
static const bool is_signed = false;
|
|
static const bool is_integer = true;
|
|
static const bool is_exact = true;
|
|
static const int radix = 2;
|
|
static bool epsilon() throw() { return 0; }
|
|
static bool round_error() throw() { return 0; }
|
|
|
|
static const int min_exponent = 0;
|
|
static const int min_exponent10 = 0;
|
|
static const int max_exponent = 0;
|
|
static const int max_exponent10 = 0;
|
|
|
|
static const bool has_infinity = false;
|
|
static const bool has_quiet_NaN = false;
|
|
static const bool has_signaling_NaN = false;
|
|
static const float_denorm_style has_denorm = denorm_absent;
|
|
static const bool has_denorm_loss = false;
|
|
static bool infinity() throw() { return 0; }
|
|
static bool quiet_NaN() throw() { return 0; }
|
|
static bool signaling_NaN() throw() { return 0; }
|
|
static bool denorm_min() throw() { return 0; }
|
|
|
|
static const bool is_iec559 = false;
|
|
static const bool is_bounded = true;
|
|
static const bool is_modulo = false;
|
|
|
|
static const bool traps = false;
|
|
static const bool tinyness_before = false;
|
|
static const float_round_style round_style = round_toward_zero;
|
|
};
|
|
}</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Tokyo: The LWG desires wording that specifies exact values
|
|
rather than more general wording in the original proposed
|
|
resolution.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico
|
|
Josuttis provided the above wording.]</i></p>
|
|
<hr>
|
|
<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p>
|
|
<b>Section:</b> 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p>
|
|
<p>Paragraph 4 of 20.3 says:</p>
|
|
<blockquote>
|
|
<p> [Example: To negate every element of a: transform(a.begin(), a.end(),
|
|
a.begin(), negate<double>()); The corresponding functions will inline
|
|
the addition and the negation. end example]</p>
|
|
</blockquote>
|
|
<p>(Note: The "addition" referred to in the above is in para 3) we can
|
|
find no other wording, except this (non-normative) example which suggests that
|
|
any "inlining" will take place in this case.</p>
|
|
<p>Indeed both:</p>
|
|
<blockquote>
|
|
<p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
|
|
unspecified whether any global functions in the C++ Standard Library
|
|
are defined as inline (7.1.2).</p>
|
|
</blockquote>
|
|
<p>and</p>
|
|
<blockquote>
|
|
<p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
|
|
unspecified whether any member functions in the C++ Standard Library
|
|
are defined as inline (7.1.2).</p>
|
|
</blockquote>
|
|
<p>take care to state that this may indeed NOT be the case.</p>
|
|
<p>Thus the example "mandates" behavior that is explicitly
|
|
not required elsewhere.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.3 paragraph 1, remove the sentence:</p>
|
|
<blockquote>
|
|
<p>They are important for the effective use of the library.</p>
|
|
</blockquote>
|
|
<p>Remove 20.3 paragraph 2, which reads:</p>
|
|
<blockquote>
|
|
<p> Using function objects together with function templates
|
|
increases the expressive power of the library as well as making the
|
|
resulting code much more efficient.</p>
|
|
</blockquote>
|
|
<p>In 20.3 paragraph 4, remove the sentence:</p>
|
|
<blockquote>
|
|
<p>The corresponding functions will inline the addition and the
|
|
negation.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
|
|
<hr>
|
|
<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p>
|
|
<b>Section:</b> 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p>
|
|
<p>In section 23.3.5.2 , paragraph 13 defines the
|
|
bitset::set operation to take a second parameter of type int. The
|
|
function tests whether this value is non-zero to determine whether to
|
|
set the bit to true or false. The type of this second parameter should
|
|
be bool. For one thing, the intent is to specify a Boolean value. For
|
|
another, the result type from test() is bool. In addition, it's
|
|
possible to slice an integer that's larger than an int. This can't
|
|
happen with bool, since conversion to bool has the semantic of
|
|
translating 0 to false and any non-zero value to true.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.3.5 Para 1 Replace:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
|
|
</blockquote>
|
|
<p>With:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
|
</blockquote>
|
|
<p>In 23.3.5.2 Para 12(.5) Replace:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
|
|
</blockquote>
|
|
<p>With:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work
|
|
on better P/R wording.]</i></p>
|
|
<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
<tt>bool</tt> is a better choice. It is believed that binary
|
|
compatibility is not an issue, because this member function is
|
|
usually implemented as <tt>inline</tt>, and because it is already
|
|
the case that users cannot rely on the type of a pointer to a
|
|
nonvirtual member of a standard library class.</p>
|
|
<hr>
|
|
<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p>
|
|
<b>Section:</b> 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p>
|
|
<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
|
|
and includes a parenthetical note saying that it is the number of
|
|
digits after the decimal point.<br>
|
|
<br>
|
|
This claim is not strictly correct. For example, in the default
|
|
floating-point output format, setprecision sets the number of
|
|
significant digits printed, not the number of digits after the decimal
|
|
point.<br>
|
|
<br>
|
|
I would like the committee to look at the definition carefully and
|
|
correct the statement in 27.4.2.2</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove from 27.4.2.2 , paragraph 9, the text
|
|
"(number of digits after the decimal point)".</p>
|
|
<hr>
|
|
<a name="193"><h3>193. Heap operations description incorrect</h3></a><p>
|
|
<b>Section:</b> 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p>
|
|
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
|
|
is<br>
|
|
<br>
|
|
`"(1) *a is the largest element"<br>
|
|
<br>
|
|
I think this is incorrect and should be changed to the wording in the proposed
|
|
resolution.</p>
|
|
<p>Actually there are two independent changes:</p>
|
|
<blockquote>
|
|
<p>A-"part of largest equivalence class" instead of "largest", cause 25.3
|
|
[lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
|
|
<p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions could not be used for a
|
|
priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects priority AND time).</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.3.6 property (1) from:</p>
|
|
<blockquote>
|
|
<p>(1) *a is the largest element</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>(1) There is no element greater than <tt>*a</tt>
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p>
|
|
<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
|
|
What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
|
|
reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
|
|
should set failbit. Should it set eofbit as well? The standard
|
|
doesn't seem to answer that question.</p>
|
|
|
|
<p>On the one hand, nothing in 27.6.1.1.2 says that
|
|
<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
|
|
other hand, 27.6.1.1 paragraph 4 says that if
|
|
extraction from a <tt>streambuf</tt> "returns
|
|
<tt>traits::eof()</tt>, then the input function, except as explicitly
|
|
noted otherwise, completes its actions and does
|
|
<tt>setstate(eofbit)"</tt>. So the question comes down to
|
|
whether <tt>basic_istream<>::sentry</tt>'s constructor is an
|
|
input function.</p>
|
|
|
|
<p>Comments from Jerry Schwarz:</p>
|
|
<blockquote>
|
|
<p>It was always my intention that eofbit should be set any time that a
|
|
virtual returned something to indicate eof, no matter what reason
|
|
iostream code had for calling the virtual.</p>
|
|
<p>
|
|
The motivation for this is that I did not want to require streambufs
|
|
to behave consistently if their virtuals are called after they have
|
|
signaled eof.</p>
|
|
<p>
|
|
The classic case is a streambuf reading from a UNIX file. EOF isn't
|
|
really a state for UNIX file descriptors. The convention is that a
|
|
read on UNIX returns 0 bytes to indicate "EOF", but the file
|
|
descriptor isn't shut down in any way and future reads do not
|
|
necessarily also return 0 bytes. In particular, you can read from
|
|
tty's on UNIX even after they have signaled "EOF". (It
|
|
isn't always understood that a ^D on UNIX is not an EOF indicator, but
|
|
an EOL indicator. By typing a "line" consisting solely of
|
|
^D you cause a read to return 0 bytes, and by convention this is
|
|
interpreted as end of file.)</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
|
|
<blockquote>
|
|
<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt>
|
|
returns <tt>traits::eof()</tt>, the function calls
|
|
<tt>setstate(failbit | eofbit)</tt> (which may throw
|
|
<tt>ios_base::failure</tt>).
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p>
|
|
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
|
|
<p>
|
|
Suppose that <tt>A</tt> is a class that conforms to the
|
|
Allocator requirements of Table 32, and <tt>a</tt> is an
|
|
object of class <tt>A</tt> What should be the return
|
|
value of <tt>a.allocate(0)</tt>? Three reasonable
|
|
possibilities: forbid the argument <tt>0</tt>, return
|
|
a null pointer, or require that the return value be a
|
|
unique non-null pointer.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add a note to the <tt>allocate</tt> row of Table 32:
|
|
"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>A key to understanding this issue is that the ultimate use of
|
|
allocate() is to construct an iterator, and that iterator for zero
|
|
length sequences must be the container's past-the-end
|
|
representation. Since this already implies special case code, it
|
|
would be over-specification to mandate the return value.
|
|
</p>
|
|
<hr>
|
|
<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p>
|
|
<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p>
|
|
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
|
|
past-the-end values are always non-singular."</p>
|
|
<p>This places an unnecessary restriction on past-the-end iterators for
|
|
containers with forward iterators (for example, a singly-linked list). If the
|
|
past-the-end value on such a container was a well-known singular value, it would
|
|
still satisfy all forward iterator requirements.</p>
|
|
<p>Removing this restriction would allow, for example, a singly-linked list
|
|
without a "footer" node.</p>
|
|
<p>This would have an impact on existing code that expects past-the-end
|
|
iterators obtained from different (generic) containers being not equal.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 24.1 paragraph 5, the last sentence, from:</p>
|
|
<blockquote>
|
|
<p>Dereferenceable and past-the-end values are always non-singular.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Dereferenceable values are always non-singular. </p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>For some kinds of containers, including singly linked lists and
|
|
zero-length vectors, null pointers are perfectly reasonable past-the-end
|
|
iterators. Null pointers are singular.
|
|
</p>
|
|
<hr>
|
|
<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
|
|
<p>In Section 21.3 the basic_string member function
|
|
declarations use a consistent style except for the following functions:</p>
|
|
<blockquote>
|
|
<pre>void push_back(const charT);
|
|
basic_string& assign(const basic_string&);
|
|
void swap(basic_string<charT,traits,Allocator>&);</pre>
|
|
</blockquote>
|
|
<p>- push_back, assign, swap: missing argument name <br>
|
|
- push_back: use of const with charT (i.e. POD type passed by value
|
|
not by reference - should be charT or const charT& )<br>
|
|
- swap: redundant use of template parameters in argument
|
|
basic_string<charT,traits,Allocator>&</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In Section 21.3 change the basic_string member
|
|
function declarations push_back, assign, and swap to:</p>
|
|
<blockquote>
|
|
<pre>void push_back(charT c);
|
|
|
|
basic_string& assign(const basic_string& str);
|
|
void swap(basic_string& str);</pre>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although the standard is in general not consistent in declaration
|
|
style, the basic_string declarations are consistent other than the
|
|
above. The LWG felt that this was sufficient reason to merit the
|
|
change.
|
|
</p>
|
|
<hr>
|
|
<a name="210"><h3>210. distance first and last confused</h3></a><p>
|
|
<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
|
|
<p>In paragraph 9 of section 25 , it is written:</p>
|
|
<blockquote>
|
|
<p> In the description of the algorithms operators + and - are used
|
|
for some of the iterator categories for which they do not have to
|
|
be defined. In these cases the semantics of [...] a-b is the same
|
|
as of<br>
|
|
<br>
|
|
<tt>return distance(a, b);</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>On the last line of paragraph 9 of section 25 change
|
|
<tt>"a-b"</tt> to <tt>"b-a".</tt>
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>There are two ways to fix the defect; change the description to b-a
|
|
or change the return to distance(b,a). The LWG preferred the
|
|
former for consistency.</p>
|
|
<hr>
|
|
<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
|
|
<p>The description of the stream extraction operator for std::string (section
|
|
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
|
|
the case that the operator fails to extract any characters from the input
|
|
stream.</p>
|
|
<p>This implies that the typical construction</p>
|
|
<blockquote>
|
|
<pre>std::istream is;
|
|
std::string str;
|
|
...
|
|
while (is >> str) ... ;</pre>
|
|
</blockquote>
|
|
<p>(which tests failbit) is not required to terminate at EOF.</p>
|
|
<p>Furthermore, this is inconsistent with other extraction operators,
|
|
which do include this requirement. (See sections 27.6.1.2 and 27.6.1.3 ), where this
|
|
requirement is present, either explicitly or implicitly, for the
|
|
extraction operators. It is also present explicitly in the description
|
|
of getline (istream&, string&, charT) in section 21.3.7.9 paragraph 8.)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 :</p>
|
|
<blockquote>
|
|
|
|
<p>If the function extracts no characters, it calls
|
|
is.setstate(ios::failbit) which may throw ios_base::failure
|
|
(27.4.4.3).</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p>
|
|
<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
|
|
<p>The standard doesn't specify what min_element() and max_element() shall
|
|
return if the range is empty (first equals last). The usual implementations
|
|
return last. This problem seems also apply to partition(), stable_partition(),
|
|
next_permutation(), and prev_permutation().</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 25.3.7 - Minimum and maximum, paragraphs 7 and
|
|
9, append: Returns last if first==last.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG looked in some detail at all of the above mentioned
|
|
algorithms, but believes that except for min_element() and
|
|
max_element() it is already clear that last is returned if first ==
|
|
last.</p>
|
|
<hr>
|
|
<a name="214"><h3>214. set::find() missing const overload</h3></a><p>
|
|
<b>Section:</b> 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 28 Feb 2000</p>
|
|
<p>The specification for the associative container requirements in
|
|
Table 69 state that the find member function should "return
|
|
iterator; const_iterator for constant a". The map and multimap
|
|
container descriptions have two overloaded versions of find, but set
|
|
and multiset do not, all they have is:</p>
|
|
<blockquote>
|
|
<pre>iterator find(const key_type & x) const;</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
|
|
equal_range() in section 23.3.3 and section 23.3.4 to each have two overloads:</p>
|
|
<blockquote>
|
|
<pre>iterator find(const key_type & x);
|
|
const_iterator find(const key_type & x) const;</pre>
|
|
<pre>iterator lower_bound(const key_type & x);
|
|
const_iterator lower_bound(const key_type & x) const;</pre>
|
|
<pre>iterator upper_bound(const key_type & x);
|
|
const_iterator upper_bound(const key_type & x) const;</pre>
|
|
<pre>pair<iterator, iterator> equal_range(const key_type & x);
|
|
pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
|
|
extending the proposed resolution to lower_bound, upper_bound, and
|
|
equal_range.]</i></p>
|
|
<hr>
|
|
<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p>
|
|
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
|
|
<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
|
|
must be const in order for it to be callable on a const object (a reference to
|
|
which which is what std::use_facet<>() returns).</p>
|
|
<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
|
|
name of the namespace `My'.</p>
|
|
<p>3) In the definition of `loc' and subsequently in the call to use_facet<>()
|
|
in main(), the name of the facet is misspelled: it should read `My::JCtype'
|
|
rather than `My::JCType'.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the "Classifying Japanese characters" example in 22.2.8,
|
|
paragraph 11 with the following:</p>
|
|
<pre>#include <locale></pre>
|
|
<pre>namespace My {
|
|
using namespace std;
|
|
class JCtype : public locale::facet {
|
|
public:
|
|
static locale::id id; // required for use as a new locale facet
|
|
bool is_kanji (wchar_t c) const;
|
|
JCtype() {}
|
|
protected:
|
|
~JCtype() {}
|
|
};
|
|
}</pre>
|
|
<pre>// file: filt.C
|
|
#include <iostream>
|
|
#include <locale>
|
|
#include "jctype" // above
|
|
std::locale::id My::JCtype::id; // the static JCtype member
|
|
declared above.</pre>
|
|
<pre>int main()
|
|
{
|
|
using namespace std;
|
|
typedef ctype<wchar_t> wctype;
|
|
locale loc(locale(""), // the user's preferred locale...
|
|
new My::JCtype); // and a new feature ...
|
|
wchar_t c = use_facet<wctype>(loc).widen('!');
|
|
if (!use_facet<My::JCtype>(loc).is_kanji(c))
|
|
cout << "no it isn't!" << endl;
|
|
return 0;
|
|
}</pre>
|
|
<hr>
|
|
<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p>
|
|
<b>Section:</b> 27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p>
|
|
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
|
|
paragraph 2:</p>
|
|
<blockquote>
|
|
<p>Effects: Destroys an object of class ios_base. Calls each registered
|
|
callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
|
|
time that any ios_base member function called from within fn has well defined
|
|
results.</p>
|
|
</blockquote>
|
|
<p>But what is not clear is: If no callback functions were ever registered, does
|
|
it matter whether the ios_base members were ever initialized?</p>
|
|
<p>For instance, does this program have defined behavior:</p>
|
|
<blockquote>
|
|
<pre>#include <ios></pre>
|
|
<pre>class D : public std::ios_base { };</pre>
|
|
<pre>int main() { D d; }</pre>
|
|
</blockquote>
|
|
<p>It seems that registration of a callback function would surely affect the
|
|
state of an ios_base. That is, when you register a callback function with an
|
|
ios_base, the ios_base must record that fact somehow.</p>
|
|
<p>But if after construction the ios_base is in an indeterminate state, and that
|
|
state is not made determinate before the destructor is called, then how would
|
|
the destructor know if any callbacks had indeed been registered? And if the
|
|
number of callbacks that had been registered is indeterminate, then is not the
|
|
behavior of the destructor undefined?</p>
|
|
<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
|
|
it explicit that destruction before initialization results in undefined
|
|
behavior.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Modify 27.4.2.7 paragraph 1 from</p>
|
|
<blockquote>
|
|
<p>Effects: Each ios_base member has an indeterminate value after
|
|
construction.</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>Effects: Each ios_base member has an indeterminate value after
|
|
construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
|
|
have taken place, the behavior is undefined.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="221"><h3>221. num_get<>::do_get stage 2 processing broken</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Mar 2000</p>
|
|
<p>Stage 2 processing of numeric conversion is broken.</p>
|
|
|
|
<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
|
|
conversion specifier is %i. A %i specifier determines a number's base
|
|
by its prefix (0 for octal, 0x for hex), so the intention is clearly
|
|
that a 0x prefix is allowed. Paragraph 8 in the same section,
|
|
however, describes very precisely how characters are processed. (It
|
|
must be done "as if" by a specified code fragment.) That
|
|
description does not allow a 0x prefix to be recognized.</p>
|
|
|
|
<p>Very roughly, stage 2 processing reads a char_type ct. It converts
|
|
ct to a char, not by using narrow but by looking it up in a
|
|
translation table that was created by widening the string literal
|
|
"0123456789abcdefABCDEF+-". The character "x" is
|
|
not found in that table, so it can't be recognized by stage 2
|
|
processing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
|
|
<blockquote>
|
|
<pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
|
|
</blockquote>
|
|
<p>with the line:</p>
|
|
<blockquote>
|
|
<pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>If we're using the technique of widening a string literal, the
|
|
string literal must contain every character we wish to recognize.
|
|
This technique has the consequence that alternate representations
|
|
of digits will not be recognized. This design decision was made
|
|
deliberately, with full knowledge of that limitation.</p>
|
|
<hr>
|
|
<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
|
|
<b>Section:</b> 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p>
|
|
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
|
|
<blockquote>
|
|
<pre>21.3.6.8 - basic_string::compare [lib.string::compare]
|
|
|
|
int compare(size_type pos1, size_type n1,
|
|
const basic_string<charT,traits,Allocator>& str ,
|
|
size_type pos2 , size_type n2 ) const;
|
|
|
|
-4- Returns:
|
|
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
|
basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre>
|
|
</blockquote>
|
|
<p>and the constructor that's implicitly called by the above is
|
|
defined to throw an out-of-range exception if pos > str.size(). See
|
|
section 21.3.1 paragraph 4.</p>
|
|
|
|
<p>On the other hand, the compare function descriptions themselves don't have
|
|
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
|
|
that do not apply to a function are omitted.</p>
|
|
<p>So it seems there is an inconsistency in the standard -- are the
|
|
"Effects" clauses correct, or are the "Throws" clauses
|
|
missing?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 17.3.1.3 paragraph 3, the footnote 148 attached to
|
|
the sentence "Descriptions of function semantics contain the
|
|
following elements (as appropriate):", insert the word
|
|
"further" so that the foot note reads:</p>
|
|
<blockquote>
|
|
<p>To save space, items that do not apply to a function are
|
|
omitted. For example, if a function does not specify any further
|
|
preconditions, there will be no "Requires" paragraph.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The standard is somewhat inconsistent, but a failure to note a
|
|
throw condition in a throws clause does not grant permission not to
|
|
throw. The inconsistent wording is in a footnote, and thus
|
|
non-normative. The proposed resolution from the LWG clarifies the
|
|
footnote.</p>
|
|
<hr>
|
|
<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p>
|
|
<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
|
|
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 25.2.9 , replace:</p>
|
|
<blockquote>
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
|
applies swap to all pairs of iterators first + i, (last - i) - 1.
|
|
</blockquote>
|
|
<p>with:</p>
|
|
<blockquote>
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
|
applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p>
|
|
<p>In the associative container requirements table in 23.1.2 paragraph 7,
|
|
a.clear() has complexity "log(size()) + N". However, the meaning of N
|
|
is not defined.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the associative container requirements table in 23.1.2 paragraph
|
|
7, the complexity of a.clear(), change "log(size()) + N" to
|
|
"linear in <tt>size()</tt>".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>It's the "log(size())", not the "N", that is in
|
|
error: there's no difference between <i>O(N)</i> and <i>O(N +
|
|
log(N))</i>. The text in the standard is probably an incorrect
|
|
cut-and-paste from the range version of <tt>erase</tt>.</p>
|
|
<hr>
|
|
<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
|
|
<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p>
|
|
<p>25.2.2 reads:</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt> template<class T> void swap(T& a, T& b);</tt><br>
|
|
<br>
|
|
Requires: Type T is Assignable (_lib.container.requirements_).<br>
|
|
Effects: Exchanges values stored in two locations.</p>
|
|
</blockquote>
|
|
<p>The only reasonable** generic implementation of swap requires construction of a
|
|
new temporary copy of one of its arguments:</p>
|
|
<blockquote>
|
|
<pre>template<class T> void swap(T& a, T& b);
|
|
{
|
|
T tmp(a);
|
|
a = b;
|
|
b = tmp;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
|
|
<p>**Yes, there's also an unreasonable implementation which would require T to be
|
|
DefaultConstructible instead of CopyConstructible. I don't think this is worthy
|
|
of consideration:</p>
|
|
<blockquote>
|
|
<pre>template<class T> void swap(T& a, T& b);
|
|
{
|
|
T tmp;
|
|
tmp = a;
|
|
a = b;
|
|
b = tmp;
|
|
}</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.2.2 paragraph 1 from:</p>
|
|
<blockquote>
|
|
<p> Requires: Type T is Assignable (23.1).</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="234"><h3>234. Typos in allocator definition</h3></a><p>
|
|
<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
|
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
|
|
<tt>destruct()</tt> are described as returns but the functions actually
|
|
return <tt>void</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Substitute "Returns" by "Effect".</p>
|
|
<hr>
|
|
<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p>
|
|
<b>Section:</b> 23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
|
<p>The complexity specification in paragraph 6 says that the complexity
|
|
is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
|
|
defined on iterators this term is in general undefined because it
|
|
would have to be <tt>last - first</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change paragraph 6 from</p>
|
|
<blockquote>Linear in <i>first - last</i>.</blockquote>
|
|
<p>to become</p>
|
|
<blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
|
|
<hr>
|
|
<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p>
|
|
<p>basic_istream<>::get(), and basic_istream<>::getline(),
|
|
are unclear with respect to the behavior and side-effects of the named
|
|
functions in case of an error.</p>
|
|
|
|
<p>27.6.1.3, p1 states that "... If the sentry object returns
|
|
true, when converted to a value of type bool, the function endeavors
|
|
to obtain the requested input..." It is not clear from this (or
|
|
the rest of the paragraph) what precisely the behavior should be when
|
|
the sentry ctor exits by throwing an exception or when the sentry
|
|
object returns false. In particular, what is the number of characters
|
|
extracted that gcount() returns supposed to be?</p>
|
|
|
|
<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
|
|
"... In any case, it then stores a null character (using
|
|
charT()) into the next successive location of the array." Is not
|
|
clear whether this sentence applies if either of the conditions above
|
|
holds (i.e., when sentry fails).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to 27.6.1.3, p1 after the sentence</p>
|
|
|
|
<blockquote>
|
|
"... If the sentry object returns true, when converted to a value of
|
|
type bool, the function endeavors to obtain the requested input."
|
|
</blockquote>
|
|
|
|
<p>the following</p>
|
|
|
|
|
|
<blockquote>
|
|
"Otherwise, if the sentry constructor exits by throwing an exception or
|
|
if the sentry object returns false, when converted to a value of type
|
|
bool, the function returns without attempting to obtain any input. In
|
|
either case the number of extracted characters is set to 0; unformatted
|
|
input functions taking a character array of non-zero size as an argument
|
|
shall also store a null character (using charT()) in the first location
|
|
of the array."
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although the general philosophy of the input functions is that the
|
|
argument should not be modified upon failure, <tt>getline</tt>
|
|
historically added a terminating null unconditionally. Most
|
|
implementations still do that. Earlier versions of the draft standard
|
|
had language that made this an unambiguous requirement; those words
|
|
were moved to a place where their context made them less clear. See
|
|
Jerry Schwarz's message c++std-lib-7618.</p>
|
|
<hr>
|
|
<a name="248"><h3>248. time_get fails to set eofbit</h3></a><p>
|
|
<b>Section:</b> 22.2.5 <a href="lib-locales.html#lib.category.time"> [lib.category.time]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2000</p>
|
|
<p>There is no requirement that any of time_get member functions set
|
|
ios::eofbit when they reach the end iterator while parsing their input.
|
|
Since members of both the num_get and money_get facets are required to
|
|
do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
|
|
should follow the same requirement for consistency.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
|
|
|
|
<blockquote>
|
|
If the end iterator is reached during parsing by any of the get()
|
|
member functions, the member sets ios_base::eofbit in err.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Two alternative resolutions were proposed. The LWG chose this one
|
|
because it was more consistent with the way eof is described for other
|
|
input facets.</p>
|
|
<hr>
|
|
<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p>
|
|
<b>Section:</b> 27.7.1 <a href="lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
|
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
|
|
doesn't list a typedef for the template parameter
|
|
<tt>Allocator</tt>. This makes it impossible to determine the type of
|
|
the allocator at compile time. It's also inconsistent with all other
|
|
template classes in the library that do provide a typedef for the
|
|
<tt>Allocator</tt> parameter.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
|
|
basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
|
|
basic_stringstream (27.7.4) the typedef:</p>
|
|
<pre>
|
|
typedef Allocator allocator_type;
|
|
</pre>
|
|
<hr>
|
|
<a name="252"><h3>252. missing casts/C-style casts used in iostreams</h3></a><p>
|
|
<b>Section:</b> 27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
|
<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
|
|
const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
|
|
The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
|
|
D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
|
|
the cast altogether.</p>
|
|
|
|
<p>C-style casts have not been deprecated, so the first part of this
|
|
issue is stylistic rather than a matter of correctness.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.7.2.2, p1 replace </p>
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
|
|
<p>In 27.7.3.2, p1 replace</p>
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
<p>In 27.7.6, p1, replace</p>
|
|
<pre> -1- Returns: &sb</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
<p>In D.7.2.2, p1 replace</p>
|
|
<pre> -2- Returns: &sb. </pre>
|
|
|
|
<p>with</p>
|
|
<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre>
|
|
<hr>
|
|
<a name="256"><h3>256. typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p>
|
|
<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 21 Aug 2000</p>
|
|
<p>
|
|
27.4.4.2, p17 says
|
|
</p>
|
|
|
|
<blockquote>
|
|
-17- Before copying any parts of rhs, calls each registered callback
|
|
pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
|
|
exceptions() have been replaced, calls each callback pair that was
|
|
copied from rhs as (*fn)(copy_event,*this,index).
|
|
</blockquote>
|
|
|
|
<p>
|
|
The name copy_event isn't defined anywhere. The intended name was
|
|
copyfmt_event.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
|
|
<hr>
|
|
<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
|
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
|
|
it as returning the iterator by value. 24.5.1.2, p5 shows the same
|
|
operator as returning the iterator by reference. That's incorrect
|
|
given the Effects clause below (since a temporary is returned). The
|
|
`&' is probably just a typo.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the declaration in 24.5.1.2, p5 from</p>
|
|
<pre>
|
|
istream_iterator<T,charT,traits,Distance>& operator++(int);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
istream_iterator<T,charT,traits,Distance> operator++(int);
|
|
</pre>
|
|
<p>(that is, remove the `&').</p>
|
|
<hr>
|
|
<a name="261"><h3>261. Missing description of <tt>istream_iterator::operator!=</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
|
<p>
|
|
24.5.1, p3 lists the synopsis for
|
|
</p>
|
|
|
|
<pre>
|
|
template <class T, class charT, class traits, class Distance>
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
|
</pre>
|
|
|
|
<p>
|
|
but there is no description of what the operator does (i.e., no Effects
|
|
or Returns clause) in 24.5.1.2.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add paragraph 7 to the end of section 24.5.1.2 with the following text:
|
|
</p>
|
|
|
|
<pre>
|
|
template <class T, class charT, class traits, class Distance>
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
|
</pre>
|
|
|
|
<p>-7- Returns: !(x == y).</p>
|
|
<hr>
|
|
<a name="262"><h3>262. Bitmask operator ~ specified incorrectly</h3></a><p>
|
|
<b>Section:</b> 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 03 Sep 2000</p>
|
|
<p>
|
|
The ~ operation should be applied after the cast to int_type.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
|
|
</p>
|
|
|
|
<pre>
|
|
bitmask operator~ ( bitmask X )
|
|
{ return static_cast< bitmask>(static_cast<int_type>(~ X)); }
|
|
</pre>
|
|
|
|
<p>
|
|
to:
|
|
</p>
|
|
|
|
<pre>
|
|
bitmask operator~ ( bitmask X )
|
|
{ return static_cast< bitmask>(~static_cast<int_type>(X)); }
|
|
</pre>
|
|
<hr>
|
|
<a name="263"><h3>263. Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Kevlin Henney <b>Date:</b> 04 Sep 2000</p>
|
|
<p>
|
|
The note in paragraph 6 suggests that the invalidation rules for
|
|
references, pointers, and iterators in paragraph 5 permit a reference-
|
|
counted implementation (actually, according to paragraph 6, they permit
|
|
a "reference counted implementation", but this is a minor editorial fix).
|
|
</p>
|
|
|
|
<p>
|
|
However, the last sub-bullet is so worded as to make a reference-counted
|
|
implementation unviable. In the following example none of the
|
|
conditions for iterator invalidation are satisfied:
|
|
</p>
|
|
|
|
<pre>
|
|
// first example: "*******************" should be printed twice
|
|
string original = "some arbitrary text", copy = original;
|
|
const string & alias = original;
|
|
|
|
string::const_iterator i = alias.begin(), e = alias.end();
|
|
for(string::iterator j = original.begin(); j != original.end(); ++j)
|
|
*j = '*';
|
|
while(i != e)
|
|
cout << *i++;
|
|
cout << endl;
|
|
cout << original << endl;
|
|
</pre>
|
|
|
|
<p>
|
|
Similarly, in the following example:
|
|
</p>
|
|
|
|
<pre>
|
|
// second example: "some arbitrary text" should be printed out
|
|
string original = "some arbitrary text", copy = original;
|
|
const string & alias = original;
|
|
|
|
string::const_iterator i = alias.begin();
|
|
original.begin();
|
|
while(i != alias.end())
|
|
cout << *i++;
|
|
</pre>
|
|
|
|
<p>
|
|
I have tested this on three string implementations, two of which were
|
|
reference counted. The reference-counted implementations gave
|
|
"surprising behavior" because they invalidated iterators on
|
|
the first call to non-const begin since construction. The current
|
|
wording does not permit such invalidation because it does not take
|
|
into account the first call since construction, only the first call
|
|
since various member and non-member function calls.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the following sentence in 21.3 paragraph 5 from
|
|
</p>
|
|
|
|
<blockquote>
|
|
Subsequent to any of the above uses except the forms of insert() and
|
|
erase() which return iterators, the first call to non-const member
|
|
functions operator[](), at(), begin(), rbegin(), end(), or rend().
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Following construction or any of the above uses, except the forms of
|
|
insert() and erase() that return iterators, the first call to non-
|
|
const member functions operator[](), at(), begin(), rbegin(), end(),
|
|
or rend().
|
|
</blockquote>
|
|
<hr>
|
|
<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p>
|
|
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 11 Sep 2000</p>
|
|
<p>
|
|
I don't see any requirements on the types of the elements of the
|
|
std::pair container in 20.2.2. From the descriptions of the member
|
|
functions it appears that they must at least satisfy the requirements of
|
|
20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
|
|
the case of the [in]equality operators also the requirements of 20.1.1
|
|
[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
|
|
</p>
|
|
|
|
<p>
|
|
I believe that the the CopyConstructible requirement is unnecessary in
|
|
the case of 20.2.2, p2.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the Effects clause in 20.2.2, p2 from</p>
|
|
|
|
<blockquote>
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
|
first(T1()), second(T2()) {} </tt>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
|
first(), second() {} </tt>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The existing specification of pair's constructor appears to be a
|
|
historical artifact: there was concern that pair's members be properly
|
|
zero-initialized when they are built-in types. At one time there was
|
|
uncertainty about whether they would be zero-initialized if the
|
|
default constructor was written the obvious way. This has been
|
|
clarified by core issue 178, and there is no longer any doubt that
|
|
the straightforward implementation is correct.</p>
|
|
<hr>
|
|
<a name="268"><h3>268. Typo in locale synopsis</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
|
|
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
|
|
the semicolons after the declarations of the default ctor
|
|
locale::locale() and the copy ctor locale::locale(const locale&)
|
|
are missing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the missing semicolons, i.e., change</p>
|
|
|
|
<pre>
|
|
// construct/copy/destroy:
|
|
locale() throw()
|
|
locale(const locale& other) throw()
|
|
</pre>
|
|
|
|
<p>in the synopsis in 22.1.1 to</p>
|
|
|
|
<pre>
|
|
// construct/copy/destroy:
|
|
locale() throw();
|
|
locale(const locale& other) throw();
|
|
</pre>
|
|
<p>----- End of document -----</p>
|
|
</body>
|
|
</html>
|