mirror of
git://gcc.gnu.org/git/gcc.git
synced 2024-12-21 00:30:05 +08:00
664ce87016
2002-11-21 Phil Edwards <pme@gcc.gnu.org> * docs/doxygen/style.css: Update. * docs/doxygen/user.cfg.in: Update. * docs/html/documentation.html: Regenerate. * docs/html/17_intro/howto.html: Tweak I/O sentry entry. * docs/html/27_io/howto.html: New section on headers. * docs/html/faq/index.html: Add i386 threading entry. * docs/html/faq/index.txt: Regenerate. * docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html: Import R23. From-SVN: r59326
8043 lines
394 KiB
HTML
8043 lines
394 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/02-0049 = WG21 N1391</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Date:</td>
|
|
<td align="left">10 Sep 2002</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Project:</td>
|
|
<td align="left">Programming Language C++</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">Reply to:</td>
|
|
<td align="left">Matt Austern <austern@apple.com></td>
|
|
</tr>
|
|
</table>
|
|
<h1>C++ Standard Library Defect Report List (Revision 23)</h1>
|
|
<p>Reference ISO/IEC IS 14882:1998(E)</p>
|
|
<p>Also see:</p>
|
|
<ul>
|
|
<li>
|
|
<a href="lwg-toc.html">Table of Contents</a> for all library issues.</li>
|
|
<li>
|
|
<a href="lwg-index.html">Index by Section</a> for all library issues.</li>
|
|
<li>
|
|
<a href="lwg-status.html">Index by Status</a> for all library issues.</li>
|
|
<li><a href="lwg-active.html">Library Active Issues List</a></li>
|
|
<li><a href="lwg-closed.html">Library Closed Issues List</a></li>
|
|
</ul>
|
|
<p>This document contains only library issues which have been closed
|
|
by the Library Working Group (LWG) after being found to be defects
|
|
in the standard. That is, issues which have a status of <a href="lwg-active.html#DR">DR</a>, <a href="lwg-active.html#TC">TC</a>, or <a href="lwg-active.html#RR">RR</a>. See the
|
|
<a href="lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the
|
|
<a href="lwg-active.html">Library Active Issues List</a> for active issues and more information. The
|
|
introductory material in that document also applies to this
|
|
document.</p>
|
|
<h2>Revision History</h2>
|
|
<ul>
|
|
<li>R23:
|
|
Pre-Santa Cruz mailing. Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
|
|
Moved issues in the TC to TC status.
|
|
</li>
|
|
<li>R22:
|
|
Post-Curaçao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
|
|
</li>
|
|
<li>R21:
|
|
Pre-Curaçao mailing. Added new issues <a href="lwg-closed.html#351">351</a>-<a href="lwg-active.html#361">361</a>.
|
|
</li>
|
|
<li>R20:
|
|
Post-Redmond mailing; reflects actions taken in Redmond. Added
|
|
new issues <a href="lwg-active.html#336">336</a>-<a href="lwg-active.html#350">350</a>, of which issues
|
|
<a href="lwg-active.html#347">347</a>-<a href="lwg-active.html#350">350</a> were added since Redmond, hence
|
|
not discussed at the meeting.
|
|
|
|
All Ready issues were moved to DR status, with the exception of issues
|
|
<a href="lwg-defects.html#284">284</a>, <a href="lwg-active.html#241">241</a>, and <a href="lwg-closed.html#267">267</a>.
|
|
|
|
Noteworthy issues discussed at Redmond include
|
|
<a href="lwg-active.html#120">120</a> <a href="lwg-active.html#202">202</a>, <a href="lwg-active.html#226">226</a>, <a href="lwg-active.html#233">233</a>,
|
|
<a href="lwg-defects.html#270">270</a>, <a href="lwg-active.html#253">253</a>, <a href="lwg-active.html#254">254</a>, <a href="lwg-active.html#323">323</a>.
|
|
</li>
|
|
<li>R19:
|
|
Pre-Redmond mailing. Added new issues
|
|
<a href="lwg-active.html#323">323</a>-<a href="lwg-defects.html#335">335</a>.
|
|
</li>
|
|
<li>R18:
|
|
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
|
|
Added new issues <a href="lwg-defects.html#312">312</a>-<a href="lwg-defects.html#317">317</a>, and discussed
|
|
new issues <a href="lwg-defects.html#271">271</a>-<a href="lwg-closed.html#314">314</a>.
|
|
|
|
Changed status of issues
|
|
<a href="lwg-defects.html#103">103</a> <a href="lwg-defects.html#118">118</a> <a href="lwg-defects.html#136">136</a> <a href="lwg-defects.html#153">153</a>
|
|
<a href="lwg-defects.html#165">165</a> <a href="lwg-defects.html#171">171</a> <a href="lwg-defects.html#183">183</a> <a href="lwg-defects.html#184">184</a>
|
|
<a href="lwg-defects.html#185">185</a> <a href="lwg-defects.html#186">186</a> <a href="lwg-defects.html#214">214</a> <a href="lwg-defects.html#221">221</a>
|
|
<a href="lwg-defects.html#234">234</a> <a href="lwg-defects.html#237">237</a> <a href="lwg-defects.html#243">243</a> <a href="lwg-defects.html#248">248</a>
|
|
<a href="lwg-defects.html#251">251</a> <a href="lwg-defects.html#252">252</a> <a href="lwg-defects.html#256">256</a> <a href="lwg-defects.html#260">260</a>
|
|
<a href="lwg-defects.html#261">261</a> <a href="lwg-defects.html#262">262</a> <a href="lwg-defects.html#263">263</a> <a href="lwg-defects.html#265">265</a>
|
|
<a href="lwg-defects.html#268">268</a>
|
|
to DR.
|
|
|
|
Changed status of issues
|
|
<a href="lwg-defects.html#49">49</a> <a href="lwg-defects.html#109">109</a> <a href="lwg-defects.html#117">117</a> <a href="lwg-defects.html#182">182</a>
|
|
<a href="lwg-defects.html#228">228</a> <a href="lwg-defects.html#230">230</a> <a href="lwg-defects.html#232">232</a> <a href="lwg-defects.html#235">235</a>
|
|
<a href="lwg-defects.html#238">238</a> <a href="lwg-active.html#241">241</a> <a href="lwg-defects.html#242">242</a> <a href="lwg-defects.html#250">250</a>
|
|
<a href="lwg-defects.html#259">259</a> <a href="lwg-defects.html#264">264</a> <a href="lwg-defects.html#266">266</a> <a href="lwg-closed.html#267">267</a>
|
|
<a href="lwg-defects.html#271">271</a> <a href="lwg-defects.html#272">272</a> <a href="lwg-defects.html#273">273</a> <a href="lwg-defects.html#275">275</a>
|
|
<a href="lwg-defects.html#281">281</a> <a href="lwg-defects.html#284">284</a> <a href="lwg-defects.html#285">285</a> <a href="lwg-defects.html#286">286</a>
|
|
<a href="lwg-defects.html#288">288</a> <a href="lwg-defects.html#292">292</a> <a href="lwg-defects.html#295">295</a> <a href="lwg-defects.html#297">297</a>
|
|
<a href="lwg-defects.html#298">298</a> <a href="lwg-defects.html#301">301</a> <a href="lwg-defects.html#303">303</a> <a href="lwg-defects.html#306">306</a>
|
|
<a href="lwg-defects.html#307">307</a> <a href="lwg-defects.html#308">308</a> <a href="lwg-defects.html#312">312</a>
|
|
to Ready.
|
|
|
|
Closed issues
|
|
<a href="lwg-closed.html#111">111</a> <a href="lwg-closed.html#277">277</a> <a href="lwg-closed.html#279">279</a> <a href="lwg-closed.html#287">287</a>
|
|
<a href="lwg-closed.html#289">289</a> <a href="lwg-closed.html#293">293</a> <a href="lwg-closed.html#302">302</a> <a href="lwg-closed.html#313">313</a>
|
|
<a href="lwg-closed.html#314">314</a>
|
|
as NAD.
|
|
|
|
</li>
|
|
<li>R17:
|
|
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
|
|
resolutions for issues <a href="lwg-defects.html#49">49</a>, <a href="lwg-defects.html#76">76</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-defects.html#235">235</a>, <a href="lwg-defects.html#250">250</a>, <a href="lwg-closed.html#267">267</a>.
|
|
Added new issues <a href="lwg-active.html#278">278</a>-<a href="lwg-defects.html#311">311</a>.
|
|
</li>
|
|
<li>R16:
|
|
post-Toronto mailing; reflects actions taken in Toronto. Added new
|
|
issues <a href="lwg-defects.html#265">265</a>-<a href="lwg-closed.html#277">277</a>. Changed status of issues
|
|
<a href="lwg-defects.html#3">3</a>, <a href="lwg-defects.html#8">8</a>, <a href="lwg-defects.html#9">9</a>, <a href="lwg-defects.html#19">19</a>,
|
|
<a href="lwg-defects.html#26">26</a>, <a href="lwg-defects.html#31">31</a>, <a href="lwg-defects.html#61">61</a>,
|
|
<a href="lwg-defects.html#63">63</a>, <a href="lwg-defects.html#86">86</a>, <a href="lwg-defects.html#108">108</a>,
|
|
<a href="lwg-defects.html#112">112</a>, <a href="lwg-defects.html#114">114</a>, <a href="lwg-defects.html#115">115</a>,
|
|
<a href="lwg-defects.html#122">122</a>, <a href="lwg-defects.html#127">127</a>, <a href="lwg-defects.html#129">129</a>,
|
|
<a href="lwg-defects.html#134">134</a>, <a href="lwg-defects.html#137">137</a>, <a href="lwg-defects.html#142">142</a>,
|
|
<a href="lwg-defects.html#144">144</a>, <a href="lwg-defects.html#146">146</a>, <a href="lwg-defects.html#147">147</a>,
|
|
<a href="lwg-defects.html#159">159</a>, <a href="lwg-defects.html#164">164</a>, <a href="lwg-defects.html#170">170</a>,
|
|
<a href="lwg-defects.html#181">181</a>, <a href="lwg-defects.html#199">199</a>, <a href="lwg-defects.html#208">208</a>,
|
|
<a href="lwg-defects.html#209">209</a>, <a href="lwg-defects.html#210">210</a>, <a href="lwg-defects.html#211">211</a>,
|
|
<a href="lwg-defects.html#212">212</a>, <a href="lwg-defects.html#217">217</a>, <a href="lwg-defects.html#220">220</a>,
|
|
<a href="lwg-defects.html#222">222</a>, <a href="lwg-defects.html#223">223</a>, <a href="lwg-defects.html#224">224</a>,
|
|
<a href="lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="lwg-active.html#23">23</a>. Reopened
|
|
issue <a href="lwg-active.html#187">187</a>. Changed issues <a href="lwg-closed.html#2">2</a> and
|
|
<a href="lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="lwg-defects.html#17">17</a>. Fixed
|
|
issue <a href="lwg-defects.html#70">70</a>: signature should be changed both places it
|
|
appears. Fixed issue <a href="lwg-defects.html#160">160</a>: previous version didn't fix
|
|
the bug in enough places.
|
|
</li>
|
|
<li>R15:
|
|
pre-Toronto mailing. Added issues
|
|
<a href="lwg-active.html#233">233</a>-<a href="lwg-defects.html#264">264</a>. Some small HTML formatting
|
|
changes so that we pass Weblint tests.
|
|
</li>
|
|
<li>R14:
|
|
post-Tokyo II mailing; reflects committee actions taken in
|
|
Tokyo. Added issues <a href="lwg-defects.html#228">228</a> to <a href="lwg-defects.html#232">232</a>. (00-0019R1/N1242)
|
|
</li>
|
|
<li>R13:
|
|
pre-Tokyo II updated: Added issues <a href="lwg-defects.html#212">212</a> to <a href="lwg-defects.html#227">227</a>.
|
|
</li>
|
|
<li>R12:
|
|
pre-Tokyo II mailing: Added issues <a href="lwg-defects.html#199">199</a> to
|
|
<a href="lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
|
|
of issue <a href="lwg-defects.html#29">29</a>. Add further rationale to issue
|
|
<a href="lwg-closed.html#178">178</a>.
|
|
</li>
|
|
<li>R11:
|
|
post-Kona mailing: Updated to reflect LWG and full committee actions
|
|
in Kona (99-0048/N1224). Note changed resolution of issues
|
|
<a href="lwg-closed.html#4">4</a> and <a href="lwg-defects.html#38">38</a>. Added issues <a href="lwg-closed.html#196">196</a>
|
|
to <a href="lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
|
|
"closed" documents. Changed the proposed resolution of issue
|
|
<a href="lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
|
|
of issue <a href="lwg-defects.html#38">38</a>.
|
|
</li>
|
|
<li>R10:
|
|
pre-Kona updated. Added proposed resolutions <a href="lwg-defects.html#83">83</a>,
|
|
<a href="lwg-defects.html#86">86</a>, <a href="lwg-active.html#91">91</a>, <a href="lwg-active.html#92">92</a>,
|
|
<a href="lwg-defects.html#109">109</a>. Added issues <a href="lwg-closed.html#190">190</a> to
|
|
<a href="lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
|
|
</li>
|
|
<li>R9:
|
|
pre-Kona mailing. Added issues <a href="lwg-closed.html#140">140</a> to
|
|
<a href="lwg-defects.html#189">189</a>. Issues list split into separate "active" and
|
|
"closed" documents. (99-0030/N1206, 25 Aug 99)
|
|
</li>
|
|
<li>R8:
|
|
post-Dublin mailing. Updated to reflect LWG and full committee actions
|
|
in Dublin. (99-0016/N1193, 21 Apr 99)
|
|
</li>
|
|
<li>R7:
|
|
pre-Dublin updated: Added issues <a href="lwg-closed.html#130">130</a>, <a href="lwg-closed.html#131">131</a>,
|
|
<a href="lwg-defects.html#132">132</a>, <a href="lwg-defects.html#133">133</a>, <a href="lwg-defects.html#134">134</a>,
|
|
<a href="lwg-closed.html#135">135</a>, <a href="lwg-defects.html#136">136</a>, <a href="lwg-defects.html#137">137</a>,
|
|
<a href="lwg-closed.html#138">138</a>, <a href="lwg-defects.html#139">139</a> (31 Mar 99)
|
|
</li>
|
|
<li>R6:
|
|
pre-Dublin mailing. Added issues <a href="lwg-defects.html#127">127</a>, <a href="lwg-closed.html#128">128</a>,
|
|
and <a href="lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
|
|
</li>
|
|
<li>R5:
|
|
update issues <a href="lwg-defects.html#103">103</a>, <a href="lwg-defects.html#112">112</a>; added issues
|
|
<a href="lwg-defects.html#114">114</a> to <a href="lwg-defects.html#126">126</a>. Format revisions to prepare
|
|
for making list public. (30 Dec 98)
|
|
</li>
|
|
<li>R4:
|
|
post-Santa Cruz II updated: Issues <a href="lwg-defects.html#110">110</a>,
|
|
<a href="lwg-closed.html#111">111</a>, <a href="lwg-defects.html#112">112</a>, <a href="lwg-closed.html#113">113</a> added, several
|
|
issues corrected. (22 Oct 98)
|
|
</li>
|
|
<li>R3:
|
|
post-Santa Cruz II: Issues <a href="lwg-closed.html#94">94</a> to <a href="lwg-defects.html#109">109</a>
|
|
added, many issues updated to reflect LWG consensus (12 Oct 98)
|
|
</li>
|
|
<li>R2:
|
|
pre-Santa Cruz II: Issues <a href="lwg-closed.html#73">73</a> to <a href="lwg-closed.html#93">93</a> added,
|
|
issue <a href="lwg-defects.html#17">17</a> updated. (29 Sep 98)
|
|
</li>
|
|
<li>R1:
|
|
Correction to issue <a href="lwg-defects.html#55">55</a> resolution, <a href="lwg-defects.html#60">60</a> code
|
|
format, <a href="lwg-defects.html#64">64</a> title. (17 Sep 98)
|
|
</li>
|
|
</ul>
|
|
<h2>Defect Reports</h2>
|
|
<hr>
|
|
<a name="1"><h3>1. C library linkage editing oversight</h3></a><p>
|
|
<b>Section:</b> 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
|
|
<p>The change specified in the proposed resolution below did not make
|
|
it into the Standard. This change was accepted in principle at the
|
|
London meeting, and the exact wording below was accepted at the
|
|
Morristown meeting.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
|
|
from:</p>
|
|
|
|
<blockquote>
|
|
<p>It is unspecified whether a name from the Standard C library
|
|
declared with external linkage has either extern "C" or
|
|
extern "C++" linkage.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Whether a name from the Standard C library declared with external
|
|
linkage has extern "C" or extern "C++" linkage
|
|
is implementation defined. It is recommended that an implementation
|
|
use extern "C++" linkage for this purpose.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p>
|
|
<b>Section:</b> 18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p>
|
|
<p>We appear not to have covered all the possibilities of
|
|
exit processing with respect to
|
|
atexit registration. <br>
|
|
<br>
|
|
Example 1: (C and C++)</p>
|
|
|
|
<pre> #include <stdlib.h>
|
|
void f1() { }
|
|
void f2() { atexit(f1); }
|
|
|
|
int main()
|
|
{
|
|
atexit(f2); // the only use of f2
|
|
return 0; // for C compatibility
|
|
}</pre>
|
|
|
|
<p>At program exit, f2 gets called due to its registration in
|
|
main. Running f2 causes f1 to be newly registered during the exit
|
|
processing. Is this a valid program? If so, what are its
|
|
semantics?</p>
|
|
|
|
<p>
|
|
Interestingly, neither the C standard, nor the C++ draft standard nor
|
|
the forthcoming C9X Committee Draft says directly whether you can
|
|
register a function with atexit during exit processing.</p>
|
|
|
|
<p>
|
|
All 3 standards say that functions are run in reverse order of their
|
|
registration. Since f1 is registered last, it ought to be run first,
|
|
but by the time it is registered, it is too late to be first.</p>
|
|
|
|
<p>If the program is valid, the standards are self-contradictory about
|
|
its semantics.</p>
|
|
|
|
<p>Example 2: (C++ only)</p>
|
|
|
|
<pre>
|
|
void F() { static T t; } // type T has a destructor
|
|
|
|
int main()
|
|
{
|
|
atexit(F); // the only use of F
|
|
}
|
|
</pre>
|
|
|
|
<p>Function F registered with atexit has a local static variable t,
|
|
and F is called for the first time during exit processing. A local
|
|
static object is initialized the first time control flow passes
|
|
through its definition, and all static objects are destroyed during
|
|
exit processing. Is the code valid? If so, what are its semantics?</p>
|
|
|
|
<p>
|
|
Section 18.3 "Start and termination" says that if a function
|
|
F is registered with atexit before a static object t is initialized, F
|
|
will not be called until after t's destructor completes.</p>
|
|
|
|
<p>
|
|
In example 2, function F is registered with atexit before its local
|
|
static object O could possibly be initialized. On that basis, it must
|
|
not be called by exit processing until after O's destructor
|
|
completes. But the destructor cannot be run until after F is called,
|
|
since otherwise the object could not be constructed in the first
|
|
place.</p>
|
|
|
|
<p>If the program is valid, the standard is self-contradictory about
|
|
its semantics.</p>
|
|
|
|
<p>I plan to submit Example 1 as a public comment on the C9X CD, with
|
|
a recommendation that the results be undefined. (Alternative: make it
|
|
unspecified. I don't think it is worthwhile to specify the case where
|
|
f1 itself registers additional functions, each of which registers
|
|
still more functions.)</p>
|
|
|
|
<p>I think we should resolve the situation in the whatever way the C
|
|
committee decides. </p>
|
|
|
|
<p>For Example 2, I recommend we declare the results undefined.</p>
|
|
|
|
<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change section 18.3/8 from:</p>
|
|
<blockquote>
|
|
First, objects with static storage duration are destroyed and
|
|
functions registered by calling atexit are called. Objects with
|
|
static storage duration are destroyed in the reverse order of the
|
|
completion of their constructor. (Automatic objects are not
|
|
destroyed as a result of calling exit().) Functions registered with
|
|
atexit are called in the reverse order of their registration. A
|
|
function registered with atexit before an object obj1 of static
|
|
storage duration is initialized will not be called until obj1's
|
|
destruction has completed. A function registered with atexit after
|
|
an object obj2 of static storage duration is initialized will be
|
|
called before obj2's destruction starts.
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
First, objects with static storage duration are destroyed and
|
|
functions registered by calling atexit are called. Non-local objects
|
|
with static storage duration are destroyed in the reverse order of
|
|
the completion of their constructor. (Automatic objects are not
|
|
destroyed as a result of calling exit().) Functions registered with
|
|
atexit are called in the reverse order of their registration, except
|
|
that a function is called after any previously registered functions
|
|
that had already been called at the time it was registered. A
|
|
function registered with atexit before a non-local object obj1 of
|
|
static storage duration is initialized will not be called until
|
|
obj1's destruction has completed. A function registered with atexit
|
|
after a non-local object obj2 of static storage duration is
|
|
initialized will be called before obj2's destruction starts. A local
|
|
static object obj3 is destroyed at the same time it would be if a
|
|
function calling the obj3 destructor were registered with atexit at
|
|
the completion of the obj3 constructor.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
|
|
supporting to the proposed resolution.</p>
|
|
<hr>
|
|
<a name="5"><h3>5. String::compare specification questionable</h3></a><p>
|
|
<b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p>
|
|
<p>At the very end of the basic_string class definition is the signature: int
|
|
compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
|
|
following text this is defined as: returns
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
|
basic_string<charT,traits,Allocator>(s,n2); </p>
|
|
|
|
<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a
|
|
= Allocator()) clearly requires that s != NULL and n < npos and further states that it
|
|
throws length_error if n == npos, it appears the compare() signature above should always
|
|
throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
|
|
null terminated character array. </p>
|
|
|
|
<p>This appears to be a typo since the obvious intent is to allow either the call above or
|
|
something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
|
|
|
|
<p>This would imply that what was really intended was two signatures int compare(size_type
|
|
pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
|
|
charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the compare signature in 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
|
|
(at the very end of the basic_string synopsis) which reads:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s,
|
|
size_type n2 = npos) const;</tt></p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s) const;<br>
|
|
int compare(size_type pos1, size_type n1,<br>
|
|
const charT* s,
|
|
size_type n2) const;</tt></p>
|
|
</blockquote>
|
|
|
|
<p>Replace the portion of 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
|
|
paragraphs 5 and 6 which read:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>int compare(size_type pos, size_type n1,<br>
|
|
charT * s, size_type n2
|
|
= npos) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>int compare(size_type pos, size_type n1,<br>
|
|
const charT * s) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s ))<br>
|
|
<br>
|
|
int compare(size_type pos, size_type n1,<br>
|
|
const charT * s,
|
|
size_type n2) const;<br>
|
|
</tt>Returns:<tt><br>
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
|
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt>
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>Editors please note that in addition to splitting the signature, the third argument
|
|
becomes const, matching the existing synopsis.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>While the LWG dislikes adding signatures, this is a clear defect in
|
|
the Standard which must be fixed. The same problem was also
|
|
identified in issues 7 (item 5) and 87.</p>
|
|
<hr>
|
|
<a name="7"><h3>7. String clause minor problems</h3></a><p>
|
|
<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
|
|
<p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
|
|
<class InputIterator> insert(iterator, InputIterator,
|
|
InputIterator) makes no sense. It refers to a member function that
|
|
doesn't exist. It also talks about the return value of a void
|
|
function. </p>
|
|
|
|
<p>(2) Several versions of basic_string::replace don't appear in the
|
|
class synopsis. </p>
|
|
|
|
<p>(3) basic_string::push_back appears in the synopsis, but is never
|
|
described elsewhere. In the synopsis its argument is const charT,
|
|
which doesn't makes much sense; it should probably be charT, or
|
|
possible const charT&. </p>
|
|
|
|
<p>(4) basic_string::pop_back is missing. </p>
|
|
|
|
<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
|
|
= npos) make no sense. First, it's const charT* in the synopsis and
|
|
charT* in the description. Second, given what it says in RETURNS,
|
|
leaving out the final argument will always result in an exception
|
|
getting thrown. This is paragraphs 5 and 6 of
|
|
21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
|
|
</p>
|
|
|
|
<p>(6) In table 37, in section 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
|
|
there's a note for X::move(s, p, n). It says "Copies correctly
|
|
even where p is in [s, s+n)". This is correct as far as it goes,
|
|
but it doesn't go far enough; it should also guarantee that the copy
|
|
is correct even where s in in [p, p+n). These are two orthogonal
|
|
guarantees, and neither one follows from the other. Both guarantees
|
|
are necessary if X::move is supposed to have the same sort of
|
|
semantics as memmove (which was clearly the intent), and both
|
|
guarantees are necessary if X::move is actually supposed to be
|
|
useful. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
|
|
<br>
|
|
EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
|
|
<br>
|
|
ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in
|
|
the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
|
|
<br>
|
|
ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
|
|
[lib.basic.string]) from:</p>
|
|
|
|
<p> void push_back(const charT)<br>
|
|
<br>
|
|
to<br>
|
|
<br>
|
|
void push_back(charT)<br>
|
|
<br>
|
|
Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
|
|
<br>
|
|
void basic_string::push_back(charT c);<br>
|
|
EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br>
|
|
<br>
|
|
ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
|
|
<br>
|
|
ITEM 5: Duplicate; see issue 5 (and 87).<br>
|
|
<br>
|
|
ITEM 6: In table 37, Replace:<br>
|
|
<br>
|
|
"Copies correctly even where p is in [s, s+n)."<br>
|
|
<br>
|
|
with:<br>
|
|
<br>
|
|
"Copies correctly even where the ranges [p, p+n) and [s,
|
|
s+n) overlap."</p>
|
|
<hr>
|
|
<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p>
|
|
<b>Section:</b> 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p>
|
|
<p>It appears there's an important guarantee missing from clause
|
|
22. We're told that invoking locale::global(L) sets the C locale if L
|
|
has a name. However, we're not told whether or not invoking
|
|
setlocale(s) sets the global C++ locale. </p>
|
|
|
|
<p>The intent, I think, is that it should not, but I can't find any
|
|
such words anywhere. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a sentence at the end of 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
|
|
paragraph 2: </p>
|
|
|
|
<blockquote>
|
|
<p>No library function other than <tt>locale::global()</tt> shall affect
|
|
the value returned by <tt>locale()</tt>. </p>
|
|
|
|
</blockquote>
|
|
<hr>
|
|
<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p>
|
|
<b>Section:</b> 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p>
|
|
<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
|
|
section 3.7.3.1 of CD2 seems to allow for the possibility that all
|
|
calls to operator new(0) yield the same pointer, an implementation
|
|
technique specifically prohibited by ARM 5.3.3.Was this prohibition
|
|
really lifted? Does the FDIS agree with CD2 in the regard? [Issues
|
|
list maintainer's note: the IS is the same.]</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the last paragraph of 3.7.3 from:</p>
|
|
<blockquote>
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program shall
|
|
conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program,
|
|
including the default versions in the library, shall conform to the semantics
|
|
specified in 3.7.3.1 and 3.7.3.2.</p>
|
|
</blockquote>
|
|
<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
|
|
<blockquote>
|
|
<p>If the size of the space requested is zero, the value returned shall not be
|
|
a null pointer value (4.10).</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Even if the size of the space requested is zero, the request can fail. If
|
|
the request succeeds, the value returned shall be a non-null pointer value
|
|
(4.10) p0 different from any previously returned value p1, unless that value
|
|
p1 was since passed to an operator delete.</p>
|
|
</blockquote>
|
|
<p>5.3.4/7 currently reads:</p>
|
|
<blockquote>
|
|
<p>When the value of the expression in a direct-new-declarator is zero, the
|
|
allocation function is called to allocate an array with no elements. The
|
|
pointer returned by the new-expression is non-null. [Note: If the library
|
|
allocation function is called, the pointer returned is distinct from the
|
|
pointer to any other object.]</p>
|
|
</blockquote>
|
|
<p>Retain the first sentence, and delete the remainder.</p>
|
|
<p>18.4.1 currently has no text. Add the following:</p>
|
|
<blockquote>
|
|
<p>Except where otherwise specified, the provisions of 3.7.3 apply to the
|
|
library versions of operator new and operator delete.</p>
|
|
</blockquote>
|
|
<p>To 18.4.1.3, add the following text:</p>
|
|
<blockquote>
|
|
<p>The provisions of 3.7.3 do not apply to these reserved placement forms of
|
|
operator new and operator delete.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
|
|
supporting to the proposed resolution.</p>
|
|
<hr>
|
|
<a name="11"><h3>11. Bitset minor problems</h3></a><p>
|
|
<b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
|
|
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
|
|
not documented in 23.3.5.2. </p>
|
|
|
|
<p>(2) The class synopsis only gives a single signature for bitset<>::operator[],
|
|
reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
|
|
on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
|
|
|
|
<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
|
|
trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
|
|
go in the Effects clause.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>ITEMS 1 AND 2:<br>
|
|
<br>
|
|
In the bitset synopsis (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
|
|
replace the member function <br>
|
|
<br>
|
|
<tt> reference operator[](size_t pos);<br>
|
|
</tt><br>
|
|
with the two member functions<br>
|
|
<br>
|
|
<tt> bool operator[](size_t pos) const; <br>
|
|
reference operator[](size_t pos); <br>
|
|
</tt><br>
|
|
Add the following text at the end of 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
|
|
immediately after paragraph 45:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>bool operator[](size_t pos) const;</tt><br>
|
|
Requires: pos is valid<br>
|
|
Throws: nothing<br>
|
|
Returns: <tt>test(pos)</tt><br>
|
|
<br>
|
|
<tt>bitset<N>::reference operator[](size_t pos);</tt> <br>
|
|
Requires: pos is valid<br>
|
|
Throws: nothing<br>
|
|
Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos]
|
|
== this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos,
|
|
val);</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes Item 3 is not a defect. "Formatted
|
|
input" implies the desired semantics. See 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
|
|
</p>
|
|
<hr>
|
|
<a name="13"><h3>13. Eos refuses to die</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p>
|
|
<p>In 27.6.1.2.3, there is a reference to "eos", which is
|
|
the only one in the whole draft (at least using Acrobat search), so
|
|
it's undefined. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
|
|
"charT()"</p>
|
|
<hr>
|
|
<a name="14"><h3>14. Locale::combine should be const</h3></a><p>
|
|
<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>locale::combine is the only member function of locale (other than constructors and
|
|
destructor) that is not const. There is no reason for it not to be const, and good reasons
|
|
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
|
|
paragraph 6: "An instance of a locale is immutable." </p>
|
|
|
|
<p>History: this member function originally was a constructor. it happened that the
|
|
interface it specified had no corresponding language syntax, so it was changed to a member
|
|
function. As constructors are never const, there was no "const" in the interface
|
|
which was transformed into member "combine". It should have been added at that
|
|
time, but the omission was not noticed. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> and also in 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add
|
|
"const" to the declaration of member combine: </p>
|
|
<blockquote>
|
|
<pre>template <class Facet> locale combine(const locale& other) const; </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p>
|
|
<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>locale::name() is described as returning a string that can be passed to a locale
|
|
constructor, but there is no matching constructor. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
|
|
"<tt>locale(name())</tt>" with
|
|
"<tt>locale(name().c_str())</tt>".
|
|
</p>
|
|
<hr>
|
|
<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p>
|
|
<b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
|
|
edited in properly. Instead, the member do_widen appears four times, with wrong argument
|
|
lists. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>The correct declarations for the overloaded members
|
|
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
|
|
from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
|
|
<hr>
|
|
<a name="17"><h3>17. Bad bool parsing</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>This section describes the process of parsing a text boolean value from the input
|
|
stream. It does not say it recognizes either of the sequences "true" or
|
|
"false" and returns the corresponding bool value; instead, it says it recognizes
|
|
only one of those sequences, and chooses which according to the received value of a
|
|
reference argument intended for returning the result, and reports an error if the other
|
|
sequence is found. (!) Furthermore, it claims to get the names from the ctype<>
|
|
facet rather than the numpunct<> facet, and it examines the "boolalpha"
|
|
flag wrongly; it doesn't define the value "loc"; and finally, it computes
|
|
wrongly whether to use numeric or "alpha" parsing.<br>
|
|
<br>
|
|
I believe the correct algorithm is "as if": </p>
|
|
|
|
<pre> // in, err, val, and str are arguments.
|
|
err = 0;
|
|
const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
|
|
const string_type t = np.truename(), f = np.falsename();
|
|
bool tm = true, fm = true;
|
|
size_t pos = 0;
|
|
while (tm && pos < t.size() || fm && pos < f.size()) {
|
|
if (in == end) { err = str.eofbit; }
|
|
bool matched = false;
|
|
if (tm && pos < t.size()) {
|
|
if (!err && t[pos] == *in) matched = true;
|
|
else tm = false;
|
|
}
|
|
if (fm && pos < f.size()) {
|
|
if (!err && f[pos] == *in) matched = true;
|
|
else fm = false;
|
|
}
|
|
if (matched) { ++in; ++pos; }
|
|
if (pos > t.size()) tm = false;
|
|
if (pos > f.size()) fm = false;
|
|
}
|
|
if (tm == fm || pos == 0) { err |= str.failbit; }
|
|
else { val = tm; }
|
|
return in;</pre>
|
|
|
|
<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
|
|
when one is a substring of the other. The proposed text below captures the logic of the
|
|
code above.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
|
|
change "&&" to "&".</p>
|
|
|
|
<p>Then, replace paragraphs 15 and 16 as follows:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>Otherwise target sequences are determined "as if" by
|
|
calling the members <tt>falsename()</tt> and
|
|
<tt>truename()</tt> of the facet obtained by
|
|
<tt>use_facet<numpunct<charT> >(str.getloc())</tt>.
|
|
Successive characters in the range <tt>[in,end)</tt> (see
|
|
[lib.sequence.reqmts]) are obtained and matched against
|
|
corresponding positions in the target sequences only as necessary to
|
|
identify a unique match. The input iterator <tt>in</tt> is
|
|
compared to <tt>end</tt> only when necessary to obtain a
|
|
character. If and only if a target sequence is uniquely matched,
|
|
<tt>val</tt> is set to the corresponding value.</p>
|
|
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
|
|
successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
|
|
<tt>str.eofbit</tt> if, when seeking another character to match, it is found that
|
|
<tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
|
|
<tt>(str.failbit|str.eofbit)</tt>if
|
|
the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
|
|
<tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
|
|
<tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
|
|
<tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
|
|
<tt>true</tt>:"1"
|
|
and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
|
|
and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
|
|
<tt>err==str.failbit</tt>. --end example]</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the list of num_get<> non-virtual members on page 22-23, the member
|
|
that parses bool values was omitted from the list of definitions of non-virtual
|
|
members, though it is listed in the class definition and the corresponding
|
|
virtual is listed everywhere appropriate. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add at the beginning of 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
|
|
another get member for bool&, copied from the entry in
|
|
22.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
|
|
<hr>
|
|
<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>
|
|
In the definitions of codecvt<>::do_out and do_in, they are
|
|
specified to return noconv if "no conversion is
|
|
needed". This definition is too vague, and does not say
|
|
normatively what is done with the buffers.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the entry for noconv in the table under paragraph 4 in section
|
|
22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
|
|
and input sequence is identical to converted sequence.</p>
|
|
</blockquote>
|
|
<p>Change the Note in paragraph 2 to normative text as follows:</p>
|
|
<blockquote>
|
|
<p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
|
|
same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
|
|
<tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
|
|
unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p>
|
|
<b>Section:</b> 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The synopsis for numpunct<>::do_thousands_sep, and the
|
|
definition of numpunct<>::thousands_sep which calls it, specify
|
|
that it returns a value of type char_type. Here it is erroneously
|
|
described as returning a "string_type". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change
|
|
"string_type" to "char_type". </p>
|
|
<hr>
|
|
<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the second table in the section, captioned "Required
|
|
instantiations", the instantiations for codecvt_byname<>
|
|
have been omitted. These are necessary to allow users to construct a
|
|
locale by name from facets. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add in 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
|
|
"Required instantiations", in the category "ctype"
|
|
the lines </p>
|
|
|
|
<blockquote>
|
|
<pre>codecvt_byname<char,char,mbstate_t>,
|
|
codecvt_byname<wchar_t,char,mbstate_t> </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="22"><h3>22. Member open vs. flags</h3></a><p>
|
|
<b>Section:</b> 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of basic_istream<>::open leaves unanswered questions about how it
|
|
responds to or changes flags in the error status for the stream. A strict reading
|
|
indicates that it ignores the bits and does not change them, which confuses users who do
|
|
not expect eofbit and failbit to remain set after a successful open. There are three
|
|
reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
|
|
and eofbit on call to open(). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>A successful open does not change the error state.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This may seem surprising to some users, but it's just an instance
|
|
of a general rule: error flags are never cleared by the
|
|
implementation. The only way error flags are are ever cleared is if
|
|
the user explicitly clears them by hand.</p>
|
|
|
|
<p>The LWG believed that preserving this general rule was
|
|
important enough so that an exception shouldn't be made just for this
|
|
one case. The resolution of this issue clarifies what the LWG
|
|
believes to have been the original intent.</p>
|
|
|
|
<hr>
|
|
<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of codecvt<>::do_out and do_in mentions a
|
|
symbol "do_convert" which is not defined in the
|
|
standard. This is a leftover from an edit, and should be "do_in
|
|
and do_out". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
|
|
"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
|
|
or do_out". </p>
|
|
<hr>
|
|
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the description of operator<< applied to strings, the standard says that uses
|
|
the smaller of os.width() and str.size(), to pad "as described in stage 3"
|
|
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 4 from:<br>
|
|
<br>
|
|
"... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
|
..."<br>
|
|
<br>
|
|
to: <br>
|
|
<br>
|
|
"... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
|
..."</p>
|
|
<hr>
|
|
<a name="26"><h3>26. Bad sentry example</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In paragraph 6, the code in the example: </p>
|
|
|
|
<pre> template <class charT, class traits = char_traits<charT> >
|
|
basic_istream<charT,traits>::sentry(
|
|
basic_istream<charT,traits>& is, bool noskipws = false) {
|
|
...
|
|
int_type c;
|
|
typedef ctype<charT> ctype_type;
|
|
const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
|
|
while ((c = is.rdbuf()->snextc()) != traits::eof()) {
|
|
if (ctype.is(ctype.space,c)==0) {
|
|
is.rdbuf()->sputbackc (c);
|
|
break;
|
|
}
|
|
}
|
|
...
|
|
}</pre>
|
|
|
|
<p>fails to demonstrate correct use of the facilities described. In
|
|
particular, it fails to use traits operators, and specifies incorrect
|
|
semantics. (E.g. it specifies skipping over the first character in the
|
|
sequence without examining it.) </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the example above from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
|
|
paragraph 6.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The originally proposed replacement code for the example was not
|
|
correct. The LWG tried in Kona and again in Tokyo to correct it
|
|
without success. In Tokyo, an implementor reported that actual working
|
|
code ran over one page in length and was quite complicated. The LWG
|
|
decided that it would be counter-productive to include such a lengthy
|
|
example, which might well still contain errors.</p>
|
|
<hr>
|
|
<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p>
|
|
<b>Section:</b> 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The string::erase(iterator first, iterator last) is specified to return an element one
|
|
place beyond the next element after the last one erased. E.g. for the string
|
|
"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
|
|
while 'd' has not been erased. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
|
|
|
|
<blockquote>
|
|
<p>Returns: an iterator which points to the element immediately following _last_ prior to
|
|
the element being erased. </p>
|
|
</blockquote>
|
|
|
|
<p>to read </p>
|
|
|
|
<blockquote>
|
|
<p>Returns: an iterator which points to the element pointed to by _last_ prior to the
|
|
other elements being erased. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p>
|
|
<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of the vector form of ctype<char>::is can be interpreted to mean
|
|
something very different from what was intended. Paragraph 4 says </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
|
|
table()[(unsigned char)*p]. </p>
|
|
</blockquote>
|
|
|
|
<p>This is intended to copy the value indexed from table()[] into the place identified in
|
|
vec[]. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
|
|
the value table()[(unsigned char)*p]. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p>
|
|
<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Sections 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
|
|
a function ios_base::init, which is not defined. Probably they mean
|
|
basic_ios<>::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
|
|
paragraph 3. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>[R12: modified to include paragraph 5.]</p>
|
|
|
|
<p>In 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p>
|
|
|
|
<blockquote>
|
|
<p>ios_base::init </p>
|
|
</blockquote>
|
|
|
|
<p>to </p>
|
|
|
|
<blockquote>
|
|
<p>basic_ios<char>::init </p>
|
|
</blockquote>
|
|
|
|
<p>Also, make a similar change in 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
|
|
should read </p>
|
|
|
|
<blockquote>
|
|
<p>basic_ios<wchar_t>::init </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="30"><h3>30. Wrong header for LC_*</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
|
|
where they are in fact defined elsewhere to appear in <clocale>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
|
|
"<cctype>" to read "<clocale>". </p>
|
|
<hr>
|
|
<a name="31"><h3>31. Immutable locale values</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
|
|
<i>immutable</i>; once a facet reference is obtained from it,
|
|
...". This has caused some confusion, because locale variables
|
|
are manifestly assignable. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
|
|
|
|
<blockquote>
|
|
<p>An instance of <tt>locale</tt> is immutable; once a facet
|
|
reference is obtained from it, that reference remains usable as long
|
|
as the locale value itself exists.</p>
|
|
</blockquote>
|
|
|
|
<p>with</p>
|
|
|
|
<blockquote>
|
|
<p>Once a facet reference is obtained from a locale object by
|
|
calling use_facet<>, that reference remains usable, and the
|
|
results from member functions of it may be cached and re-used, as
|
|
long as some locale object refers to that facet.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of the required state before calling virtual member
|
|
basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
|
|
described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
|
|
Specifically, the latter says it calls pbackfail if: </p>
|
|
|
|
<p> traits::eq(c,gptr()[-1]) is false </p>
|
|
|
|
<p>where pbackfail claims to require: </p>
|
|
|
|
<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
|
|
|
|
<p>It appears that the pbackfail description is wrong. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
|
|
|
|
<blockquote>
|
|
<p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
|
|
</blockquote>
|
|
|
|
<p>to </p>
|
|
|
|
<blockquote>
|
|
<p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Note deliberate reordering of arguments for clarity in addition to the correction of
|
|
the argument value.</p>
|
|
<hr>
|
|
<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the table defining the results from do_out and do_in, the specification for the
|
|
result <i>error</i> says </p>
|
|
|
|
<blockquote>
|
|
<p>encountered a from_type character it could not convert </p>
|
|
</blockquote>
|
|
|
|
<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
|
|
an internT for do_out. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
|
|
in the table for the case of _error_ with </p>
|
|
|
|
<blockquote>
|
|
<p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p>
|
|
<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
|
|
ctype<charT>, but it has no such members. Note that this is also a problem in
|
|
22.2.2.1.2, addressed in (4). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects:
|
|
clause for member put(...., bool), replace the initialization of the
|
|
string_type value s as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>const numpunct& np = use_facet<numpunct<charT> >(loc);
|
|
string_type s = val ? np.truename() : np.falsename(); </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p>
|
|
<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In 27.4.5.1 <a href="lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
|
|
named "unitbuf". Unlike other manipulators, it's not listed
|
|
in synopsis. Similarly for "nounitbuf". </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the synopsis for <ios> in 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
|
|
the entry for "nouppercase", the prototypes: </p>
|
|
|
|
<blockquote>
|
|
<pre>ios_base& unitbuf(ios_base& str);
|
|
ios_base& nounitbuf(ios_base& str); </pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p>
|
|
<b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
|
|
specified badly, so that an implementation which only keeps the last value stored appears
|
|
to conform. In particular, it says: </p>
|
|
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
|
member with a different index ... </p>
|
|
|
|
<p>This is not idle speculation; at least one implementation was done this way. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in
|
|
paragraph 4, replace the sentence: </p>
|
|
|
|
<blockquote>
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
|
[pword] member with a different index, after a call to its copyfmt member, or when the
|
|
object is destroyed. </p>
|
|
</blockquote>
|
|
|
|
<p>with: </p>
|
|
|
|
<blockquote>
|
|
<p>The reference returned is invalid after any other operations on the object. However,
|
|
the value of the storage referred to is retained, so that until the next call to copyfmt,
|
|
calling iword [pword] with the same index yields another reference to the same value. </p>
|
|
</blockquote>
|
|
|
|
<p>substituting "iword" or "pword" as appropriate. </p>
|
|
<hr>
|
|
<a name="37"><h3>37. Leftover "global" reference</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
|
|
|
|
<blockquote>
|
|
<p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
|
|
the standard exception bad_cast. </p>
|
|
</blockquote>
|
|
|
|
<p>This is not supported by the definition of use_facet<>, and represents semantics
|
|
from an old draft. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
|
|
expression </p>
|
|
|
|
<blockquote>
|
|
<p>(or, failing that, in the global locale) </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="38"><h3>38. Facet definition incomplete</h3></a><p>
|
|
<b>Section:</b> 22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>It has been noticed by Esa Pulkkinen that the definition of
|
|
"facet" is incomplete. In particular, a class derived from
|
|
another facet, but which does not define a member <i>id</i>, cannot
|
|
safely serve as the argument <i>F</i> to use_facet<F>(loc),
|
|
because there is no guarantee that a reference to the facet instance
|
|
stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which
|
|
reads: </p>
|
|
|
|
<blockquote>
|
|
<p>Get a reference to a facet of a locale. </p>
|
|
</blockquote>
|
|
|
|
<p>with: </p>
|
|
|
|
<blockquote>
|
|
<p>Requires: <tt>Facet</tt> is a facet class whose definition
|
|
contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Kona: strike as overspecification the text "(not inherits)"
|
|
from the original resolution, which read "... whose definition
|
|
contains (not inherits) the public static member
|
|
<tt>id</tt>..."
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p>
|
|
<b>Section:</b> 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
|
|
3, the standard contains three lines of garbage text left over from a previous edit. </p>
|
|
|
|
<blockquote>
|
|
<pre>istreambuf_iterator<charT,traits> tmp = *this;
|
|
sbuf_->sbumpc();
|
|
return(tmp); </pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
|
|
end of paragraph 3. </p>
|
|
<hr>
|
|
<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Paragraph 3 of the locale examples is a description of part of an
|
|
implementation technique that has lost its referent, and doesn't mean
|
|
anything. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Delete 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
|
|
initialization/identification system depends...", or (at the
|
|
editor's option) replace it with a place-holder to keep the paragraph
|
|
numbering the same. </p>
|
|
<hr>
|
|
<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
|
|
which may throw an exception". However, ios_base offers no
|
|
interface to set or to test badbit; those interfaces are defined in
|
|
basic_ios<>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the description in 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
|
|
paragraph 2, and also in paragraph 4, as follows. Replace</p>
|
|
|
|
<blockquote>
|
|
<p>If the function fails it sets badbit, which may throw an exception.</p>
|
|
</blockquote>
|
|
|
|
<p>with</p>
|
|
|
|
<blockquote>
|
|
<p>If the function fails, and <tt>*this</tt> is a base sub-object of
|
|
a <tt>basic_ios<></tt> object or sub-object, the effect is
|
|
equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt>
|
|
on the derived object (which may throw <tt>failure</tt>).</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
|
|
setstate(badbit).]</i></p>
|
|
|
|
<hr>
|
|
<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The basic_string<> copy constructor: </p>
|
|
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos, const Allocator& a = Allocator()); </pre>
|
|
|
|
<p>specifies an Allocator argument default value that is
|
|
counter-intuitive. The natural choice for a the allocator to copy from
|
|
is str.get_allocator(). Though this cannot be expressed in
|
|
default-argument notation, overloading suffices. </p>
|
|
|
|
<p>Alternatively, the other containers in Clause 23 (deque, list,
|
|
vector) do not have this form of constructor, so it is inconsistent,
|
|
and an evident source of confusion, for basic_string<> to have
|
|
it, so it might better be removed. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
|
|
constructor as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str);
|
|
basic_string(const basic_string& str, size_type pos, size_type n = npos,
|
|
const Allocator& a = Allocator());</pre>
|
|
</blockquote>
|
|
|
|
<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
|
|
as above. Add to paragraph 5, Effects:</p>
|
|
|
|
<blockquote>
|
|
<p>In the first form, the Allocator value used is copied from
|
|
<tt>str.get_allocator()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes the constructor is actually broken, rather than
|
|
just an unfortunate design choice.</p>
|
|
|
|
<p>The LWG considered two other possible resolutions:</p>
|
|
|
|
<p>A. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
|
|
constructor as follows:</p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos);
|
|
basic_string(const basic_string& str, size_type pos,
|
|
size_type n, const Allocator& a); </pre>
|
|
</blockquote>
|
|
|
|
<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
|
|
as above. Add to paragraph 5, Effects: </p>
|
|
|
|
<blockquote>
|
|
<p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
|
|
value <tt>str.get_allocator()</tt>. </p>
|
|
</blockquote>
|
|
|
|
<p>B. In 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
|
|
the declaration of the copy constructor as follows: </p>
|
|
|
|
<blockquote>
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
|
size_type n = npos); </pre>
|
|
</blockquote>
|
|
|
|
<p>The proposed resolution reflects the original intent of the LWG. It
|
|
was also noted by Pete Becker that this fix "will cause
|
|
a small amount of existing code to now work correctly."</p>
|
|
|
|
<p><i>[
|
|
Kona: issue editing snafu fixed - the proposed resolution now correctly
|
|
reflects the LWG consensus.
|
|
]</i></p>
|
|
<hr>
|
|
<a name="46"><h3>46. Minor Annex D errors</h3></a><p>
|
|
<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
|
|
<p>See lib-6522 and edit-814.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
|
|
basic_streambuf<char>) from:</p>
|
|
|
|
<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
|
|
|
|
<p>In D.7.4 <a href="future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
|
|
int_type:</p>
|
|
|
|
<pre> namespace std {
|
|
class strstream
|
|
: public basic_iostream<char> {
|
|
public:
|
|
// Types
|
|
typedef char char_type;
|
|
typedef typename char_traits<char>::int_type int_type
|
|
typedef typename char_traits<char>::pos_type pos_type;</pre>
|
|
<hr>
|
|
<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p>
|
|
<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
|
|
section has two RETURNS clauses, and they make no sense as
|
|
stated. They make perfect sense, though, if you swap them. Am I
|
|
correct in thinking that paragraphs 2 and 4 just got mixed up by
|
|
accident?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
|
|
<hr>
|
|
<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p>
|
|
<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
|
|
base class, exception, with exception(msg). Class exception (see
|
|
18.6.1) has no such constructor.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
|
|
|
|
<blockquote>
|
|
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p>
|
|
<b>Section:</b> 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>Two problems</p>
|
|
|
|
<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
|
|
returns. Does it return f, or does it return the previous
|
|
synchronization state? My guess is the latter, but the standard
|
|
doesn't say so.</p>
|
|
|
|
<p>(2) 27.4.2.4 doesn't say what it means for streams to be
|
|
synchronized with stdio. Again, of course, I can make some
|
|
guesses. (And I'm unhappy about the performance implications of those
|
|
guesses, but that's another matter.)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the following sentence in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
|
|
returns clause from:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>true</tt> if the standard iostream objects (27.3) are
|
|
synchronized and otherwise returns <tt>false</tt>.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>true</tt> if the previous state of the standard iostream
|
|
objects (27.3) was synchronized and otherwise returns
|
|
<tt>false</tt>.</p>
|
|
</blockquote>
|
|
|
|
<p>Add the following immediately after 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
|
|
paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p>When a standard iostream object str is <i>synchronized</i> with a
|
|
standard stdio stream f, the effect of inserting a character c by</p>
|
|
<pre>
|
|
fputc(f, c);
|
|
</pre>
|
|
|
|
<p>is the same as the effect of</p>
|
|
<pre>
|
|
str.rdbuf()->sputc(c);
|
|
</pre>
|
|
|
|
<p>for any sequence of characters; the effect of extracting a
|
|
character c by</p>
|
|
<pre>
|
|
c = fgetc(f);
|
|
</pre>
|
|
|
|
<p>is the same as the effect of:</p>
|
|
<pre>
|
|
c = str.rdbuf()->sbumpc(c);
|
|
</pre>
|
|
|
|
<p>for any sequences of characters; and the effect of pushing
|
|
back a character c by</p>
|
|
<pre>
|
|
ungetc(c, f);
|
|
</pre>
|
|
|
|
<p>is the same as the effect of</p>
|
|
<pre>
|
|
str.rdbuf()->sputbackc(c);
|
|
</pre>
|
|
|
|
<p>for any sequence of characters. [<i>Footnote</i>: This implies
|
|
that operations on a standard iostream object can be mixed arbitrarily
|
|
with operations on the corresponding stdio stream. In practical
|
|
terms, synchronization usually means that a standard iostream object
|
|
and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
|
|
</blockquote>
|
|
|
|
<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
|
|
of "synchronization"]</i></p>
|
|
|
|
<p><i>[post-Copenhagen: proposed resolution was revised slightly:
|
|
text was added in the non-normative footnote to say that operations
|
|
on the two streams can be mixed arbitrarily.]</i></p>
|
|
<hr>
|
|
<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
|
<p>As written, ios_base has a copy constructor and an assignment
|
|
operator. (Nothing in the standard says it doesn't have one, and all
|
|
classes have copy constructors and assignment operators unless you
|
|
take specific steps to avoid them.) However, nothing in 27.4.2 says
|
|
what the copy constructor and assignment operator do. </p>
|
|
|
|
<p>My guess is that this was an oversight, that ios_base is, like
|
|
basic_ios, not supposed to have a copy constructor or an assignment
|
|
operator.</p>
|
|
|
|
<p>
|
|
Jerry Schwarz comments: Yes, its an oversight, but in the opposite
|
|
sense to what you're suggesting. At one point there was a definite
|
|
intention that you could copy ios_base. It's an easy way to save the
|
|
entire state of a stream for future use. As you note, to carry out
|
|
that intention would have required a explicit description of the
|
|
semantics (e.g. what happens to the iarray and parray stuff).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
|
|
constructor and operator= members as being private.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes the difficulty of specifying correct semantics
|
|
outweighs any benefit of allowing ios_base objects to be copyable.</p>
|
|
<hr>
|
|
<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p>
|
|
<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p>
|
|
<p>The std::sort algorithm can in general only sort a given sequence
|
|
by moving around values. The list<>::sort() member on the other
|
|
hand could move around values or just update internal pointers. Either
|
|
method can leave iterators into the list<> dereferencable, but
|
|
they would point to different things. </p>
|
|
|
|
<p>Does the FDIS mandate anywhere which method should be used for
|
|
list<>::sort()?</p>
|
|
|
|
<p>Matt Austern comments:</p>
|
|
|
|
<p>I think you've found an omission in the standard. </p>
|
|
|
|
<p>The library working group discussed this point, and there was
|
|
supposed to be a general requirement saying that list, set, map,
|
|
multiset, and multimap may not invalidate iterators, or change the
|
|
values that iterators point to, except when an operation does it
|
|
explicitly. So, for example, insert() doesn't invalidate any iterators
|
|
and erase() and remove() only invalidate iterators pointing to the
|
|
elements that are being erased. </p>
|
|
|
|
<p>I looked for that general requirement in the FDIS, and, while I
|
|
found a limited form of it for the sorted associative containers, I
|
|
didn't find it for list. It looks like it just got omitted. </p>
|
|
|
|
<p>The intention, though, is that list<>::sort does not
|
|
invalidate any iterators and does not change the values that any
|
|
iterator points to. There would be no reason to have the member
|
|
function otherwise.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a new paragraph at the end of 23.1:</p>
|
|
|
|
<blockquote>
|
|
<p>Unless otherwise specified (either explicitly or by defining a function in terms of
|
|
other functions), invoking a container member function or passing a container as an
|
|
argument to a library function shall not invalidate iterators to, or change the values of,
|
|
objects within that container. </p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This was US issue CD2-23-011; it was accepted in London but the
|
|
change was not made due to an editing oversight. The wording in the
|
|
proposed resolution below is somewhat updated from CD2-23-011,
|
|
particularly the addition of the phrase "or change the values
|
|
of"</p>
|
|
<hr>
|
|
<a name="52"><h3>52. Small I/O problems</h3></a><p>
|
|
<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
|
<p>First, 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
|
|
it should be titled "basic_ios<>() effects", not
|
|
"ios_base() effects". </p>
|
|
|
|
<p>[The second item is a duplicate; see issue <a href="lwg-closed.html#6">6</a> for
|
|
resolution.]</p>
|
|
|
|
<p>Second, 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
|
|
different things wrong with it, some of which I've already discussed
|
|
with Jerry, but the most obvious mechanical sort of error is that it
|
|
uses expressions like P(i) and p(i), without ever defining what sort
|
|
of thing "i" is.
|
|
</p>
|
|
|
|
<p>(The other problem is that it requires support for streampos
|
|
arithmetic. This is impossible on some systems, i.e. ones where file
|
|
position is a complicated structure rather than just a number. Jerry
|
|
tells me that the intention was to require syntactic support for
|
|
streampos arithmetic, but that it wasn't actually supposed to do
|
|
anything meaningful except on platforms, like Unix, where genuine
|
|
arithmetic is possible.) </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
|
|
"ios_base() effects" to "basic_ios<>()
|
|
effects". </p>
|
|
<hr>
|
|
<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p>
|
|
<b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
|
<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
|
|
The important question is whether basic_ios::~basic_ios() destroys
|
|
rdbuf().</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add after 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>virtual ~basic_ios();</tt></p>
|
|
<p>
|
|
<b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG reviewed the additional question of whether or not
|
|
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
|
|
clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6. This issue was reviewed at length
|
|
by the LWG, which removed from the original proposed resolution a
|
|
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
|
|
<tt>badbit</tt>".</p>
|
|
<hr>
|
|
<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p>
|
|
<b>Section:</b> 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p>
|
|
<p>The class synopsis for basic_streambuf shows a (virtual)
|
|
destructor, but the standard doesn't say what that destructor does. My
|
|
assumption is that it does nothing, but the standard should say so
|
|
explicitly. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add after 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p><tt>virtual ~basic_streambuf();</tt></p>
|
|
<p>
|
|
<b>Effects</b>: None.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p>
|
|
<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p>
|
|
<p>Several member functions in clause 27 are defined in certain
|
|
circumstances to return an "invalid stream position", a term
|
|
that is defined nowhere in the standard. Two places (27.5.2.4.2,
|
|
paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
|
|
a definition in _lib.iostreams.definitions_, a nonexistent
|
|
section. </p>
|
|
|
|
<p>I suspect that the invalid stream position is just supposed to be
|
|
pos_type(-1). Probably best to say explicitly in (for example)
|
|
27.5.2.4.2 that the return value is pos_type(-1), rather than to use
|
|
the term "invalid stream position", define that term
|
|
somewhere, and then put in a cross-reference. </p>
|
|
|
|
<p>The phrase "invalid stream position" appears ten times in
|
|
the C++ Standard. In seven places it refers to a return value, and it
|
|
should be changed. In three places it refers to an argument, and it
|
|
should not be changed. Here are the three places where "invalid
|
|
stream position" should not be changed:</p>
|
|
|
|
<blockquote>
|
|
<p>27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
|
|
27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
|
|
D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
|
|
object of class pos_type that stores an invalid stream position
|
|
(_lib.iostreams.definitions_)" to "Returns
|
|
<tt>pos_type(off_type(-1))</tt>".
|
|
</p>
|
|
|
|
<p>In 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
|
|
an object of class pos_type that stores an invalid stream
|
|
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
|
|
|
|
<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>". </p>
|
|
|
|
<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
|
|
invalid stream position (27.4.3)" to "returns
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
|
|
|
<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
|
|
returns an invalid stream position (_lib.iostreams.definitions_)"
|
|
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
|
|
</p>
|
|
|
|
<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
|
|
|
<p>In D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
|
|
stores an invalid stream position" to "the return value is
|
|
<tt>pos_type(off_type(-1))</tt>"</p>
|
|
<hr>
|
|
<a name="56"><h3>56. Showmanyc's return type</h3></a><p>
|
|
<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p>
|
|
<p>The class summary for basic_streambuf<>, in 27.5.2, says that
|
|
showmanyc has return type int. However, 27.5.2.4.3 says that its
|
|
return type is streamsize. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change <tt>showmanyc</tt>'s return type in the
|
|
27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="57"><h3>57. Mistake in char_traits</h3></a><p>
|
|
<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
|
|
<p>21.1.3.2, paragraph 3, says "The types streampos and
|
|
wstreampos may be different if the implementation supports no shift
|
|
encoding in narrow-oriented iostreams but supports one or more shift
|
|
encodings in wide-oriented streams". </p>
|
|
|
|
<p>That's wrong: the two are the same type. The <iosfwd> summary
|
|
in 27.2 says that streampos and wstreampos are, respectively, synonyms
|
|
for fpos<char_traits<char>::state_type> and
|
|
fpos<char_traits<wchar_t>::state_type>, and, flipping back
|
|
to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
|
|
char_traits<char>::state_type and
|
|
char_traits<wchar_t>::state_type must both be mbstate_t. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the sentence in 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
|
|
begins "The types streampos and wstreampos may be
|
|
different..." . </p>
|
|
<hr>
|
|
<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p>
|
|
<b>Section:</b> 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p>
|
|
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
|
|
next pointer for the input sequence by n." </p>
|
|
|
|
<p>The straightforward interpretation is that it is just gptr() +=
|
|
n. An alternative interpretation, though, is that it behaves as if it
|
|
calls sbumpc n times. (The issue, of course, is whether it might ever
|
|
call underflow.) There is a similar ambiguity in the case of
|
|
pbump. </p>
|
|
|
|
<p>(The "classic" AT&T implementation used the
|
|
former interpretation.)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Advances the next pointer for the input sequence by n.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
|
|
</blockquote>
|
|
|
|
<p>Make the same change to 27.5.2.3.2 <a href="lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
|
|
effects.</p>
|
|
<hr>
|
|
<a name="60"><h3>60. What is a formatted input function?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p>
|
|
<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
|
|
formatted input functions. Some of the functions defined in section
|
|
27.6.1.2 explicitly say that those requirements apply ("Behaves
|
|
like a formatted input member (as described in 27.6.1.2.1)"), but
|
|
others don't. The question: is 27.6.1.2.1 supposed to apply to
|
|
everything in 27.6.1.2, or only to those member functions that
|
|
explicitly say "behaves like a formatted input member"? Or
|
|
to put it differently: are we to assume that everything that appears
|
|
in a section called "Formatted input functions" really is a
|
|
formatted input function? I assume that 27.6.1.2.1 is intended to
|
|
apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
|
|
is not intended to apply to extractors like </p>
|
|
|
|
<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre>
|
|
|
|
<p>and </p>
|
|
|
|
<pre> basic_istream& operator>>(basic_streammbuf*);</pre>
|
|
|
|
<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
|
|
output. </p>
|
|
|
|
<p>Comments from Judy Ward: It seems like the problem is that the
|
|
basic_istream and basic_ostream operator <<()'s that are used
|
|
for the manipulators and streambuf* are in the wrong section and
|
|
should have their own separate section or be modified to make it clear
|
|
that the "Common requirements" listed in section 27.6.1.2.1
|
|
(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
|
|
apply to them. </p>
|
|
|
|
<p>Additional comments from Dietmar Kühl: It appears to be somewhat
|
|
nonsensical to consider the functions defined in 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input
|
|
function" but since these functions are defined in a section
|
|
labeled "Formatted input functions" it is unclear to me
|
|
whether these operators are considered formatted input functions which
|
|
have to conform to the "common requirements" from 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not
|
|
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
|
|
set (... but setting <tt>noskipws</tt> using the manipulator syntax
|
|
would also skip whitespace :-)</p> <p>It is not clear which functions
|
|
are to be considered unformatted input functions. As written, it seems
|
|
that all functions in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
|
|
functions. However, it does not really make much sense to construct a
|
|
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
|
|
unclear what happens to the <tt>gcount()</tt> if
|
|
eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
|
|
<tt>sync()</tt> is called: These functions don't extract characters,
|
|
some of them even "unextract" a character. Should this still
|
|
be reflected in <tt>gcount()</tt>? Of course, it could be read as if
|
|
after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
|
|
(the last unformatted input function, <tt>gcount()</tt>, didn't
|
|
extract any character) and after a call to <tt>putback()</tt>
|
|
<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
|
|
function <tt>putback()</tt> did "extract" back into the
|
|
stream). Correspondingly for <tt>unget()</tt>. Is this what is
|
|
intended? If so, this should be clarified. Otherwise, a corresponding
|
|
clarification should be used.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
|
|
Change the beginning of the second sentence from "The conversion
|
|
occurs" to "These extractors behave as formatted input functions (as
|
|
described in 27.6.1.2.1). After a sentry object is constructed,
|
|
the conversion occurs"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
|
|
Add an effects clause. "Effects: None. This extractor does
|
|
not behave as a formatted input function (as described in
|
|
27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
|
|
first two sentences from "If sb is null, calls setstate(failbit),
|
|
which may throw ios_base::failure (27.4.4.3). Extracts characters
|
|
from *this..." to "Behaves as a formatted input function (as described
|
|
in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
|
|
throw ios_base::failure (27.4.4.3). After a sentry object is
|
|
constructed, extracts characters from *this...".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
|
|
effects clause. "Effects: none. This member function does not behave
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
|
character" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
|
character"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
|
character" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
|
character"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 10, because it refers to paragraph 7.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 15.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
[No change needed in paragraph 23.]
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
|
|
beginning of the first sentence of the effects clause from "Extracts
|
|
characters" to "Behaves as an unformatted input function (as described
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
|
characters"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
|
described in 27.6.1.3, paragraph 1). After constructing a sentry
|
|
object, reads but does not extract the current input character."
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
|
|
first sentence of the Effects clause from "If !good() calls..." to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good()
|
|
calls..." Add a new sentence to the end of the Effects clause:
|
|
"[Note: this function extracts no characters, so the value returned
|
|
by the next call to gcount() is 0.]"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
|
|
first sentence of the Effects clause from "If !good() calls" to
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1). After constructing a sentry object, if !good() calls".
|
|
Add a new sentence to the end of the Effects clause: "[Note: this
|
|
function extracts no characters, so the value returned by the next
|
|
call to gcount() is 0.]"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
|
|
first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if rdbuf() is"
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
|
described in 27.6.1.3, paragraph 1), except that it does not count the
|
|
number of characters extracted and does not affect the value returned
|
|
by subsequent calls to gcount()." Change the first sentence of
|
|
paragraph 37 from "if fail()" to "after constructing a sentry object,
|
|
if fail()".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if fail()
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
|
1), except that it does not count the number of characters extracted
|
|
and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if fail()
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
|
|
the beginning of the third sentence from "The formatting conversion"
|
|
to "These extractors behave as formatted output functions (as
|
|
described in 27.6.2.5.1). After the sentry object is constructed, the
|
|
conversion occurs".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
|
|
effects clause: "Effects: None. Does not behave as a formatted output
|
|
function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
|
|
sentence from "If sb" to "Behaves as a formatted output function (as
|
|
described in 27.6.2.5.1). After the sentry object is constructed, if
|
|
sb".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
|
|
sentence from "Inserts the character" to "Behaves as an unformatted
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
|
constructing a sentry object, inserts the character".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
|
|
sentence from "Obtains characters" to "Behaves as an unformatted
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
|
constructing a sentry object, obtains characters".
|
|
</p>
|
|
|
|
<p>
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
|
|
sentence at the end of the paragraph: "Does not behave as an
|
|
unformatted output function (as described in 27.6.2.6, paragraph 1)."
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
|
|
by Judy Ward and Matt Austern. This proposed resolution is section
|
|
VI of that paper.</p>
|
|
<hr>
|
|
<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The introduction to the section on unformatted input (27.6.1.3)
|
|
says that every unformatted input function catches all exceptions that
|
|
were thrown during input, sets badbit, and then conditionally rethrows
|
|
the exception. That seems clear enough. Several of the specific
|
|
functions, however, such as get() and read(), are documented in some
|
|
circumstances as setting eofbit and/or failbit. (The standard notes,
|
|
correctly, that setting eofbit or failbit can sometimes result in an
|
|
exception being thrown.) The question: if one of these functions
|
|
throws an exception triggered by setting failbit, is this an exception
|
|
"thrown during input" and hence covered by 27.6.1.3, or does
|
|
27.6.1.3 only refer to a limited class of exceptions? Just to make
|
|
this concrete, suppose you have the following snippet. </p>
|
|
|
|
<pre>
|
|
char buffer[N];
|
|
istream is;
|
|
...
|
|
is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
|
|
is.read(buffer, N);</pre>
|
|
|
|
<p>Now suppose we reach EOF before we've read N characters. What
|
|
iostate bits can we expect to be set, and what exception (if any) will
|
|
be thrown? </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.1.3, paragraph 1, after the sentence that begins
|
|
"If an exception is thrown...", add the following
|
|
parenthetical comment: "(Exceptions thrown from
|
|
<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)"
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG looked to two alternative wordings, and choose the proposed
|
|
resolution as better standardese.</p>
|
|
<hr>
|
|
<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
|
|
"calls rdbuf()->pubsync() and, if that function returns -1
|
|
... returns traits::eof()." </p>
|
|
|
|
<p>That looks suspicious, because traits::eof() is of type
|
|
traits::int_type while the return type of sync() is int. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
|
|
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
|
|
</p>
|
|
<hr>
|
|
<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p>
|
|
<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p>
|
|
<p>Clause 27 details an exception-handling policy for formatted input,
|
|
unformatted input, and formatted output. It says nothing for
|
|
unformatted output (27.6.2.6). 27.6.2.6 should either include the same
|
|
kind of exception-handling policy as in the other three places, or
|
|
else it should have a footnote saying that the omission is
|
|
deliberate. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 27.6.2.6, paragraph 1, replace the last sentence ("In any
|
|
case, the unformatted output function ends by destroying the sentry
|
|
object, then returning the value specified for the formatted output
|
|
function.") with the following text:
|
|
</p>
|
|
<blockquote>
|
|
If an exception is thrown during output, then <tt>ios::badbit</tt> is
|
|
turned on [Footnote: without causing an <tt>ios::failure</tt> to be
|
|
thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &
|
|
badbit) != 0</tt> then the exception is rethrown. In any case, the
|
|
unformatted output function ends by destroying the sentry object,
|
|
then, if no exception was thrown, returning the value specified for
|
|
the formatted output function.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
This exception-handling policy is consistent with that of formatted
|
|
input, unformatted input, and formatted output.
|
|
</p>
|
|
<hr>
|
|
<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p>
|
|
<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
|
|
different ways, depending on whether the second sentence is read as an
|
|
elaboration of the first. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
|
|
"If the function inserts no characters ..." with:</p>
|
|
|
|
<blockquote>
|
|
<p>If the function inserts no characters, it calls
|
|
<tt>setstate(failbit)</tt>, which may throw
|
|
<tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
|
|
because it caught an exception thrown while extracting characters
|
|
from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
|
|
(27.4.4.3), then the caught exception is rethrown. </p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p>
|
|
<b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
|
|
<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
|
|
"Performs an operation that is defined separately for each class
|
|
derived from strstreambuf". This is obviously an incorrect
|
|
cut-and-paste from basic_streambuf. There are no classes derived from
|
|
strstreambuf. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
|
|
clause which currently says "Performs an operation that is
|
|
defined separately for each class derived from strstreambuf"
|
|
with:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>Effects</b>: implementation defined, except that
|
|
<tt>setbuf(0,0)</tt> has no effect.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p>
|
|
<p>Extractors for char* (27.6.1.2.3) do not store a null character
|
|
after the extracted character sequence whereas the unformatted
|
|
functions like get() do. Why is this?</p>
|
|
|
|
<p>Comment from Jerry Schwarz: There is apparently an editing
|
|
glitch. You'll notice that the last item of the list of what stops
|
|
extraction doesn't make any sense. It was supposed to be the line that
|
|
said a null is stored.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
|
|
item from:</p>
|
|
|
|
<blockquote>
|
|
A null byte (<tt>charT()</tt>) in the next position, which may be
|
|
the first position if no characters were extracted.
|
|
</blockquote>
|
|
|
|
<p>to become a new paragraph which reads:</p>
|
|
|
|
<blockquote>
|
|
Operator>> then stores a null byte (<tt>charT()</tt>) in the
|
|
next position, which may be the first position if no characters were
|
|
extracted.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p>
|
|
<b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
|
|
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
|
|
|
|
<p>(Please note that this is entirely separate from the question of
|
|
whether a vector iterator is required to be a pointer; the answer to
|
|
that question is clearly "no," as it would rule out
|
|
debugging implementations)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following text to the end of 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a>,
|
|
paragraph 1. </p>
|
|
|
|
<blockquote>
|
|
<p>The elements of a vector are stored contiguously, meaning that if
|
|
v is a <tt>vector<T, Allocator></tt> where T is some type
|
|
other than <tt>bool</tt>, then it obeys the identity <tt>&v[n]
|
|
== &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG feels that as a practical matter the answer is clearly
|
|
"yes". There was considerable discussion as to the best way
|
|
to express the concept of "contiguous", which is not
|
|
directly defined in the standard. Discussion included:</p>
|
|
|
|
<ul>
|
|
<li>An operational definition similar to the above proposed resolution is
|
|
already used for valarray (26.3.2.3 <a href="lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
|
|
<li>There is no need to explicitly consider a user-defined operator&
|
|
because elements must be copyconstructible (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
|
|
and copyconstructible (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
|
|
requirements for operator&.</li>
|
|
<li>There is no issue of one-past-the-end because of language rules.</li>
|
|
</ul>
|
|
<hr>
|
|
<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p>
|
|
<b>Section:</b> 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p>
|
|
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
|
|
|
|
<p>uncaught_exception() doesn't have a throw specification.</p>
|
|
|
|
<p>It is intentional ? Does it means that one should be prepared to
|
|
handle exceptions thrown from uncaught_exception() ?</p>
|
|
|
|
<p>uncaught_exception() is called in exception handling contexts where
|
|
exception safety is very important.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 15.5.3 <a href="except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
|
|
<hr>
|
|
<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p>
|
|
<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
|
|
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
|
|
is described in 22.2.5.1.2 <a href="lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
|
|
consistent with do_get_weekday and with its specified use by member
|
|
get_monthname. However, in the synopsis, it is specified instead with
|
|
four arguments. The missing argument is the "end" iterator
|
|
value.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
|
|
the declaration of member do_monthname as follows:</p>
|
|
|
|
<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
|
|
ios_base::iostate& err, tm* t) const;</pre>
|
|
<hr>
|
|
<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p>
|
|
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
|
|
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
|
|
parentheses and a spurious <b>n</b>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
|
|
following:</p>
|
|
|
|
<blockquote>
|
|
<b>Returns</b>: The maximum value that
|
|
<tt>do_length(state, from, from_end, 1)</tt> can return for any
|
|
valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
|
|
<tt>state</tt>. The specialization <tt>codecvt<char, char,
|
|
mbstate_t>::do_max_length()</tt> returns 1.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt
|
|
Austern <b>Date:</b> 18 Sep 1998</p>
|
|
<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
|
|
and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
|
|
parameter of the member functions <tt>length</tt> and
|
|
<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member
|
|
function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
|
|
paragraph 9) say that the type is <tt>stateT&</tt>. Either the
|
|
synopsis or the summary must be changed. </p>
|
|
|
|
<p>If (as I believe) the member function descriptions are correct,
|
|
then we must also add text saying how <tt>do_length</tt> changes its
|
|
<tt>stateT</tt> argument. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
|
|
change the <tt>stateT</tt> argument type on both member
|
|
<tt>length()</tt> and member <tt>do_length()</tt> from </p>
|
|
|
|
<blockquote>
|
|
<p><tt>const stateT&</tt></p>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<p><tt>stateT&</tt></p>
|
|
</blockquote>
|
|
|
|
<p>In 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
|
|
<tt>do_length</tt> a paragraph:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: The effect on the <tt>state</tt> argument is ``as if''
|
|
it called <tt>do_in(state, from, from_end, from, to, to+max,
|
|
to)</tt> for <tt>to</tt> pointing to a buffer of at least
|
|
<tt>max</tt> elements.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p>
|
|
<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Sep 1998</p>
|
|
<p>This issue concerns the requirements on classes derived from
|
|
<tt>codecvt</tt>, including user-defined classes. What are the
|
|
restrictions on the conversion from external characters
|
|
(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
|
|
Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
|
|
the I/O library make? </p>
|
|
|
|
<p>The question is whether it's possible to convert from internal
|
|
characters to external characters one internal character at a time,
|
|
and whether, given a valid sequence of external characters, it's
|
|
possible to pick off internal characters one at a time. Or, to put it
|
|
differently: given a sequence of external characters and the
|
|
corresponding sequence of internal characters, does a position in the
|
|
internal sequence correspond to some position in the external
|
|
sequence? </p>
|
|
|
|
<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
|
|
sequence of <i>M</i> external characters and that <tt>[ifirst,
|
|
ilast)</tt> is the corresponding sequence of <i>N</i> internal
|
|
characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>,
|
|
applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
|
|
ilast)</tt>. Now the question: does there necessarily exist a
|
|
subsequence of external characters, <tt>[first, last_1)</tt>, such
|
|
that the corresponding sequence of internal characters is the single
|
|
character <tt>*ifirst</tt>?
|
|
</p>
|
|
|
|
<p>(What a "no" answer would mean is that
|
|
<tt>my_encoding</tt> translates sequences only as blocks. There's a
|
|
sequence of <i>M</i> external characters that maps to a sequence of
|
|
<i>N</i> internal characters, but that external sequence has no
|
|
subsequence that maps to <i>N-1</i> internal characters.) </p>
|
|
|
|
<p>Some of the wording in the standard, such as the description of
|
|
<tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
|
|
paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
|
|
possible to pick off internal characters one at a time from a sequence
|
|
of external characters. However, this is never explicitly stated one
|
|
way or the other. </p>
|
|
|
|
<p>This issue seems (and is) quite technical, but it is important if
|
|
we expect users to provide their own encoding facets. This is an area
|
|
where the standard library calls user-supplied code, so a well-defined
|
|
set of requirements for the user-supplied code is crucial. Users must
|
|
be aware of the assumptions that the library makes. This issue affects
|
|
positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
|
|
and several of <tt>codecvt</tt>'s member functions. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
|
|
(27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
|
|
<pre>
|
|
do_out(state, from, from_end, from_next, to, to_lim, to_next)
|
|
</pre>
|
|
would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
|
|
<pre>
|
|
do_out(state, from, from + 1, from_next, to, to_end, to_next)
|
|
</pre>
|
|
must also return <tt>ok</tt>, and that if
|
|
<pre>
|
|
do_in(state, from, from_end, from_next, to, to_lim, to_next)
|
|
</pre>
|
|
would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
|
|
<pre>
|
|
do_in(state, from, from_end, from_next, to, to + 1, to_next)
|
|
</pre>
|
|
<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this
|
|
means that <tt>basic_filebuf</tt> assumes that the mapping from
|
|
internal to external characters is 1 to N: a <tt>codecvt</tt> that is
|
|
used by <tt>basic_filebuf</tt> must be able to translate characters
|
|
one internal character at a time. <i>--End Footnote</i>]</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: Minor change in proposed resolution. Original
|
|
proposed resolution talked about "success", with a parenthetical
|
|
comment that success meant returning <tt>ok</tt>. New wording
|
|
removes all talk about "success", and just talks about the
|
|
return value.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
|
|
<p>The proposed resoluion says that conversions can be performed one
|
|
internal character at a time. This rules out some encodings that
|
|
would otherwise be legal. The alternative answer would mean there
|
|
would be some internal positions that do not correspond to any
|
|
external file position.</p>
|
|
<p>
|
|
An example of an encoding that this rules out is one where the
|
|
<tt>internT</tt> and <tt>externT</tt> are of the same type, and
|
|
where the internal sequence <tt>c1 c2</tt> corresponds to the
|
|
external sequence <tt>c2 c1</tt>.
|
|
</p>
|
|
<p>It was generally agreed that <tt>basic_filebuf</tt> relies
|
|
on this property: it was designed under the assumption that
|
|
the external-to-internal mapping is N-to-1, and it is not clear
|
|
that <tt>basic_filebuf</tt> is implementable without that
|
|
restriction.
|
|
</p>
|
|
<p>
|
|
The proposed resolution is expressed as a restriction on
|
|
<tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
|
|
than a blanket restriction on all <tt>codecvt</tt> facets,
|
|
because <tt>basic_filebuf</tt> is the only other part of the
|
|
library that uses <tt>codecvt</tt>. If a user wants to define
|
|
a <tt>codecvt</tt> facet that implements a more general N-to-M
|
|
mapping, there is no reason to prohibit it, so long as the user
|
|
does not expect <tt>basic_filebuf</tt> to be able to use it.
|
|
</p>
|
|
<hr>
|
|
<a name="78"><h3>78. Typo: event_call_back</h3></a><p>
|
|
<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>typo: event_call_back should be event_callback </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
|
|
"event_call_back" to "event_callback". </p>
|
|
<hr>
|
|
<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p>
|
|
<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
|
|
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
|
|
|
|
<p>In 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p>
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
|
|
|
<p>Thus whether the second parameter is optional is not clear. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
|
|
<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
|
|
|
|
<p>to:</p>
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
|
<hr>
|
|
<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p>
|
|
<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
|
|
class complex. This redundancy should be removed.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Reduce redundancy according to the general style of the standard. </p>
|
|
<hr>
|
|
<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>Many string member functions throw if size is getting or exceeding
|
|
npos. However, I wonder why they don't throw if size is getting or
|
|
exceeding max_size() instead of npos. May be npos is known at compile
|
|
time, while max_size() is known at runtime. However, what happens if
|
|
size exceeds max_size() but not npos, then? It seems the standard
|
|
lacks some clarifications here.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>After 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
|
|
described in this clause...") add a new paragraph:</p>
|
|
|
|
<blockquote>
|
|
<p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
|
|
<tt> max_size()</tt> then
|
|
the operation throws <tt>length_error</tt>.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes length_error is the correct exception to throw.</p>
|
|
<hr>
|
|
<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p>
|
|
<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>The constructor from a range:</p>
|
|
|
|
<pre>template<class InputIterator>
|
|
basic_string(InputIterator begin, InputIterator end,
|
|
const Allocator& a = Allocator());</pre>
|
|
|
|
<p>lacks a throws clause. However, I would expect that it throws
|
|
according to the other constructors if the numbers of characters in
|
|
the range equals npos (or exceeds max_size(), see above). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
|
|
constructors which say "Throws: length_error if n ==
|
|
npos."</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Throws clauses for length_error if n == npos are no longer needed
|
|
because they are subsumed by the general wording added by the
|
|
resolution for issue <a href="lwg-defects.html#83">83</a>.</p>
|
|
<hr>
|
|
<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>The effect of operator >> for strings contain the following item:</p>
|
|
|
|
<p> <tt>isspace(c,getloc())</tt> is true for the next available input
|
|
character c.</p>
|
|
|
|
<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>Set::iterator is described as implementation-defined with a
|
|
reference to the container requirement; the container requirement says
|
|
that const_iterator is an iterator pointing to const T and iterator an
|
|
iterator pointing to T.</p>
|
|
|
|
<p>23.1.2 paragraph 2 implies that the keys should not be modified to
|
|
break the ordering of elements. But that is not clearly
|
|
specified. Especially considering that the current standard requires
|
|
that iterator for associative containers be different from
|
|
const_iterator. Set, for example, has the following: </p>
|
|
|
|
<p><tt>typedef implementation defined iterator;<br>
|
|
// See _lib.container.requirements_</tt></p>
|
|
|
|
<p>23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
|
|
to T (table 65). Disallowing user modification of keys by changing the
|
|
standard to require an iterator for associative container to be the
|
|
same as const_iterator would be overkill since that will unnecessarily
|
|
significantly restrict the usage of associative container. A class to
|
|
be used as elements of set, for example, can no longer be modified
|
|
easily without either redesigning the class (using mutable on fields
|
|
that have nothing to do with ordering), or using const_cast, which
|
|
defeats requiring iterator to be const_iterator. The proposed solution
|
|
goes in line with trusting user knows what he is doing. </p>
|
|
|
|
<p>
|
|
<b>Other Options Evaluated:</b> </p>
|
|
|
|
<p>Option A. In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
|
|
first sentence, and before "In addition,...", add one line:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>Modification of keys shall not change their strict weak ordering. </p>
|
|
</blockquote>
|
|
|
|
<p>Option B. Add three new sentences to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
|
|
|
|
<blockquote>
|
|
<p>At the end of paragraph 5: "Keys in an associative container
|
|
are immutable." At the end of paragraph 6: "For
|
|
associative containers where the value type is the same as the key
|
|
type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
|
|
constant iterators. It is unspecified whether or not
|
|
<tt>iterator</tt> and <tt>const_iterator</tt> are the same
|
|
type."</p>
|
|
</blockquote>
|
|
|
|
<p>Option C. To 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
|
|
currently reads:</p>
|
|
|
|
<blockquote>
|
|
<p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
|
|
comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
|
|
container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
|
|
== false && comp(k2, k1) == false.</p>
|
|
</blockquote>
|
|
|
|
<p> add the following:</p>
|
|
|
|
<blockquote>
|
|
<p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
|
|
value whenever it is evaluated. [Note: If k2 is removed from the container and later
|
|
reinserted, comp(k1, k2) must still return a consistent value but this value may be
|
|
different than it was the first time k1 and k2 were in the same container. This is
|
|
intended to allow usage like a string key that contains a filename, where comp compares
|
|
file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
|
|
reinserted, comp(k1, k2) must again return a consistent value but this value may be
|
|
different than it was the previous time k2 was in the container.]</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following to 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
|
|
the indicated location:</p>
|
|
|
|
<blockquote>
|
|
<p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
|
|
calling comp(k1, k2) shall always return the same
|
|
value."</p>
|
|
<p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
|
|
<p>At the end of paragraph 6: "For associative containers where the value type is the
|
|
same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
|
|
iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
|
|
are the same type."</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Several arguments were advanced for and against allowing set elements to be
|
|
mutable as long as the ordering was not effected. The argument which swayed the
|
|
LWG was one of safety; if elements were mutable, there would be no compile-time
|
|
way to detect of a simple user oversight which caused ordering to be
|
|
modified. There was a report that this had actually happened in practice,
|
|
and had been painful to diagnose. If users need to modify elements,
|
|
it is possible to use mutable members or const_cast.</p>
|
|
|
|
<p>Simply requiring that keys be immutable is not sufficient, because the comparison
|
|
object may indirectly (via pointers) operate on values outside of the keys.</p>
|
|
|
|
<p>
|
|
The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
|
|
to be different types to allow for potential future work in which some
|
|
member functions might be overloaded between the two types. No such
|
|
member functions exist now, and the LWG believes that user functionality
|
|
will not be impaired by permitting the two types to be the same. A
|
|
function that operates on both iterator types can be defined for
|
|
<tt>const_iterator</tt> alone, and can rely on the automatic
|
|
conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
|
|
</p>
|
|
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
|
|
<hr>
|
|
<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p>
|
|
<b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>This is the only place in the whole standard where the implementation has to document
|
|
something private.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Remove the comment which says "// remainder implementation defined" from:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
|
|
</li>
|
|
<li>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
|
|
</li>
|
|
<li>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
|
|
</li>
|
|
<li>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
|
</li>
|
|
</ul>
|
|
<hr>
|
|
<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p>
|
|
<b>Section:</b> 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
|
|
exception::what() is left unspecified. This issue has implications
|
|
with exception safety of exception handling: some exceptions should
|
|
not throw bad_alloc.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
|
|
clause) the sentence:</p>
|
|
|
|
<blockquote>
|
|
<p>The return value remains valid until the exception object from which it is obtained is
|
|
destroyed or a non-const member function of the exception object is called.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>If an exception object has non-const members, they may be used
|
|
to set internal state that should affect the contents of the string
|
|
returned by <tt>what()</tt>.
|
|
</p>
|
|
<hr>
|
|
<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p>
|
|
<b>Section:</b> 20.3.6 <a href="lib-utilities.html#lib.binders"> [lib.binders]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p>
|
|
|
|
<p>There are no versions of binders that apply to non-const elements
|
|
of a sequence. This makes examples like for_each() using bind2nd() on
|
|
page 521 of "The C++ Programming Language (3rd)"
|
|
non-conforming. Suitable versions of the binders need to be added.</p>
|
|
|
|
<p>Further discussion from Nico:</p>
|
|
|
|
<p>What is probably meant here is shown in the following example:</p>
|
|
|
|
<pre>class Elem {
|
|
public:
|
|
void print (int i) const { }
|
|
void modify (int i) { }
|
|
}; </pre>
|
|
<pre>int main()
|
|
{
|
|
vector<Elem> coll(2);
|
|
for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK
|
|
for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR
|
|
}</pre>
|
|
|
|
<p>The error results from the fact that bind2nd() passes its first
|
|
argument (the argument of the sequence) as constant reference. See the
|
|
following typical implementation:</p>
|
|
|
|
<blockquote>
|
|
<pre>template <class Operation>
|
|
class binder2nd
|
|
: public unary_function<typename Operation::first_argument_type,
|
|
typename Operation::result_type> {
|
|
protected:
|
|
Operation op;
|
|
typename Operation::second_argument_type value;
|
|
public:
|
|
binder2nd(const Operation& o,
|
|
const typename Operation::second_argument_type& v)
|
|
: op(o), value(v) {} </pre>
|
|
<pre> typename Operation::result_type
|
|
operator()(const typename Operation::first_argument_type& x) const {
|
|
return op(x, value);
|
|
}
|
|
};</pre>
|
|
</blockquote>
|
|
|
|
<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
|
|
|
|
<blockquote>
|
|
<pre>template <class Operation>
|
|
class binder2nd
|
|
: public unary_function<typename Operation::first_argument_type,
|
|
typename Operation::result_type> {
|
|
protected:
|
|
Operation op;
|
|
typename Operation::second_argument_type value;
|
|
public:
|
|
binder2nd(const Operation& o,
|
|
const typename Operation::second_argument_type& v)
|
|
: op(o), value(v) {} </pre>
|
|
<pre> typename Operation::result_type
|
|
operator()(const typename Operation::first_argument_type& x) const {
|
|
return op(x, value);
|
|
}
|
|
typename Operation::result_type
|
|
operator()(typename Operation::first_argument_type& x) const {
|
|
return op(x, value);
|
|
}
|
|
};</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
<b>Howard believes there is a flaw</b> in this resolution.
|
|
See c++std-lib-9127. We may need to reopen this issue.</p>
|
|
|
|
<p>In 20.3.6.1 <a href="lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
|
|
<blockquote>
|
|
<p><tt>typename Operation::result_type<br>
|
|
operator()(const typename Operation::second_argument_type& x) const;</tt></p>
|
|
</blockquote>
|
|
<p>insert:</p>
|
|
<blockquote>
|
|
<p><tt>typename Operation::result_type<br>
|
|
operator()(typename Operation::second_argument_type& x) const;</tt></p>
|
|
</blockquote>
|
|
<p>In 20.3.6.3 <a href="lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
|
|
<blockquote>
|
|
<p><tt>typename Operation::result_type<br>
|
|
operator()(const typename Operation::first_argument_type& x) const;</tt></p>
|
|
</blockquote>
|
|
<p>insert:</p>
|
|
<blockquote>
|
|
<p><tt>typename Operation::result_type<br>
|
|
operator()(typename Operation::first_argument_type& x) const;</tt></p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG discussed this at some length.It was agreed that
|
|
this is a mistake in the design, but there was no consensus on whether
|
|
it was a defect in the Standard. Straw vote: NAD - 5. Accept
|
|
proposed resolution - 3. Leave open - 6.]</i></p>
|
|
|
|
<p><i>[Copenhagen: It was generally agreed that this was a defect.
|
|
Strap poll: NAD - 0. Accept proposed resolution - 10.
|
|
Leave open - 1.]</i></p>
|
|
|
|
<hr>
|
|
<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p>
|
|
<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
|
|
<p>Member istreambuf_iterator<>::equal is not declared
|
|
"const", yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
|
|
which is const, calls it. This is contradictory. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also in 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
|
|
replace:</p>
|
|
|
|
<blockquote>
|
|
<pre>bool equal(istreambuf_iterator& b);</pre>
|
|
</blockquote>
|
|
|
|
<p>with:</p>
|
|
|
|
<blockquote>
|
|
<pre>bool equal(const istreambuf_iterator& b) const;</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
|
|
<b>Section:</b> 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p>
|
|
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
|
|
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
|
|
reads "<i>s</i> is not null". However, <i>s</i> is a
|
|
reference, and references can't be null. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
|
|
|
|
<p>Move the current paragraph 1, which reads "Requires: s is not
|
|
null.", from the first constructor to the second constructor.</p>
|
|
|
|
<p>Insert a new paragraph 1 Requires clause for the first constructor
|
|
reading:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="114"><h3>114. Placement forms example in error twice</h3></a><p>
|
|
<b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
|
|
<p>Section 18.4.1.3 contains the following example: </p>
|
|
|
|
<pre>[Example: This can be useful for constructing an object at a known address:
|
|
char place[sizeof(Something)];
|
|
Something* p = new (place) Something();
|
|
-end example]</pre>
|
|
|
|
<p>First code line: "place" need not have any special alignment, and the
|
|
following constructor could fail due to misaligned data.</p>
|
|
|
|
<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG
|
|
believes the () are correct.]</p>
|
|
|
|
<p>Examples are not normative, but nevertheless should not show code that is invalid or
|
|
likely to fail.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the <u> first line of code</u> in the example in
|
|
18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<pre>void* place = operator new(sizeof(Something));</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="115"><h3>115. Typo in strstream constructors</h3></a><p>
|
|
<b>Section:</b> D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p>
|
|
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Constructs an object of class strstream, initializing the base class with
|
|
iostream(& sb) and initializing sb with one of the two constructors: </p>
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
|
elements. The constructor is strstreambuf(s, n, s). </p>
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
|
elements that contains an NTBS whose first element is designated by s. The constructor is
|
|
strstreambuf(s, n, s+std::strlen(s)).</p>
|
|
</blockquote>
|
|
|
|
<p>Notice the second condition is the same as the first. I think the second condition
|
|
should be "If mode&app==app", or "mode&app!=0", meaning that
|
|
the append bit is set.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.7.3.1 <a href="future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
|
|
paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
|
|
and the second condition to <tt>(mode&app)!=0</tt>.</p>
|
|
<hr>
|
|
<a name="117"><h3>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p>
|
|
<b>Section:</b> 27.6.2.5.2 <a href="lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
|
|
<p>The <b>effects</b> clause for numeric inserters says that
|
|
insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
|
|
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
|
|
int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
|
|
<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
|
|
delegated to <tt>num_put</tt>, and that insertion is performed as if
|
|
through the following code fragment: </p>
|
|
|
|
<pre>bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(), val). failed();</pre>
|
|
|
|
<p>This doesn't work, because <tt>num_put<></tt>::put is only
|
|
overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
|
|
long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
|
|
void*</tt>. That is, the code fragment in the standard is incorrect
|
|
(it is diagnosed as ambiguous at compile time) for the types
|
|
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
|
|
int</tt>, and <tt>float</tt>. </p>
|
|
|
|
<p>We must either add new member functions to <tt>num_put</tt>, or
|
|
else change the description in <tt>ostream</tt> so that it only calls
|
|
functions that are actually there. I prefer the latter. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
The classes num_get<> and num_put<> handle locale­dependent numeric
|
|
formatting and parsing. These inserter functions use the imbued
|
|
locale value to perform numeric formatting. When val is of type bool,
|
|
long, unsigned long, double, long double, or const void*, the
|
|
formatting conversion occurs as if it performed the following code
|
|
fragment:
|
|
</p>
|
|
|
|
<pre>
|
|
bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(), val). failed();
|
|
</pre>
|
|
|
|
<p>
|
|
When val is of type short the formatting conversion occurs as if it
|
|
performed the following code fragment:
|
|
</p>
|
|
|
|
<pre>
|
|
ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
|
|
bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(),
|
|
baseflags == ios_base::oct || baseflags == ios_base::hex
|
|
? static_cast<long>(static_cast<unsigned short>(val))
|
|
: static_cast<long>(val)). failed();
|
|
</pre>
|
|
|
|
<p>
|
|
When val is of type int the formatting conversion occurs as if it performed
|
|
the following code fragment:
|
|
</p>
|
|
|
|
<pre>
|
|
ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
|
|
bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(),
|
|
baseflags == ios_base::oct || baseflags == ios_base::hex
|
|
? static_cast<long>(static_cast<unsigned int>(val))
|
|
: static_cast<long>(val)). failed();
|
|
</pre>
|
|
|
|
<p>
|
|
When val is of type unsigned short or unsigned int the formatting conversion
|
|
occurs as if it performed the following code fragment:
|
|
</p>
|
|
|
|
<pre>
|
|
bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
|
|
failed();
|
|
</pre>
|
|
|
|
<p>
|
|
When val is of type float the formatting conversion occurs as if it
|
|
performed the following code fragment:
|
|
</p>
|
|
|
|
<pre>
|
|
bool failed = use_facet<
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
|
>(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
|
|
failed();
|
|
</pre>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[post-Toronto: This differs from the previous proposed
|
|
resolution; PJP provided the new wording. The differences are in
|
|
signed short and int output.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The original proposed resolution was to cast int and short to long,
|
|
unsigned int and unsigned short to unsigned long, and float to double,
|
|
thus ensuring that we don't try to use nonexistent num_put<>
|
|
member functions. The current proposed resolution is more
|
|
complicated, but gives more expected results for hex and octal output
|
|
of signed short and signed int. (On a system with 16-bit short, for
|
|
example, printing short(-1) in hex format should yield 0xffff.)</p>
|
|
<hr>
|
|
<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
|
|
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
|
|
<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
|
|
<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
|
|
formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
|
|
|
|
<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, val);
|
|
setstate(err);</pre>
|
|
|
|
<p>According to section 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
|
|
<tt>num_get<>::get()</tt> is only overloaded for the types
|
|
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
|
|
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
|
|
<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
|
|
<tt>void*</tt>. Comparing the lists from the two sections, we find
|
|
that 27.6.1.2.2 is using a nonexistent function for types
|
|
<tt>short</tt> and <tt>int</tt>. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
|
|
two lines (1st and 3rd) which read:</p>
|
|
<blockquote>
|
|
<pre>operator>>(short& val);
|
|
...
|
|
operator>>(int& val);</pre>
|
|
</blockquote>
|
|
|
|
<p>And add the following at the end of that section (27.6.1.2.2) :</p>
|
|
|
|
<blockquote>
|
|
<pre>operator>>(short& val);</pre>
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
|
the same notation as for the preceding code fragment):</p>
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
long lval;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
|
if (err == 0
|
|
&& (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
|
|
err = ios_base::failbit;
|
|
setstate(err);</pre>
|
|
<pre>operator>>(int& val);</pre>
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
|
the same notation as for the preceding code fragment):</p>
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
|
iostate err = 0;
|
|
long lval;
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
|
if (err == 0
|
|
&& (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
|
|
err = ios_base::failbit;
|
|
setstate(err);</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
|
|
<hr>
|
|
<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
|
|
<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
|
|
|
|
<p>"An implementation may strengthen the exception-specification
|
|
for a function by removing listed exceptions." </p>
|
|
|
|
<p>The problem is that if an implementation is allowed to do this for
|
|
virtual functions, then a library user cannot write a class that
|
|
portably derives from that class. </p>
|
|
|
|
<p>For example, this would not compile if ios_base::failure::~failure
|
|
had an empty exception specification: </p>
|
|
|
|
<pre>#include <ios>
|
|
#include <string>
|
|
|
|
class D : public std::ios_base::failure {
|
|
public:
|
|
D(const std::string&);
|
|
~D(); // error - exception specification must be compatible with
|
|
// overridden virtual function ios_base::failure::~failure()
|
|
};</pre>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p>
|
|
|
|
<p> "may strengthen the
|
|
exception-specification for a function"</p>
|
|
|
|
<p>to:</p>
|
|
|
|
<p> "may strengthen the
|
|
exception-specification for a non-virtual function". </p>
|
|
<hr>
|
|
<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p>
|
|
<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Section 27.5.2 describes the streambuf classes this way: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>The class streambuf is a specialization of the template class basic_streambuf
|
|
specialized for the type char. </p>
|
|
|
|
<p>The class wstreambuf is a specialization of the template class basic_streambuf
|
|
specialized for the type wchar_t. </p>
|
|
|
|
</blockquote>
|
|
|
|
<p>This implies that these classes must be template specializations, not typedefs. </p>
|
|
|
|
<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
|
|
sentences). </p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The <tt>streambuf</tt> synopsis already has a declaration for the
|
|
typedefs and that is sufficient. </p>
|
|
<hr>
|
|
<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p>
|
|
<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
|
|
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
|
|
to return a const char* not a const charT*. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
|
|
<tt>do_scan_not()</tt> to return a <tt> const
|
|
charT*</tt>. </p>
|
|
<hr>
|
|
<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p>
|
|
<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
|
|
declared to return a valarray<T>, but in Section 26.3.2.5 <a href="lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The
|
|
latter appears to be correct. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change in Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
|
|
<tt>operator!()</tt> so that the return type is
|
|
<tt>valarray<bool></tt>. </p>
|
|
<hr>
|
|
<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p>
|
|
<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
<p>Typos in 22.2.1.1.2 need to be fixed.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
|
|
|
|
<pre> do_widen(do_narrow(c),0) == c</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> do_widen(do_narrow(c,0)) == c</pre>
|
|
|
|
<p>and change:</p>
|
|
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
|
|
<hr>
|
|
<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p>
|
|
<b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p>
|
|
<p>There are two problems with the current <tt>auto_ptr</tt> wording
|
|
in the standard: </p>
|
|
|
|
<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
|
|
because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to
|
|
<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by
|
|
Nathan Myers, with the same proposed resolution.</i>
|
|
</p>
|
|
|
|
<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
|
|
<tt>auto_ptr_ref</tt> argument. </p>
|
|
|
|
<p>I have discussed these problems with my proposal coauthor, Bill
|
|
Gibbons, and with some compiler and library implementors, and we
|
|
believe that these problems are not desired or desirable implications
|
|
of the standard. </p>
|
|
|
|
<p>25 Aug 1999: The proposed resolution now reflects changes suggested
|
|
by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
|
|
"assignment operator" to "public assignment
|
|
operator", 2) changed effects to specify use of release(), 3)
|
|
made the conversion to auto_ptr_ref const. </p>
|
|
|
|
<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
|
|
states that the conversion from auto_ptr to auto_ptr_ref should
|
|
be const. This is not acceptable, because it would allow
|
|
initialization and assignment from _any_ const auto_ptr! It also
|
|
introduces an implementation difficulty in writing this conversion
|
|
function -- namely, somewhere along the line, a const_cast will be
|
|
necessary to remove that const so that release() may be called. This
|
|
may result in undefined behavior [7.1.5.1/4]. The conversion
|
|
operator does not have to be const, because a non-const implicit
|
|
object parameter may be bound to an rvalue [13.3.3.1.4/3]
|
|
[13.3.1/5]. </p>
|
|
|
|
<p>Tokyo: The LWG removed the following from the proposed resolution:</p>
|
|
|
|
<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
|
|
paragraph 2, make the conversion to auto_ptr_ref const:</p>
|
|
<blockquote>
|
|
<pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
|
|
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
|
|
|
|
<p>In 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
|
|
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
|
|
|
|
<blockquote>
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
|
|
</blockquote>
|
|
|
|
<p>Also add the assignment operator to 20.4.5.3 <a href="lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
|
|
|
|
<blockquote>
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
|
|
|
|
<b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
|
|
p</tt> that <tt>r</tt> holds a reference to.<br>
|
|
<b>Returns: </b><tt>*this</tt>.
|
|
|
|
</blockquote>
|
|
<hr>
|
|
<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
|
|
<p>Currently, the standard does not specify how seekg() and seekp()
|
|
indicate failure. They are not required to set failbit, and they can't
|
|
return an error indication because they must return *this, i.e. the
|
|
stream. Hence, it is undefined what happens if they fail. And they
|
|
<i>can</i> fail, for instance, when a file stream is disconnected from the
|
|
underlying file (is_open()==false) or when a wide character file
|
|
stream must perform a state-dependent code conversion, etc. </p>
|
|
|
|
<p>The stream functions seekg() and seekp() should set failbit in the
|
|
stream state in case of failure.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the Effects: clause of seekg() in
|
|
27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
|
|
27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
|
|
|
|
<blockquote>
|
|
<p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Setting failbit is the usual error reporting mechanism for streams</p>
|
|
<hr>
|
|
<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p>
|
|
<b>Section:</b> 23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The description reads:</p>
|
|
|
|
<p>-1- Effects:</p>
|
|
|
|
<pre> if (sz > size())
|
|
insert(end(), sz-size(), c);
|
|
else if (sz < size())
|
|
erase(begin()+sz, end());
|
|
else
|
|
; // do nothing</pre>
|
|
|
|
<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 23.2.2.2 paragraph 1 to:</p>
|
|
|
|
<p>Effects:</p>
|
|
|
|
<pre> if (sz > size())
|
|
insert(end(), sz-size(), c);
|
|
else if (sz < size())
|
|
{
|
|
iterator i = begin();
|
|
advance(i, sz);
|
|
erase(i, end());
|
|
}</pre>
|
|
|
|
<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
|
|
with David Abrahams. They had a discussion and believe there is
|
|
no issue of exception safety with the proposed resolution.]</i></p>
|
|
<hr>
|
|
<a name="133"><h3>133. map missing get_allocator()</h3></a><p>
|
|
<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The title says it all.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
|
|
after operator= in the map declaration:</p>
|
|
|
|
<pre> allocator_type get_allocator() const;</pre>
|
|
<hr>
|
|
<a name="134"><h3>134. vector constructors over specified</h3></a><p>
|
|
<b>Section:</b> 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>The complexity description says: "It does at most 2N calls to the copy constructor
|
|
of T and logN reallocations if they are just input iterators ...".</p>
|
|
|
|
<p>This appears to be overly restrictive, dictating the precise memory/performance
|
|
tradeoff for the implementor.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
|
|
|
|
<p>-1- Complexity: The constructor template <class
|
|
InputIterator> vector(InputIterator first, InputIterator last)
|
|
makes only N calls to the copy constructor of T (where N is the
|
|
distance between first and last) and no reallocations if iterators
|
|
first and last are of forward, bidirectional, or random access
|
|
categories. It makes order N calls to the copy constructor of T and
|
|
order logN reallocations if they are just input iterators.
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>"at most 2N calls" is correct only if the growth factor
|
|
is greater than or equal to 2.
|
|
</p>
|
|
<hr>
|
|
<a name="136"><h3>136. seekp, seekg setting wrong streams?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
|
<p>I may be misunderstanding the intent, but should not seekg set only
|
|
the input stream and seekp set only the output stream? The description
|
|
seems to say that each should set both input and output streams. If
|
|
that's really the intent, I withdraw this proposal.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In section 27.6.1.3 change:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre>
|
|
|
|
<p>In section 27.6.1.3 change:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre>
|
|
|
|
<p>In section 27.6.2.4, paragraph 2 change:</p>
|
|
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre>
|
|
|
|
<p>In section 27.6.2.4, paragraph 4 change:</p>
|
|
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
|
|
|
<p>To:</p>
|
|
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre>
|
|
|
|
<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
|
|
like the opinion of more iostream experts before taking action.]</i></p>
|
|
|
|
<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
|
|
incorrect, his implementation already implements the Proposed
|
|
Resolution.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Matt Austern comments:<br>
|
|
Is it a problem with basic_istream and basic_ostream, or is it a problem
|
|
with basic_stringbuf?
|
|
We could resolve the issue either by changing basic_istream and
|
|
basic_ostream, or by changing basic_stringbuf. I prefer the latter
|
|
change (or maybe both changes): I don't see any reason for the standard to
|
|
require that std::stringbuf s(std::string("foo"), std::ios_base::in);
|
|
s.pubseekoff(0, std::ios_base::beg); must fail.<br>
|
|
This requirement is a bit weird. There's no similar requirement
|
|
for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or
|
|
basic_filebuf<>::seekpos.]</i></p>
|
|
<hr>
|
|
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
|
|
<p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
|
|
|
|
<p>-4- In the call to use_facet<Facet>(loc), the type argument
|
|
chooses a facet, making available all members of the named type. If
|
|
Facet is not present in a locale (or, failing that, in the global
|
|
locale), it throws the standard exception bad_cast. A C++ program can
|
|
check if a locale implements a particular facet with the template
|
|
function has_facet<Facet>(). </p>
|
|
|
|
<p>This contradicts the specification given in section
|
|
22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
|
|
<br><br>
|
|
template <class Facet> const Facet& use_facet(const
|
|
locale& loc); <br>
|
|
<br>
|
|
-1- Get a reference to a facet of a locale. <br>
|
|
-2- Returns: a reference to the corresponding facet of loc, if present. <br>
|
|
-3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br>
|
|
-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the phrase "(or, failing that, in the global locale)"
|
|
from section 22.1.1. </p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Needed for consistency with the way locales are handled elsewhere
|
|
in the standard.</p>
|
|
<hr>
|
|
<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p>
|
|
<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p>
|
|
<p>The sentence introducing the Optional sequence operation table
|
|
(23.1.1 paragraph 12) has two problems:</p>
|
|
|
|
<p>A. It says ``The operations in table 68 are provided only for the containers for which
|
|
they take constant time.''<br>
|
|
<br>
|
|
That could be interpreted in two ways, one of them being ``Even though table 68 shows
|
|
particular operations as being provided, implementations are free to omit them if they
|
|
cannot implement them in constant time.''<br>
|
|
<br>
|
|
B. That paragraph says nothing about amortized constant time, and it should. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..."
|
|
with:</p>
|
|
|
|
<blockquote>
|
|
<p>Table 68 lists sequence operations that are provided for some types of sequential
|
|
containers but not others. An implementation shall provide these operations for all
|
|
container types shown in the ``container'' column, and shall implement them so as to take
|
|
amortized constant time.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
|
|
<b>Section:</b> 21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p>
|
|
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
|
|
say:<br>
|
|
<br>
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();</tt>
|
|
</p>
|
|
|
|
<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p>
|
|
|
|
<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
|
|
proposed resolution.]</i></p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
|
|
<br>
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();<br>
|
|
<br>
|
|
</tt>to:<br>
|
|
<tt><br>
|
|
</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p>
|
|
<b>Section:</b> 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
|
|
<p>The lexicographical_compare complexity is specified as:<br>
|
|
<br>
|
|
"At most min((last1 - first1), (last2 - first2))
|
|
applications of the corresponding comparison."<br>
|
|
<br>
|
|
The best I can do is twice that expensive.</p>
|
|
|
|
<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
|
|
equality you have to check both < and >? Yes, IMO you are
|
|
right! (and Matt states this complexity in his book)</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
|
|
<blockquote>
|
|
At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
|
|
applications of the corresponding comparison.
|
|
</blockquote>
|
|
|
|
<p>Change the example at the end of paragraph 3 to read:</p>
|
|
<blockquote>
|
|
[Example:<br>
|
|
<br>
|
|
for ( ; first1 != last1 && first2 != last2 ;
|
|
++first1, ++first2) {<br>
|
|
if (*first1 < *first2) return true;<br>
|
|
if (*first2 < *first1) return false;<br>
|
|
}<br>
|
|
return first1 == last1 && first2 != last2;<br>
|
|
<br>
|
|
--end example]
|
|
</blockquote>
|
|
<hr>
|
|
<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p>
|
|
<b>Section:</b> 23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p>
|
|
<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
|
|
to have complexity requirements which are incorrect, and which contradict the
|
|
complexity requirements for insert(). I suspect that the text in question,
|
|
below, was taken from vector:</p>
|
|
<blockquote>
|
|
<p>Complexity: If the iterators first and last are forward iterators,
|
|
bidirectional iterators, or random access iterators the constructor makes only
|
|
N calls to the copy constructor, and performs no reallocations, where N is
|
|
last - first.</p>
|
|
</blockquote>
|
|
<p>The word "reallocations" does not really apply to deque. Further,
|
|
all of the following appears to be spurious:</p>
|
|
<blockquote>
|
|
<p>It makes at most 2N calls to the copy constructor of T and log N
|
|
reallocations if they are input iterators.1)</p>
|
|
<p>1) The complexity is greater in the case of input iterators because each
|
|
element must be added individually: it is impossible to determine the distance
|
|
between first abd last before doing the copying.</p>
|
|
</blockquote>
|
|
<p>This makes perfect sense for vector, but not for deque. Why should deque gain
|
|
an efficiency advantage from knowing in advance the number of elements to
|
|
insert?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
|
|
footnote, with the following text (which also corrects the "abd"
|
|
typo):</p>
|
|
<blockquote>
|
|
<p>Complexity: Makes last - first calls to the copy constructor of T.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p>
|
|
<b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
|
|
<p>The <u> extractor</u> for complex numbers is specified as: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p> template<class T, class charT, class traits> <br>
|
|
basic_istream<charT, traits>& <br>
|
|
operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br>
|
|
<br>
|
|
Effects: Extracts a complex number x of the form: u, (u), or (u,v),
|
|
where u is the real part and v is the imaginary part
|
|
(lib.istream.formatted). <br>
|
|
Requires: The input values be convertible to T. If bad input is
|
|
encountered, calls is.setstate(ios::failbit) (which may throw
|
|
ios::failure (lib.iostate.flags). <br>
|
|
Returns: is .</p>
|
|
|
|
</blockquote>
|
|
<p>Is it intended that the extractor for complex numbers does not skip
|
|
whitespace, unlike all other extractors in the standard library do?
|
|
Shouldn't a sentry be used? <br>
|
|
<br>
|
|
The <u>inserter</u> for complex numbers is specified as:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p> template<class T, class charT, class traits> <br>
|
|
basic_ostream<charT, traits>& <br>
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br>
|
|
<br>
|
|
Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
|
|
<br>
|
|
template<class T, class charT, class traits> <br>
|
|
basic_ostream<charT, traits>& <br>
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br>
|
|
{ <br>
|
|
basic_ostringstream<charT, traits> s; <br>
|
|
s.flags(o.flags()); <br>
|
|
s.imbue(o.getloc()); <br>
|
|
s.precision(o.precision()); <br>
|
|
s << '(' << x.real() << "," << x.imag() << ')'; <br>
|
|
return o << s.str(); <br>
|
|
}</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>Is it intended that the inserter for complex numbers ignores the
|
|
field width and does not do any padding? If, with the suggested
|
|
implementation above, the field width were set in the stream then the
|
|
opening parentheses would be adjusted, but the rest not, because the
|
|
field width is reset to zero after each insertion.</p>
|
|
|
|
<p>I think that both operations should use sentries, for sake of
|
|
consistency with the other inserters and extractors in the
|
|
library. Regarding the issue of padding in the inserter, I don't know
|
|
what the intent was. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>After 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a
|
|
Notes clause:</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>Notes: This extraction is performed as a series of simpler
|
|
extractions. Therefore, the skipping of whitespace is specified to be the
|
|
same for each of the simpler extractions.</p>
|
|
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>For extractors, the note is added to make it clear that skipping whitespace
|
|
follows an "all-or-none" rule.</p>
|
|
|
|
<p>For inserters, the LWG believes there is no defect; the standard is correct
|
|
as written.</p>
|
|
<hr>
|
|
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p>
|
|
<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
|
<p>The library had many global functions until 17.4.1.1 [lib.contents]
|
|
paragraph 2 was added: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>All library entities except macros, operator new and operator
|
|
delete are defined within the namespace std or namespaces nested
|
|
within namespace std. </p>
|
|
|
|
</blockquote>
|
|
|
|
<p>It appears "global function" was never updated in the following: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>17.4.4.3 - Global functions [lib.global.functions]<br>
|
|
<br>
|
|
-1- It is unspecified whether any global functions in the C++ Standard
|
|
Library are defined as inline (dcl.fct.spec).<br>
|
|
<br>
|
|
-2- A call to a global function signature described in Clauses
|
|
lib.language.support through lib.input.output behaves the same as if
|
|
the implementation declares no additional global function
|
|
signatures.*<br>
|
|
<br>
|
|
[Footnote: A valid C++ program always calls the expected library
|
|
global function. An implementation may also define additional
|
|
global functions that would otherwise not be called by a valid C++
|
|
program. --- end footnote]<br>
|
|
<br>
|
|
-3- A global function cannot be declared by the implementation as
|
|
taking additional default arguments. <br>
|
|
<br>
|
|
17.4.4.4 - Member functions [lib.member.functions]<br>
|
|
<br>
|
|
-2- An implementation can declare additional non-virtual member
|
|
function signatures within a class: </p>
|
|
|
|
<blockquote>
|
|
|
|
<p>-- by adding arguments with default values to a member function
|
|
signature; The same latitude does not extend to the implementation of
|
|
virtual or global functions, however. </p>
|
|
|
|
</blockquote>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> Change "global" to "global or non-member" in:</p>
|
|
<blockquote>
|
|
<p>17.4.4.3 [lib.global.functions] section title,<br>
|
|
17.4.4.3 [lib.global.functions] para 1,<br>
|
|
17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
|
|
places in the footnote,<br>
|
|
17.4.4.3 [lib.global.functions] para 3,<br>
|
|
17.4.4.4 [lib.member.functions] para 2</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Because operator new and delete are global, the proposed resolution
|
|
was changed from "non-member" to "global or non-member.
|
|
</p>
|
|
<hr>
|
|
<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
|
|
<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
|
|
do_falsename() functions in the example facet BoolNames should be
|
|
const. The functions they are overriding in
|
|
numpunct_byname<char> are const. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
|
|
two places:</p>
|
|
<blockquote>
|
|
<p><tt>string do_truename() const { return "Oui Oui!"; }<br>
|
|
string do_falsename() const { return "Mais Non!"; }</tt></p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p>
|
|
<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
|
|
|
|
<blockquote>
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
|
that for some <u>integer</u> j in the range [first2, last2) ...</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
|
that for some iterator j in the range [first2, last2) ...</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p>
|
|
<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p>
|
|
<p>For both sequences and associative containers, a.clear() has the
|
|
semantics of erase(a.begin(),a.end()), which is undefined for an empty
|
|
container since erase(q1,q2) requires that q1 be dereferenceable
|
|
(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
|
|
not dereferenceable.<br>
|
|
<br>
|
|
The requirement that q1 be unconditionally dereferenceable causes many
|
|
operations to be intuitively undefined, of which clearing an empty
|
|
container is probably the most dire.<br>
|
|
<br>
|
|
Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
|
|
q2) is required to be a valid range, stating that q1 and q2 must be
|
|
iterators or certain kinds of iterators is unnecessary.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.1.1, paragraph 3, change:</p>
|
|
<blockquote>
|
|
<p>p and q2 denote valid iterators to a, q <u> and q1</u> denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
|
|
in a</u>
|
|
</p>
|
|
</blockquote>
|
|
<p>In 23.1.2, paragraph 7, change:</p>
|
|
<blockquote>
|
|
<p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
|
|
iterators to a, [q1, q2) is a valid range</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
|
|
<u>into a</u>
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p>
|
|
<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
|
|
because there is no function <tt>is()</tt> which only takes a character as
|
|
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
|
|
vague.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns
|
|
clause from:</p>
|
|
<blockquote>
|
|
<p>"... such that <tt>is(*p)</tt>
|
|
would..."</p>
|
|
</blockquote>
|
|
<p>to: "... such that <tt>is(m, *p)</tt>
|
|
would...."</p>
|
|
<hr>
|
|
<a name="153"><h3>153. Typo in <tt>narrow()</tt> semantics</h3></a><p>
|
|
<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The description of the array version of <tt>narrow()</tt> (in
|
|
paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
|
|
takes only three arguments because in addition to the range a default
|
|
character is needed.</p>
|
|
|
|
<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
|
|
two signatures followed by a <b>Returns</b> clause that only addresses
|
|
one of them.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the returns clause in 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
|
|
paragraph 10 from:</p>
|
|
<p> Returns: do_widen(low, high, to).</p>
|
|
|
|
<p>to:</p>
|
|
<p> Returns: do_widen(c) or do_widen(low, high, to),
|
|
respectively.</p>
|
|
|
|
<p>Change 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p>
|
|
<pre> char narrow(char c, char /*dfault*/) const;
|
|
const char* narrow(const char* low, const char* high,
|
|
char /*dfault*/, char* to) const;</pre>
|
|
<pre> Returns: do_narrow(low, high, to).</pre>
|
|
<p>to:</p>
|
|
<pre> char narrow(char c, char dfault) const;
|
|
const char* narrow(const char* low, const char* high,
|
|
char dfault, char* to) const;</pre>
|
|
<pre> Returns: do_narrow(c, dfault) or
|
|
do_narrow(low, high, dfault, to), respectively.</pre>
|
|
|
|
<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
|
|
defined version could be different.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
|
|
the LWG. He could find no other places the problem occurred. He
|
|
asks for clarification of the Kona "a user defined
|
|
version..." comment above. Perhaps it was a circuitous way of
|
|
saying "dfault" needed to be uncommented?]</i></p>
|
|
|
|
<p><i>[Post-Toronto: the issues list maintainer has merged in the
|
|
proposed resolution from issue <a href="lwg-closed.html#207">207</a>, which addresses the
|
|
same paragraphs.]</i></p>
|
|
<hr>
|
|
<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The table in paragraph 7 for the length modifier does not list the length
|
|
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
|
|
standard asks the implementation to do undefined things when using <tt>scanf()</tt>
|
|
(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
|
|
is actually a problem I found quite often in production code, too).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
|
|
Modifier table to say that for <tt>double</tt> a length modifier
|
|
<tt>l</tt> is to be used.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The standard makes an embarrassing beginner's mistake.</p>
|
|
<hr>
|
|
<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>There are conflicting statements about where the class
|
|
<tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
|
|
it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
|
|
"<tt>basic_ios::Init"</tt> to
|
|
"<tt>ios_base::Init"</tt>.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although not strictly wrong, the standard was misleading enough to warrant
|
|
the change.</p>
|
|
<hr>
|
|
<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p>
|
|
<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>There is a small discrepancy between the declarations of
|
|
<tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
|
|
<tt>locale const&</tt> (correct), in 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
|
|
is passed as <tt>locale const</tt> (wrong).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
|
|
from "<tt>locale const" to "locale
|
|
const&".</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The default behavior of <tt>setbuf()</tt> is described only for the
|
|
situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
|
|
namely to do nothing. What has to be done in other situations
|
|
is not described although there is actually only one reasonable
|
|
approach, namely to do nothing, too.</p>
|
|
|
|
<p>Since changing the buffer would almost certainly mess up most
|
|
buffer management of derived classes unless these classes do it
|
|
themselves, the default behavior of <tt>setbuf()</tt> should always be
|
|
to do nothing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
|
|
to: "Default behavior: Does nothing. Returns this."</p>
|
|
<hr>
|
|
<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The description of the meaning of the result of
|
|
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
|
|
<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
|
|
this function only reads the current character but does not extract
|
|
it, <tt>uflow()</tt> would extract the current character. This should
|
|
be fixed to use <tt>sbumpc()</tt> instead.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
|
|
<tt>showmanyc()</tt>returns clause, by replacing the word
|
|
"supplied" with the words "extracted from the
|
|
stream".</p>
|
|
<hr>
|
|
<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
|
|
is not defined. Probably, the referred function is
|
|
<tt>basic_ios<>::exceptions()</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
|
|
27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>,
|
|
paragraph 1, change "<tt>exception()" to
|
|
"exceptions()"</tt>.</p>
|
|
|
|
<p><i>[Note to Editor: "exceptions" with an "s"
|
|
is the correct spelling.]</i></p>
|
|
<hr>
|
|
<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The note in the second paragraph pretends that the first argument
|
|
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
|
|
an object of type <tt>istreambuf_iterator</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
|
|
<blockquote>
|
|
<p>The first argument provides an object of the istream_iterator class...</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>The first argument provides an object of the istreambuf_iterator class...</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p>
|
|
<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
|
|
<p>In 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
|
|
as taking a fill character as an argument, but the description of the
|
|
function does not say whether the character is used at all and, if so,
|
|
in which way. The same holds for any format control parameters that
|
|
are accessible through the ios_base& argument, such as the
|
|
adjustment or the field width. Is strftime() supposed to use the fill
|
|
character in any way? In any case, the specification of
|
|
time_put.do_put() looks inconsistent to me.<br> <br> Is the
|
|
signature of do_put() wrong, or is the effects clause incomplete?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following note after 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
|
|
paragraph 2:</p>
|
|
<blockquote>
|
|
<p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
|
|
for this argument. --end Note]</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG felt that while the normative text was correct,
|
|
users need some guidance on what to pass for the <tt>fill</tt>
|
|
argument since the standard doesn't say how it's used.</p>
|
|
<hr>
|
|
<a name="165"><h3>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p>
|
|
<b>Section:</b> 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
|
|
functions falling into one of the groups "formatted output functions"
|
|
and "unformatted output functions" calls any stream buffer function
|
|
which might call a virtual function other than <tt>overflow()</tt>. Basically
|
|
this is fine but this implies that <tt>sputn()</tt> (this function would call
|
|
the virtual function <tt>xsputn()</tt>) is never called by any of the standard
|
|
output functions. Is this really intended? At minimum it would be convenient to
|
|
call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
|
|
is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
|
|
with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt>
|
|
and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
|
|
under "unformatted output functions").</p>
|
|
<p>In addition, I guess that the sentence starting with "They may use other
|
|
public members of <tt>basic_ostream</tt> ..." probably was intended to
|
|
start with "They may use other public members of <tt>basic_streamuf</tt>..."
|
|
although the problem with the virtual members exists in both cases.</p>
|
|
<p>I see two obvious resolutions:</p>
|
|
<ol>
|
|
<li>state in a footnote that this means that <tt>xsputn()</tt> will never be
|
|
called by any ostream member and that this is intended.</li>
|
|
<li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
|
|
Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
|
|
</ol>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
|
|
<blockquote>
|
|
<p>They may use other public members of basic_ostream except that they do not
|
|
invoke any virtual members of rdbuf() except overflow().</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>They may use other public members of basic_ostream except that they shall
|
|
not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
|
|
sync().</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
|
|
PJP why the standard is written this way.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
|
|
LWG. He comments: The rules can be made a little bit more specific if
|
|
necessary be explicitly spelling out what virtuals are allowed to be
|
|
called from what functions and eg to state specifically that flush()
|
|
is allowed to call sync() while other functions are not.]</i></p>
|
|
<hr>
|
|
<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p>
|
|
<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The first paragraph begins with a descriptions what has to be done
|
|
in <i>formatted</i> output functions. Probably this is a typo and the
|
|
paragraph really want to describe unformatted output functions...</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
|
|
sentences, change the word "formatted" to
|
|
"unformatted":</p>
|
|
<blockquote>
|
|
<p>"Each <b>unformatted </b> output function begins ..."<br>
|
|
"... value specified for the <b>unformatted </b> output
|
|
function."</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
|
|
<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
|
|
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
|
|
especially in view of the restriction that <tt>basic_ostream</tt>
|
|
member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
|
|
is to be created.</p>
|
|
<p>Of course, the resolution below requires some handling of
|
|
simultaneous input and output since it is no longer possible to update
|
|
<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
|
|
solution is to handle this in <tt>underflow()</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
|
|
"at least" as in the following:</p>
|
|
<blockquote>
|
|
<p>To make a write position available, the function reallocates (or initially
|
|
allocates) an array object with a sufficient number of elements to hold the
|
|
current array object (if any), plus <b>at least</b> one additional write
|
|
position.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
|
|
<tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
|
|
<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
|
|
in their definition of the type <tt>traits_type</tt>: For
|
|
<tt>istringstream</tt>, this type is defined, for the other two it is
|
|
not. This should be consistent.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><b>Proposed resolution:</b></p> <p>To the declarations of
|
|
<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
|
|
<tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
|
|
<blockquote>
|
|
<pre>typedef traits traits_type;</pre>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p>
|
|
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
|
|
output position is maintained by <tt>basic_filebuf</tt>. Still, the
|
|
description of <tt>seekpos()</tt> seems to talk about different file
|
|
positions. In particular, it is unclear (at least to me) what is
|
|
supposed to happen to the output buffer (if there is one) if only the
|
|
input position is changed. The standard seems to mandate that the
|
|
output buffer is kept and processed as if there was no positioning of
|
|
the output position (by changing the input position). Of course, this
|
|
can be exactly what you want if the flag <tt>ios_base::ate</tt> is
|
|
set. However, I think, the standard should say something like
|
|
this:</p>
|
|
<ul>
|
|
<li>If <tt>(which & mode) == 0</tt> neither read nor write position is
|
|
changed and the call fails. Otherwise, the joint read and write position is
|
|
altered to correspond to <tt>sp</tt>.</li>
|
|
<li>If there is an output buffer, the output sequences is updated and any
|
|
unshift sequence is written before the position is altered.</li>
|
|
<li>If there is an input buffer, the input sequence is updated after the
|
|
position is altered.</li>
|
|
</ul>
|
|
<p>Plus the appropriate error handling, that is...</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
|
|
paragraph 14 from:</p>
|
|
<blockquote>
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
|
ios_base::out);</p>
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
|
in sp (as described below).</p>
|
|
<p>- if (which&ios_base::in)!=0, set the file position to sp, then update
|
|
the input sequence</p>
|
|
<p>- if (which&ios_base::out)!=0, then update the output sequence, write
|
|
any unshift sequence, and set the file position to sp.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
|
ios_base::out);</p>
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
|
in sp (as described below). Altering the file position performs as follows:</p>
|
|
<p>1. if (om & ios_base::out)!=0, then update the output sequence and
|
|
write any unshift sequence;</p>
|
|
<p>2. set the file position to sp;</p>
|
|
<p>3. if (om & ios_base::in)!=0, then update the input sequence;</p>
|
|
<p>where om is the open mode passed to the last call to open(). The operation
|
|
fails if is_open() returns false.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
|
|
<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
|
|
<hr>
|
|
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
|
|
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
|
|
argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
|
|
paragraph 23 the first argument is of type <tt>int.</tt>
|
|
</p>
|
|
|
|
<p>As far as I can see this is not really a contradiction because
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
|
intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
|
|
as described in issue <a href="lwg-defects.html#173">173</a>.</p>
|
|
|
|
<p>Darin Adler also
|
|
submitted this issue, commenting: Either 27.6.1.1 should be modified
|
|
to show a first parameter of type int, or 27.6.1.3 should be modified
|
|
to show a first parameter of type streamsize and use
|
|
numeric_limits<streamsize>::max.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses
|
|
of <tt>int</tt> in the description of <tt>ignore()</tt> to
|
|
<tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
|
|
<p>
|
|
In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
|
|
object of type <tt>streamsize</tt> as second argument. However, in
|
|
27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
|
|
<tt>int</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
As far as I can see this is not really a contradiction because
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
|
intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
|
|
as described in issue <a href="lwg-defects.html#172">172</a>.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
|
|
<tt>int</tt> in the description of <tt>setbuf()</tt> to
|
|
<tt>streamsize</tt>.</p>
|
|
<hr>
|
|
<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
|
|
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
|
|
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
|
|
OFF_T streampos;</tt>" to "<tt>typedef POS_T
|
|
streampos;</tt>"</p>
|
|
<hr>
|
|
<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>According to paragraph 8 of this section, the methods
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
|
<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
|
|
"may" be overloaded by a version of this function taking the
|
|
type <tt>ios_base::open_mode</tt> as last argument argument instead of
|
|
<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
|
|
in this section to be an alias for one of the integral types). The
|
|
clause specifies, that the last argument has a default argument in
|
|
three cases. However, this generates an ambiguity with the overloaded
|
|
version because now the arguments are absolutely identical if the last
|
|
argument is not specified.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
|
<tt>basic_ifstream::open()</tt>, and
|
|
<tt>basic_ofstream::open().</tt>
|
|
</p>
|
|
<hr>
|
|
<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
|
|
<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
|
<p>The "overload" for the function <tt>exceptions()</tt> in
|
|
paragraph 8 gives the impression that there is another function of
|
|
this function defined in class <tt>ios_base</tt>. However, this is not
|
|
the case. Thus, it is hard to tell how the semantics (paragraph 9) can
|
|
be implemented: "Call the corresponding member function specified
|
|
in clause 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
|
|
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
|
|
<hr>
|
|
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p>
|
|
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
|
|
<p>The claim has surfaced in Usenet that expressions such as<br>
|
|
<br>
|
|
<tt>make_pair("abc", 3)</tt><br>
|
|
<br>
|
|
are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
|
|
parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br>
|
|
<br>
|
|
I doubt anyone intended that behavior...
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.2 <a href="lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
|
|
declaration of make_pair():</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
|
|
</blockquote>
|
|
<p> In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2>
|
|
pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<pre>template <class T1, class T2>
|
|
pair<T1, T2> make_pair(T1 x, T2 y);</pre>
|
|
</blockquote>
|
|
<p>and add the following footnote to the effects clause:</p>
|
|
<blockquote>
|
|
<p> According to 12.8 [class.copy], an implementation is permitted
|
|
to not perform a copy of an argument, thus avoiding unnecessary
|
|
copies.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Two potential fixes were suggested by Matt Austern and Dietmar
|
|
Kühl, respectively, 1) overloading with array arguments, and 2) use of
|
|
a reference_traits class with a specialization for arrays. Andy
|
|
Koenig suggested changing to pass by value. In discussion, it appeared
|
|
that this was a much smaller change to the standard that the other two
|
|
suggestions, and any efficiency concerns were more than offset by the
|
|
advantages of the solution. Two implementors reported that the
|
|
proposed resolution passed their test suites.</p>
|
|
<hr>
|
|
<a name="182"><h3>182. Ambiguous references to size_t</h3></a><p>
|
|
<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Al Stevens <b>Date:</b> 15 Aug 1999</p>
|
|
<p>Many references to <tt> size_t</tt> throughout the document
|
|
omit the <tt> std::</tt> namespace qualification.</p> <p>For
|
|
example, 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
|
|
<blockquote>
|
|
<pre>— operator new(size_t)
|
|
— operator new(size_t, const std::nothrow_t&)
|
|
— operator new[](size_t)
|
|
— operator new[](size_t, const std::nothrow_t&)</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> In 17.4.3.4 <a href="lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
|
|
<blockquote>
|
|
<p><tt> - operator new(size_t)<br>
|
|
- operator new(size_t, const std::nothrow_t&)<br>
|
|
- operator new[](size_t)<br>
|
|
- operator new[](size_t, const std::nothrow_t&)</tt></p>
|
|
</blockquote>
|
|
<p> by:</p>
|
|
<blockquote>
|
|
<pre>- operator new(std::size_t)
|
|
- operator new(std::size_t, const std::nothrow_t&)
|
|
- operator new[](std::size_t)
|
|
- operator new[](std::size_t, const std::nothrow_t&)</pre>
|
|
</blockquote>
|
|
<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
|
|
<blockquote>
|
|
<p>The typedef members pointer, const_pointer, size_type, and difference_type
|
|
are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
|
|
</blockquote>
|
|
<p> by:</p>
|
|
<blockquote>
|
|
<p>The typedef members pointer, const_pointer, size_type, and difference_type
|
|
are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
|
|
respectively.</p>
|
|
</blockquote>
|
|
<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
|
|
<blockquote>
|
|
<p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
|
|
<p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
|
|
is unspecified when or how often this function is called. The use of hint is
|
|
unspecified, but intended as an aid to locality if an implementation so
|
|
desires.</p>
|
|
</blockquote>
|
|
<p>by:</p>
|
|
<blockquote>
|
|
<p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
|
|
<p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
|
|
it is unspecified when or how often this function is called. The use of hint
|
|
is unspecified, but intended as an aid to locality if an implementation so
|
|
desires.</p>
|
|
</blockquote>
|
|
<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
|
|
<blockquote>
|
|
<p>In Table 37, X denotes a Traits class defining types and functions for the
|
|
character container type CharT; c and d denote values of type CharT; p and q
|
|
denote values of type const CharT*; s denotes a value of type CharT*; n, i and
|
|
j denote values of type size_t; e and f denote values of type X::int_type; pos
|
|
denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
|
|
</blockquote>
|
|
<p>by:</p>
|
|
<blockquote>
|
|
<p>In Table 37, X denotes a Traits class defining types and functions for the
|
|
character container type CharT; c and d denote values of type CharT; p and q
|
|
denote values of type const CharT*; s denotes a value of type CharT*; n, i and
|
|
j denote values of type std::size_t; e and f denote values of type X::int_type;
|
|
pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
|
|
</blockquote>
|
|
<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
|
|
X::length(p): "size_t" by "std::size_t".</p>
|
|
<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
|
|
typedef ptrdiff_t difference_type;<br>
|
|
by:<br>
|
|
typedef std::ptrdiff_t difference_type;</p>
|
|
<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of template <class charT> class ctype.<br>
|
|
<br>
|
|
In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
|
|
<br>
|
|
template<class Iterator> struct iterator_traits<br>
|
|
template<class T> struct iterator_traits<T*><br>
|
|
template<class T> struct iterator_traits<const T*></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG believes correcting names like <tt>size_t</tt> and
|
|
<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
|
|
to be essentially editorial. There there can't be another size_t or
|
|
ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
|
|
|
|
<blockquote>
|
|
For each type T from the Standard C library, the types ::T and std::T
|
|
are reserved to the implementation and, when defined, ::T shall be
|
|
identical to std::T.
|
|
</blockquote>
|
|
|
|
<p>The issue is treated as a Defect Report to make explicit the Project
|
|
Editor's authority to make this change.</p>
|
|
|
|
<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
|
|
request of the LWG.]</i></p>
|
|
|
|
<p><i>[Toronto: This is tangentially related to issue <a href="lwg-active.html#229">229</a>, but only tangentially: the intent of this issue is to
|
|
address use of the name <tt>size_t</tt> in contexts outside of
|
|
namespace std, such as in the description of <tt>::operator new</tt>.
|
|
The proposed changes should be reviewed to make sure they are
|
|
correct.]</i></p>
|
|
|
|
<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
|
|
them to be correct.]</i></p>
|
|
|
|
<hr>
|
|
<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p>
|
|
<b>Section:</b> 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 7 Jul 1999</p>
|
|
<p>27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
|
|
exposition):</p>
|
|
<blockquote>
|
|
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
|
|
of) basic_ostream then the expression out<<s behaves as if f(s) were
|
|
called, and if [2] in is an (instance of) basic_istream then the expression
|
|
in>>s behaves as if f(s) were called. Where f can be defined as: ios_base&
|
|
f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags
|
|
str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
|
|
out<<s has type ostream& and value out. [4] The expression in>>s
|
|
has type istream& and value in.</p>
|
|
</blockquote>
|
|
<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
|
|
"The expression out << s has type basic_ostream& ..." and
|
|
[4] should read: "The expression in >> s has type basic_istream&
|
|
..."</p>
|
|
<p>If the wording in the standard is correct, I can see no way of implementing
|
|
any of the manipulators so that they will work with wide character streams.</p>
|
|
<p>e.g. wcout << setbase( 16 );</p>
|
|
<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which
|
|
doesn't).</p>
|
|
<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
|
|
8. In addition, Para 6 [setfill] has a similar error, but relates only to
|
|
ostreams.</p>
|
|
<p>I'd be happier if there was a better way of saying this, to make it clear
|
|
that the value of the expression is "the same specialization of
|
|
basic_ostream as out"&</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace section 27.6.3 <a href="lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
|
|
following:</p>
|
|
<blockquote>
|
|
<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
|
|
function.<br>
|
|
<br>
|
|
<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
|
|
<br>
|
|
-3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if
|
|
f(s, mask) were called. The function f can be defined as:*<br>
|
|
<br>
|
|
[Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the
|
|
basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears
|
|
ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout <<
|
|
noshowbase). --- end footnote]<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
|
{<br>
|
|
// reset specified flags<br>
|
|
str.setf(ios_base::fmtflags(0), mask);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
|
|
<br>
|
|
-4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s,
|
|
mask) were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
|
{<br>
|
|
// set specified flags<br>
|
|
str.setf(mask);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setbase(int base);</tt><br>
|
|
<br>
|
|
-5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, base) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s,
|
|
base) were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int base)<br>
|
|
{<br>
|
|
// set basefield<br>
|
|
str.setf(base == 8 ? ios_base::oct :<br>
|
|
base == 10 ? ios_base::dec :<br>
|
|
base == 16 ? ios_base::hex :<br>
|
|
ios_base::fmtflags(0), ios_base::basefield);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
|
<br>
|
|
<tt>smanip setfill(char_type c);<br>
|
|
</tt><br>
|
|
-6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream<charT,traits> and c has type charT then the
|
|
expression out<<s behaves as if f(s, c) were called. The function f can be
|
|
defined as:<br>
|
|
<br>
|
|
<tt>template<class charT, class traits><br>
|
|
basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br>
|
|
{<br>
|
|
// set fill character<br>
|
|
str.fill(c);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.<br>
|
|
<br>
|
|
<tt>smanip setprecision(int n);</tt><br>
|
|
<br>
|
|
-7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n)
|
|
were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
|
{<br>
|
|
// set precision<br>
|
|
str.precision(n);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in<br>
|
|
.<br>
|
|
<tt>smanip setw(int n);<br>
|
|
</tt><br>
|
|
-8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves
|
|
as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n)
|
|
were called. The function f can be defined as:<br>
|
|
<br>
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
|
{<br>
|
|
// set width<br>
|
|
str.width(n);<br>
|
|
return str;<br>
|
|
}<br>
|
|
</tt><br>
|
|
The expression out<<s has type
|
|
basic_ostream<charT,traits>& and value out. The expression
|
|
in>>s has type basic_istream<charT,traits>& and value
|
|
in.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
|
|
the proposed resolution.]</i></p>
|
|
|
|
<p><i>[Tokyo - The LWG noted that issue <a href="lwg-closed.html#216">216</a> involves
|
|
the same paragraphs.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
|
|
resolution of this issue with the proposed resolution for issue <a href="lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
|
|
intertwined that dealing with them separately appear fraught with
|
|
error. The full text was supplied by Bill Plauger; it was cross
|
|
checked against changes supplied by Andy Sawyer. It should be further
|
|
checked by the LWG.]</i></p>
|
|
<hr>
|
|
<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p>
|
|
<b>Section:</b> 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p>
|
|
<p>bools are defined by the standard to be of integer types, as per
|
|
3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types"
|
|
seems to have a special meaning for the author of 18.2. The net effect
|
|
is an unclear and confusing specification for
|
|
numeric_limits<bool> as evidenced below.</p>
|
|
|
|
<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer
|
|
types, the number of non-sign bits in the representation.</p>
|
|
|
|
<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
|
|
arithmetical value converts to true.</p>
|
|
|
|
<p>I don't think it makes sense at all to require
|
|
numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to
|
|
be meaningful.</p>
|
|
|
|
<p>The standard defines what constitutes a signed (resp. unsigned) integer
|
|
types. It doesn't categorize bool as being signed or unsigned. And the set of
|
|
values of bool type has only two elements.</p>
|
|
|
|
<p>I don't think it makes sense to require numeric_limits<bool>::is_signed
|
|
to be meaningful.</p>
|
|
|
|
<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p>
|
|
<blockquote>
|
|
<p>For integer types, specifies the base of the representation.186)</p>
|
|
</blockquote>
|
|
|
|
<p>This disposition is at best misleading and confusing for the standard
|
|
requires a "pure binary numeration system" for integer types as per
|
|
3.9.1/7</p>
|
|
|
|
<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
|
|
BCD)." This also erroneous as the standard never defines any integer
|
|
types with base representation other than 2.</p>
|
|
|
|
<p>Furthermore, numeric_limits<bool>::is_modulo and
|
|
numeric_limits<bool>::is_signed have similar problems.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Append to the end of 18.2.1.5 <a href="lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
|
|
<blockquote>
|
|
<p>The specialization for bool shall be provided as follows:</p>
|
|
<pre> namespace std {
|
|
template<> class numeric_limits<bool> {
|
|
public:
|
|
static const bool is_specialized = true;
|
|
static bool min() throw() { return false; }
|
|
static bool max() throw() { return true; }
|
|
|
|
static const int digits = 1;
|
|
static const int digits10 = 0;
|
|
static const bool is_signed = false;
|
|
static const bool is_integer = true;
|
|
static const bool is_exact = true;
|
|
static const int radix = 2;
|
|
static bool epsilon() throw() { return 0; }
|
|
static bool round_error() throw() { return 0; }
|
|
|
|
static const int min_exponent = 0;
|
|
static const int min_exponent10 = 0;
|
|
static const int max_exponent = 0;
|
|
static const int max_exponent10 = 0;
|
|
|
|
static const bool has_infinity = false;
|
|
static const bool has_quiet_NaN = false;
|
|
static const bool has_signaling_NaN = false;
|
|
static const float_denorm_style has_denorm = denorm_absent;
|
|
static const bool has_denorm_loss = false;
|
|
static bool infinity() throw() { return 0; }
|
|
static bool quiet_NaN() throw() { return 0; }
|
|
static bool signaling_NaN() throw() { return 0; }
|
|
static bool denorm_min() throw() { return 0; }
|
|
|
|
static const bool is_iec559 = false;
|
|
static const bool is_bounded = true;
|
|
static const bool is_modulo = false;
|
|
|
|
static const bool traps = false;
|
|
static const bool tinyness_before = false;
|
|
static const float_round_style round_style = round_toward_zero;
|
|
};
|
|
}</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Tokyo: The LWG desires wording that specifies exact values
|
|
rather than more general wording in the original proposed
|
|
resolution.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico
|
|
Josuttis provided the above wording.]</i></p>
|
|
<hr>
|
|
<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p>
|
|
<b>Section:</b> 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p>
|
|
<p>Paragraph 4 of 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
|
|
<blockquote>
|
|
<p> [Example: To negate every element of a: transform(a.begin(), a.end(),
|
|
a.begin(), negate<double>()); The corresponding functions will inline
|
|
the addition and the negation. end example]</p>
|
|
</blockquote>
|
|
<p>(Note: The "addition" referred to in the above is in para 3) we can
|
|
find no other wording, except this (non-normative) example which suggests that
|
|
any "inlining" will take place in this case.</p>
|
|
<p>Indeed both:</p>
|
|
<blockquote>
|
|
<p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
|
|
unspecified whether any global functions in the C++ Standard Library
|
|
are defined as inline (7.1.2).</p>
|
|
</blockquote>
|
|
<p>and</p>
|
|
<blockquote>
|
|
<p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
|
|
unspecified whether any member functions in the C++ Standard Library
|
|
are defined as inline (7.1.2).</p>
|
|
</blockquote>
|
|
<p>take care to state that this may indeed NOT be the case.</p>
|
|
<p>Thus the example "mandates" behavior that is explicitly
|
|
not required elsewhere.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
|
|
<blockquote>
|
|
<p>They are important for the effective use of the library.</p>
|
|
</blockquote>
|
|
<p>Remove 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
|
|
<blockquote>
|
|
<p> Using function objects together with function templates
|
|
increases the expressive power of the library as well as making the
|
|
resulting code much more efficient.</p>
|
|
</blockquote>
|
|
<p>In 20.3 <a href="lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
|
|
<blockquote>
|
|
<p>The corresponding functions will inline the addition and the
|
|
negation.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
|
|
<hr>
|
|
<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p>
|
|
<b>Section:</b> 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p>
|
|
<p>In section 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
|
|
bitset::set operation to take a second parameter of type int. The
|
|
function tests whether this value is non-zero to determine whether to
|
|
set the bit to true or false. The type of this second parameter should
|
|
be bool. For one thing, the intent is to specify a Boolean value. For
|
|
another, the result type from test() is bool. In addition, it's
|
|
possible to slice an integer that's larger than an int. This can't
|
|
happen with bool, since conversion to bool has the semantic of
|
|
translating 0 to false and any non-zero value to true.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
|
|
</blockquote>
|
|
<p>With:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
|
</blockquote>
|
|
<p>In 23.3.5.2 <a href="lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
|
|
</blockquote>
|
|
<p>With:</p>
|
|
<blockquote>
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work
|
|
on better P/R wording.]</i></p>
|
|
<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
<tt>bool</tt> is a better choice. It is believed that binary
|
|
compatibility is not an issue, because this member function is
|
|
usually implemented as <tt>inline</tt>, and because it is already
|
|
the case that users cannot rely on the type of a pointer to a
|
|
nonvirtual member of a standard library class.</p>
|
|
<hr>
|
|
<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p>
|
|
<b>Section:</b> 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p>
|
|
<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
|
|
and includes a parenthetical note saying that it is the number of
|
|
digits after the decimal point.<br>
|
|
<br>
|
|
This claim is not strictly correct. For example, in the default
|
|
floating-point output format, setprecision sets the number of
|
|
significant digits printed, not the number of digits after the decimal
|
|
point.<br>
|
|
<br>
|
|
I would like the committee to look at the definition carefully and
|
|
correct the statement in 27.4.2.2</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove from 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
|
|
"(number of digits after the decimal point)".</p>
|
|
<hr>
|
|
<a name="193"><h3>193. Heap operations description incorrect</h3></a><p>
|
|
<b>Section:</b> 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p>
|
|
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
|
|
is<br>
|
|
<br>
|
|
`"(1) *a is the largest element"<br>
|
|
<br>
|
|
I think this is incorrect and should be changed to the wording in the proposed
|
|
resolution.</p>
|
|
<p>Actually there are two independent changes:</p>
|
|
<blockquote>
|
|
<p>A-"part of largest equivalence class" instead of "largest", cause 25.3
|
|
[lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
|
|
<p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions could not be used for a
|
|
priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects priority AND time).</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
|
|
<blockquote>
|
|
<p>(1) *a is the largest element</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>(1) There is no element greater than <tt>*a</tt>
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
|
|
<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p>
|
|
<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
|
|
What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
|
|
reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
|
|
should set failbit. Should it set eofbit as well? The standard
|
|
doesn't seem to answer that question.</p>
|
|
|
|
<p>On the one hand, nothing in 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that
|
|
<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
|
|
other hand, 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
|
|
extraction from a <tt>streambuf</tt> "returns
|
|
<tt>traits::eof()</tt>, then the input function, except as explicitly
|
|
noted otherwise, completes its actions and does
|
|
<tt>setstate(eofbit)"</tt>. So the question comes down to
|
|
whether <tt>basic_istream<>::sentry</tt>'s constructor is an
|
|
input function.</p>
|
|
|
|
<p>Comments from Jerry Schwarz:</p>
|
|
<blockquote>
|
|
<p>It was always my intention that eofbit should be set any time that a
|
|
virtual returned something to indicate eof, no matter what reason
|
|
iostream code had for calling the virtual.</p>
|
|
<p>
|
|
The motivation for this is that I did not want to require streambufs
|
|
to behave consistently if their virtuals are called after they have
|
|
signaled eof.</p>
|
|
<p>
|
|
The classic case is a streambuf reading from a UNIX file. EOF isn't
|
|
really a state for UNIX file descriptors. The convention is that a
|
|
read on UNIX returns 0 bytes to indicate "EOF", but the file
|
|
descriptor isn't shut down in any way and future reads do not
|
|
necessarily also return 0 bytes. In particular, you can read from
|
|
tty's on UNIX even after they have signaled "EOF". (It
|
|
isn't always understood that a ^D on UNIX is not an EOF indicator, but
|
|
an EOL indicator. By typing a "line" consisting solely of
|
|
^D you cause a read to return 0 bytes, and by convention this is
|
|
interpreted as end of file.)</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
|
|
<blockquote>
|
|
<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt>
|
|
returns <tt>traits::eof()</tt>, the function calls
|
|
<tt>setstate(failbit | eofbit)</tt> (which may throw
|
|
<tt>ios_base::failure</tt>).
|
|
</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="198"><h3>198. Validity of pointers and references unspecified after iterator destruction</h3></a><p>
|
|
<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Nov 1999</p>
|
|
<p>
|
|
Is a pointer or reference obtained from an iterator still valid after
|
|
destruction of the iterator?
|
|
</p>
|
|
<p>
|
|
Is a pointer or reference obtained from an iterator still valid after the value
|
|
of the iterator changes?
|
|
</p>
|
|
<blockquote>
|
|
<pre>
|
|
#include <iostream>
|
|
#include <vector>
|
|
#include <iterator>
|
|
|
|
int main()
|
|
{
|
|
typedef std::vector<int> vec_t;
|
|
vec_t v;
|
|
v.push_back( 1 );
|
|
|
|
// Is a pointer or reference obtained from an iterator still
|
|
// valid after destruction of the iterator?
|
|
int * p = &*v.begin();
|
|
std::cout << *p << '\n'; // OK?
|
|
|
|
// Is a pointer or reference obtained from an iterator still
|
|
// valid after the value of the iterator changes?
|
|
vec_t::iterator iter( v.begin() );
|
|
p = &*iter++;
|
|
std::cout << *p << '\n'; // OK?
|
|
|
|
return 0;
|
|
}
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>The standard doesn't appear to directly address these
|
|
questions. The standard needs to be clarified. At least two real-world
|
|
cases have been reported where library implementors wasted
|
|
considerable effort because of the lack of clarity in the
|
|
standard. The question is important because requiring pointers and
|
|
references to remain valid has the effect for practical purposes of
|
|
prohibiting iterators from pointing to cached rather than actual
|
|
elements of containers.</p>
|
|
|
|
<p>The standard itself assumes that pointers and references obtained
|
|
from an iterator are still valid after iterator destruction or
|
|
change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
|
|
effects:</p>
|
|
|
|
<blockquote>
|
|
<pre>Iterator tmp = current;
|
|
return *--tmp;</pre>
|
|
</blockquote>
|
|
<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 <a href="lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
|
|
<blockquote>
|
|
<pre>return &(operator*());</pre>
|
|
</blockquote>
|
|
|
|
<p>Because the standard itself assumes pointers and references remain
|
|
valid after iterator destruction or change, the standard should say so
|
|
explicitly. This will also reduce the chance of user code breaking
|
|
unexpectedly when porting to a different standard library
|
|
implementation.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a new paragraph to 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
|
|
<blockquote>
|
|
Destruction of an iterator may invalidate pointers and references
|
|
previously obtained from that iterator.
|
|
</blockquote>
|
|
|
|
<p>Replace paragraph 1 of 24.4.1.3.3 <a href="lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
|
|
|
|
<blockquote>
|
|
<p><b>Effects:</b></p>
|
|
<pre>
|
|
this->tmp = current;
|
|
--this->tmp;
|
|
return *this->tmp;
|
|
</pre>
|
|
|
|
<p>
|
|
[<i>Note:</i> This operation must use an auxiliary member variable,
|
|
rather than a temporary variable, to avoid returning a reference that
|
|
persists beyond the lifetime of its associated iterator. (See
|
|
24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.) The name of this member variable is shown for
|
|
exposition only. <i>--end note</i>]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Post-Tokyo: The issue has been reformulated purely
|
|
in terms of iterators.]</i></p>
|
|
|
|
<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
|
|
assumption by reverse_iterator. The issue and proposed resolution was
|
|
reformulated yet again to reflect this reality.]</i></p>
|
|
|
|
<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
|
|
assumes its underlying iterator has persistent pointers and
|
|
references. Andy Koenig pointed out that it is possible to rewrite
|
|
reverse_iterator so that it no longer makes such an assupmption.
|
|
However, this issue is related to issue <a href="lwg-active.html#299">299</a>. If we
|
|
decide it is intentional that <tt>p[n]</tt> may return by value
|
|
instead of reference when <tt>p</tt> is a Random Access Iterator,
|
|
other changes in reverse_iterator will be necessary.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This issue has been discussed extensively. Note that it is
|
|
<i>not</i> an issue about the behavior of predefined iterators. It is
|
|
asking whether or not user-defined iterators are permitted to have
|
|
transient pointers and references. Several people presented examples
|
|
of useful user-defined iterators that have such a property; examples
|
|
include a B-tree iterator, and an "iota iterator" that doesn't point
|
|
to memory. Library implementors already seem to be able to cope with
|
|
such iterators: they take pains to avoid forming references to memory
|
|
that gets iterated past. The only place where this is a problem is
|
|
<tt>reverse_iterator</tt>, so this issue changes
|
|
<tt>reverse_iterator</tt> to make it work.</p>
|
|
|
|
<p>This resolution does not weaken any guarantees provided by
|
|
predefined iterators like <tt>list<int>::iterator</tt>.
|
|
Clause 23 should be reviewed to make sure that guarantees for
|
|
predefined iterators are as strong as users expect.</p>
|
|
|
|
<hr>
|
|
<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p>
|
|
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
|
|
<p>
|
|
Suppose that <tt>A</tt> is a class that conforms to the
|
|
Allocator requirements of Table 32, and <tt>a</tt> is an
|
|
object of class <tt>A</tt> What should be the return
|
|
value of <tt>a.allocate(0)</tt>? Three reasonable
|
|
possibilities: forbid the argument <tt>0</tt>, return
|
|
a null pointer, or require that the return value be a
|
|
unique non-null pointer.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add a note to the <tt>allocate</tt> row of Table 32:
|
|
"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>A key to understanding this issue is that the ultimate use of
|
|
allocate() is to construct an iterator, and that iterator for zero
|
|
length sequences must be the container's past-the-end
|
|
representation. Since this already implies special case code, it
|
|
would be over-specification to mandate the return value.
|
|
</p>
|
|
<hr>
|
|
<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p>
|
|
<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p>
|
|
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
|
|
past-the-end values are always non-singular."</p>
|
|
<p>This places an unnecessary restriction on past-the-end iterators for
|
|
containers with forward iterators (for example, a singly-linked list). If the
|
|
past-the-end value on such a container was a well-known singular value, it would
|
|
still satisfy all forward iterator requirements.</p>
|
|
<p>Removing this restriction would allow, for example, a singly-linked list
|
|
without a "footer" node.</p>
|
|
<p>This would have an impact on existing code that expects past-the-end
|
|
iterators obtained from different (generic) containers being not equal.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
|
|
<blockquote>
|
|
<p>Dereferenceable and past-the-end values are always non-singular.</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Dereferenceable values are always non-singular. </p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>For some kinds of containers, including singly linked lists and
|
|
zero-length vectors, null pointers are perfectly reasonable past-the-end
|
|
iterators. Null pointers are singular.
|
|
</p>
|
|
<hr>
|
|
<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
|
|
<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
|
|
declarations use a consistent style except for the following functions:</p>
|
|
<blockquote>
|
|
<pre>void push_back(const charT);
|
|
basic_string& assign(const basic_string&);
|
|
void swap(basic_string<charT,traits,Allocator>&);</pre>
|
|
</blockquote>
|
|
<p>- push_back, assign, swap: missing argument name <br>
|
|
- push_back: use of const with charT (i.e. POD type passed by value
|
|
not by reference - should be charT or const charT& )<br>
|
|
- swap: redundant use of template parameters in argument
|
|
basic_string<charT,traits,Allocator>&</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
|
|
function declarations push_back, assign, and swap to:</p>
|
|
<blockquote>
|
|
<pre>void push_back(charT c);
|
|
|
|
basic_string& assign(const basic_string& str);
|
|
void swap(basic_string& str);</pre>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although the standard is in general not consistent in declaration
|
|
style, the basic_string declarations are consistent other than the
|
|
above. The LWG felt that this was sufficient reason to merit the
|
|
change.
|
|
</p>
|
|
<hr>
|
|
<a name="210"><h3>210. distance first and last confused</h3></a><p>
|
|
<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
|
|
<p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
|
|
<blockquote>
|
|
<p> In the description of the algorithms operators + and - are used
|
|
for some of the iterator categories for which they do not have to
|
|
be defined. In these cases the semantics of [...] a-b is the same
|
|
as of<br>
|
|
<br>
|
|
<tt>return distance(a, b);</tt>
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>On the last line of paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
|
|
<tt>"a-b"</tt> to <tt>"b-a".</tt>
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>There are two ways to fix the defect; change the description to b-a
|
|
or change the return to distance(b,a). The LWG preferred the
|
|
former for consistency.</p>
|
|
<hr>
|
|
<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p>
|
|
<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
|
|
<p>The description of the stream extraction operator for std::string (section
|
|
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
|
|
the case that the operator fails to extract any characters from the input
|
|
stream.</p>
|
|
<p>This implies that the typical construction</p>
|
|
<blockquote>
|
|
<pre>std::istream is;
|
|
std::string str;
|
|
...
|
|
while (is >> str) ... ;</pre>
|
|
</blockquote>
|
|
<p>(which tests failbit) is not required to terminate at EOF.</p>
|
|
<p>Furthermore, this is inconsistent with other extraction operators,
|
|
which do include this requirement. (See sections 27.6.1.2 <a href="lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this
|
|
requirement is present, either explicitly or implicitly, for the
|
|
extraction operators. It is also present explicitly in the description
|
|
of getline (istream&, string&, charT) in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p>
|
|
<blockquote>
|
|
|
|
<p>If the function extracts no characters, it calls
|
|
is.setstate(ios::failbit) which may throw ios_base::failure
|
|
(27.4.4.3).</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p>
|
|
<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
|
|
<p>The standard doesn't specify what min_element() and max_element() shall
|
|
return if the range is empty (first equals last). The usual implementations
|
|
return last. This problem seems also apply to partition(), stable_partition(),
|
|
next_permutation(), and prev_permutation().</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and
|
|
9, append: Returns last if first==last.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG looked in some detail at all of the above mentioned
|
|
algorithms, but believes that except for min_element() and
|
|
max_element() it is already clear that last is returned if first ==
|
|
last.</p>
|
|
<hr>
|
|
<a name="214"><h3>214. set::find() missing const overload</h3></a><p>
|
|
<b>Section:</b> 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 28 Feb 2000</p>
|
|
<p>The specification for the associative container requirements in
|
|
Table 69 state that the find member function should "return
|
|
iterator; const_iterator for constant a". The map and multimap
|
|
container descriptions have two overloaded versions of find, but set
|
|
and multiset do not, all they have is:</p>
|
|
<blockquote>
|
|
<pre>iterator find(const key_type & x) const;</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
|
|
equal_range() in section 23.3.3 <a href="lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
|
|
<blockquote>
|
|
<pre>iterator find(const key_type & x);
|
|
const_iterator find(const key_type & x) const;</pre>
|
|
<pre>iterator lower_bound(const key_type & x);
|
|
const_iterator lower_bound(const key_type & x) const;</pre>
|
|
<pre>iterator upper_bound(const key_type & x);
|
|
const_iterator upper_bound(const key_type & x) const;</pre>
|
|
<pre>pair<iterator, iterator> equal_range(const key_type & x);
|
|
pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
|
|
extending the proposed resolution to lower_bound, upper_bound, and
|
|
equal_range.]</i></p>
|
|
<hr>
|
|
<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p>
|
|
<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p>
|
|
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
|
|
<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
|
|
must be const in order for it to be callable on a const object (a reference to
|
|
which which is what std::use_facet<>() returns).</p>
|
|
<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
|
|
name of the namespace `My'.</p>
|
|
<p>3) In the definition of `loc' and subsequently in the call to use_facet<>()
|
|
in main(), the name of the facet is misspelled: it should read `My::JCtype'
|
|
rather than `My::JCType'.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the "Classifying Japanese characters" example in 22.2.8,
|
|
paragraph 11 with the following:</p>
|
|
<pre>#include <locale></pre>
|
|
<pre>namespace My {
|
|
using namespace std;
|
|
class JCtype : public locale::facet {
|
|
public:
|
|
static locale::id id; // required for use as a new locale facet
|
|
bool is_kanji (wchar_t c) const;
|
|
JCtype() {}
|
|
protected:
|
|
~JCtype() {}
|
|
};
|
|
}</pre>
|
|
<pre>// file: filt.C
|
|
#include <iostream>
|
|
#include <locale>
|
|
#include "jctype" // above
|
|
std::locale::id My::JCtype::id; // the static JCtype member
|
|
declared above.</pre>
|
|
<pre>int main()
|
|
{
|
|
using namespace std;
|
|
typedef ctype<wchar_t> wctype;
|
|
locale loc(locale(""), // the user's preferred locale...
|
|
new My::JCtype); // and a new feature ...
|
|
wchar_t c = use_facet<wctype>(loc).widen('!');
|
|
if (!use_facet<My::JCtype>(loc).is_kanji(c))
|
|
cout << "no it isn't!" << endl;
|
|
return 0;
|
|
}</pre>
|
|
<hr>
|
|
<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p>
|
|
<b>Section:</b> 27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p>
|
|
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
|
|
paragraph 2:</p>
|
|
<blockquote>
|
|
<p>Effects: Destroys an object of class ios_base. Calls each registered
|
|
callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
|
|
time that any ios_base member function called from within fn has well defined
|
|
results.</p>
|
|
</blockquote>
|
|
<p>But what is not clear is: If no callback functions were ever registered, does
|
|
it matter whether the ios_base members were ever initialized?</p>
|
|
<p>For instance, does this program have defined behavior:</p>
|
|
<blockquote>
|
|
<pre>#include <ios></pre>
|
|
<pre>class D : public std::ios_base { };</pre>
|
|
<pre>int main() { D d; }</pre>
|
|
</blockquote>
|
|
<p>It seems that registration of a callback function would surely affect the
|
|
state of an ios_base. That is, when you register a callback function with an
|
|
ios_base, the ios_base must record that fact somehow.</p>
|
|
<p>But if after construction the ios_base is in an indeterminate state, and that
|
|
state is not made determinate before the destructor is called, then how would
|
|
the destructor know if any callbacks had indeed been registered? And if the
|
|
number of callbacks that had been registered is indeterminate, then is not the
|
|
behavior of the destructor undefined?</p>
|
|
<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
|
|
it explicit that destruction before initialization results in undefined
|
|
behavior.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Modify 27.4.2.7 paragraph 1 from</p>
|
|
<blockquote>
|
|
<p>Effects: Each ios_base member has an indeterminate value after
|
|
construction.</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>Effects: Each ios_base member has an indeterminate value after
|
|
construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
|
|
have taken place, the behavior is undefined.</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="221"><h3>221. num_get<>::do_get stage 2 processing broken</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Mar 2000</p>
|
|
<p>Stage 2 processing of numeric conversion is broken.</p>
|
|
|
|
<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
|
|
conversion specifier is %i. A %i specifier determines a number's base
|
|
by its prefix (0 for octal, 0x for hex), so the intention is clearly
|
|
that a 0x prefix is allowed. Paragraph 8 in the same section,
|
|
however, describes very precisely how characters are processed. (It
|
|
must be done "as if" by a specified code fragment.) That
|
|
description does not allow a 0x prefix to be recognized.</p>
|
|
|
|
<p>Very roughly, stage 2 processing reads a char_type ct. It converts
|
|
ct to a char, not by using narrow but by looking it up in a
|
|
translation table that was created by widening the string literal
|
|
"0123456789abcdefABCDEF+-". The character "x" is
|
|
not found in that table, so it can't be recognized by stage 2
|
|
processing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
|
|
<blockquote>
|
|
<pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
|
|
</blockquote>
|
|
<p>with the line:</p>
|
|
<blockquote>
|
|
<pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>If we're using the technique of widening a string literal, the
|
|
string literal must contain every character we wish to recognize.
|
|
This technique has the consequence that alternate representations
|
|
of digits will not be recognized. This design decision was made
|
|
deliberately, with full knowledge of that limitation.</p>
|
|
<hr>
|
|
<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
|
|
<b>Section:</b> 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p>
|
|
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
|
|
<blockquote>
|
|
<pre>21.3.6.8 - basic_string::compare [lib.string::compare]
|
|
|
|
int compare(size_type pos1, size_type n1,
|
|
const basic_string<charT,traits,Allocator>& str ,
|
|
size_type pos2 , size_type n2 ) const;
|
|
|
|
-4- Returns:
|
|
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
|
basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre>
|
|
</blockquote>
|
|
<p>and the constructor that's implicitly called by the above is
|
|
defined to throw an out-of-range exception if pos > str.size(). See
|
|
section 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
|
|
|
|
<p>On the other hand, the compare function descriptions themselves don't have
|
|
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
|
|
that do not apply to a function are omitted.</p>
|
|
<p>So it seems there is an inconsistency in the standard -- are the
|
|
"Effects" clauses correct, or are the "Throws" clauses
|
|
missing?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
|
|
the sentence "Descriptions of function semantics contain the
|
|
following elements (as appropriate):", insert the word
|
|
"further" so that the foot note reads:</p>
|
|
<blockquote>
|
|
<p>To save space, items that do not apply to a function are
|
|
omitted. For example, if a function does not specify any further
|
|
preconditions, there will be no "Requires" paragraph.</p>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The standard is somewhat inconsistent, but a failure to note a
|
|
throw condition in a throws clause does not grant permission not to
|
|
throw. The inconsistent wording is in a footnote, and thus
|
|
non-normative. The proposed resolution from the LWG clarifies the
|
|
footnote.</p>
|
|
<hr>
|
|
<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p>
|
|
<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
|
|
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
|
|
<blockquote>
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
|
applies swap to all pairs of iterators first + i, (last - i) - 1.
|
|
</blockquote>
|
|
<p>with:</p>
|
|
<blockquote>
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
|
applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
|
|
</blockquote>
|
|
<hr>
|
|
<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p>
|
|
<p>In the associative container requirements table in 23.1.2 paragraph 7,
|
|
a.clear() has complexity "log(size()) + N". However, the meaning of N
|
|
is not defined.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the associative container requirements table in 23.1.2 paragraph
|
|
7, the complexity of a.clear(), change "log(size()) + N" to
|
|
"linear in <tt>size()</tt>".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>It's the "log(size())", not the "N", that is in
|
|
error: there's no difference between <i>O(N)</i> and <i>O(N +
|
|
log(N))</i>. The text in the standard is probably an incorrect
|
|
cut-and-paste from the range version of <tt>erase</tt>.</p>
|
|
<hr>
|
|
<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
|
|
<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p>
|
|
<p>25.2.2 reads:</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt> template<class T> void swap(T& a, T& b);</tt><br>
|
|
<br>
|
|
Requires: Type T is Assignable (_lib.container.requirements_).<br>
|
|
Effects: Exchanges values stored in two locations.</p>
|
|
</blockquote>
|
|
<p>The only reasonable** generic implementation of swap requires construction of a
|
|
new temporary copy of one of its arguments:</p>
|
|
<blockquote>
|
|
<pre>template<class T> void swap(T& a, T& b);
|
|
{
|
|
T tmp(a);
|
|
a = b;
|
|
b = tmp;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
|
|
<p>**Yes, there's also an unreasonable implementation which would require T to be
|
|
DefaultConstructible instead of CopyConstructible. I don't think this is worthy
|
|
of consideration:</p>
|
|
<blockquote>
|
|
<pre>template<class T> void swap(T& a, T& b);
|
|
{
|
|
T tmp;
|
|
tmp = a;
|
|
a = b;
|
|
b = tmp;
|
|
}</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.2.2 paragraph 1 from:</p>
|
|
<blockquote>
|
|
<p> Requires: Type T is Assignable (23.1).</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="228"><h3>228. Incorrect specification of "..._byname" facets</h3></a><p>
|
|
<b>Section:</b> 22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p>
|
|
<p>The sections 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
|
|
22.2.1.6 <a href="lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
|
|
definitions of the "..._byname" classes by listing a bunch
|
|
of virtual functions. At the same time, no semantics of these
|
|
functions are defined. Real implementations do not define these
|
|
functions because the functional part of the facets is actually
|
|
implemented in the corresponding base classes and the constructor of
|
|
the "..._byname" version just provides suitable date used by
|
|
these implementations. For example, the 'numpunct' methods just return
|
|
values from a struct. The base class uses a statically initialized
|
|
struct while the derived version reads the contents of this struct
|
|
from a table. However, no virtual function is defined in
|
|
'numpunct_byname'.</p>
|
|
|
|
<p>For most classes this does not impose a problem but specifically
|
|
for 'ctype' it does: The specialization for 'ctype_byname<char>'
|
|
is required because otherwise the semantics would change due to the
|
|
virtual functions defined in the general version for 'ctype_byname':
|
|
In 'ctype<char>' the method 'do_is()' is not virtual but it is
|
|
made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'.
|
|
Thus, a class derived from 'ctype_byname<char>' can tell whether
|
|
this class is specialized or not under the current specification:
|
|
Without the specialization, 'do_is()' is virtual while with
|
|
specialization it is not virtual.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT>
|
|
class ctype_byname : public ctype<charT> {
|
|
public:
|
|
typedef ctype<charT>::mask mask;
|
|
explicit ctype_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~ctype_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class internT, class externT, class stateT>
|
|
class codecvt_byname : public codecvt<internT, externT, stateT> {
|
|
public:
|
|
explicit codecvt_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~codecvt_byname(); // virtual
|
|
};
|
|
}
|
|
</pre>
|
|
<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT>
|
|
class numpunct_byname : public numpunct<charT> {
|
|
// this class is specialized for char and wchar_t.
|
|
public:
|
|
typedef charT char_type;
|
|
typedef basic_string<charT> string_type;
|
|
explicit numpunct_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~numpunct_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT>
|
|
class collate_byname : public collate<charT> {
|
|
public:
|
|
typedef basic_string<charT> string_type;
|
|
explicit collate_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~collate_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT, class InputIterator = istreambuf_iterator<charT> >
|
|
class time_get_byname : public time_get<charT, InputIterator> {
|
|
public:
|
|
typedef time_base::dateorder dateorder;
|
|
typedef InputIterator iter_type</pre>
|
|
<pre> explicit time_get_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~time_get_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
|
|
class time_put_byname : public time_put<charT, OutputIterator>
|
|
{
|
|
public:
|
|
typedef charT char_type;
|
|
typedef OutputIterator iter_type;</pre>
|
|
<pre> explicit time_put_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~time_put_byname(); // virtual
|
|
};
|
|
}"</pre>
|
|
<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT, bool Intl = false>
|
|
class moneypunct_byname : public moneypunct<charT, Intl> {
|
|
public:
|
|
typedef money_base::pattern pattern;
|
|
typedef basic_string<charT> string_type;</pre>
|
|
<pre> explicit moneypunct_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~moneypunct_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
|
|
<pre> namespace std {
|
|
template <class charT>
|
|
class messages_byname : public messages<charT> {
|
|
public:
|
|
typedef messages_base::catalog catalog;
|
|
typedef basic_string<charT> string_type;</pre>
|
|
<pre> explicit messages_byname(const char*, size_t refs = 0);
|
|
protected:
|
|
~messages_byname(); // virtual
|
|
};
|
|
}</pre>
|
|
<p>Remove section 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
|
|
this case only those members are defined to be virtual which are
|
|
defined to be virtual in 'ctype<cT>'.)</p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
|
|
the LWG to solve the underlying problems raised by issue <a href="lwg-closed.html#138">138</a>.]</i></p>
|
|
|
|
<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
|
|
three last virtual functions from <tt>messages_byname</tt>.]</i></p>
|
|
|
|
<hr>
|
|
<a name="230"><h3>230. Assignable specified without also specifying CopyConstructible</h3></a><p>
|
|
<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 26 Apr 2000</p>
|
|
<p>Issue <a href="lwg-defects.html#227">227</a> identified an instance (std::swap) where
|
|
Assignable was specified without also specifying
|
|
CopyConstructible. The LWG asked that the standard be searched to
|
|
determine if the same defect existed elsewhere.</p>
|
|
|
|
<p>There are a number of places (see proposed resolution below) where
|
|
Assignable is specified without also specifying
|
|
CopyConstructible. There are also several cases where both are
|
|
specified. For example, 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
|
|
change "T is Assignable" to "T is CopyConstructible and
|
|
Assignable"
|
|
</p>
|
|
|
|
<p>In 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
|
|
"Key is Assignable" to "Key is
|
|
CopyConstructible and Assignable"<br>
|
|
</p>
|
|
|
|
<p>In 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
|
|
</p>
|
|
<blockquote>
|
|
<p> A class or a built-in type X satisfies the requirements of an
|
|
output iterator if X is an Assignable type (23.1) and also the
|
|
following expressions are valid, as shown in Table 73:
|
|
</p>
|
|
</blockquote>
|
|
<p>to:
|
|
</p>
|
|
<blockquote>
|
|
<p> A class or a built-in type X satisfies the requirements of an
|
|
output iterator if X is a CopyConstructible (20.1.3) and Assignable
|
|
type (23.1) and also the following expressions are valid, as shown in
|
|
Table 73:
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
|
|
the LWG. He asks that the 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
|
|
CopyConstructible is really a requirement and may be
|
|
overspecification.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The original proposed resolution also included changes to input
|
|
iterator, fill, and replace. The LWG believes that those changes are
|
|
not necessary. The LWG considered some blanket statement, where an
|
|
Assignable type was also required to be Copy Constructible, but
|
|
decided against this because fill and replace really don't require the
|
|
Copy Constructible property.</p>
|
|
<hr>
|
|
<a name="232"><h3>232. "depends" poorly defined in 17.4.3.1</h3></a><p>
|
|
<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 18 Apr 2000</p>
|
|
<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
|
|
specializations of standard templates to those that "depend on a
|
|
user-defined name of external linkage."</p>
|
|
<p>This term, however, is not adequately defined, making it possible to
|
|
construct a specialization that is, I believe, technically legal according to
|
|
17.4.3.1/1, but that specializes a standard template for a built-in type such as
|
|
'int'.</p>
|
|
<p>The following code demonstrates the problem:</p>
|
|
<blockquote>
|
|
<pre>#include <algorithm></pre>
|
|
<pre>template<class T> struct X
|
|
{
|
|
typedef T type;
|
|
};</pre>
|
|
<pre>namespace std
|
|
{
|
|
template<> void swap(::X<int>::type& i, ::X<int>::type& j);
|
|
}</pre>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change "user-defined name" to "user-defined
|
|
type".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
|
|
Programming Language</i>. It disallows the example in the issue,
|
|
since the underlying type itself is not user-defined. The only
|
|
possible problem I can see is for non-type templates, but there's no
|
|
possible way for a user to come up with a specialization for bitset,
|
|
for example, that might not have already been specialized by the
|
|
implementor?</p>
|
|
|
|
<p><i>[Toronto: this may be related to issue <a href="lwg-active.html#120">120</a>.]</i></p>
|
|
|
|
<p><i>[post-Toronto: Judy provided the above proposed resolution and
|
|
rationale.]</i></p>
|
|
<hr>
|
|
<a name="234"><h3>234. Typos in allocator definition</h3></a><p>
|
|
<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
|
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
|
|
<tt>destruct()</tt> are described as returns but the functions actually
|
|
return <tt>void</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Substitute "Returns" by "Effect".</p>
|
|
<hr>
|
|
<a name="235"><h3>235. No specification of default ctor for reverse_iterator</h3></a><p>
|
|
<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
|
<p>The declaration of <tt>reverse_iterator</tt> lists a default
|
|
constructor. However, no specification is given what this constructor
|
|
should do.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In section 24.4.1.3.1 <a href="lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
|
|
paragraph:</p>
|
|
<blockquote>
|
|
<p><tt>reverse_iterator()</tt></p>
|
|
|
|
<p>Default initializes <tt>current</tt>. Iterator operations
|
|
applied to the resulting iterator have defined behavior if and
|
|
only if the corresponding operations are defined on a default
|
|
constructed iterator of type <tt>Iterator</tt>.</p>
|
|
</blockquote>
|
|
<p><i>[pre-Copenhagen: Dietmar provide wording for proposed
|
|
resolution.]</i></p>
|
|
<hr>
|
|
<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p>
|
|
<b>Section:</b> 23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
|
<p>The complexity specification in paragraph 6 says that the complexity
|
|
is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
|
|
defined on iterators this term is in general undefined because it
|
|
would have to be <tt>last - first</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change paragraph 6 from</p>
|
|
<blockquote>Linear in <i>first - last</i>.</blockquote>
|
|
<p>to become</p>
|
|
<blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
|
|
<hr>
|
|
<a name="238"><h3>238. Contradictory results of stringbuf initialization.</h3></a><p>
|
|
<b>Section:</b> 27.7.1.1 <a href="lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 11 May 2000</p>
|
|
<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
|
|
'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
|
|
that far but consider this code:</p>
|
|
|
|
<pre>
|
|
std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
|
|
std::cout << "'" << sbuf.str() << "'\n";
|
|
</pre>
|
|
|
|
<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
|
|
the output sequence nor the input sequence is initialized and
|
|
paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
|
|
returns the input or the output sequence. None of them is initialized,
|
|
ie. both are empty, in which case the return from <tt>str()</tt> is
|
|
defined to be <tt>basic_string<cT>()</tt>.</p>
|
|
|
|
<p>However, probably only test cases in some testsuites will detect this
|
|
"problem"...</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove 27.7.1.1 paragraph 4.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
|
|
we fixed it, it would say just the same thing as text that's already
|
|
in the standard.</p>
|
|
<hr>
|
|
<a name="239"><h3>239. Complexity of unique() and/or unique_copy incorrect</h3></a><p>
|
|
<b>Section:</b> 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
|
<p>The complexity of unique and unique_copy are inconsistent with each
|
|
other and inconsistent with the implementations. The standard
|
|
specifies:</p>
|
|
|
|
<p>for unique():</p>
|
|
|
|
<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
|
|
(last - first) - 1 applications of the corresponding predicate, otherwise
|
|
no applications of the predicate.</blockquote>
|
|
|
|
<p>for unique_copy():</p>
|
|
|
|
<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
|
|
predicate.</blockquote>
|
|
|
|
<p>
|
|
The implementations do it the other way round: unique() applies the
|
|
predicate last-first times and unique_copy() applies it last-first-1
|
|
times.</p>
|
|
|
|
<p>As both algorithms use the predicate for pair-wise comparison of
|
|
sequence elements I don't see a justification for unique_copy()
|
|
applying the predicate last-first times, especially since it is not
|
|
specified to which pair in the sequence the predicate is applied
|
|
twice.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change both complexity sections in 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
|
|
|
|
<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
|
|
applications of the corresponding predicate.</blockquote>
|
|
|
|
<hr>
|
|
<a name="240"><h3>240. Complexity of adjacent_find() is meaningless</h3></a><p>
|
|
<b>Section:</b> 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
|
<p>The complexity section of adjacent_find is defective:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
template <class ForwardIterator>
|
|
ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
|
|
BinaryPredicate pred);
|
|
</pre>
|
|
|
|
<p>-1- Returns: The first iterator i such that both i and i + 1 are in
|
|
the range [first, last) for which the following corresponding
|
|
conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
|
|
last if no such iterator is found.</p>
|
|
|
|
<p>-2- Complexity: Exactly find(first, last, value) - first applications
|
|
of the corresponding predicate.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>In the Complexity section, it is not defined what "value"
|
|
is supposed to mean. My best guess is that "value" means an
|
|
object for which one of the conditions pred(*i,value) or
|
|
pred(value,*i) is true, where i is the iterator defined in the Returns
|
|
section. However, the value type of the input sequence need not be
|
|
equality-comparable and for this reason the term find(first, last,
|
|
value) - first is meaningless.</p>
|
|
|
|
<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
|
|
find_if(first, last, bind1st(pred,*i)) - first might come closer to
|
|
the intended specification. Binders can only be applied to function
|
|
objects that have the function call operator declared const, which is
|
|
not required of predicates because they can have non-const data
|
|
members. For this reason, a specification using a binder could only be
|
|
an "as-if" specification.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the complexity section in 25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
|
|
<blockquote>
|
|
For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
|
|
(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
|
|
corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
|
|
return value.
|
|
</blockquote>
|
|
|
|
<p><i>[Copenhagen: the original resolution specified an upper
|
|
bound. The LWG preferred an exact count.]</i></p>
|
|
|
|
<hr>
|
|
<a name="242"><h3>242. Side effects of function objects</h3></a><p>
|
|
<b>Section:</b> 25.2.3 <a href="lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
|
<p>The algorithms transform(), accumulate(), inner_product(),
|
|
partial_sum(), and adjacent_difference() require that the function
|
|
object supplied to them shall not have any side effects.</p>
|
|
|
|
<p>The standard defines a side effect in 1.9 <a href="intro.html#intro.execution"> [intro.execution]</a> as:</p>
|
|
<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
|
|
modifying an object, calling a library I/O function, or calling a function
|
|
that does any of those operations are all side effects, which are changes
|
|
in the state of the execution environment.</blockquote>
|
|
|
|
<p>As a consequence, the function call operator of a function object supplied
|
|
to any of the algorithms listed above cannot modify data members, cannot
|
|
invoke any function that has a side effect, and cannot even create and
|
|
modify temporary objects. It is difficult to imagine a function object
|
|
that is still useful under these severe limitations. For instance, any
|
|
non-trivial transformator supplied to transform() might involve creation
|
|
and modification of temporaries, which is prohibited according to the current
|
|
wording of the standard.</p>
|
|
|
|
<p>On the other hand, popular implementations of these algorithms exhibit
|
|
uniform and predictable behavior when invoked with a side-effect-producing
|
|
function objects. It looks like the strong requirement is not needed for
|
|
efficient implementation of these algorithms.</p>
|
|
|
|
<p>The requirement of side-effect-free function objects could be
|
|
replaced by a more relaxed basic requirement (which would hold for all
|
|
function objects supplied to any algorithm in the standard library):</p>
|
|
<blockquote>A function objects supplied to an algorithm shall not invalidate
|
|
any iterator or sequence that is used by the algorithm. Invalidation of
|
|
the sequence includes destruction of the sorting order if the algorithm
|
|
relies on the sorting order (see section 25.3 - Sorting and related operations
|
|
[lib.alg.sorting]).</blockquote>
|
|
|
|
<p>I can't judge whether it is intended that the function objects supplied
|
|
to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
|
|
shall not modify sequence elements through dereferenced iterators.</p>
|
|
|
|
<p>It is debatable whether this issue is a defect or a change request.
|
|
Since the consequences for user-supplied function objects are drastic and
|
|
limit the usefulness of the algorithms significantly I would consider it
|
|
a defect.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>Things to notice about these changes:</i></p>
|
|
|
|
<ol>
|
|
<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
|
|
are intentional. we want to prevent side-effects from
|
|
invalidating the end iterators.</i>
|
|
</li>
|
|
|
|
<li> <i>That has the unintentional side-effect of prohibiting
|
|
modification of the end element as a side-effect. This could
|
|
conceivably be significant in some cases.</i>
|
|
</li>
|
|
|
|
<li> <i>The wording also prevents side-effects from modifying elements
|
|
of the output sequence. I can't imagine why anyone would want
|
|
to do this, but it is arguably a restriction that implementors
|
|
don't need to place on users.</i>
|
|
</li>
|
|
|
|
<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
|
|
and simple, but would require more verbiage.</i>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Change 25.2.3/2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: op and binary_op shall not have any side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: in the ranges [first1, last1], [first2, first2 +
|
|
(last1 - first1)] and [result, result + (last1- first1)], op and
|
|
binary_op shall neither modify elements nor invalidate iterators or
|
|
subranges.
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
|
|
<p>Change 25.2.3/2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: op and binary_op shall not have any side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: op and binary_op shall not invalidate iterators or
|
|
subranges, or modify elements in the ranges [first1, last1],
|
|
[first2, first2 + (last1 - first1)], and [result, result + (last1
|
|
- first1)].
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
|
|
<p>Change 26.4.1/2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
|
types. binary_op shall not cause side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
|
(lib.copyconstructible) and Assignable
|
|
(lib.container.requirements) types. In the range [first, last],
|
|
binary_op shall neither modify elements nor invalidate iterators
|
|
or subranges.
|
|
[Footnote: The use of a fully closed range is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
<p>Change 26.4.2/2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
|
types. binary_op1 and binary_op2 shall not cause side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
|
types. In the ranges [first, last] and [first2, first2 + (last -
|
|
first)], binary_op1 and binary_op2 shall neither modify elements
|
|
nor invalidate iterators or subranges.
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
|
|
<p>Change 26.4.3/4 from:</p>
|
|
|
|
<blockquote>
|
|
-4- Requires: binary_op is expected not to have any side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-4- Requires: In the ranges [first, last] and [result, result +
|
|
(last - first)], binary_op shall neither modify elements nor
|
|
invalidate iterators or subranges.
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
<p>Change 26.4.4/2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: binary_op shall not have any side effects.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-2- Requires: In the ranges [first, last] and [result, result +
|
|
(last - first)], binary_op shall neither modify elements nor
|
|
invalidate iterators or subranges.
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
|
</blockquote>
|
|
|
|
<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
|
|
|
|
<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
|
|
added footnotes pointing out that the use of closed ranges was
|
|
intentional.]</i></p>
|
|
|
|
<hr>
|
|
<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p>
|
|
<p>basic_istream<>::get(), and basic_istream<>::getline(),
|
|
are unclear with respect to the behavior and side-effects of the named
|
|
functions in case of an error.</p>
|
|
|
|
<p>27.6.1.3, p1 states that "... If the sentry object returns
|
|
true, when converted to a value of type bool, the function endeavors
|
|
to obtain the requested input..." It is not clear from this (or
|
|
the rest of the paragraph) what precisely the behavior should be when
|
|
the sentry ctor exits by throwing an exception or when the sentry
|
|
object returns false. In particular, what is the number of characters
|
|
extracted that gcount() returns supposed to be?</p>
|
|
|
|
<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
|
|
"... In any case, it then stores a null character (using
|
|
charT()) into the next successive location of the array." Is not
|
|
clear whether this sentence applies if either of the conditions above
|
|
holds (i.e., when sentry fails).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to 27.6.1.3, p1 after the sentence</p>
|
|
|
|
<blockquote>
|
|
"... If the sentry object returns true, when converted to a value of
|
|
type bool, the function endeavors to obtain the requested input."
|
|
</blockquote>
|
|
|
|
<p>the following</p>
|
|
|
|
|
|
<blockquote>
|
|
"Otherwise, if the sentry constructor exits by throwing an exception or
|
|
if the sentry object returns false, when converted to a value of type
|
|
bool, the function returns without attempting to obtain any input. In
|
|
either case the number of extracted characters is set to 0; unformatted
|
|
input functions taking a character array of non-zero size as an argument
|
|
shall also store a null character (using charT()) in the first location
|
|
of the array."
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Although the general philosophy of the input functions is that the
|
|
argument should not be modified upon failure, <tt>getline</tt>
|
|
historically added a terminating null unconditionally. Most
|
|
implementations still do that. Earlier versions of the draft standard
|
|
had language that made this an unambiguous requirement; those words
|
|
were moved to a place where their context made them less clear. See
|
|
Jerry Schwarz's message c++std-lib-7618.</p>
|
|
<hr>
|
|
<a name="248"><h3>248. time_get fails to set eofbit</h3></a><p>
|
|
<b>Section:</b> 22.2.5 <a href="lib-locales.html#lib.category.time"> [lib.category.time]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2000</p>
|
|
<p>There is no requirement that any of time_get member functions set
|
|
ios::eofbit when they reach the end iterator while parsing their input.
|
|
Since members of both the num_get and money_get facets are required to
|
|
do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
|
|
should follow the same requirement for consistency.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
|
|
|
|
<blockquote>
|
|
If the end iterator is reached during parsing by any of the get()
|
|
member functions, the member sets ios_base::eofbit in err.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Two alternative resolutions were proposed. The LWG chose this one
|
|
because it was more consistent with the way eof is described for other
|
|
input facets.</p>
|
|
<hr>
|
|
<a name="250"><h3>250. splicing invalidates iterators</h3></a><p>
|
|
<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p>
|
|
<p>
|
|
Section 23.2.2.4 [lib.list.ops] states that
|
|
</p>
|
|
<pre>
|
|
void splice(iterator position, list<T, Allocator>& x);
|
|
</pre>
|
|
<p>
|
|
<i>invalidates</i> all iterators and references to list <tt>x</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
This is unnecessary and defeats an important feature of splice. In
|
|
fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
|
|
after <tt>splice</tt>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Add a footnote to 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
|
|
<blockquote>
|
|
[<i>Footnote:</i> As specified in 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
|
|
4-5, the semantics described in this clause applies only to the case
|
|
where allocators compare equal. --end footnote]
|
|
</blockquote>
|
|
|
|
<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
|
|
<blockquote>
|
|
Effects: Inserts the contents of x before position and x becomes
|
|
empty. Pointers and references to the moved elements of x now refer to
|
|
those same elements but as members of *this. Iterators referring to the
|
|
moved elements will continue to refer to their elements, but they now
|
|
behave as iterators into *this, not into x.
|
|
</blockquote>
|
|
|
|
<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
|
|
<blockquote>
|
|
Effects: Inserts an element pointed to by i from list x before
|
|
position and removes the element from x. The result is unchanged if
|
|
position == i or position == ++i. Pointers and references to *i continue
|
|
to refer to this same element but as a member of *this. Iterators to *i
|
|
(including i itself) continue to refer to the same element, but now
|
|
behave as iterators into *this, not into x.
|
|
</blockquote>
|
|
|
|
<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
|
|
<blockquote>
|
|
Requires: [first, last) is a valid range in x. The result is
|
|
undefined if position is an iterator in the range [first, last).
|
|
Pointers and references to the moved elements of x now refer to those
|
|
same elements but as members of *this. Iterators referring to the moved
|
|
elements will continue to refer to their elements, but they now behave as
|
|
iterators into *this, not into x.
|
|
</blockquote>
|
|
|
|
<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The original proposed resolution said that iterators and references
|
|
would remain "valid". The new proposed resolution clarifies what that
|
|
means. Note that this only applies to the case of equal allocators.
|
|
From 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
|
|
allocators compare nonequal is outside the scope of the standard.</p>
|
|
<hr>
|
|
<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p>
|
|
<b>Section:</b> 27.7.1 <a href="lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
|
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
|
|
doesn't list a typedef for the template parameter
|
|
<tt>Allocator</tt>. This makes it impossible to determine the type of
|
|
the allocator at compile time. It's also inconsistent with all other
|
|
template classes in the library that do provide a typedef for the
|
|
<tt>Allocator</tt> parameter.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
|
|
basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
|
|
basic_stringstream (27.7.4) the typedef:</p>
|
|
<pre>
|
|
typedef Allocator allocator_type;
|
|
</pre>
|
|
<hr>
|
|
<a name="252"><h3>252. missing casts/C-style casts used in iostreams</h3></a><p>
|
|
<b>Section:</b> 27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
|
<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
|
|
const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
|
|
The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
|
|
D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
|
|
the cast altogether.</p>
|
|
|
|
<p>C-style casts have not been deprecated, so the first part of this
|
|
issue is stylistic rather than a matter of correctness.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.7.2.2, p1 replace </p>
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
|
|
<p>In 27.7.3.2, p1 replace</p>
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
<p>In 27.7.6, p1, replace</p>
|
|
<pre> -1- Returns: &sb</pre>
|
|
|
|
<p>with</p>
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
|
|
|
<p>In D.7.2.2, p1 replace</p>
|
|
<pre> -2- Returns: &sb. </pre>
|
|
|
|
<p>with</p>
|
|
<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre>
|
|
<hr>
|
|
<a name="256"><h3>256. typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p>
|
|
<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 21 Aug 2000</p>
|
|
<p>
|
|
27.4.4.2, p17 says
|
|
</p>
|
|
|
|
<blockquote>
|
|
-17- Before copying any parts of rhs, calls each registered callback
|
|
pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
|
|
exceptions() have been replaced, calls each callback pair that was
|
|
copied from rhs as (*fn)(copy_event,*this,index).
|
|
</blockquote>
|
|
|
|
<p>
|
|
The name copy_event isn't defined anywhere. The intended name was
|
|
copyfmt_event.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
|
|
<hr>
|
|
<a name="259"><h3>259. <tt>basic_string::operator[]</tt> and const correctness</h3></a><p>
|
|
<b>Section:</b> 21.3.4 <a href="lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Chris Newton <b>Date:</b> 27 Aug 2000</p>
|
|
<p>
|
|
<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
|
|
</p>
|
|
|
|
<p>
|
|
The standard's description of <tt>basic_string<>::operator[]</tt>
|
|
seems to violate const correctness.
|
|
</p>
|
|
|
|
<p>
|
|
The standard (21.3.4/1) says that "If <tt>pos < size()</tt>,
|
|
returns <tt>data()[pos]</tt>." The types don't work. The
|
|
return value of <tt>data()</tt> is <tt>const charT*</tt>, but
|
|
<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In section 21.3.4, paragraph 1, change
|
|
"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
|
|
<i>pos</i>)</tt>".
|
|
</p>
|
|
<hr>
|
|
<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
|
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
|
|
it as returning the iterator by value. 24.5.1.2, p5 shows the same
|
|
operator as returning the iterator by reference. That's incorrect
|
|
given the Effects clause below (since a temporary is returned). The
|
|
`&' is probably just a typo.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the declaration in 24.5.1.2, p5 from</p>
|
|
<pre>
|
|
istream_iterator<T,charT,traits,Distance>& operator++(int);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
istream_iterator<T,charT,traits,Distance> operator++(int);
|
|
</pre>
|
|
<p>(that is, remove the `&').</p>
|
|
<hr>
|
|
<a name="261"><h3>261. Missing description of <tt>istream_iterator::operator!=</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 24.5.1.2 <a href="lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
|
<p>
|
|
24.5.1, p3 lists the synopsis for
|
|
</p>
|
|
|
|
<pre>
|
|
template <class T, class charT, class traits, class Distance>
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
|
</pre>
|
|
|
|
<p>
|
|
but there is no description of what the operator does (i.e., no Effects
|
|
or Returns clause) in 24.5.1.2.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add paragraph 7 to the end of section 24.5.1.2 with the following text:
|
|
</p>
|
|
|
|
<pre>
|
|
template <class T, class charT, class traits, class Distance>
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
|
</pre>
|
|
|
|
<p>-7- Returns: !(x == y).</p>
|
|
<hr>
|
|
<a name="262"><h3>262. Bitmask operator ~ specified incorrectly</h3></a><p>
|
|
<b>Section:</b> 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 03 Sep 2000</p>
|
|
<p>
|
|
The ~ operation should be applied after the cast to int_type.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
|
|
</p>
|
|
|
|
<pre>
|
|
bitmask operator~ ( bitmask X )
|
|
{ return static_cast< bitmask>(static_cast<int_type>(~ X)); }
|
|
</pre>
|
|
|
|
<p>
|
|
to:
|
|
</p>
|
|
|
|
<pre>
|
|
bitmask operator~ ( bitmask X )
|
|
{ return static_cast< bitmask>(~static_cast<int_type>(X)); }
|
|
</pre>
|
|
<hr>
|
|
<a name="263"><h3>263. Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p>
|
|
<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Kevlin Henney <b>Date:</b> 04 Sep 2000</p>
|
|
<p>
|
|
The note in paragraph 6 suggests that the invalidation rules for
|
|
references, pointers, and iterators in paragraph 5 permit a reference-
|
|
counted implementation (actually, according to paragraph 6, they permit
|
|
a "reference counted implementation", but this is a minor editorial fix).
|
|
</p>
|
|
|
|
<p>
|
|
However, the last sub-bullet is so worded as to make a reference-counted
|
|
implementation unviable. In the following example none of the
|
|
conditions for iterator invalidation are satisfied:
|
|
</p>
|
|
|
|
<pre>
|
|
// first example: "*******************" should be printed twice
|
|
string original = "some arbitrary text", copy = original;
|
|
const string & alias = original;
|
|
|
|
string::const_iterator i = alias.begin(), e = alias.end();
|
|
for(string::iterator j = original.begin(); j != original.end(); ++j)
|
|
*j = '*';
|
|
while(i != e)
|
|
cout << *i++;
|
|
cout << endl;
|
|
cout << original << endl;
|
|
</pre>
|
|
|
|
<p>
|
|
Similarly, in the following example:
|
|
</p>
|
|
|
|
<pre>
|
|
// second example: "some arbitrary text" should be printed out
|
|
string original = "some arbitrary text", copy = original;
|
|
const string & alias = original;
|
|
|
|
string::const_iterator i = alias.begin();
|
|
original.begin();
|
|
while(i != alias.end())
|
|
cout << *i++;
|
|
</pre>
|
|
|
|
<p>
|
|
I have tested this on three string implementations, two of which were
|
|
reference counted. The reference-counted implementations gave
|
|
"surprising behavior" because they invalidated iterators on
|
|
the first call to non-const begin since construction. The current
|
|
wording does not permit such invalidation because it does not take
|
|
into account the first call since construction, only the first call
|
|
since various member and non-member function calls.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the following sentence in 21.3 paragraph 5 from
|
|
</p>
|
|
|
|
<blockquote>
|
|
Subsequent to any of the above uses except the forms of insert() and
|
|
erase() which return iterators, the first call to non-const member
|
|
functions operator[](), at(), begin(), rbegin(), end(), or rend().
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Following construction or any of the above uses, except the forms of
|
|
insert() and erase() that return iterators, the first call to non-
|
|
const member functions operator[](), at(), begin(), rbegin(), end(),
|
|
or rend().
|
|
</blockquote>
|
|
<hr>
|
|
<a name="264"><h3>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John Potter <b>Date:</b> 07 Sep 2000</p>
|
|
<p>
|
|
Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
|
|
Consider inserting a sorted range of even integers into a set<int> containing the odd
|
|
integers in the same range.
|
|
</p>
|
|
|
|
<p><i>Related issue: <a href="lwg-closed.html#102">102</a></i></p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In Table 69, in section 23.1.2, change the complexity clause for
|
|
insertion of a range from "N log(size() + N) (N is the distance
|
|
from i to j) in general; linear if [i, j) is sorted according to
|
|
value_comp()" to "N log(size() + N), where N is the distance
|
|
from i to j".
|
|
</p>
|
|
|
|
<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
|
|
parens in the revised wording.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Testing for valid insertions could be less efficient than simply
|
|
inserting the elements when the range is not both sorted and between
|
|
two adjacent existing elements; this could be a QOI issue.
|
|
</p>
|
|
|
|
<p>
|
|
The LWG considered two other options: (a) specifying that the
|
|
complexity was linear if [i, j) is sorted according to value_comp()
|
|
and between two adjacent existing elements; or (b) changing to
|
|
Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
|
|
number of elements which do not insert immediately after the previous
|
|
element from [i, j) including the first). The LWG felt that, since
|
|
we can't guarantee linear time complexity whenever the range to be
|
|
inserted is sorted, it's more trouble than it's worth to say that it's
|
|
linear in some special cases.
|
|
</p>
|
|
<hr>
|
|
<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p>
|
|
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 11 Sep 2000</p>
|
|
<p>
|
|
I don't see any requirements on the types of the elements of the
|
|
std::pair container in 20.2.2. From the descriptions of the member
|
|
functions it appears that they must at least satisfy the requirements of
|
|
20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
|
|
the case of the [in]equality operators also the requirements of 20.1.1
|
|
[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
|
|
</p>
|
|
|
|
<p>
|
|
I believe that the the CopyConstructible requirement is unnecessary in
|
|
the case of 20.2.2, p2.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the Effects clause in 20.2.2, p2 from</p>
|
|
|
|
<blockquote>
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
|
first(T1()), second(T2()) {} </tt>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
|
first(), second() {} </tt>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The existing specification of pair's constructor appears to be a
|
|
historical artifact: there was concern that pair's members be properly
|
|
zero-initialized when they are built-in types. At one time there was
|
|
uncertainty about whether they would be zero-initialized if the
|
|
default constructor was written the obvious way. This has been
|
|
clarified by core issue 178, and there is no longer any doubt that
|
|
the straightforward implementation is correct.</p>
|
|
<hr>
|
|
<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p>
|
|
<b>Section:</b> 18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 24 Sep 2000</p>
|
|
<p>
|
|
The synopsis for std::bad_exception lists the function ~bad_exception()
|
|
but there is no description of what the function does (the Effects
|
|
clause is missing).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Remove the destructor from the class synopses of
|
|
<tt>bad_alloc</tt> (18.4.2.1 <a href="lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
|
|
<tt>bad_cast</tt> (18.5.2 <a href="lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
|
|
<tt>bad_typeid</tt> (18.5.3 <a href="lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
|
|
and <tt>bad_exception</tt> (18.6.2.1 <a href="lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
This is a general problem with the exception classes in clause 18.
|
|
The proposed resolution is to remove the destructors from the class
|
|
synopses, rather than to document the destructors' behavior, because
|
|
removing them is more consistent with how exception classes are
|
|
described in clause 19.
|
|
</p>
|
|
<hr>
|
|
<a name="268"><h3>268. Typo in locale synopsis</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
|
|
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
|
|
the semicolons after the declarations of the default ctor
|
|
locale::locale() and the copy ctor locale::locale(const locale&)
|
|
are missing.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the missing semicolons, i.e., change</p>
|
|
|
|
<pre>
|
|
// construct/copy/destroy:
|
|
locale() throw()
|
|
locale(const locale& other) throw()
|
|
</pre>
|
|
|
|
<p>in the synopsis in 22.1.1 to</p>
|
|
|
|
<pre>
|
|
// construct/copy/destroy:
|
|
locale() throw();
|
|
locale(const locale& other) throw();
|
|
</pre>
|
|
<hr>
|
|
<a name="270"><h3>270. Binary search requirements overly strict</h3></a><p>
|
|
<b>Section:</b> 25.3.3 <a href="lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Oct 2000</p>
|
|
<p>
|
|
Each of the four binary search algorithms (lower_bound, upper_bound,
|
|
equal_range, binary_search) has a form that allows the user to pass a
|
|
comparison function object. According to 25.3, paragraph 2, that
|
|
comparison function object has to be a strict weak ordering.
|
|
</p>
|
|
|
|
<p>
|
|
This requirement is slightly too strict. Suppose we are searching
|
|
through a sequence containing objects of type X, where X is some
|
|
large record with an integer key. We might reasonably want to look
|
|
up a record by key, in which case we would want to write something
|
|
like this:
|
|
</p>
|
|
<pre>
|
|
struct key_comp {
|
|
bool operator()(const X& x, int n) const {
|
|
return x.key() < n;
|
|
}
|
|
}
|
|
|
|
std::lower_bound(first, last, 47, key_comp());
|
|
</pre>
|
|
|
|
<p>
|
|
key_comp is not a strict weak ordering, but there is no reason to
|
|
prohibit its use in lower_bound.
|
|
</p>
|
|
|
|
<p>
|
|
There's no difficulty in implementing lower_bound so that it allows
|
|
the use of something like key_comp. (It will probably work unless an
|
|
implementor takes special pains to forbid it.) What's difficult is
|
|
formulating language in the standard to specify what kind of
|
|
comparison function is acceptable. We need a notion that's slightly
|
|
more general than that of a strict weak ordering, one that can encompass
|
|
a comparison function that involves different types. Expressing that
|
|
notion may be complicated.
|
|
</p>
|
|
|
|
<p><i>Additional questions raised at the Toronto meeting:</i></p>
|
|
<ul>
|
|
<li> Do we really want to specify what ordering the implementor must
|
|
use when calling the function object? The standard gives
|
|
specific expressions when describing these algorithms, but it also
|
|
says that other expressions (with different argument order) are
|
|
equivalent.</li>
|
|
<li> If we are specifying ordering, note that the standard uses both
|
|
orderings when describing <tt>equal_range</tt>.</li>
|
|
<li> Are we talking about requiring these algorithms to work properly
|
|
when passed a binary function object whose two argument types
|
|
are not the same, or are we talking about requirements when
|
|
they are passed a binary function object with several overloaded
|
|
versions of <tt>operator()</tt>?</li>
|
|
<li> The definition of a strict weak ordering does not appear to give
|
|
any guidance on issues of overloading; it only discusses expressions,
|
|
and all of the values in these expressions are of the same type.
|
|
Some clarification would seem to be in order.</li>
|
|
</ul>
|
|
|
|
<p><i>Additional discussion from Copenhagen:</i></p>
|
|
<ul>
|
|
<li>It was generally agreed that there is a real defect here: if
|
|
the predicate is merely required to be a Strict Weak Ordering, then
|
|
it's possible to pass in a function object with an overloaded
|
|
operator(), where the version that's actually called does something
|
|
completely inappropriate. (Such as returning a random value.)</li>
|
|
|
|
<li>An alternative formulation was presented in a paper distributed by
|
|
David Abrahams at the meeting, "Binary Search with Heterogeneous
|
|
Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
|
|
predicate as a Strict Weak Ordering acting on a sorted sequence, view
|
|
the predicate/value pair as something that partitions a sequence.
|
|
This is almost equivalent to saying that we should view binary search
|
|
as if we are given a unary predicate and a sequence, such that f(*p)
|
|
is true for all p below a specific point and false for all p above it.
|
|
The proposed resolution is based on that alternative formulation.</li>
|
|
</ul>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
|
|
|
|
<blockquote>
|
|
3 For all algorithms that take Compare, there is a version that uses
|
|
operator< instead. That is, comp(*i, *j) != false defaults to *i <
|
|
*j != false. For the algorithms to work correctly, comp has to
|
|
induce a strict weak ordering on the values.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
3 For all algorithms that take Compare, there is a version that uses
|
|
operator< instead. That is, comp(*i, *j) != false defaults to *i
|
|
< *j != false. For algorithms other than those described in
|
|
lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
|
|
a strict weak ordering on the values.
|
|
</blockquote>
|
|
|
|
<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
|
|
|
|
<blockquote>
|
|
-6- A sequence [start, finish) is partitioned with respect to an
|
|
expression f(e) if there exists an integer n such that
|
|
for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
|
|
and only if i < n.
|
|
</blockquote>
|
|
|
|
<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
|
|
|
|
<blockquote>
|
|
-1- All of the algorithms in this section are versions of binary
|
|
search and assume that the sequence being searched is in order
|
|
according to the implied or explicit comparison function. They work
|
|
on non-random access iterators minimizing the number of
|
|
comparisons, which will be logarithmic for all types of
|
|
iterators. They are especially appropriate for random access
|
|
iterators, because these algorithms do a logarithmic number of
|
|
steps through the data structure. For non-random access iterators
|
|
they execute a linear number of steps.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-1- All of the algorithms in this section are versions of binary
|
|
search and assume that the sequence being searched is partitioned
|
|
with respect to an expression formed by binding the search key to
|
|
an argument of the implied or explicit comparison function. They
|
|
work on non-random access iterators minimizing the number of
|
|
comparisons, which will be logarithmic for all types of
|
|
iterators. They are especially appropriate for random access
|
|
iterators, because these algorithms do a logarithmic number of
|
|
steps through the data structure. For non-random access iterators
|
|
they execute a linear number of steps.
|
|
</blockquote>
|
|
|
|
<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: Type T is LessThanComparable
|
|
(lib.lessthancomparable).
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
|
respect to the expression e < value or comp(e, value)
|
|
</blockquote>
|
|
|
|
|
|
<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
-2- Effects: Finds the first position into which value can be
|
|
inserted without violating the ordering.
|
|
</blockquote>
|
|
|
|
<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
|
respect to the expression !(value < e) or !comp(value, e)
|
|
</blockquote>
|
|
|
|
<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
|
|
|
|
<blockquote>
|
|
-2- Effects: Finds the furthermost position into which value can be
|
|
inserted without violating the ordering.
|
|
</blockquote>
|
|
|
|
<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: Type T is LessThanComparable
|
|
(lib.lessthancomparable).
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
|
respect to the expressions e < value and !(value < e) or
|
|
comp(e, value) and !comp(value, e). Also, for all elements e of
|
|
[first, last), e < value implies !(value < e) or comp(e,
|
|
value) implies !comp(value, e)
|
|
</blockquote>
|
|
|
|
<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
|
|
|
|
<blockquote>
|
|
-2- Effects: Finds the largest subrange [i, j) such that the value
|
|
can be inserted at any iterator k in it without violating the
|
|
ordering. k satisfies the corresponding conditions: !(*k < value)
|
|
&& !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
|
|
false.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre>
|
|
-2- Returns:
|
|
make_pair(lower_bound(first, last, value),
|
|
upper_bound(first, last, value))
|
|
or
|
|
make_pair(lower_bound(first, last, value, comp),
|
|
upper_bound(first, last, value, comp))
|
|
</pre>
|
|
|
|
<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: Type T is LessThanComparable
|
|
(lib.lessthancomparable).
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
|
respect to the expressions e < value and !(value < e) or comp(e,
|
|
value) and !comp(value, e). Also, for all elements e of [first,
|
|
last), e < value implies !(value < e) or comp(e, value) implies
|
|
!comp(value, e)
|
|
</blockquote>
|
|
|
|
<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
|
|
|
|
<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and
|
|
changed the "other than those described in" wording.) Also, the LWG
|
|
decided to accept the "optional" part.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The proposed resolution reinterprets binary search. Instead of
|
|
thinking about searching for a value in a sorted range, we view that
|
|
as an important special case of a more general algorithm: searching
|
|
for the partition point in a partitioned range.</p>
|
|
|
|
<p>We also add a guarantee that the old wording did not: we ensure
|
|
that the upper bound is no earlier than the lower bound, that
|
|
the pair returned by equal_range is a valid range, and that the first
|
|
part of that pair is the lower bound.</p>
|
|
<hr>
|
|
<a name="271"><h3>271. basic_iostream missing typedefs</h3></a><p>
|
|
<b>Section:</b> 27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
|
<p>
|
|
Class template basic_iostream has no typedefs. The typedefs it
|
|
inherits from its base classes can't be used, since (for example)
|
|
basic_iostream<T>::traits_type is ambiguous.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Add the following to basic_iostream's class synopsis in
|
|
27.6.1.5 <a href="lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
|
|
|
|
<pre>
|
|
// types:
|
|
typedef charT char_type;
|
|
typedef typename traits::int_type int_type;
|
|
typedef typename traits::pos_type pos_type;
|
|
typedef typename traits::off_type off_type;
|
|
typedef traits traits_type;
|
|
</pre>
|
|
<hr>
|
|
<a name="272"><h3>272. Missing parentheses around subexpression</h3></a><p>
|
|
<b>Section:</b> 27.4.4.3 <a href="lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
|
<p>
|
|
27.4.4.3, p4 says about the postcondition of the function: If
|
|
rdbuf()!=0 then state == rdstate(); otherwise
|
|
rdstate()==state|ios_base::badbit.
|
|
</p>
|
|
|
|
<p>
|
|
The expression on the right-hand-side of the operator==() needs to be
|
|
parenthesized in order for the whole expression to ever evaluate to
|
|
anything but non-zero.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add parentheses like so: rdstate()==(state|ios_base::badbit).
|
|
</p>
|
|
<hr>
|
|
<a name="273"><h3>273. Missing ios_base qualification on members of a dependent class</h3></a><p>
|
|
<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
|
<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
|
|
27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
|
|
That's incorrect since the names are members of a dependent base
|
|
class (14.6.2 [temp.dep]) and thus not visible.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Qualify the names with the name of the class of which they are
|
|
members, i.e., ios_base.</p>
|
|
<hr>
|
|
<a name="274"><h3>274. a missing/impossible allocator requirement</h3></a><p>
|
|
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
|
<p>
|
|
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
|
|
any type. But the synopsis in 20.4.1 calls for allocator<>::address() to
|
|
be overloaded on reference and const_reference, which is ill-formed for
|
|
all T = const U. In other words, this won't work:
|
|
</p>
|
|
|
|
<p>
|
|
template class std::allocator<const int>;
|
|
</p>
|
|
|
|
<p>
|
|
The obvious solution is to disallow specializations of allocators on
|
|
const types. However, while containers' elements are required to be
|
|
assignable (which rules out specializations on const T's), I think that
|
|
allocators might perhaps be potentially useful for const values in other
|
|
contexts. So if allocators are to allow const types a partial
|
|
specialization of std::allocator<const T> would probably have to be
|
|
provided.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
|
|
|
|
<blockquote>
|
|
any type
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
<blockquote>
|
|
any non-const, non-reference type
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: previous proposed resolution was "any non-const,
|
|
non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
Two resolutions were originally proposed: one that partially
|
|
specialized std::allocator for const types, and one that said an
|
|
allocator's value type may not be const. The LWG chose the second.
|
|
The first wouldn't be appropriate, because allocators are intended for
|
|
use by containers, and const value types don't work in containers.
|
|
Encouraging the use of allocators with const value types would only
|
|
lead to unsafe code.
|
|
</p>
|
|
<p>
|
|
The original text for proposed resolution 2 was modified so that it
|
|
also forbids volatile types and reference types.
|
|
</p>
|
|
|
|
<p><i>[Curaçao: LWG double checked and believes volatile is correctly
|
|
excluded from the PR.]</i></p>
|
|
|
|
<hr>
|
|
<a name="275"><h3>275. Wrong type in num_get::get() overloads</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 02 Nov 2000</p>
|
|
<p>
|
|
In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
|
|
There are eight overloads, all of which are identical except for the
|
|
last parameter. The overloads are:
|
|
</p>
|
|
<ul>
|
|
<li> long& </li>
|
|
<li> unsigned short& </li>
|
|
<li> unsigned int& </li>
|
|
<li> unsigned long& </li>
|
|
<li> short& </li>
|
|
<li> double& </li>
|
|
<li> long double& </li>
|
|
<li> void*& </li>
|
|
</ul>
|
|
|
|
<p>
|
|
There is a similar list, in 22.2.2.1.2, of overloads for
|
|
num_get<>::do_get(). In this list, the last parameter has
|
|
the types:
|
|
</p>
|
|
<ul>
|
|
<li> long& </li>
|
|
<li> unsigned short& </li>
|
|
<li> unsigned int& </li>
|
|
<li> unsigned long& </li>
|
|
<li> float& </li>
|
|
<li> double& </li>
|
|
<li> long double& </li>
|
|
<li> void*& </li>
|
|
</ul>
|
|
|
|
<p>
|
|
These two lists are not identical. They should be, since
|
|
<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
|
|
the arguments it was given.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
|
|
<pre>
|
|
iter_type get(iter_type in, iter_type end, ios_base& str,
|
|
ios_base::iostate& err, short& val) const;
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
iter_type get(iter_type in, iter_type end, ios_base& str,
|
|
ios_base::iostate& err, float& val) const;
|
|
</pre>
|
|
<hr>
|
|
<a name="276"><h3>276. Assignable requirement for container value type overly strict</h3></a><p>
|
|
<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 07 Nov 2000</p>
|
|
<p>
|
|
23.1/3 states that the objects stored in a container must be
|
|
Assignable. 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
|
|
states that map satisfies all requirements for a container, while in
|
|
the same time defining value_type as pair<const Key, T> - a type
|
|
that is not Assignable.
|
|
</p>
|
|
|
|
<p>
|
|
It should be noted that there exists a valid and non-contradictory
|
|
interpretation of the current text. The wording in 23.1/3 avoids
|
|
mentioning value_type, referring instead to "objects stored in a
|
|
container." One might argue that map does not store objects of
|
|
type map::value_type, but of map::mapped_type instead, and that the
|
|
Assignable requirement applies to map::mapped_type, not
|
|
map::value_type.
|
|
</p>
|
|
|
|
<p>
|
|
However, this makes map a special case (other containers store objects of
|
|
type value_type) and the Assignable requirement is needlessly restrictive in
|
|
general.
|
|
</p>
|
|
|
|
<p>
|
|
For example, the proposed resolution of active library issue
|
|
<a href="lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
|
|
means that no set operations can exploit the fact that the stored
|
|
objects are Assignable.
|
|
</p>
|
|
|
|
<p>
|
|
This is related to, but slightly broader than, closed issue
|
|
<a href="lwg-closed.html#140">140</a>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>23.1/3: Strike the trailing part of the sentence:</p>
|
|
<blockquote>
|
|
, and the additional requirements of Assignable types from 23.1/3
|
|
</blockquote>
|
|
<p>so that it reads:</p>
|
|
<blockquote>
|
|
-3- The type of objects stored in these components must meet the
|
|
requirements of CopyConstructible types (lib.copyconstructible).
|
|
</blockquote>
|
|
|
|
<p>23.1/4: Modify to make clear that this requirement is not for all
|
|
containers. Change to:</p>
|
|
|
|
<blockquote>
|
|
-4- Table 64 defines the Assignable requirement. Some containers
|
|
require this property of the types to be stored in the container. T is
|
|
the type used to instantiate the container. t is a value of T, and u is
|
|
a value of (possibly const) T.
|
|
</blockquote>
|
|
|
|
<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
|
|
CopyConstructible".</p>
|
|
|
|
<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p>
|
|
|
|
<blockquote>
|
|
-2- A deque satisfies all of the requirements of a container and of a
|
|
reversible container (given in tables in lib.container.requirements) and
|
|
of a sequence, including the optional sequence requirements
|
|
(lib.sequence.reqmts). In addition to the requirements on the stored
|
|
object described in 23.1[lib.container.requirements], the stored object
|
|
must also meet the requirements of Assignable. Descriptions are
|
|
provided here only for operations on deque that are not described in one
|
|
of these tables or for operations where there is additional semantic
|
|
information.
|
|
</blockquote>
|
|
|
|
<p>23.2.2/2: Add Assignable requirement to specific methods of list.
|
|
Change to:</p>
|
|
|
|
<blockquote>
|
|
<p>-2- A list satisfies all of the requirements of a container and of a
|
|
reversible container (given in two tables in lib.container.requirements)
|
|
and of a sequence, including most of the the optional sequence
|
|
requirements (lib.sequence.reqmts). The exceptions are the operator[]
|
|
and at member functions, which are not provided.
|
|
|
|
[Footnote: These member functions are only provided by containers whose
|
|
iterators are random access iterators. --- end foonote]
|
|
</p>
|
|
|
|
<p>list does not require the stored type T to be Assignable unless the
|
|
following methods are instantiated:
|
|
|
|
[Footnote: Implementors are permitted but not required to take advantage
|
|
of T's Assignable properties for these methods. -- end foonote]
|
|
</p>
|
|
<pre>
|
|
list<T,Allocator>& operator=(const list<T,Allocator>& x );
|
|
template <class InputIterator>
|
|
void assign(InputIterator first, InputIterator last);
|
|
void assign(size_type n, const T& t);
|
|
</pre>
|
|
|
|
|
|
<p>Descriptions are provided here only for operations on list that are not
|
|
described in one of these tables or for operations where there is
|
|
additional semantic information.</p>
|
|
</blockquote>
|
|
|
|
<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p>
|
|
|
|
<blockquote>
|
|
-2- A vector satisfies all of the requirements of a container and of a
|
|
reversible container (given in two tables in lib.container.requirements)
|
|
and of a sequence, including most of the optional sequence requirements
|
|
(lib.sequence.reqmts). The exceptions are the push_front and pop_front
|
|
member functions, which are not provided. In addition to the
|
|
requirements on the stored object described in
|
|
23.1[lib.container.requirements], the stored object must also meet the
|
|
requirements of Assignable. Descriptions are provided here only for
|
|
operations on vector that are not described in one of these tables or
|
|
for operations where there is additional semantic information.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>list, set, multiset, map, multimap are able to store non-Assignables.
|
|
However, there is some concern about <tt>list<T></tt>:
|
|
although in general there's no reason for T to be Assignable, some
|
|
implementations of the member functions <tt>operator=</tt> and
|
|
<tt>assign</tt> do rely on that requirement. The LWG does not want
|
|
to forbid such implementations.</p>
|
|
|
|
<p>Note that the type stored in a standard container must still satisfy
|
|
the requirements of the container's allocator; this rules out, for
|
|
example, such types as "const int". See issue <a href="lwg-defects.html#274">274</a>
|
|
for more details.
|
|
</p>
|
|
|
|
<p>In principle we could also relax the "Assignable" requirement for
|
|
individual <tt>vector</tt> member functions, such as
|
|
<tt>push_back</tt>. However, the LWG did not see great value in such
|
|
selective relaxation. Doing so would remove implementors' freedom to
|
|
implement <tt>vector::push_back</tt> in terms of
|
|
<tt>vector::insert</tt>.</p>
|
|
|
|
<hr>
|
|
<a name="281"><h3>281. std::min() and max() requirements overly restrictive</h3></a><p>
|
|
<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Dec 2000</p>
|
|
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
|
|
requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
|
|
and <tt>CopyConstructible</tt> (20.1.3 <a href="lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
|
|
Since the functions take and return their arguments and result by
|
|
const reference, I believe the <tt>CopyConstructible</tt> requirement
|
|
is unnecessary.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
|
|
25.3.7, p1 with</p>
|
|
<p>
|
|
<b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
|
|
(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
|
|
</p>
|
|
<p>and replace 25.3.7, p4 with</p>
|
|
<p>
|
|
<b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
|
|
(20.1.2 <a href="lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
|
|
</p>
|
|
<hr>
|
|
<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p>
|
|
<b>Section:</b> 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 26 Dec 2000</p>
|
|
<p>The example in 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
|
|
library function <tt>strcmp()</tt> with the function pointer adapter
|
|
<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
|
|
functions have <tt>extern "C"</tt> or <tt>extern
|
|
"C++"</tt> linkage [17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
|
|
function pointers with different the language linkage specifications
|
|
(7.5 <a href="dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
|
|
well-formed is unspecified.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 20.3.7 <a href="lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
|
|
<blockquote>
|
|
<p>[<i>Example:</i>
|
|
</p>
|
|
<pre>
|
|
replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
|
|
</pre>
|
|
<p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
|
|
</blockquote>
|
|
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>[<i>Example:</i>
|
|
</p>
|
|
<pre>
|
|
int compare(const char*, const char*);
|
|
replace_if(v.begin(), v.end(),
|
|
not1(bind2nd(ptr_fun(compare), "abc")), "def");
|
|
</pre>
|
|
<p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
|
|
</blockquote>
|
|
|
|
<p>Also, remove footnote 215 in that same paragraph.</p>
|
|
|
|
<p><i>[Copenhagen: Minor change in the proposed resolution. Since this
|
|
issue deals in part with C and C++ linkage, it was believed to be too
|
|
confusing for the strings in the example to be "C" and "C++".
|
|
]</i></p>
|
|
|
|
<p><i>[Redmond: More minor changes. Got rid of the footnote (which
|
|
seems to make a sweeping normative requirement, even though footnotes
|
|
aren't normative), and changed the sentence after the footnote so that
|
|
it corresponds to the new code fragment.]</i></p>
|
|
|
|
<hr>
|
|
<a name="285"><h3>285. minor editorial errors in fstream ctors</h3></a><p>
|
|
<b>Section:</b> 27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 31 Dec 2000</p>
|
|
<p>27.8.1.6 <a href="lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
|
|
27.8.1.12 <a href="lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
|
|
</p>
|
|
|
|
<p>... If that function returns a null pointer, calls
|
|
<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
|
|
</p>
|
|
|
|
<p>The parenthetical note doesn't apply since the ctors cannot throw an
|
|
exception due to the requirement in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
|
|
that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Strike the parenthetical note from the Effects clause in each of the
|
|
paragraphs mentioned above.
|
|
</p>
|
|
<hr>
|
|
<a name="286"><h3>286. <cstdlib> requirements missing size_t typedef</h3></a><p>
|
|
<b>Section:</b> 25.4 <a href="lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
|
|
<p>
|
|
The <cstdlib> header file contains prototypes for bsearch and
|
|
qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
|
|
prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
|
|
require the typedef size_t. Yet size_t is not listed in the
|
|
<cstdlib> synopsis table 78 in section 25.4.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add the type size_t to Table 78 (section 25.4) and add
|
|
the type size_t <cstdlib> to Table 97 (section C.2).
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p>
|
|
<hr>
|
|
<a name="288"><h3>288. <cerrno> requirements missing macro EILSEQ</h3></a><p>
|
|
<b>Section:</b> 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
|
|
<p>
|
|
ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
|
|
of macros defined in <errno.h> is adjusted to include a new
|
|
macro, EILSEQ"
|
|
</p>
|
|
|
|
<p>
|
|
ISO/IEC 14882:1998(E) section 19.3 does not refer
|
|
to the above amendment.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Update Table 26 (section 19.3) "Header <cerrno> synopsis"
|
|
and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
|
|
</p>
|
|
<hr>
|
|
<a name="292"><h3>292. effects of a.copyfmt (a)</h3></a><p>
|
|
<b>Section:</b> 27.4.4.2 <a href="lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jan 2001</p>
|
|
<p>The Effects clause of the member function <tt>copyfmt()</tt> in
|
|
27.4.4.2, p15 doesn't consider the case where the left-hand side
|
|
argument is identical to the argument on the right-hand side, that is
|
|
<tt>(this == &rhs)</tt>. If the two arguments are identical there
|
|
is no need to copy any of the data members or call any callbacks
|
|
registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
|
|
points out in message c++std-lib-8149 it appears to be incorrect to
|
|
allow the object to fire <tt>erase_event</tt> followed by
|
|
<tt>copyfmt_event</tt> since the callback handling the latter event
|
|
may inadvertently attempt to access memory freed by the former.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the Effects clause in 27.4.4.2, p15 from</p>
|
|
|
|
<blockquote>
|
|
<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
|
|
the corresponding member objects of <tt>rhs</tt>, except that...
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise
|
|
assigns to the member objects of <tt>*this</tt> the corresponding member
|
|
objects of <tt>rhs</tt>, except that...
|
|
</blockquote>
|
|
<hr>
|
|
<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p>
|
|
<b>Section:</b> 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p>
|
|
<p>
|
|
Table 80 lists the contents of the <cmath> header. It does not
|
|
list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
|
|
signatures present in <cmath>, does say that several overloads
|
|
of <tt>abs()</tt> should be defined in <cmath>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
|
|
of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
|
|
paragraph 1.
|
|
</p>
|
|
|
|
<p><i>[Copenhagen: Modified proposed resolution so that it also gets
|
|
rid of that vestigial list of functions in paragraph 1.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>All this DR does is fix a typo; it's uncontroversial. A
|
|
separate question is whether we're doing the right thing in
|
|
putting some overloads in <cmath> that we aren't also
|
|
putting in <cstdlib>. That's issue <a href="lwg-active.html#323">323</a>.</p>
|
|
<hr>
|
|
<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p>
|
|
<b>Section:</b> 20.3.8 <a href="lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Jan 2001</p>
|
|
<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
|
|
<tt>const_mem_fun1_t</tt>
|
|
in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and
|
|
<tt>binary_function<T*,
|
|
A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and
|
|
<tt>first_argument_type</tt>
|
|
members, respectively, are both defined to be <tt>T*</tt> (non-const).
|
|
However, their function call member operator takes a <tt>const T*</tt>
|
|
argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
|
|
T*</tt> instead, so that one can easily refer to it in generic code. The
|
|
example below derived from existing code fails to compile due to the
|
|
discrepancy:
|
|
</p>
|
|
|
|
<p>
|
|
<tt>template <class T></tt>
|
|
<br><tt>void foo (typename T::argument_type arg) // #1</tt>
|
|
<br><tt>{</tt>
|
|
<br><tt> typename T::result_type (T::*pf) (typename
|
|
T::argument_type)
|
|
const = // #2</tt>
|
|
<br><tt> &T::operator();</tt>
|
|
<br><tt>}</tt>
|
|
</p>
|
|
|
|
<p><tt>struct X { /* ... */ };</tt></p>
|
|
|
|
<p>
|
|
<tt>int main ()</tt>
|
|
<br><tt>{</tt>
|
|
<br><tt> const X x;</tt>
|
|
<br><tt> foo<std::const_mem_fun_t<void, X>
|
|
>(&x);
|
|
// #3</tt>
|
|
<br><tt>}</tt>
|
|
</p>
|
|
|
|
<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
|
|
<br>#2 the type of the pointer is incompatible with the type of the member
|
|
function
|
|
<br>#3 the address of a constant being passed to a function taking a non-const
|
|
<tt>X*</tt>
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the top portion of the definition of the class template
|
|
const_mem_fun_t in 20.3.8, p8
|
|
</p>
|
|
<p>
|
|
<tt>template <class S, class T> class const_mem_fun_t</tt>
|
|
<br><tt> : public
|
|
unary_function<T*, S> {</tt>
|
|
</p>
|
|
<p>with</p>
|
|
<p>
|
|
<tt>template <class S, class T> class const_mem_fun_t</tt>
|
|
<br><tt> : public
|
|
unary_function<<b>const</b> T*, S> {</tt>
|
|
</p>
|
|
<p>Also replace the top portion of the definition of the class template
|
|
const_mem_fun1_t in 20.3.8, p9</p>
|
|
<p>
|
|
<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
|
|
<br><tt> : public
|
|
binary_function<T*, A, S> {</tt>
|
|
</p>
|
|
<p>with</p>
|
|
<p>
|
|
<tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
|
|
<br><tt> : public
|
|
binary_function<<b>const</b> T*, A, S> {</tt>
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
|
|
and the argument type itself, are not the same.</p>
|
|
<hr>
|
|
<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p>
|
|
<b>Section:</b> 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p>
|
|
<p>
|
|
The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
|
|
namely that for non-null value of <i>ptr</i>, the operator reclaims storage
|
|
allocated by the earlier call to the default <tt>operator new[]</tt> - is not
|
|
correct in all cases. Since the specified <tt>operator new[]</tt> default
|
|
behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
|
|
replaced, along with <tt>operator delete</tt>, by the user, to implement their
|
|
own memory management, the specified default behavior of<tt> operator
|
|
delete[]</tt> must be to call <tt>operator delete</tt>.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 18.4.1.2, p12 from</p>
|
|
<blockquote>
|
|
<b>-12-</b> <b>Default behavior:</b>
|
|
<ul>
|
|
<li>
|
|
For a null value of <i><tt>ptr</tt></i> , does nothing.
|
|
</li>
|
|
<li>
|
|
Any other value of <i><tt>ptr</tt></i> shall be a value returned
|
|
earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
|
|
[Footnote: The value must not have been invalidated by an intervening
|
|
call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
|
|
--- end footnote]
|
|
For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
|
|
allocated by the earlier call to the default <tt>operator new[]</tt>.
|
|
</li>
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
|
|
delete(</tt><i>ptr</i>)
|
|
or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
|
|
</blockquote>
|
|
<p>and expunge paragraph 13.</p>
|
|
<hr>
|
|
<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p>
|
|
<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p>
|
|
<p>
|
|
The effects clause for the basic_string template ctor in 21.3.1, p15
|
|
leaves out the third argument of type Allocator. I believe this to be
|
|
a mistake.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
|
|
type, equivalent to</p>
|
|
|
|
<blockquote><tt>basic_string(static_cast<size_type>(begin),
|
|
static_cast<value_type>(end))</tt></blockquote>
|
|
</blockquote>
|
|
|
|
<p>with</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
|
|
type, equivalent to</p>
|
|
|
|
<blockquote><tt>basic_string(static_cast<size_type>(begin),
|
|
static_cast<value_type>(end), <b>a</b>)</tt></blockquote>
|
|
</blockquote>
|
|
<hr>
|
|
<a name="303"><h3>303. Bitset input operator underspecified</h3></a><p>
|
|
<b>Section:</b> 23.3.5.3 <a href="lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Feb 2001</p>
|
|
<p>
|
|
In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
|
|
"Extracts up to <i>N</i> (single-byte) characters from
|
|
<i>is</i>.", where <i>is</i> is a stream of type
|
|
<tt>basic_istream<charT, traits></tt>.
|
|
</p>
|
|
|
|
<p>
|
|
The standard does not say what it means to extract single byte
|
|
characters from a stream whose character type, <tt>charT</tt>, is in
|
|
general not a single-byte character type. Existing implementations
|
|
differ.
|
|
</p>
|
|
|
|
<p>
|
|
A reasonable solution will probably involve <tt>widen()</tt> and/or
|
|
<tt>narrow()</tt>, since they are the supplied mechanism for
|
|
converting a single character between <tt>char</tt> and
|
|
arbitrary <tt>charT</tt>.
|
|
</p>
|
|
|
|
<p>Narrowing the input characters is not the same as widening the
|
|
literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
|
|
locales in which more than one wide character maps to the narrow
|
|
character <tt>'0'</tt>. Narrowing means that alternate
|
|
representations may be used for bitset input, widening means that
|
|
they may not be.</p>
|
|
|
|
<p>Note that for numeric input, <tt>num_get<></tt>
|
|
(22.2.2.1.2/8) compares input characters to widened version of narrow
|
|
character literals.</p>
|
|
|
|
<p>From Pete Becker, in c++std-lib-8224:</p>
|
|
<blockquote>
|
|
<p>
|
|
Different writing systems can have different representations for the
|
|
digits that represent 0 and 1. For example, in the Unicode representation
|
|
of the Devanagari script (used in many of the Indic languages) the digit 0
|
|
is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
|
|
into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
|
|
0x0031 for for the Latin representations of '0' and '1', as well as code
|
|
points for the same numeric values in several other scripts (Tamil has no
|
|
character for 0, but does have the digits 1-9), and any of these values
|
|
would also be narrowed to '0' and '1'.
|
|
</p>
|
|
|
|
<p>...</p>
|
|
|
|
<p>
|
|
It's fairly common to intermix both native and Latin
|
|
representations of numbers in a document. So I think the rule has to be
|
|
that if a wide character represents a digit whose value is 0 then the bit
|
|
should be cleared; if it represents a digit whose value is 1 then the bit
|
|
should be set; otherwise throw an exception. So in a Devanagari locale,
|
|
both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
|
|
would set it. Widen can't do that. It would pick one of those two values,
|
|
and exclude the other one.
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>From Jens Maurer, in c++std-lib-8233:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
Whatever we decide, I would find it most surprising if
|
|
bitset conversion worked differently from int conversion
|
|
with regard to alternate local representations of
|
|
numbers.
|
|
</p>
|
|
|
|
<p>Thus, I think the options are:</p>
|
|
<ul>
|
|
<li> Have a new defect issue for 22.2.2.1.2/8 so that it will
|
|
require the use of narrow().</li>
|
|
|
|
<li> Have a defect issue for bitset() which describes clearly
|
|
that widen() is to be used.</li>
|
|
</ul>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Replace the first two sentences of paragraph 5 with:</p>
|
|
|
|
<blockquote>
|
|
Extracts up to <i>N</i> characters from <i>is</i>. Stores these
|
|
characters in a temporary object <i>str</i> of type
|
|
<tt>basic_string<charT, traits></tt>, then evaluates the
|
|
expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>.
|
|
</blockquote>
|
|
|
|
<p>Replace the third bullet item in paragraph 5 with:</p>
|
|
<ul><li>
|
|
the next input character is neither <tt><i>is</i>.widen(0)</tt>
|
|
nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
|
|
is not extracted).
|
|
</li></ul>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>Input for <tt>bitset</tt> should work the same way as numeric
|
|
input. Using <tt>widen</tt> does mean that alternative digit
|
|
representations will not be recognized, but this was a known
|
|
consequence of the design choice.</p>
|
|
<hr>
|
|
<a name="306"><h3>306. offsetof macro and non-POD types</h3></a><p>
|
|
<b>Section:</b> 18.1 <a href="lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Feb 2001</p>
|
|
<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
|
|
|
|
<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
|
|
accepts a restricted set of <i>type</i> arguments in this
|
|
International Standard. <i>type</i> shall be a POD structure or a POD
|
|
union (clause 9). The result of applying the offsetof macro to a field
|
|
that is a static data member or a function member is
|
|
undefined."</p>
|
|
|
|
<p>For the POD requirement, it doesn't say "no diagnostic
|
|
required" or "undefined behavior". I read 1.4 <a href="intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
|
|
It's not clear whether this requirement was intended. While it's
|
|
possible to provide such a diagnostic, the extra complication doesn't
|
|
seem to add any value.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
|
|
structure or a POD union the results are undefined."</p>
|
|
|
|
<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
|
|
agreed that requiring a diagnostic was inadvertent, but some LWG
|
|
members thought that diagnostics should be required whenever
|
|
possible.]</i></p>
|
|
|
|
<hr>
|
|
<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p>
|
|
<b>Section:</b> 23.2.3 <a href="lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p>
|
|
|
|
<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
|
|
|
|
<p>
|
|
The standard is currently inconsistent in 23.2.3.2 <a href="lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
|
|
paragraph 1 and 23.2.3.3 <a href="lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
|
|
23.2.3.3/1, for example, says:
|
|
</p>
|
|
|
|
<blockquote>
|
|
-1- Any sequence supporting operations back(), push_back() and pop_back()
|
|
can be used to instantiate stack. In particular, vector (lib.vector), list
|
|
(lib.list) and deque (lib.deque) can be used.
|
|
</blockquote>
|
|
|
|
<p>But this is false: vector<bool> can not be used, because the
|
|
container adaptors return a T& rather than using the underlying
|
|
container's reference type.</p>
|
|
|
|
<p>This is a contradiction that can be fixed by:</p>
|
|
|
|
<ol>
|
|
<li>Modifying these paragraphs to say that vector<bool>
|
|
is an exception.</li>
|
|
<li>Removing the vector<bool> specialization.</li>
|
|
<li>Changing the return types of stack and priority_queue to use
|
|
reference typedef's.</li>
|
|
</ol>
|
|
|
|
<p>
|
|
I propose 3. This does not preclude option 2 if we choose to do it
|
|
later (see issue <a href="lwg-active.html#96">96</a>); the issues are independent. Option
|
|
3 offers a small step towards support for proxied containers. This
|
|
small step fixes a current contradiction, is easy for vendors to
|
|
implement, is already implemented in at least one popular lib, and
|
|
does not break any code.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Summary: Add reference and const_reference typedefs to queue,
|
|
priority_queue and stack. Change return types of "value_type&" to
|
|
"reference". Change return types of "const value_type&" to
|
|
"const_reference". Details:</p>
|
|
|
|
<p>Change 23.2.3.1/1 from:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = deque<T> >
|
|
class queue {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
|
|
public:
|
|
explicit queue(const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
value_type& front() { return c.front(); }
|
|
const value_type& front() const { return c.front(); }
|
|
value_type& back() { return c.back(); }
|
|
const value_type& back() const { return c.back(); }
|
|
void push(const value_type& x) { c.push_back(x); }
|
|
void pop() { c.pop_front(); }
|
|
};
|
|
</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = deque<T> >
|
|
class queue {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::reference reference;
|
|
typedef typename Container::const_reference const_reference;
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
|
|
public:
|
|
explicit queue(const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
reference front() { return c.front(); }
|
|
const_reference front() const { return c.front(); }
|
|
reference back() { return c.back(); }
|
|
const_reference back() const { return c.back(); }
|
|
void push(const value_type& x) { c.push_back(x); }
|
|
void pop() { c.pop_front(); }
|
|
};
|
|
</pre>
|
|
|
|
<p>Change 23.2.3.2/1 from:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = vector<T>,
|
|
class Compare = less<typename Container::value_type> >
|
|
class priority_queue {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
Compare comp;
|
|
|
|
public:
|
|
explicit priority_queue(const Compare& x = Compare(),
|
|
const Container& = Container());
|
|
template <class InputIterator>
|
|
priority_queue(InputIterator first, InputIterator last,
|
|
const Compare& x = Compare(),
|
|
const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
const value_type& top() const { return c.front(); }
|
|
void push(const value_type& x);
|
|
void pop();
|
|
};
|
|
// no equality is provided
|
|
}
|
|
</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = vector<T>,
|
|
class Compare = less<typename Container::value_type> >
|
|
class priority_queue {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::reference reference;
|
|
typedef typename Container::const_reference const_reference;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
Compare comp;
|
|
|
|
public:
|
|
explicit priority_queue(const Compare& x = Compare(),
|
|
const Container& = Container());
|
|
template <class InputIterator>
|
|
priority_queue(InputIterator first, InputIterator last,
|
|
const Compare& x = Compare(),
|
|
const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
const_reference top() const { return c.front(); }
|
|
void push(const value_type& x);
|
|
void pop();
|
|
};
|
|
// no equality is provided
|
|
}
|
|
</pre>
|
|
|
|
<p>And change 23.2.3.3/1 from:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = deque<T> >
|
|
class stack {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
|
|
public:
|
|
explicit stack(const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
value_type& top() { return c.back(); }
|
|
const value_type& top() const { return c.back(); }
|
|
void push(const value_type& x) { c.push_back(x); }
|
|
void pop() { c.pop_back(); }
|
|
};
|
|
|
|
template <class T, class Container>
|
|
bool operator==(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator< (const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator!=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator> (const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator>=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator<=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
}
|
|
</pre>
|
|
|
|
<p>to:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class T, class Container = deque<T> >
|
|
class stack {
|
|
public:
|
|
typedef typename Container::value_type value_type;
|
|
typedef typename Container::reference reference;
|
|
typedef typename Container::const_reference const_reference;
|
|
typedef typename Container::size_type size_type;
|
|
typedef Container container_type;
|
|
protected:
|
|
Container c;
|
|
|
|
public:
|
|
explicit stack(const Container& = Container());
|
|
|
|
bool empty() const { return c.empty(); }
|
|
size_type size() const { return c.size(); }
|
|
reference top() { return c.back(); }
|
|
const_reference top() const { return c.back(); }
|
|
void push(const value_type& x) { c.push_back(x); }
|
|
void pop() { c.pop_back(); }
|
|
};
|
|
|
|
template <class T, class Container>
|
|
bool operator==(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator< (const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator!=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator> (const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator>=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
template <class T, class Container>
|
|
bool operator<=(const stack<T, Container>& x,
|
|
const stack<T, Container>& y);
|
|
}
|
|
</pre>
|
|
|
|
<p><i>[Copenhagen: This change was discussed before the IS was released
|
|
and it was deliberately not adopted. Nevertheless, the LWG believes
|
|
(straw poll: 10-2) that it is a genuine defect.]</i></p>
|
|
|
|
<hr>
|
|
<a name="308"><h3>308. Table 82 mentions unrelated headers</h3></a><p>
|
|
<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Mar 2001</p>
|
|
<p>
|
|
Table 82 in section 27 mentions the header <cstdlib> for String
|
|
streams (27.7 <a href="lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers <cstdio> and
|
|
<cwchar> for File streams (27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
|
|
why these headers are mentioned in this context since they do not
|
|
define any of the library entities described by the
|
|
subclauses. According to 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
|
|
are to be listed in the summary.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove <cstdlib> and <cwchar> from
|
|
Table 82.</p>
|
|
|
|
<p><i>[Copenhagen: changed the proposed resolution slightly. The
|
|
original proposed resolution also said to remove <cstdio> from
|
|
Table 82. However, <cstdio> is mentioned several times within
|
|
section 27.8 <a href="lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
|
|
|
|
<hr>
|
|
<a name="310"><h3>310. Is errno a macro?</h3></a><p>
|
|
<b>Section:</b> 17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</p>
|
|
<p>
|
|
Exactly how should errno be declared in a conforming C++ header?
|
|
</p>
|
|
|
|
<p>
|
|
The C standard says in 7.1.4 that it is unspecified whether errno is a
|
|
macro or an identifier with external linkage. In some implementations
|
|
it can be either, depending on compile-time options. (E.g., on
|
|
Solaris in multi-threading mode, errno is a macro that expands to a
|
|
function call, but is an extern int otherwise. "Unspecified" allows
|
|
such variability.)
|
|
</p>
|
|
|
|
<p>The C++ standard:</p>
|
|
<ul>
|
|
<li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
|
|
<li>17.4.3.1.3 footnote 166 says errno is reserved as an external
|
|
name (true), and implies that it is an identifier.</li>
|
|
<li>19.3 simply lists errno as a macro (by what reasoning?) and goes
|
|
on to say that the contents of of C++ <errno.h> are the
|
|
same as in C, begging the question.</li>
|
|
<li>C.2, table 95 lists errno as a macro, without comment.</li>
|
|
</ul>
|
|
|
|
<p>I find no other references to errno.</p>
|
|
|
|
<p>We should either explicitly say that errno must be a macro, even
|
|
though it need not be a macro in C, or else explicitly leave it
|
|
unspecified. We also need to say something about namespace std.
|
|
A user who includes <cerrno> needs to know whether to write
|
|
<tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
|
|
else <cerrno> is useless.</p>
|
|
|
|
<p>Two acceptable fixes:</p>
|
|
<ul>
|
|
<li><p>errno must be a macro. This is trivially satisfied by adding<br>
|
|
#define errno (::std::errno)<br>
|
|
to the headers if errno is not already a macro. You then always
|
|
write errno without any scope qualification, and it always expands
|
|
to a correct reference. Since it is always a macro, you know to
|
|
avoid using errno as a local identifer.</p></li>
|
|
<li><p>errno is in the global namespace. This fix is inferior, because
|
|
::errno is not guaranteed to be well-formed.</p></li>
|
|
</ul>
|
|
|
|
<p><i>[
|
|
This issue was first raised in 1999, but it slipped through
|
|
the cracks.
|
|
]</i></p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the Note in section 17.4.1.2p5 from</p>
|
|
|
|
<blockquote>
|
|
Note: the names defined as macros in C include the following:
|
|
assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Note: the names defined as macros in C include the following:
|
|
assert, offsetof, setjmp, va_arg, va_end, and va_start.
|
|
</blockquote>
|
|
|
|
<p>In section 19.3, change paragraph 2 from</p>
|
|
|
|
<blockquote>
|
|
The contents are the same as the Standard C library header
|
|
<errno.h>.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
The contents are the same as the Standard C library header
|
|
<errno.h>, except that errno shall be defined as a macro.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>C++ must not leave it up to the implementation to decide whether or
|
|
not a name is a macro; it must explicitly specify exactly which names
|
|
are required to be macros. The only one that really works is for it
|
|
to be a macro.</p>
|
|
|
|
<p><i>[Curaçao: additional rationale added.]</i></p>
|
|
|
|
<hr>
|
|
<a name="311"><h3>311. Incorrect wording in basic_ostream class synopsis</h3></a><p>
|
|
<b>Section:</b> 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Mar 2001</p>
|
|
|
|
<p>In 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
|
|
|
|
<pre>
|
|
// partial specializationss
|
|
template<class traits>
|
|
basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
|
|
const char * );
|
|
</pre>
|
|
|
|
<p>Problems:</p>
|
|
<ul>
|
|
<li>Too many 's's at the end of "specializationss" </li>
|
|
<li>This is an overload, not a partial specialization</li>
|
|
</ul>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In the synopsis in 27.6.2.1 <a href="lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
|
|
<i>// partial specializationss</i> comment. Also remove the same
|
|
comment (correctly spelled, but still incorrect) from the synopsis in
|
|
27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Pre-Redmond: added 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
|
|
comment in c++std-lib-8939.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="312"><h3>312. Table 27 is missing headers</h3></a><p>
|
|
<b>Section:</b> 20 <a href="lib-utilities.html#lib.utilities"> [lib.utilities]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Mar 2001</p>
|
|
<p>Table 27 in section 20 lists the header <memory> (only) for
|
|
Memory (lib.memory) but neglects to mention the headers
|
|
<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add <cstdlib> and <cstring> to Table 27, in the same row
|
|
as <memory>.</p>
|
|
<hr>
|
|
<a name="315"><h3>315. Bad "range" in list::unique complexity</h3></a><p>
|
|
<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p>
|
|
<p>
|
|
23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
|
|
list::unique as: "If the range (last - first) is not empty, exactly
|
|
(last - first) -1 applications of the corresponding predicate,
|
|
otherwise no applications of the predicate)".
|
|
</p>
|
|
|
|
<p>
|
|
"(last - first)" is not a range.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the "range" from (last - first) to [first, last).
|
|
</p>
|
|
<hr>
|
|
<a name="316"><h3>316. Vague text in Table 69</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p>
|
|
<p>Table 69 says this about a_uniq.insert(t):</p>
|
|
|
|
<blockquote>
|
|
inserts t if and only if there is no element in the container with key
|
|
equivalent to the key of t. The bool component of the returned pair
|
|
indicates whether the insertion takes place and the iterator component of the
|
|
pair points to the element with key equivalent to the key of t.
|
|
</blockquote>
|
|
|
|
<p>The description should be more specific about exactly how the bool component
|
|
indicates whether the insertion takes place.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the text in question to</p>
|
|
|
|
<blockquote>
|
|
...The bool component of the returned pair is true if and only if the insertion
|
|
takes place...
|
|
</blockquote>
|
|
<hr>
|
|
<a name="317"><h3>317. Instantiation vs. specialization of facets</h3></a><p>
|
|
<b>Section:</b> 22 <a href="lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p>
|
|
<p>
|
|
The localization section of the standard refers to specializations of
|
|
the facet templates as instantiations even though the required facets
|
|
are typically specialized rather than explicitly (or implicitly)
|
|
instantiated. In the case of ctype<char> and
|
|
ctype_byname<char> (and the wchar_t versions), these facets are
|
|
actually required to be specialized. The terminology should be
|
|
corrected to make it clear that the standard doesn't mandate explicit
|
|
instantiation (the term specialization encompasses both explicit
|
|
instantiations and specializations).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In the following paragraphs, replace all occurrences of the word
|
|
instantiation or instantiations with specialization or specializations,
|
|
respectively:
|
|
</p>
|
|
|
|
<blockquote>
|
|
22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
|
|
22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
|
|
22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
|
|
Footnote 242.
|
|
</blockquote>
|
|
|
|
<p>And change the text in 22.1.1.1.1, p4 from</p>
|
|
|
|
<blockquote>
|
|
An implementation is required to provide those instantiations
|
|
for facet templates identified as members of a category, and
|
|
for those shown in Table 52:
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
An implementation is required to provide those specializations...
|
|
</blockquote>
|
|
|
|
<p><i>[Nathan will review these changes, and will look for places where
|
|
explicit specialization is necessary.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>This is a simple matter of outdated language. The language to
|
|
describe templates was clarified during the standardization process,
|
|
but the wording in clause 22 was never updated to reflect that
|
|
change.</p>
|
|
<hr>
|
|
<a name="318"><h3>318. Misleading comment in definition of numpunct_byname</h3></a><p>
|
|
<b>Section:</b> 22.2.3.2 <a href="lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 May 2001</p>
|
|
<p>The definition of the numpunct_byname template contains the following
|
|
comment:</p>
|
|
|
|
<pre>
|
|
namespace std {
|
|
template <class charT>
|
|
class numpunct_byname : public numpunct<charT> {
|
|
// this class is specialized for char and wchar_t.
|
|
...
|
|
</pre>
|
|
|
|
<p>There is no documentation of the specializations and it seems
|
|
conceivable that an implementation will not explicitly specialize the
|
|
template at all, but simply provide the primary template.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the comment from the text in 22.2.3.2 and from the proposed
|
|
resolution of library issue <a href="lwg-defects.html#228">228</a>.</p>
|
|
<hr>
|
|
<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p>
|
|
<b>Section:</b> 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p>
|
|
<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
|
|
behavior" elements describe "the semantics of a function definition
|
|
provided by either the implementation or a C++ program."</p>
|
|
|
|
<p>The standard specifies 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
|
|
elements describe "the preconditions for calling the function."</p>
|
|
|
|
<p>In the sections noted below, the current wording specifies
|
|
"Required Behavior" for what are actually preconditions, and thus
|
|
should be specified as "Requires".</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>In 18.4.1.1 <a href="lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
|
|
<blockquote>
|
|
<p>Required behavior: accept a value of ptr that is null or that was
|
|
returned by an earlier call ...</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Requires: the value of ptr is null or the value returned by an
|
|
earlier call ...</p>
|
|
</blockquote>
|
|
|
|
<p>In 18.4.1.2 <a href="lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
|
|
<blockquote>
|
|
<p>Required behavior: accept a value of ptr that is null or that was
|
|
returned by an earlier call ...</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Requires: the value of ptr is null or the value returned by an
|
|
earlier call ...</p>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="321"><h3>321. Typo in num_get</h3></a><p>
|
|
<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Kevin Djang <b>Date:</b> 17 May 2001</p>
|
|
<p>
|
|
Section 22.2.2.1.2 at p7 states that "A length specifier is added to
|
|
the conversion function, if needed, as indicated in Table 56."
|
|
However, Table 56 uses the term "length modifier", not "length
|
|
specifier".
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
|
|
to be "A length modifier is added ..."
|
|
</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>C uses the term "length modifier". We should be consistent.</p>
|
|
<hr>
|
|
<a name="322"><h3>322. iterator and const_iterator should have the same value type</h3></a><p>
|
|
<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 17 May 2001</p>
|
|
<p>
|
|
It's widely assumed that, if X is a container,
|
|
iterator_traits<X::iterator>::value_type and
|
|
iterator_traits<X::const_iterator>::value_type should both be
|
|
X::value_type. However, this is nowhere stated. The language in
|
|
Table 65 is not precise about the iterators' value types (it predates
|
|
iterator_traits), and could even be interpreted as saying that
|
|
iterator_traits<X::const_iterator>::value_type should be "const
|
|
X::value_type".
|
|
</p>
|
|
|
|
<p>Related issue: <a href="lwg-closed.html#279">279</a>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In Table 65 ("Container Requirements"), change the return type for
|
|
X::iterator to "iterator type whose value type is T". Change the
|
|
return type for X::const_iterator to "constant iterator type whose
|
|
value type is T".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
This belongs as a container requirement, rather than an iterator
|
|
requirement, because the whole notion of iterator/const_iterator
|
|
pairs is specific to containers' iterator.
|
|
</p>
|
|
<p>
|
|
It is existing practice that (for example)
|
|
iterator_traits<list<int>::const_iterator>::value_type
|
|
is "int", rather than "const int". This is consistent with
|
|
the way that const pointers are handled: the standard already
|
|
requires that iterator_traits<const int*>::value_type is int.
|
|
</p>
|
|
<hr>
|
|
<a name="327"><h3>327. Typo in time_get facet in table 52</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Tiki Wan <b>Date:</b> 06 Jul 2001</p>
|
|
<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
|
|
<tt>time_get_byname</tt> are listed incorrectly in table 52,
|
|
required instantiations. In both cases the second template
|
|
parameter is given as OutputIterator. It should instead be
|
|
InputIterator, since these are input facets.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In table 52, required instantiations, in
|
|
22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
|
|
<pre>
|
|
time_get<wchar_t, OutputIterator>
|
|
time_get_byname<wchar_t, OutputIterator>
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
time_get<wchar_t, InputIterator>
|
|
time_get_byname<wchar_t, InputIterator>
|
|
</pre>
|
|
|
|
<p><i>[Redmond: Very minor change in proposed resolution. Original had
|
|
a typo, wchart instead of wchar_t.]</i></p>
|
|
|
|
<hr>
|
|
<a name="328"><h3>328. Bad sprintf format modifier in money_put<>::do_put()</h3></a><p>
|
|
<b>Section:</b> 22.2.6.2.2 <a href="lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 07 Jul 2001</p>
|
|
<p>The sprintf format string , "%.01f" (that's the digit one), in the
|
|
description of the do_put() member functions of the money_put facet in
|
|
22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
|
|
for values of type long double, and second, the precision of 01
|
|
doesn't seem to make sense. What was most likely intended was
|
|
"%.0Lf"., that is a precision of zero followed by the L length
|
|
modifier.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the format string to "%.0Lf".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Fixes an obvious typo</p>
|
|
<hr>
|
|
<a name="331"><h3>331. bad declaration of destructor for ios_base::failure</h3></a><p>
|
|
<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 23 Aug 2001</p>
|
|
<p>
|
|
With the change in 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
|
|
"An implementation may strengthen the exception-specification for a
|
|
non-virtual function by removing listed exceptions."
|
|
(issue <a href="lwg-defects.html#119">119</a>)
|
|
and the following declaration of ~failure() in ios_base::failure
|
|
</p>
|
|
<pre>
|
|
namespace std {
|
|
class ios_base::failure : public exception {
|
|
public:
|
|
...
|
|
virtual ~failure();
|
|
...
|
|
};
|
|
}
|
|
</pre>
|
|
<p>the class failure cannot be implemented since in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
|
|
exception specification:</p>
|
|
<pre>
|
|
namespace std {
|
|
class exception {
|
|
public:
|
|
...
|
|
virtual ~exception() throw();
|
|
...
|
|
};
|
|
}
|
|
</pre>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove the declaration of ~failure().</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The proposed resolution is consistent with the way that destructors
|
|
of other classes derived from <tt>exception</tt> are handled.</p>
|
|
<hr>
|
|
<a name="335"><h3>335. minor issue with char_traits, table 37</h3></a><p>
|
|
<b>Section:</b> 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 06 Sep 2001</p>
|
|
<p>
|
|
Table 37, in 21.1.1 <a href="lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
|
|
as:
|
|
</p>
|
|
<pre>
|
|
X::assign(c,d) assigns c = d.
|
|
</pre>
|
|
|
|
<p>And para 1 says:</p>
|
|
|
|
<blockquote>
|
|
[...] c and d denote values of type CharT [...]
|
|
</blockquote>
|
|
|
|
<p>
|
|
Naturally, if c and d are <i>values</i>, then the assignment is
|
|
(effectively) meaningless. It's clearly intended that (in the case of
|
|
assign, at least), 'c' is intended to be a reference type.
|
|
</p>
|
|
|
|
<p>I did a quick survey of the four implementations I happened to have
|
|
lying around, and sure enough they all have signatures:</p>
|
|
<pre>
|
|
assign( charT&, const charT& );
|
|
</pre>
|
|
|
|
<p>(or the equivalent). It's also described this way in Nico's book.
|
|
(Not to mention the synopses of char_traits<char> in 21.1.3.1
|
|
and char_traits<wchar_t> in 21.1.3.2...)
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following to 21.1.1 para 1:</p>
|
|
<blockquote>
|
|
r denotes an lvalue of CharT
|
|
</blockquote>
|
|
|
|
<p>and change the description of assign in the table to:</p>
|
|
<pre>
|
|
X::assign(r,d) assigns r = d
|
|
</pre>
|
|
<hr>
|
|
<a name="337"><h3>337. replace_copy_if's template parameter should be InputIterator</h3></a><p>
|
|
<b>Section:</b> 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 07 Sep 2001</p>
|
|
<p>From c++std-edit-876:</p>
|
|
|
|
<p>
|
|
In section 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
|
|
parameter of template replace_copy_if should be "InputIterator"
|
|
instead of "Iterator". According to 17.3.2.1 <a href="lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
|
|
parameter name conveys real normative meaning.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
|
|
<hr>
|
|
<a name="345"><h3>345. type tm in <cwchar></h3></a><p>
|
|
<b>Section:</b> 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Clark Nelson <b>Date:</b> 19 Oct 2001</p>
|
|
<p>
|
|
C99, and presumably amendment 1 to C90, specify that <wchar.h>
|
|
declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
|
|
<cwchar>. Is this omission intentional or accidental?
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In section 21.4 <a href="lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
|
|
<hr>
|
|
<a name="346"><h3>346. Some iterator member functions should be const</h3></a><p>
|
|
<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 20 Oct 2001</p>
|
|
<p>Iterator member functions and operators that do not change the state
|
|
of the iterator should be defined as const member functions or as
|
|
functions that take iterators either by const reference or by
|
|
value. The standard does not explicitly state which functions should
|
|
be const. Since this a fairly common mistake, the following changes
|
|
are suggested to make this explicit.</p>
|
|
|
|
<p>The tables almost indicate constness properly through naming: r
|
|
for non-const and a,b for const iterators. The following changes
|
|
make this more explicit and also fix a couple problems.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
|
|
"In the following sections, a and b denote values of X..." to
|
|
"In the following sections, a and b denote values of type const X...".</p>
|
|
|
|
<p>In Table 73, change</p>
|
|
<pre>
|
|
a->m U& ...
|
|
</pre>
|
|
|
|
<p>to</p>
|
|
|
|
<pre>
|
|
a->m const U& ...
|
|
r->m U& ...
|
|
</pre>
|
|
|
|
<p>In Table 73 expression column, change</p>
|
|
|
|
<pre>
|
|
*a = t
|
|
</pre>
|
|
|
|
<p>to</p>
|
|
|
|
<pre>
|
|
*r = t
|
|
</pre>
|
|
|
|
<p><i>[Redmond: The container requirements should be reviewed to see if
|
|
the same problem appears there.]</i></p>
|
|
|
|
<p>----- End of document -----</p>
|
|
</body>
|
|
</html>
|